I always thought this rule is just for stylistic reasons. Otherwise (if you just care about declaration stability) why would you not use explicit-module-boundary-type instead?

Same question as @Josh-Cena. Also I personally very much like the stylistic preference of always enforcing return types, but no strong opinion.

I would be happy with explicit-module-boundary-type. Just as long as I don't have to keep annotating return types in all functions, always.

I always thought this rule is just for stylistic reasons

The big reason EFRT has remained is because it makes it easier to review PRs in github alone.

But TBH we're getting to a point of scale where most changes are pretty complicated and reviewing them in GH alone is hard.
Which is why I'm not able to review as much as I once did - most of my time is spent on mobile and it's impossible to review our PRs like that.

Additionally the place where EFRT shines is complex cross-boundary interactions where a change can cause unseen side-effects downstream somewhere. But almost all of our code is isolated and used within a single file - so you just don't have the same opportunity for actions-at-a-distance.

I think we're at this point where EFRT gets in the way more than it helps us. But I'm personally very strongly in favour of strictly typed module boundaries - so I don't think going to nothing at all is correct. Which leads us to EMBT or ID.

Realistically - ideally we should deprecate and remove EMBT now that isolatedDeclarations exists. The two systems look to implement the same things - though EMBT is actually much, much weaker of a check than what ID is. I don't really see a reason why all EMBT users couldn't migrate to ID.

The added benefit of ID is that you can switch ypur build over to oxc/swc/etc on top as well for that sweet sweet build speed improvement. Which I'm sure we would love too for a faster devloop and CI time.

Proposal: let's switch the repo to EMBT in the meantime, and file a followup issue each for deprecating EFRT and EMBT? Even if we decline either or both of those deprecations, IMO it'd be good to discuss separately.

and file a followup issue each for deprecating EFRT

To clarify:

EFRT is great and a completely useful style - just not one that I think has use for our project any longer. The rule should stay - people find value in it and there is no alternative.

EMBT is a great and useful style - but it's a weak subset of ID and realistically should be deprecated in favour of people just using ID.

Also note that ID would be easy to migrate to.
There are typed codemods to do the migration.

But we never built any tools for EMBT.

Having played around with ID a little bit - my experience was I don't think it's actually easy to migrate to, in general

• it significantly restricts what types can lie on the module boundary.
• it can't be used without declaration: true (note that our repo has specified declaration: false intentionally in some places).

(In my quick test in the typescript-eslint repo, we get no ID errors for the packages that currently specify declaration: true 🎉, but we get quite a few if we run it in eslint-plugin and eslint-plugin-internal)

Note that ID is also not actually a superset of EMBT, since it does allow inferred return types, as long as they're "simple" for computers to infer (as opposed to for humans to infer). (reference: go to the phrase "There are also certain expressions where the type is "trivial" to calculate." in the TS 5.5 blog)

Conclusion - I'd say if we turn off EFRT, I would significantly prefer using EMBT rather than trying to switch to ID.

(also will preemptively say -1 on deprecating EMBT or EFRT)