Skip to content

Enable eslint caching in development #1578

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

Merged
merged 3 commits into from
Feb 24, 2017
Merged

Conversation

viankakrisna
Copy link
Contributor

POC for #740. Haven't found any problem, build times improved about 1s on my project and machine.

POC for facebook#740. Haven't found any problem, build times improved about 1s on my project and machine.
@@ -118,7 +118,8 @@ module.exports = {
// Point ESLint to our predefined config.
options: {
configFile: path.join(__dirname, '../.eslintrc'),
useEslintrc: false
useEslintrc: false,
cache: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't want this specific setting to be inside of // @remove-on-eject block.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll likely want for this to get merged first: webpack-contrib/eslint-loader#151. Or it will be confusing to ejected users who change the rules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Babel falls back to OS tmp dir. Does eslint-loader, too? We should probably use consistent mechanisms. If eslint-loader doesn't, we should send a PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comments! I realized that i'm searching the cache issues in eslint repo rather than eslint-loader repo. I've sent a pr on tmp dir fallback on eslint-loader repo on webpack-contrib/eslint-loader#154. And yup, I think we should wait until webpack-contrib/eslint-loader#151 merged first.

We probably don't want this specific setting to be inside of // @remove-on-eject block.

So, should we move the // @remove-on-eject block. to the inside of the options?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, should we move the // @remove-on-eject block. to the inside of the options?

Yes I think so.

@viankakrisna
Copy link
Contributor Author

@gaearon @Timer now that eslint-loader 1.6.3 released, can we revisit this?

@gaearon gaearon added this to the 0.9.1 milestone Feb 24, 2017
@gaearon gaearon self-assigned this Feb 24, 2017
@gaearon
Copy link
Contributor

gaearon commented Feb 24, 2017

Have you tested that this works?

@gaearon
Copy link
Contributor

gaearon commented Feb 24, 2017

I'm going to trust that this works and ninja-land it.

@gaearon gaearon merged commit 8d41328 into facebook:master Feb 24, 2017
@viankakrisna
Copy link
Contributor Author

I'm going to trust that this works and ninja-land it.

😄 This is hilarious, thank you!

Have you tested that this works?

Yeah, I tried it by turning off eqeqeq in eslint-config-react-app while the warning still in the terminal, and restart it, the warning's gone. :)

@viankakrisna viankakrisna deleted the patch-1 branch February 24, 2017 21:25
@dylanrhysscott
Copy link

@gaearon @viankakrisna I think this has caused me some problems - Compilation is periodically / intermittently failing with this error:

Module build failed: Error: ENOENT: no such file or directory, open '/app/client/node_modules/.cache/eslint-loader/data.json'

If I save a file compilation passes a second time. I can't find anything relating to this in issues and didn't want to open something in case its me. This is the most recent change that maybe related. I'm using the latest version of Node & NPM. Any suggestions?

Thanks

@Timer
Copy link
Contributor

Timer commented Feb 26, 2017

Oh no! That's not good at all, @dylanrhysscott.
Sorry about that!

Could you please open a formal issue and we'll do some triaging to determine if we need to revert this in a release and/or report a bug upstream?

Thanks!

@dylanrhysscott
Copy link

@Timer No worries these things happen! :) Will ping you an issue shortly!

Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants