Skip to content
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

Closed
devinrhode2 opened this issue Sep 25, 2019 · 7 comments
Closed

eslint improvements #111

devinrhode2 opened this issue Sep 25, 2019 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@devinrhode2
Copy link

devinrhode2 commented Sep 25, 2019

(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 :)

@patricklafrance patricklafrance added the help wanted Extra attention is needed label Sep 25, 2019
@patricklafrance
Copy link
Contributor

patricklafrance commented Sep 25, 2019

Hi @devinrhode2

I am not sure how to achieve this.

I tried to set the following options of the webpack eslint-loader without success:

emitError: true,
emitWarning: true

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

@devinrhode2
Copy link
Author

it could be as simple as... turning off eslint-loader... and running some sort of child process for npx eslint ${eslint options}.. assuming it can still pickup various babel plugins... and we can 'pipe' the input into the terminal without issues...

tested doing

setInterval(() => {
    console.log('craco heartbeat');
}, 1000);

in the craco config and it never stops logging to the terminal. I've also never noticed any differences between running npx eslint ... and the dev server itself

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 npx eslint command in that webpack plugin callback/hook.

So theoretically it'd be something like:

// craco.config.js plugins...
{ plugin: indyEslint(`"**/*.*" --format compassion --any-cli-options-you-want`) }

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 npx eslint command runs, it re-reads the .eslintrc.js file, and it also would print out syntax errors in that file too.

I don't know if child processes share the same environment variables, but it'd be nice for my scenario to have npx eslint run with the same env vars.

If this can be done via webpack plugin then in the eslint recipes it could be shown as a 2nd example

@patricklafrance
Copy link
Contributor

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.

@devinrhode2 devinrhode2 changed the title .eslintrc.js parse/syntax errors are not shown to user eslint improvements Sep 29, 2019
@devinrhode2
Copy link
Author

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...
in craco.config.js...
watch for changes to .eslintrc.js (perhaps with chokidar or watchman)... then re-require the file - we can pass the module.exports from .eslintrc.js to eslint-loader... but it comes down to... how can eslint-loader get the new config while webpack is running?

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..

@patricklafrance
Copy link
Contributor

Hi @devinrhode2

Same setup here on my projects. I disabled CRA eslint support and use the vscode eslint plugin instead.

@devinrhode2
Copy link
Author

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.

@patricklafrance
Copy link
Contributor

I will close the issue since there no further steps to do. Will be available for info.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants