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 |
btmills
left a comment
There was a problem hiding this comment.
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. |
btmills
left a comment
There was a problem hiding this comment.
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. |
btmills
left a comment
There was a problem hiding this comment.
Nice! Sorry about the false positive on a couple of those.
| rules: defaultRulesConfig | ||
| } | ||
| }, | ||
| ignores: ["node_modules/**"], |
There was a problem hiding this comment.
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.
These are all glob patterns now. I’ll update them to match the current defaults.
There was a problem hiding this comment.
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
.gitignorepatterns (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.
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 <[email protected]>
Co-authored-by: Brandon Mills <[email protected]>
Co-authored-by: Brandon Mills <[email protected]>
Co-authored-by: Brandon Mills <[email protected]>
5986e58 to
7b66408
Compare
mdjermanovic
left a comment
There was a problem hiding this comment.
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
FlatConfigArrayclass and associated tests to make sure everything is working okay.FlatConfigArrayis not referenced anywhere while running ESLint currently, as implementingFlatConfigArrayis meant to be a standalone task. In the next task, I'll work on using it wheneslint.config.jsis found.Merging this does not result in any end-user-facing changes. It will result in
FlatConfigArraytests being run withnpm testIs there anything you'd like reviewers to focus on?