[conaclos]

Note that `Readonly<T>` does not prevent a call to side-effect methods when `T` is not among a predefined set of built-in types. Indeed, it prevents such calls only on predefined types such as arrays, maps, and sets. It could be more "accurate" to use `readonly number[]` instead of `Readonly<Array<number>>` for highlighting the difference.

[cstrnt]

That's right. But I wanted to to use `Readonly<T>` because it can also be applied to plain objects while readonly cant

[BoorishBears]

That example disappointed me a little.

It was an easy catch because I was told there's an issue, but I'm surprised const arrays don't at least have a warning there. Or even default to having readonly-like behavior

[nosianu]

Which "const" do you mean? The one in front of a variable declaration cannot make the array itself constant. That's because that "const" only refers to that variable itself, which is just a pointer (except for the primitive types).

The variable declaration "const" means this variable cannot be changed to point to a different object. It says nothing about the thing it points to and that is how that keyword was designed in this language. It's Javascript (ECMAscript), not Typescript.

On the other hand, using Typescript (which only adds type annotations but the actual code is ECMAscript apart from very few small things such as "enums"), you can append "as const" after an array though as type annotation, as in

    const arr = [1,2,3] as const;

    // Type error: "Property 'push' does not exist on type 'readonly [1, 2, 3]'"
    arr.push(5);

Which is the same as Readonly<type>.

This "as const" annotation can be used for any object, not just for arrays. Of course, it can only guard against known methods of mutating an object, such as direct write access to properties and known mutating function calls for known object types such as the built-in ones (Array, Set, Map, etc., each one needs the definitions for the readonly-version of its type in the Typescript-bundled type library).

[ketzo]

Wow, the fact that `as const` has such a meaningful difference from a variable declared as `const` seems... not great.

Surely they could have gone with, like, `final` or `immutable` instead..? I'm sure they had their reasons. But seems rough.

[BoorishBears]

This comment would be a lot shorter if you assumed I meant Typescript in response to a Typescript article...

But I digress, the point is in my experience Typescript is very good about catching footguns left around by ECMAScript.

So I'm surprised there isn't some sort of catch for this as written in the article maybe behind a config flag, not by rewriting the definition.

[nosianu]

> if you assumed I meant Typescript in response to a Typescript article...

You misunderstand TypeScript.

They cannot 8and will not) change the "Javascript" in Typescript. "const" is a keyword with a meaning defined by the ECMAscript standard.

Typescript IS Javascript. All they do is add type annotations. Only some old non-essential features like namespaces and enums need to be transpiled, and "enums" really is not much and should actually be handled by whatever minifier and bundler/packager you use. Other than that, if you removed the type annotations you are left with 100% ECMAscript.

Typescript was meant to be just a type-annotation extension and explicitly made the decision that the code itself would always be stock-standard Javascript.

Arguably, it was a bad design decision that now confuses lots of people about the nature of Typescript by bundling type-checking and transpiling to some target (originally for older runtimes that did not understand es2015 or were lacking some feature available in the latest JS runtimes and ECMAscript standard).

It is therefore not a surprise at all that Typescript did not make "const" into something else. The basis always is the ECMAscript standard.