RFC: Support [email protected]

[TylerJang27]

[email protected] was released and with it a major change to how eslint is configured. The migration process is nontrivial and may not be an option/priority for every project. Additionally, upgrading will loudly fail unless you have accounted for the config. Accordingly, I have done the following:

• Make direct_configs a property of commands, allowing us to version the configs that are applicable for linter
  • Users will only be upgraded/init'd/enabled at compatible versions with their config
• Modify the eslint tests to handle pre- and post- eslint9
• Upgrade this repo to use an eslint9 flat config
• Perform an audit and address a handful of the new diagnostics coming from eslint9

This will require a version bump and minimum requirement increase to support.

[trunk-io[bot]]

⏱️ 1h 59m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
Linter Tests macOS	1h	🟩 🟥 🟩
Linter Tests ubuntu-latest	22m	🟩
Windows Linter Tests	9m	🟩 🟩
Tool Tests (ubuntu-latest)	7m	🟩
Linter Tests macOS	6m	🟩
Tool Tests (macOS)	5m	🟩
Trunk Check runner [linux]	3m	🟩 🟩
CodeQL-Build	2m	🟩 🟩
Tool Tests (macOS)	2m	🟩
Action Tests	2m	🟩
Repo Tests / Plugin Tests	38s	🟩
Detect changed files	8s	🟩 🟩
Aggregate Test Results	6s	🟥 🟩 🟩
Action Tests	1s	⬜
Repo Tests / Plugin Tests	1s	⬜
Linter Tests Linux	1s	⬜
Tool Tests (Linux)	1s	⬜

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

[TylerJang27]

Ultimately, there are 2 existing issues warranting this change (or a similar one):

1. LUV cannot safely upgrade a user on [email protected] to [email protected], since it will 100% break said user, even with the environment variable override that doesn't really work
2. If we detect an eslint config, we need to know which version of eslint to enable at. Having an @package would alleviate this issue

[trunk-staging-io[bot]]

💊 0 quarantined ✅ 261 passed 🕐 266 new ⋅ (learn more)

_{docs ⋅ learn more about trunk.io}

[TylerJang27]

@det Plan for release since older CLI versions will naively respect LUV, AND also won't have the direct_configs update here:

1. Land this
2. Follow-up with a patch that omits eslint from LUV uploading
3. Release plugins
4. Let it marinate for ~1 week so that the newest LUV will stay at 8.57.0
5. Revert the patch so that LUV will have the correct newest validated eslint version

The patch is only necessary for extra caution, in case someone is on a new CLI version but not a new plugins version (or on an old CLI version).