Add new rule no-decorators-before-export
#1700
Conversation
lin-ll
changed the title
no-decorators-before-export
|
|
||
| 💼 This rule is enabled in the ✅ `recommended` [config](https://github.com/ember-cli/eslint-plugin-ember#-configurations). | ||
|
|
||
| 🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix). |
There was a problem hiding this comment.
Maybe worth adding a note that the fixer only works for named exports
| export default MyComponent; | ||
| ``` | ||
|
|
||
| Unfortunately, in order to maximize compatibility with existing decorators, the second rendition of the spec - the rendition of the spec which Ember adopted (there have been four) - allowed this syntax to still be used if using the babel plugin AND also explicitly allowing it in the plugin config. Ember chose to be maximally capatible and enabled this option. |
There was a problem hiding this comment.
| Unfortunately, in order to maximize compatibility with existing decorators, the second rendition of the spec - the rendition of the spec which Ember adopted (there have been four) - allowed this syntax to still be used if using the babel plugin AND also explicitly allowing it in the plugin config. Ember chose to be maximally capatible and enabled this option. | |
| Unfortunately, in order to maximize compatibility with existing decorators, the second rendition of the spec - the rendition of the spec which Ember adopted (there have been four) - allowed this syntax to still be used if using the babel plugin AND also explicitly allowing it in the plugin config. Ember chose to be maximally compatible and enabled this option. |
|
|
||
| @classic | ||
| export class MyKlass extends EmberObject {} | ||
| ``` |
There was a problem hiding this comment.
If possible, do you mind adding a couple link references as well, like the proposal for decorators and issues that were caused by this?
| description: | ||
| 'disallow the use of a class decorator on an export declaration. Enforces use of the decorator on the class directly before exporting the result.', | ||
| category: 'Miscellaneous', | ||
| recommended: true, |
There was a problem hiding this comment.
Note: recommended rules are only added in major versions so this should be removed. We can enable it in the next major version.
| @@ -0,0 +1,73 @@ | |||
| 'use strict'; | |||
|
|
|||
| /** @type {import('eslint').Rule.RuleModule} */ | |||
There was a problem hiding this comment.
This type annotation is supposed to go directly above module.exports = { ....
| invalid: [ | ||
| // basic | ||
| { | ||
| code: "import classic from 'ember-classic-decorators';\n@classic\nexport class Foo {}", |
There was a problem hiding this comment.
I'm finding these single-line strings with \n a hard to read. Normally, we use multi-line template strings.
| const sourceCode = context.getSourceCode(); | ||
| const src = sourceCode.getText(node); |
There was a problem hiding this comment.
These variables can move inside the fixer since they aren't used outside.
| return ( | ||
| node.declaration && | ||
| node.declaration.type === 'ClassDeclaration' && | ||
| node.declaration.decorators?.length |
There was a problem hiding this comment.
Normally we should have a comparison length > 0. Or are you trying to check if the array exists at all? Then Array.isArray() is more clear.
There was a problem hiding this comment.
it might not exist, or it may exist and be empty, in either case that is fine.
There was a problem hiding this comment.
Okay, well !Array.isArray(node.declaration.decorators) || node.declaration.decorators.length > 0 would convey that intent more clearly to me. Feel free to leave as is if you prefer.
|
|
||
| /** @type {import('eslint').Rule.RuleModule} */ | ||
|
|
||
| function reportInvalidSyntax(context, node) { |
There was a problem hiding this comment.
Can you add a comment explaining the general strategy/approach/what's going on?
| } | ||
| } | ||
|
|
||
| function isInvalidSyntax(node) { |
There was a problem hiding this comment.
Seems like this could just be a generic classDeclarationHasDecorators(node) function. That way, it's more clear what it's doing, and could be reusable in other places.
There was a problem hiding this comment.
It isn’t though, it’s checking against an export declaration specifically
There was a problem hiding this comment.
My bad, then exportDeclarationHasDecorators?. Feel free to leave it if you want, but I think my own confusion illustrates the point. I'm just thinking of ways to make it more clear about what it's doing and reusable.
@bmish it is already running on one |
|
@runspired would love to get this rule in still! Are you planning to work on it? |
resolves #1699