-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(prefer-const): add rule #933
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 1b1b4f7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Since this rule logic has been adapted from the original I feel it's mandatory to also evaluate all the expected behaviour, not only what happens in |
2052cf5
to
84be629
Compare
Thanks for working on implementing this rule! I think it just avoids calling listeners on I imagine it would probably be something like this: create(context) {
return defineWrapperListener(coreRule, context, {
createListenerProxy(coreListener) {
return {
...coreListener,
VariableDeclaration(node) {
for (const decl of node.declarations) {
if (
decl.init?.type === 'CallExpression' &&
decl.init.callee.type === 'Identifier' &&
['$state', '$props', '$derived'].includes(decl.init.callee.name)
) {
return;
}
}
coreListener.VariableDeclaration?.(node);
}
};
}
});
} |
Thanks @ota-meshi for pointing this out, my initial idea was to use a proxy for the rule, to avoid having a complete re-write. Should've asked before spending so many hours 😅 🤦🏼 Will look into it. Maybe I'll end up closing this PR in favour of another one. |
After having finished the implementation, I've decided to extract the logic into a function, since I strongly believe it'll be easier to understand, as functions are equivalent to classes, if done right. The reason of this commit is to save the current implementation in case I want to revert changes.
Code has been moved into `prefer-const-helpers` folder, so the rule file is simpler.
By adding the original rule tests, I was able to identify issues with the rule, that had been caused because of the refactoring. Now, not only I think the code is more readable and maintainable, but also the behavior is as expected, and there are tests to ensure that. There's a tests that has been skipped since it reporting a false positive, which is dues to `@typescript-eslint`. I've reported the issue in typescript-eslint/typescript-eslint#10426
Remove the duplicated code implementation in the rule, by using the helpers to get the actual rule ✨
53282a2
to
1b1b4f7
Compare
Adds a new rule named
prefer-const
which:in New Rules: rune-prefer-let & prefer-const #818.
PortsProxies the originalprefer-const
rule from ESLint, adapting it for Svelte.This PR is an updated version of #816, which did not include types. Also, someopinionated changes were made in terms of code style, not in terms of behavior.
Avoided re-implemeting the core rule, by using the
getCoreRule
and proxying thedefault implementation.
I found that this rule could be very useful for Svelte, and there could be many
developers who would benefit from it.
At the same time, I thought that theinitial implementation was a good starting point, and that adding types and
would make the rule more robust to changes.
However, the rule should not have many changes, as how variables are handled in
JS is not likely to change.