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

New: Do not exclude dot files by default #55

Closed

Conversation

mightyiam
Copy link

Summary

ESLint excludes dot files (files whose names begin with .) by default.
This is a proposal to remove this default exclusion.

@jsf-clabot
Copy link

jsf-clabot commented May 23, 2020

CLA assistant check
All committers have signed the CLA.


## Frequently Asked Questions

Q: Do you have real examples of JavaScript dot files in projects where the authors are under the false assumption that those files are linted, where in truth, the are not?
Copy link

Choose a reason for hiding this comment

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

Another example here: In Ember applications we actually ended up adding !.* to the default .eslintignore due to folks accidentally assuming they were already checked.

ember-cli/ember-cli#8070

More info / background also in eslint/eslint#10341

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

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

In theory, I support linting dotfiles and dotfolders by default. I agree that it is unexpected that .*.js files are ignored by default. Having dotfiles linted by default would also mean that the end user would be notified immediately if they are linting things they don't intend to (because they would warn), rather than silently ignoring files they believe are being linted.

All that being said, this could cause a lot of pain in the ecosystem, and I'm wary of making a change that could have such a huge ripple effect. One possible solution to this would be to change the default ignore patterns only when using eslint.config.js, since that's an opt-in path and won't break existing CI builds. I don't want to tie that RFC to this change, though, since it's been in the works so long and it sounds like we're finally reaching consensus on the feature set.

@mightyiam
Copy link
Author

@kaicataldo is there test infrastructure to see some example breaking changes, please?

@kaicataldo kaicataldo added Initial Commenting This RFC is in the initial feedback stage and removed triage labels May 23, 2020
@kaicataldo
Copy link
Member

@mightyiam Can you clarify what you mean?

@mightyiam
Copy link
Author

A test that clones many projects that use ESLint, upgrades the version of ESLint and attempts to run their lint command to obtain examples of actual ecosystem breakage.

@kaicataldo
Copy link
Member

We don't have infrastructure to do this. I'm also not sure it's necessary, given how clear of a breaking change this is.

Note that this change isn't limited to configuration dotfiles. As a concrete example, many popular tools create caches (Gatsby creates a .cache directory filled with *.js files, for instance) that are currently ignored by default. This change would mean the contents would suddenly be linted if the file isn't included in the project's .eslintignore.

@kaicataldo
Copy link
Member

And to be clear, doing a test like the above wouldn't necessarily give us the data we need. The needs and setups of open source projects versus closed source applications can be very different.

@nzakas
Copy link
Member

nzakas commented May 25, 2020

I agree with the premise here — less magic is better. I also agree that it’s a major breaking change and like @kaicataldo’s suggestion about waiting to make such a change until it can be shipped with the new config system. Since the ignore mechanism is tied in and will be changing anyway, that would be the best opportunity to incorporate a change like this.

@mightyiam
Copy link
Author

@nzakas so this PR would be merged into #9? Are you taking that on? I wouldn't like to get into the details of #9 myself.

@nzakas
Copy link
Member

nzakas commented May 26, 2020

Yes, I can work this into #9 so we have a holistic view of the changes.

@nzakas
Copy link
Member

nzakas commented May 28, 2020

I've incorporated this into #7, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Initial Commenting This RFC is in the initial feedback stage
Projects
None yet
5 participants