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

Use overrides for a single .eslintrc.js. #7443

Merged
merged 1 commit into from Nov 20, 2017

Conversation

rwjblue
Copy link
Member

@rwjblue rwjblue commented Nov 15, 2017

Update the .eslintrc.js used by apps and addons, to avoid needing separate "sprinkles" of eslint configuration throughout the projects codebase.

Compatible with eslint@4.1.0.

Additional reading:

@rwjblue
Copy link
Member Author

rwjblue commented Nov 15, 2017

I will follow up and make sure that ember-cli-eslint's blueprint is in sync once we settle on this...

@rwjblue rwjblue requested a review from Turbo87 November 15, 2017 00:04
@@ -2,12 +2,39 @@ module.exports = {
root: true,
parserOptions: {
ecmaVersion: 2017,
sourceType: 'module'
sourceType: 'module',
Copy link
Member

Choose a reason for hiding this comment

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

seems strange to only have trailing commas in this file. I vote for removal.

Copy link
Member Author

Choose a reason for hiding this comment

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

😭 but ok 😄

Copy link
Member

Choose a reason for hiding this comment

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

I agree, we should add them to all files...

Copy link
Member Author

Choose a reason for hiding this comment

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

Ya, agreed. Though I’m happy to do this separately.

files: [
'./ember-cli-build.js',
'./testem.js',
'./index.js',
Copy link
Member

Choose a reason for hiding this comment

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

should we use ./*.js instead?

Copy link
Member Author

Choose a reason for hiding this comment

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

Interesting. I hadn’t thought of that. Should work nicely.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sadly, this doesn't work. The main issue is that in the implementation (eslint/eslint#8081) when the files and excludedFiles are passed in to minimatch (here) they also pass { matchBase: true } as options.

From the minimatch README about matchBase:

If set, then patterns without slashes will be matched against the basename of the path if it contains slashes. For example, a?b would match the path /xyz/123/acb, but not /xyz/acb/123.

tl;dr Due to the usage of matchBase it is not possible to use globs to match files in the project root. If we use *.js it matches all files in the repo, if we use ./*.js it matches no files, if we use /*.js it throws an error....

😭 😭 😭

ecmaVersion: 2015,
},
env: {
browser: false,
Copy link
Member

Choose a reason for hiding this comment

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

I think this has to be browser: null or something like that. iirc true/false only defines whether the global can be overwritten or something like that

Copy link
Member Author

Choose a reason for hiding this comment

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

Really!?!?! Weird! I’ll look it up. I have used this on a few other projects, will test and update as needed.

Copy link
Member

Choose a reason for hiding this comment

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

I just realized I might be confusing this with the stuff in the globals object, but we should verify just in case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ya, I was looking through the docs on configuring and I think you are thinking of the globals stuff. For easy cross referencing:

// test files
{
files: ['tests/**/*.js'],
env: {
Copy link
Member

Choose a reason for hiding this comment

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

indentation

'./ember-cli-build.js',
'./testem.js',
'./index.js',
'config/**/*.js',
Copy link
Member

Choose a reason for hiding this comment

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

what about tests/dummy/config/**/*.js?

Copy link
Member Author

Choose a reason for hiding this comment

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

👍 - good idea


// test files
{
files: ['tests/**/*.js'],
Copy link
Member

Choose a reason for hiding this comment

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

can we exclude tests/dummy/?

it's okay if we can't since we haven't done it before either, but would be nice though

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, added and confirmed. Works nicely!

@kellyselden
Copy link
Member

I would like to hold off merging until our meeting. I'm not 100% in favor of this. I like getting rid of the first line sprinkles of node files, but I'm not convinced that removing our tests/.eslintrc.js is a good idea. Everybody's documentation and blueprint injection touch that file (globals and test helpers), and it seems to me that it is in it's correct place.

@rwjblue
Copy link
Member Author

rwjblue commented Nov 15, 2017

I would like to hold off merging until our meeting.

Seems good, happy to discuss...

I like getting rid of the first line sprinkles of node files, but I'm not convinced that removing our tests/.eslintrc.js is a good idea.

This is where we disagree. The current system of having many .eslintrc files all over makes it very difficult to understand what the current ruleset is at any given point (a number of times I've resorted to using eslint --print-config some/file/path.js just to figure out what the heck is running). Another issue is that (other than simple things like env) its not possible by adding a .eslintrc file to handle directories that contain mixed rulesets .

Everybody's documentation and blueprint injection touch that file (globals and test helpers), and it seems to me that it is in it's correct place.

I think this is actually a separate concern from the others. We should choose the right set of defaults, and recommend them while also providing time and assistance to addons that may need to make modifications. Modifying a single file (.eslintrc.js) in general, is easier than having to modify many potential locations...

@kellyselden
Copy link
Member

We decided in the core meeting that this is the way forward. With module unification, test files will be strewn about a project, so wildcard paths inside a single eslint config is the future (TM).

@rwjblue
Copy link
Member Author

rwjblue commented Nov 18, 2017

Rebased and addressed all outstanding comments...

Update the `.eslintrc.js` used by apps and addons, to avoid needing
separate "sprinkles" of eslint configuration throughout the projects
codebase.

Compatible with `eslint@4.1.0`.
@rwjblue rwjblue merged commit 4dfbd37 into ember-cli:master Nov 20, 2017
@Turbo87
Copy link
Member

Turbo87 commented Nov 20, 2017

@rwjblue this shouldn't block, but can you verify the behavior for in-repo-addons?

@rwjblue
Copy link
Member Author

rwjblue commented Nov 20, 2017

@Turbo87 - Good point, I will do some testing. I believe that we might need to add lib/*/index.js to the "node" config...

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

Successfully merging this pull request may close these issues.

None yet

3 participants