u/LunarLurker-42

TypeScript 7 shipped in July as the Go port, billed as roughly 10x faster. The line that matters for linting is in the same announcement: 7.0 does not ship with an API, and typescript-eslint is named as one of the tools that still needs programmatic access to the compiler. There is a compat package, u/typescript/typescript6, that installs a tsc6 executable and re-exports the 6.0 API, with a new API expected in 7.1.

So the speedup that would matter most to typed linting is the one you cannot have yet. typescript-eslint's own performance page says that with type-aware linting your lint times should be roughly the same as your build times. Builds got most of an order of magnitude faster and the typed rules still sit on the 6.0 checker.

Which makes Biome's timing look luckier than it probably was. Its inference engine arrived with v2 in June 2025 and got its own types domain in 2.4 this February, and it does type-aware rules without loading the compiler at all. Their own preliminary figure for noFloatingPromises is about 75% of the cases typescript-eslint catches, at a fraction of the performance impact, with a warning right after it that the early numbers rest on a limited set of use cases. The docs also say a types domain rule makes Biome scan the whole project and switch the inference engine on, so that path is not free either.

On my repo the diff gets read by lint, by typecheck in CI, and by a review agent in verdent before anyone opens the PR, and I have no measurement telling me which layer is doing the work.

What are people doing in the gap? Pinning tsc6 to keep the typed rules, running Biome's approximate set on save, or waiting for 7.1?

Someone in a group chat called what I do passive income last week and it has been bugging me because it is not even close.

I configure video generation setups on hardware that clients own. They buy the machine, I get the stack running on it, test it, hand it over. Then I charge a monthly retainer to keep it working. That retainer is the part people hear about and call passive.

The setup is real work. The models I deploy publish no memory requirements and no hardware specs in their docs. Every installation is you testing whether a specific machine can hold the full workload or not. If it cannot, you find out when the process crashes. There is no reference table. You run it and see.

The retainer exists because nothing stays configured on its own. Driver updates break inference. Clients want new model weights swapped in and each swap has to be tested on their card. Optimizations that claim to save memory sometimes degrade output badly enough that you roll everything back. The setups I keep running include things like CogVideoX, LingBot-Video-MoE (30B-A3B), and Mochi, and none of them stay stable without someone watching.

I test every change on Vast.ai first because breaking a production machine you do not own ends the retainer.

The part nobody tells you: the retainer is tied to a specific machine. When that hardware goes down, the income stops and the months you spent building the relationship count for nothing. You have no control over when that happens.

It is not passive. It is recurring work that stops the moment the hardware does.

[AskJS] TypeScript 7 is 10x faster, but typed linting still runs on the 6.0 API. What are you doing in the gap?

My maintenance retainer gets called passive income a lot and it is not even close