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
{{ message }}
Repository navigation
Cannot use .eslintignore for generated files #7339
To ignore specified files from ESLint checks and start the app. Talking here mostly about generated files which we cannot just modify with the comment to disable eslint. The best course of action is to just ignore these.
Quite an exhaustive issue #6871 talks about customizing ESLint config, but not much of the mention of utilizing .eslintignore which isn't exactly huge customization and shouldn't be prohibited like that.
I can use a workaround with cra-override, but I don't want to disable a conflicting rule for a whole project when the only a bunch of generated files is affected.
Actual behavior
I have VSCode properly working with ESLint in the project. The specified file is correctly ignored there.
Slightly related to #7295. I'll look into what it would take to support eslintignore and bring it up at the next maintainers meeting? I'm not sure if there's a reason we don't support it or if it just hasn't been implemented.
@heyimalex Well, that's 2 years old and I don't see any discussion except "we don't do that". What if some views have changed on the problem?
@Timer Please, what's your take on this after that time? And can you give it a serious thought and explain some actual reasoning? So far it seems it's just "inconvenient" and nothing else.
It's hard to believe that such a trivial problem needs hard solutions. I do understand why you don't want to support .eslintrc, way too much customization. But, ignoring files from linting is hardly called customization.
Besides, it would kinda solve #6871 and people could disable ESlint for a whole project if they really want.
I think it makes sense to re-evaluate whether this is viable, given that we are working towards allowing custom eslint configs. However it is a breaking change so it would only be included in a major release that might be a while away.
Reacted by Alex Guerra, Daniel K., tsiq-alberto, Alex Hughes and Joe Jordan
I would really love to use an .eslintignore file for copied over dependencies (like scripts). These kind of which I want to keep as much as possible as the original, so I can easily implement updates.
The best way would be to fork the script and make my own npm package, but that would be pretty overkill for most of my smaller projects.
Maybe this can be implemented without breaking backwards compatibility by requiring an additional env variable to be set? Maybe something like EXTEND_ESLINT_ALLOW_ESLINTIGNORE?
Edit: Since extending the ESLint config is still experimental maybe a breaking change is okay at this point?
Reacted by Daniel K., Margarita Krutikova and Joe Jordan
Came across this thread after scratching my head as to why I could customize eslint in my CRA app to my heart's desire using .eslintrc.js, but then being unable to compile due to .eslintignore being ignored.
I think an env variable as suggested by @nphmuller is a good solution to offer this needed functionality before the long and distant CRA 4.0 is released.
Activity
heyimalex commentedon Jul 8, 2019
Slightly related to #7295. I'll look into what it would take to support eslintignore and bring it up at the next maintainers meeting? I'm not sure if there's a reason we don't support it or if it just hasn't been implemented.
heyimalex commentedon Jul 8, 2019
It looks like this was intentional via #2115, and it would be breaking so it's probably not going to change. There's more discussion in #2339. Sorry!
danielkcz commentedon Jul 9, 2019
@heyimalex Well, that's 2 years old and I don't see any discussion except "we don't do that". What if some views have changed on the problem?
@Timer Please, what's your take on this after that time? And can you give it a serious thought and explain some actual reasoning? So far it seems it's just "inconvenient" and nothing else.
It's hard to believe that such a trivial problem needs hard solutions. I do understand why you don't want to support
.eslintrc, way too much customization. But, ignoring files from linting is hardly called customization.Besides, it would kinda solve #6871 and people could disable ESlint for a whole project if they really want.
bugzpodder commentedon Jul 9, 2019
I think it makes sense to re-evaluate whether this is viable, given that we are working towards allowing custom eslint configs. However it is a breaking change so it would only be included in a major release that might be a while away.
danielkcz commentedon Jul 9, 2019
I am not entirely sure how is it breaking considering its opt-in feature, but I am fine with it either way. Thanks for reopening.
silverwind commentedon Jul 10, 2019
I too suggested removing this pesky
ignore: falsein the webpack config in #7036. My use case is for ignoring manually vendored JS libs insrc.Change should be fully backwards compatible.
nphmuller commentedon Sep 13, 2019
I would really love to use an
.eslintignorefile for copied over dependencies (like scripts). These kind of which I want to keep as much as possible as the original, so I can easily implement updates.The best way would be to fork the script and make my own npm package, but that would be pretty overkill for most of my smaller projects.
Maybe this can be implemented without breaking backwards compatibility by requiring an additional env variable to be set? Maybe something like
EXTEND_ESLINT_ALLOW_ESLINTIGNORE?Edit: Since extending the ESLint config is still experimental maybe a breaking change is okay at this point?
joejordan commentedon Oct 15, 2019
Came across this thread after scratching my head as to why I could customize eslint in my CRA app to my heart's desire using .eslintrc.js, but then being unable to compile due to .eslintignore being ignored.
I think an env variable as suggested by @nphmuller is a good solution to offer this needed functionality before the long and distant CRA 4.0 is released.
silverwind commentedon Oct 15, 2019
This should be resolved in 3.2.0 with 6f5221c.