proposal-record-tuple VS typescript-eslint

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.

This will become very useful once Records and Tuples are a thing, because it allows you to store object references in a record/tuple (which by definition can only contain primitives).

Record and tuple is at stage 2

Also, js has an ongoing immutable value data types proposal.

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

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):