-
-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eslint improvements #111
Comments
Hi @devinrhode2 I am not sure how to achieve this. I tried to set the following options of the webpack eslint-loader without success:
And reset the formatter to "stylish". Also without success. If you any idea how to fix this, I will gladly review a PR! Thank you, Patrick |
it could be as simple as... turning off eslint-loader... and running some sort of child process for tested doing
in the craco config and it never stops logging to the terminal. I've also never noticed any differences between running I think one caveat will be that now we have to have 2 watchers, we have webpack's watcher and now we since we are running eslint independently it has to have it's own watcher I don't know the api for creating webpack plugins.. but if all you did was get something that could hook into the webpack build, which shouldn't be too hard, then all you do is exec' the So theoretically it'd be something like:
Could there be syntax errors that still get printed by built-in eslint, and maybe hidden at the top of the linter output? In this case formatters with large output like compassion become less suitable and stylish would be more preferable. Either way the regular npx eslint output should print the error somewhere too. I think one awesome benefit of this approach is that everytime the I don't know if child processes share the same environment variables, but it'd be nice for my scenario to have If this can be done via webpack plugin then in the eslint recipes it could be shown as a 2nd example |
If the solution is to remove the eslint-loader and do a straight call to the eslint CLI, to me this is out of scope of craco. Adding a custom npm/yarn script to the project would do it. |
So I figured out how to restart all the whole dev server when craco.config.js (or any set of files) changes: #112 - this approach can be used to also watch .eslintrc.js for changes and then in turn, restart the whole dev server. However, I would love to more surgical refreshing of .eslintrc.js changes. I wonder if this is possible by... Perhaps eslint-loader needs an option for something like "watch .eslintrc.js for changes and refresh lint output". Lo' and behold, this is being discussed in eslint-loader: webpack-contrib/eslint-loader#214 ==== I am finding my dev server reloads faster without eslint, I don't need eslint in the terminal, I have it inside vscode and it works better inside vscode. Reflects .eslintrc.js changes without any restarting, see only lint issue per file, clicking lint issue goes directly to the offending line.. |
Hi @devinrhode2 Same setup here on my projects. I disabled CRA eslint support and use the vscode eslint plugin instead. |
You could put this issue "on hold" or something like that and close if you don't want it cluttering up issues. Although there's hardly any issues right now anyway, so might be opened back up anyway. |
I will close the issue since there no further steps to do. Will be available for info. Thank you! |
(Originally titled: ".eslintrc.js parse/syntax errors are not shown to user")
I was doing some fancy scripting in my .eslintrc.js so that I can change environment variables on the fly, which in turn affect the eslint config that is exported.
I have settings for a gitlab ci pipeline, shows accessibility lint errors and general lint errors, then I have a setting to ignore_airbnb plugin, so that doens't break otherwise working builds, and of course when vscode goes to read the eslintrc, it has no environment variables set, so the default config is optimized to help developers write good code.
Anyway, while working on this I found out eslintrc.js parse errors are not shown to the user when running npm start, even if you do
npm start | cat
to see all cra terminal output. (the| cat
essentially disables cra console clearing)If you directly run
npx eslint "**/*.*"
(or whatever file matching pattern floats your boat) then you will see if you have any syntax errors :)The text was updated successfully, but these errors were encountered: