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
Update: Implement FlatConfigArray (refs #13481) #14321
Conversation
Hi @nzakas!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
Hi @nzakas!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am pleasantly surprised by how much less is going on here than in the existing config system. Outsourcing all of the file path matching to @humanwhocodes/config-array
nicely separates the "what needs to be merged" logic from the "what are the rules for merging each field" logic. It's great to see the vision of a simpler config coming together 🎉
I believe everything has been addressed, but let me know if I missed anything. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just did a thorough pass through the schema to make sure everything matches up. I'm excited that we'll be able to alert users to invalid configurations as close to the source as possible with some of the checks you've added. There were a few particularly helpful ones that aren't covered by a test, so I pointed those out in case you'd like to add those. LGTM either way.
Nice! I’ll plan on adding tests for those. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Sorry about the false positive on a couple of those.
lib/config/default-config.js
Outdated
rules: defaultRulesConfig | ||
} | ||
}, | ||
ignores: ["node_modules/**"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this now a glob pattern, or a .gitignore
-style pattern as it used to be with ignorePatterns
?
If it's a glob, should it be **/node_modules/*
, as an equivalent to the actual default ignore pattern /**/node_modules/*
?
Also, ignoring files in the RFC specifies .git
directories. Should we add a pattern for them here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are all glob patterns now. I’ll update them to match the current defaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it also mean that we'll interpret the content of .eslintignore
file differently, depending on the format of the found eslint configuration file:
- as a list of
.gitignore
patterns (actual behavior) if the config is.eslintrc.*
. - as a list of glob patterns if the config is
eslint.config.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. There is no change to how .eslintignore will be interpreted. It will be read and compiled into a function that is then included in a flat config ignores key. (Can be either a glob pattern or a function.)
Comments addressed. |
@nzakas regarding #14321 (comment), isn't it the opposite ( Our documentation uses |
I think I've fixed everything. @mdjermanovic thanks for the amazing level of detail in your comments. |
Should be set now (hopefully). |
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
5986e58
to
7b66408
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I'm not sure if the feature of unignoring files that are ignored in the base config (or a shared config) is supported, but we can discuss that when we start integrating.
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:
Implements FlatConfigArray (refs #13481)
What changes did you make? (Give an overview)
I added
FlatConfigArray
class and associated tests to make sure everything is working okay.FlatConfigArray
is not referenced anywhere while running ESLint currently, as implementingFlatConfigArray
is meant to be a standalone task. In the next task, I'll work on using it wheneslint.config.js
is found.Merging this does not result in any end-user-facing changes. It will result in
FlatConfigArray
tests being run withnpm test
Is there anything you'd like reviewers to focus on?