typescript-eslint VS proposal-explicit-resource-management

TypeScript Best Practices

Here’s some relevant discussion about some of the footguns:

https://github.com/typescript-eslint/typescript-eslint/issue...

https://github.com/tc39/proposal-explicit-resource-managemen...

I imagine there will eventually be lint rules for this somewhere and many of those using such a modern feature are likely to be using static analysis via eslint to help mitigate the risks here, but until it’s more established and understood and lint rules are fleshed out and widely adopted, there is risk here for sure.

Seems a bit like popular lint library maintainers are overly wary to add rules before it’s better understood through wider adoption and potential adopters are wary of using it until footguns are mitigated — not quite a standstill but maybe not great either

However, I prefer more thorough rules like checking unused type imports or type narrowing problems. In order to enable these checks, we need to tweak eslint.config.js. I prefer simply adding recommendedTypeChecked config to the project. Don't forget that you also need to adapt parserOptions to this change.

EsLint: New to ESLint? It helps you write better JavaScript and TypeScript. https://typescript-eslint.io/

For ESLint + TypeScript ESLint, with the new flat config eslint.config.js:

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

🧪 The Official TC39 Proposal for ?= – Follow the formal evolution of the feature

Similar to for-of.

[1] https://github.com/tc39/proposal-explicit-resource-managemen...

[2] https://github.com/tc39/proposal-explicit-resource-managemen...

The standard doesn't have anything to do with TypeScript, not sure where you got that from? https://github.com/tc39/proposal-explicit-resource-managemen...

The explicit resource management proposal tries to make it a bit easier for us, by allowing the resource to declare how it should be managed, rather than expecting us to clean everything up when we use the resource. We get a new keyword using to define a variable (rather than const or let), which tells the runtime to clean up the resource at the end of the function.

Enter the explicit resource management proposal, which describes — among many other things — a new using operator that was introduced in TypeScript 5.2 and is making its way into JavaScript. From the top of the README file, here’s what this proposal aims to do:

In addition to this, is the new (stage 3 even!)explicit resource management proposal[0], supported by TypeScript version >= 5.2[1]

Though I agree that async context is better fit for this generally, the RMP should be good for telemetry around objects that have defined lifetime semantics, which is a step in the right direction you can use today

[0]: https://github.com/tc39/proposal-explicit-resource-managemen...

[1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-u...

It's too early for that, https://github.com/tc39/proposal-explicit-resource-management

[3]: https://github.com/tc39/proposal-explicit-resource-managemen...