v5

[ljosberinn]

What needs to be done is:

• [ ] update all dependencies to latest
  • largely frictionless until Flat Config comes into play
• [ ] this include migrating to flat config
  • likely the biggest "problem"
• migrate to LTS node
  • this may include using ESM for everything 🎉
• [ ] (for now) drop incompatible rules/plugins such as eslint-plugin-etc as you've brought up
• [ ] obviously ensure everything still works in accordance with tests
• [ ] deal with (un)expected fallout of flag config shenanigans. I have a hunch that it'll change the structure to the degree of practically a rewrite -- which I'm personally fine with but you can imagine this comes with more work
• [ ] re-evaluate all current bugs, such as:

  • 776

  • 775

  • 774

  • 760

  • 759

  • 757

  • 665

  • 622

  • 573

  • 551

• [ ] consider dropping CRA support, it's not only fallen out of fashion over recent years but also has not only be a pain to maintain and not been maintained itself for over 2 years
• [ ] evaluate eslint-plugin-json
• [ ] evaluate eslint-plugin-vitest
  • [x] flat config compatible
• [ ] evaluate eslint-plugin-playwright
  • [ ] supposedly flat config compatible according to merged PR, dependencies mention ^8.50 of ESLint

Originally posted by @ljosberinn in https://github.com/ljosberinn/eslint-config-galex/discussions/779#discussioncomment-9381384

[axelboc]

Thought I'd share some learnings that may be helpful when you upgrade TypeScript and @typescript-eslint/eslint-plugin (no rush 😉).

TypeScript has deprecated importsNotUsedAsValues since v5. I initially thought the replacement for this was verbatimModuleSyntax but turns out it's a bit more complex because importsNotUsedAsValues was never meant to be used to enforce the import type ... code style in the first place ... and neither is verbatimModuleSyntax.

The recommendation from this article seems to be to remove importsNotUsedAsValues and verbatimModuleSyntax altogether from tsconfig.json and to use ESLint rules instead.

Moreover, with inline type qualifiers, the best practice for dealing with type imports seems to have changed a bit, in particular when it comes to duplicate imports. Here is what I think we should aim for:

1. Enforce the use of type qualifiers for type-only imports:

   // Correct
   import { type Foo } from './utils'
   const foo: Foo = 1;
   
   // Incorrect
   import { Foo } from './utils'
   const foo: Foo = 1;

2. Enforce the use of inline type qualifiers for type-only imports (note that statements that contain only inline type imports are correctly removed by tsc when verbatimModuleSyntax is disabled):

   // Correct
   import { type Foo } from './utils'
   
   // Incorrect
   import type { Foo } from './utils'

3. Never allow duplicate imports, even when types are involved, thanks again to inline type qualifiers:

   // Correct
   import { Bar, type Foo } from './utils'
   
   // Incorrect
   import { Bar } from './utils'
   import type { Foo } from './utils'
   
   // Incorrect
   import { Bar } from './utils'
   import { type Foo } from './utils'

From what I gather, this would be achieved with the following rules:

• @typescript-eslint/consistent-type-imports with { prefer: 'type-imports' } (already enabled by Galex) to enforce requirement nb 1
• @typescript-eslint/consistent-type-imports with also { fixStyle: 'inline-type-imports' } (not yet configured by Galex) to enforce requirement nb 2
• import/no-duplicates with { 'prefer-inline': true } (currently disabled by Galex in TS projects) to enforce requirement nb 3

I think rule import/consistent-type-specifier-style, which is enabled by Galex with { 'prefer-inline': true }, should then be disabled, as I think it does the same thing as { fixStyle: 'inline-type-imports' } in @typescript-eslint/consistent-type-imports.