[MAJOR] v8 planning

[bradzacher]

Milestone: https://github.com/typescript-eslint/typescript-eslint/milestone/9
Breaking changes: https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+label%3A%22breaking+change%22+milestone%3A8.0.0

Background

Discussing internally off the back of my tweet thread we're thinking about trying some smaller major releases this year.

Historically our major releases have always been quite large and unwieldy for users. We often rework many rules, change the AST, delete rules, remove options, and change the recommended configs. It's a lot for a user to read, understand and action and we have a hypothesis that this fuels fragmentation amongst our userbase.

On top of that these large releases are a massive piece of work for us to prepare - often taking months of work to prepare and build along with the constant pain of syncing the ongoing minor releases.

Our latest major release (v7) was a very small major - it just bumped minimum dependency requirements. This release is only a few weeks old and yet ~14% of the userbase has already migrated - which seems to support the above hypothesis as upgrading to v7 did not require much reading or effort from users.

typescript-eslint Version 8

For this major we're currently discussing which breaking changes make the cut.
Stay tuned as we update this post with relevant discussions.

[bradzacher]

#8554 - [rule-tester] support multipass fixes

[bradzacher]

This change will be invisible for linting users and should only cause minimal disruption for rule authors.
Proposal: keep for v8

[bradzacher]

#8347 - Enhancement: Differentiate AST node types without parent (for estree) and with parent (for eslint)

[bradzacher]

This change will be invisible for linting users. It will only impact programmatic consumers of @typescript-eslint/parser - of which there should be few.
Proposal: keep for v8

[bradzacher]

#8243 - Configs: [prefer-nullish-coalescing] change default for ignoreConditionalTests to true

[bradzacher]

TODO: @JoshuaKGoldberg and I still need to resolve this issue and decide if we agree on this change.

[JoshuaKGoldberg]

If we do go for it, I think it's a small enough change that we can lump it into v8. It makes the rule less strict by default. Not very user-action-needing.

[bradzacher]

#8113 - [no-invalid-void-type]: refactor to use type checking

[bradzacher]

This change will be a pretty major piece of work as we essentially need to rewrite the rule.
It has a very high user impact as it restricts users of the rule to type-aware linting users only.

Given we have a number of other rule changes slated for this release (eg deleting all formatting rules) it might be better to bump this to make it easier for us to action this major and for users to migrate.

Proposal: bump to v9

[JoshuaKGoldberg]

I'm in favor. Agreed both that this change is a good one and it's got big user impact. Given that the rule is only in strict, not recommended, this change isn't as important as the other ones. 👍

[bradzacher]

#8092 - deprecate no-var-requires in favor of no-require-imports

[bradzacher]

This will have high user impact as no-var-requires is a pretty widely used rule.
If we can ensure that no-require-imports is a mechanical replacement then the migration should be pretty straight-forward one.

Proposal: keep for v8

[bradzacher]

#8074 - 💀 Rule deletions: formatting rules

[bradzacher]

Very high user impact but migration should be pretty mechanical over to @eslint-stylistic.
This is a non-negotiable change as we want and need to shed the maintenance burden of the formatting rules.

Resolution: keep for v8

[bradzacher]

#6433 - AST cleanup: type parameter in TSMappedType

[bradzacher]

This is going to be a really large breaking change that will be painful for users to deal with.
It'll likely break an untold number of 3rd-party lint rules.

Proposal:

1. Drop from this major release
2. Make a backwards-compatible change (eg with both new and old properties) in v8
3. Remove backwards-compatibility in v9

[JoshuaKGoldberg]

Saving the 'breaking' part of this and #1305 for v9 feels like a repeat of our v7 strategy for dropping older backwards compatibility support. Which I like. It feels like we're moving towards alternating which majors are "big" (evens) vs. more for bumping minimum versions (odds).

[bradzacher]

#6403 - Error if configuration options aren't provided as expected

[bradzacher]

This is user-visible but should be very, very low impact as current misuse of options should be rare. Any errors revealed would show users problems with their config - which is a good thing.

Proposal: keep for v8

[bradzacher]

#5856 - Remove createIsolatedProgram call from getProgramAndAST

[JoshuaKGoldberg]

My preference would be to keep for v8. Per #5856 (comment), I can't think of a reason that someone would want this now.

[bradzacher]

#5855 - Investigate removing Program from isolated programs

[JoshuaKGoldberg]

My preference would be to keep for v8. Especially with the new project service settings, we really don't want people relying on isolated programs.

[bradzacher]

#1305 - Align AST for TSEnumDeclaration with TSInterfaceDeclaration, TSModuleDeclaration, etc

[bradzacher]

This is going to be a really large breaking change that will be painful for users to deal with.
It'll likely break an untold number of 3rd-party lint rules.

Proposal:

1. Drop from this major release
2. Make a backwards-compatible change (eg with both new and old properties) in v8
3. Remove backwards-compatibility in v9

[rubiesonthesky]

Discussing internally off the back of my tweet thread we're thinking about trying some smaller major releases this year.

Historically our major releases have always been quite large and unwieldy for users. We often rework many rules, change the AST, delete rules, remove options, and change the recommended configs. It's a lot for a user to read, understand and action and we have a hypothesis that this fuels fragmentation amongst our userbase.

I think this is good idea. It's also really hard to keep track of all the new rules that some minor versions introduce. I have had to update typescript-eslint that was lagging almost year behind it was impossible to read the changelog because there were so many versions 😅 Though, it was not a problem that I did not read it the changelog because there was no breaking changes :)

What I'm mostly thinking is, that it's nice to kinda get new major version that offers you new enabled lint rules, so you can get easily benefit from them.