NEW: @W-18495437@: Detect state of user's eslint configuration files … #292
Conversation
| const WORKSPACE_WITH_FLAT_CONFIG2: string = path.join(TEST_DATA_FOLDER, 'workspaceWithFlatConfig2'); | ||
| const WORKSPACE_WITH_FLAT_CONFIG3: string = path.join(TEST_DATA_FOLDER, 'workspaceWithFlatConfig3'); | ||
|
|
||
| describe('Tests for the UserConfigInfo class', () => { |
There was a problem hiding this comment.
This file is rather exhaustive to cover all the different scenarios for the most part.
| IgnoringFlatConfigFile: | ||
| `Ignoring '%s' since ESLint "Flat" configuration files are not yet supported by this version of the 'eslint' engine.` |
There was a problem hiding this comment.
Note that this doesn't actually get displayed unless the file is auto discovered when auto_discover_eslint_config is enabled. The config still errors today when a user tries to explicitely set a flat config file.
stephen-carter-at-sf
force-pushed
the
sc/eslintV9Prep
branch
from
0274085 to
7c8f8a1
Compare
…and emit fine log
stephen-carter-at-sf
force-pushed
the
sc/eslintV9Prep
branch
from
7c8f8a1 to
aa74cc8
Compare
| // For now we just maintain a test that the v9 eslint engine errors until it has been implemented: | ||
| it('When directly calling describeRules on the v9 ESLintEngine, then we error since it has not been implemented', async () => { | ||
| const engine: ESLintEngine = new ESLintEngine(DEFAULT_CONFIG); | ||
| // For now we just maintain a test that the v9 eslint engine defers when auto discovered flat config is discovered until it has been implemented: |
There was a problem hiding this comment.
"Defers" is unclear to me. What's it deferring to? V8?
There was a problem hiding this comment.
Yeah. I can update this to make it more clear.
There was a problem hiding this comment.
done.
There was a problem hiding this comment.
Looks like the only difference between these three workspaces is the file extension of the config. Could we rename the workspaces to workspaceWithJsConfig, workspaceWithMjsConfig, and workspaceWithCjsConfig for clarity?
There was a problem hiding this comment.
that is ambiguous though. js and cjs files can either be legacy or flat.
But yeah I could rename things to be workspaceWithJsFlatConfig, workspaceWithCjsFlatConfig, workspaceWithMjsFlatConfig but the workspaceWithFlatConfig3 also has a legacy eslint ignore file in it so I can test that case as well. So I don't know how specific I want to make each of these scenarios. I was just thinking of scenario 1, 2, and 3. And I'll be adding to these soon - so it isn't just that 1 is js based, 2 is cjs based, and 3 is mjs based. I just wanted to have 3 scenarios.
Notice that in the LegacyConfig1, LegacyConfig2, and LegacyConfig3 cases I could have kept going with 4, 5, 6 etc... because I'm not even testing "yaml" for example. It's not fully exhaustive. It just gives me 3 slots to sprinkle in differences as needed moving forward. This sprinkling strategy avoids having to have a million test scenarios. So hopefully we'll be able to stick to 3 each and I can sprinkle what I need into these 3 to cover nearly all cases that actually might catch bugs.
There was a problem hiding this comment.
Fair enough. If we can't have more detail in the names of the folders, could we maybe have a README in each folder that describes the scenarios it covers?
There was a problem hiding this comment.
I just did the rename for now. Numbers, extensions... all the same to me.
packages/code-analyzer-eslint-engine/test/test-data/workspaceWithLegacyConfig2/.eslintrc.yml
Outdated
Show resolved
Hide resolved
…and emit fine log