Update top-level lint deps

[Timer]

No description provided.

[gaearon]

Let's just remove this one? I don't think we ever enabled it in the end, and there are still some issues preventing it from working well with eslint-loader (specifically, fixing the exporting file doesn't "recheck" the importing file).

[Timer]

We use the plugin in our eslint config so I don't think we can drop it, it's also a peer dep.

p.s. these packages are the top-level ones and strictly used for CI linting, they don't persist to the end-user in any way.

[gaearon]

Ah, I forgot about ''import/no-webpack-loader-syntax''. Okay

[gaearon]

Should we enable ESLint's native support for async/await?
See note in https://github.com/babel/babel-eslint/releases/tag/v7.0.0.

[Timer]

This is a peerDep of our config, and we can't switch to ESLint's native support until import() lands.

[Timer]

See import-js/eslint-plugin-import#700.

The babel-eslint parser is required for it to be parsed properly (syntax parsing is not the job of an eslint plugin).

[gaearon]

Why is this one pinned?

[Timer]

Will unpin, what about our preset (eslint-config-react-app)? Lerna doesn't bump this automatically.

[gaearon]

I'm not sure why do we even have it in root package.json?

[Timer]

Our CI currently runs lint in e2e-simple, see https://travis-ci.org/facebookincubator/create-react-app/jobs/201147269#L204-L234. We don't treat warnings as failures though, would you like to?

[gaearon]

Oh okay. Yeah I think we should fail on them.

[gaearon]

Yes, we can unpin there.

[gaearon]

To answer your earlier question—we unpinned ESLint config in #1110.

[gaearon]

Looks fine (but please unpin the ESLint plugin).
See other notes for optional changes.

[gaearon]

Why?

[Timer]

/home/travis/build/facebookincubator/create-react-app/packages/react-dev-utils/InterpolateHtmlPlugin.js
18:1 warning 'use strict' is unnecessary inside of modules strict

I can ignore it (like I did to the CLI), I was just listening to eslint. 😛 Was waiting to see if CI passed on node 4.

[gaearon]

I'm confused why it thinks it's a module. We're not using import syntax anywhere.

[Timer]

We tell it so, I'll put the stricts back.

 parserOptions: {
ecmaVersion: 6,
> sourceType: 'module',
ecmaFeatures: {
jsx: true,
generators: true,
experimentalObjectRestSpread: true
}
},

[Timer]

We could override extending our own config, but I'm not sure if that's necessary.

[gaearon]

We actually need to add stricts to Node-targeted code. Like react-scripts/config/*.

[Timer]

Most of these configs contain module.exports which eslint argues doesn't need 'use strict';, but I've adjusted the config for the other files -- what do you think now?

[gaearon]

Most of these configs contain module.exports which eslint argues doesn't need 'use strict';

This is weird (and I think it's wrong). use strict is only unnecessary for code using ES Modules. It is necessary in Node. Can you point me to ESLint doc that says otherwise?

[Timer]

Sorry, I didn't mean to state that as fact -- I derived it's been a problem before from the conversation on eslint/eslint#4832, but nothing I change seems to be making it catch and require the 'use strict';. I'm not sure if there was a regression or some really weird configuration bug, but I'm stumped.

[gaearon]

Instead let's do #1729.