We right now have no-explicit-any moved into the strict config for v6. But I understand you were expecting it to be enabled. I'm now wondering if we should keep it at recommended?

For context, strict is something we recommend for more confident TypeScript users. https://v6--typescript-eslint.netlify.app/linting/configs#strict

so what's the main difference in strictness between

strict-type-checked and the old recommended-requiring-type-checking?

The strict & strict-type-checked rulesets are a lot more opinionated. We phrase them as "Additional strict rules that can also catch bugs but are more opinionated than recommended rules.". In v6 they're supersets of the respective recommended & recommended-type-checked configs.

https://v6--typescript-eslint.netlify.app/rules/?supported-rules=xrecommended-strict shows the rules that are in strict* and not recommended*.

after reading through the list, i would definitely want about 2/3 of the strict rules and am neutral-but-could-be-pushed-positive on the remaining 1/3.

for teams that are less experienced at typescript, i think autofixing where possible + good documentation for the errors could move quite a few of the rules into "reasonable for most teams" territory.

what is the motivation for moving no-explicit-any to the strict rules?

IIRC it was that a lot of projects end up needing to use any (or at least their developers think they do), and we're trying to not be in people's way as much with the recommended rulesets. In a sense this is us capitulating to how new & intermediate TypeScript developers write code (the occasional any, not always doing type safe things). Capitulating means less friction in turning on the recommended rulesets, at the cost of being less useful out-of-the-box.

Do you think educating those users to try to use unknown instead could help adoption?

Yes, definitely. A lot of these lint rules are better from user education - and can themselves act as user education!

Which reminds me, https://typescript-eslint.io/rules/no-explicit-any could do a bit better in that regard. Filed typescript-eslint/typescript-eslint#7136. Thanks! 😄

Just following up, I finally got around to documenting this: typescript-eslint/typescript-eslint#8370

https://v6--typescript-eslint.netlify.app/rules/consistent-type-definitions is the rule to enforce which of interface or type you prefer to use consistently. In v6 right now it's moved from strict to stylistic. How does that make you feel?

For reference, a couple of full text regex searches on the next branch:

• interface .+ \{: 44 results in 40 files
• type .+ = \{: 14 results in 12 files

this is one of the few that i don't feel strongly about.

my personal preference is "type by default, interface only if necessary (ie need to extend)" but judging by these stats that's not actually what we're doing currently.

what's the eslint team's opinion on this?

We in typescript-eslint¹ have interface over type as the default in our recommended rulesets, but I don't believe any of us feel extremely strongly about it. I personally don't. IMO the most important thing for a codebase is to standardize on one to reduce confusion.

I personally have leaned towards interfaces because they've historically had better error messages in edge cases than type. Though over the last couple of years, TypeScript has gotten a lot better at using names for types. So that's not as powerful a motivator as it used to be...

I recommend using type for literals and primitives (also unions and intersections of them), and interface for all other types. The Performance page in the official TypeScript wiki recommends interface for object types because of performance options and the ability to augment types.

one big argument in favour of "type by default" is that you can't accidentally merge with globals, see https://tsplay.dev/wjanvW

and i guess it also lets you know when you read a signature that what you're looking at is what you'll get as no merging can happen anywhere down the line.

but i agree by far the most important thing is picking a set of rules and sticking with them. i'd like create-t3-app to use whatever can reasonably be called the "default" behaviour for this sort of stuff unless there's a very good reason not to.

Just to be clear - would you like me to disable the rule and revert its changes? I'm happy to, just not sure from the discussion 😅

https://v6--typescript-eslint.netlify.app/rules/sort-type-constituents - is newly in the stylistic config. While it does have an autofixer, I do worry that it's too nitpicky and will annoy people. Thoughts?

i think i like it, makes it more like interface where the things you extend comes first

Great - if we end up removing it from the config, I can manually re-enable it in this PR.

i like this a lot as well. if i'm reading an interface, i don't want to miss the fact that it extends something.

Without this, the type checked rules don't have the right compiler options: most notably strict: true.

Re versioning: I'm guessing you won't want to merge this PR until we're out of alpha/beta/rc and in 6.0.0 stable. Noting here explicitly because otherwise I think this PR is ready for review. 🙂

👍🏼

why are the resolutions needed though?

Some nested dependencies still rely on 5.x. If you remove them locally & re-run pnpm i then the pnpm-lock.yaml gets a bit bigger. Example:

  /astro-eslint-parser@0.14.0:
    resolution: {integrity: sha512-3F8l1h7+5MNxzDg1cSQxEloalG7fj64K6vOERChUVG7RLnAzSoafADnPQlU8DpMM3WRNfRHSC4NwUCORk/aPrA==}
    engines: {node: ^14.18.0 || >=16.0.0}
    dependencies:
      '@astrojs/compiler': 1.4.1
      '@typescript-eslint/scope-manager': 5.59.11
      '@typescript-eslint/types': 5.59.11

i see - is this just needed when trying the beta and something that can be removed later?

It should be yeah. This PR was useful for me in seeing who in the community we need to ask to add || 6 support! 😄