Split both options of no-unused-modules into 2 rules
See original GitHub issueApologies if there is already a ticket for this.
I find no-unused-modules
a very powerful rule however very confusing due to its options. It seems to me missingExports
and unusedExports
effectively respond to 2 different use cases.
Additionally, the ignoreExports
option applies to both options, but sometimes it makes sense to ignore patterns for one but not for the other.
For example, it might be ok for everything under test/
to not export anything but we still might want to make sure that anything exported in a test file is imported somewhere (another test file for example). For this use case, my organization uses a dedicated .eslintrc.yml
file in test/
, but people locating their test files next to their source files will not have this chance.
I believe I saw a ticket suggesting an additional ignore list to address this, which would help making my case, but I can’t seem to find it anymore so maybe I just saw what I wanted to see 😅
Lastly, I find this rule difficult to configure and predict: it respects .eslintignore
patters, nested ESLint configurations, has an additional src
options to find further patterns, but also an ignore list on its own, and will even honor files listed in package.json
(which is potentially great) if and only if the project is not private (which is less great).
I feel like splitting this rule in 2 would help reduce the confusion and may offer a way to simplify branches of configuration/ignores.
Thoughts?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top GitHub Comments
I agree, which is why I think it would be nice to be able to configure those 2 things separately, since even the rule description explains the rule in 2 different parts: “Forbid modules without any export, and exports not imported by any modules”.
Files without exports can still be used for side effects, and be entry points of a package (or, tbh, entry points in a browser in an app).