symbol-description: allow feature identifier tagging
See original GitHub issueWhat rule do you want to change? symbol-description
Does this change cause the rule to produce more or fewer warnings? Fewer, if the empty symbol is a key of an object and it’s value is another symbol, for example, used to tag an object by its provider id (the module providing the feature).
It can provide a way, for developers, to easily identify where the features on an object come from, for debugging purpose, without any conflict risks.
How will the change be implemented? (New option, new default behavior, etc.)? new default behavior
Please provide some example code that this change will affect:
export default {
...featurePrototype,
[Symbol()]: Symbol(myModuleId)
}
What does the rule currently do for this code? Triggers an error.
What will the rule do after it’s changed? Ignore in case of.
Are you willing to submit a pull request to implement this change? If needed.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:18 (7 by maintainers)
Top GitHub Comments
I think at the very least, this shouldn’t be a new default behavior and would need to be an option.
Personally, the proposal feels very specific and as @ljharb notes, is not a universal convention by any means. So I think making any modification to this rule in ESLint core would just confuse other users.
You could use eslint-rule-composer to create a custom rule based off of this rule, and use the
filterReports
method to remove lint messages that correspond to property keys which have a Symbol with description as the property value.Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.
Thanks for contributing to ESLint and we appreciate your understanding.