You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My use case:
I'm preparing an ES6+ starter for Angular 1.
I'm using ES modules in it.
I'm assigning Angular module to a variable:
constmodule=angular.module('myModule',[])
and that's why I don't want angular/module-setter rule on.
I do export default module.name so in another module I can
importMyModulefrom'./my-module'
and that's why I don't need angular/module-getter on.
But keeping those rules off is not best I can get to express my intentions. It came to my mind that I'd like not only not to check if getters are used or module is assigned, but actively disallow that.
IMO ES Modules are a valid use case of why would one want to do it.
I suggest that configuration of both angular/module-setter and angular/module-getter should be extended from no 2nd argument (as it is now) to 'always'and 'never' keywords.
The choice of keywords:
If one has angular/module-getter enabled he "wants getter syntax to always be used"
If one has angular/module-setter enabled he "wants angular modules to never be assigned to variables"
(BTW: I think having angular/module-setter rule renamed to angular/no-module-variable-assignment or so will make configuration more straightforward because now name is far from self-explainatory because "angular/no-module-variable-assignment": ["error", "always"] seems to read a bit better than "angular/module-setter": ["error", "never"])
The opposite (outcome I'd like to achieve for my ES Modules NG1 configuration) would be:
Which states that:
I'd like to enforce NOT using angular module getter syntax and
I'd like to enforce assigning newly created angular module to a variable.
The text was updated successfully, but these errors were encountered:
jrencz
changed the title
module-getter/module-setter: extended configuration
module-getter/module-setter: reversed settings
Jan 17, 2017
My use case:
I'm preparing an ES6+ starter for Angular 1.
I'm using ES modules in it.
I'm assigning Angular module to a variable:
and that's why I don't want
angular/module-setter
rule on.I do
export default module.name
so in another module I canand that's why I don't need
angular/module-getter
on.But keeping those rules off is not best I can get to express my intentions. It came to my mind that I'd like not only not to check if getters are used or module is assigned, but actively disallow that.
IMO ES Modules are a valid use case of why would one want to do it.
I suggest that configuration of both
angular/module-setter
andangular/module-getter
should be extended from no 2nd argument (as it is now) to'always'
and'never'
keywords.Now:
What I suggest:
To express current configuration (that rules are on):
The choice of keywords:
If one has
angular/module-getter
enabled he "wants getter syntax to always be used"If one has
angular/module-setter
enabled he "wants angular modules to never be assigned to variables"(BTW: I think having
angular/module-setter
rule renamed toangular/no-module-variable-assignment
or so will make configuration more straightforward because now name is far from self-explainatory because"angular/no-module-variable-assignment": ["error", "always"]
seems to read a bit better than"angular/module-setter": ["error", "never"]
)The opposite (outcome I'd like to achieve for my ES Modules NG1 configuration) would be:
Which states that:
I'd like to enforce NOT using angular module getter syntax and
I'd like to enforce assigning newly created angular module to a variable.
The text was updated successfully, but these errors were encountered: