Support for as const in Javascript

[arciisine]

Search Terms

const array, javascript, as const

Suggestion

The as const feature allows for treating literal arrays as tuples, and is useful for API design. I'd like to be able to leverage this from javascript when consuming a typescript package.

Seeing as the user cannot denote as const for arrays in javascript itself, I was hoping there could be a path to define a function parameter as a const array. This would only work if passing in an array literal, but for API design could be extremely powerful.

It would also be useful to convey the intent that a parameter supports a const array as well.

Use Cases

Primary use case for this, will be for API designers, to allow for more expressive typings.

Examples

Field Extraction

Typescript

function pick<T extends Readonly<string[]>, V extends Record<T[number], any>>(
     o: V, retain: T): Record<T[number], V[T[number]]> {
    ...
}

const res = pick({ a: 10, b: 20, c: 30 }, ['a'] as const);
// typeof res is { a: number }

Javascript

const res = pick({ a: 10, b: 20, c: 30 }, ['a']); // as const is not accessible
// typeof res is Record<string, any> 

CSV Object Creation

Typescript

function fromCSV<T extends Readonly<string[]>>(
   o: string[], fields: T): Record<T[number], string> {
 ...
}

const row = ['a','b','c','d'];
const obj = fromCSV(row, ['Name', 'Age', 'Height'] as const);
// typeof obj is { Name: string, Age: string, Height: string};

Javascript

const obj = fromCSV(row, ['Name', 'Age', 'Height']);
// typeof obj is Record<string, string>

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[lll000111]

I'd like to be able to leverage this from javascript when consuming a typescript package.

What does that mean?? You want something in the type system that compiles to (JS) CODE? Because otherwise that request is impossible, since the types are completely gone at that point. If this is what you want, you won't get it — there is no way a request to create JS code for a type annotation will be accepted (and that's good).

Apart from that, what is wrong with ReadonlyArray<type> and readonly type[]? You don't even make a reference to those two options.

I was hoping there could be a path to define a function parameter as a const array

This is exactly what these two mentioned options already provide.

I cannot imagine I'm alone saying that I don't understand what you want exactly. The use case is very unspecific too.

It does sound like you are confused about "types" in TS vs JS. Your last example under "Javascript" lists a Typescript type! Where would that come from??

[arciisine]

I'd like to be able to leverage this from javascript when consuming a typescript package.
What does that mean??

This means having typing information the .d.ts files that would allow the typechecker to infer a type as if it were specified using as const. The feature request is only regarding the type system, nothing to do with emitted code or run-time behavior.

Apart from that, what is wrong with ReadonlyArray and readonly type[]? You don't even make a reference to those two options.

Readonly array is in the code examples as it is needed to support as const properly.

Without the as const modifier, the inferred type of ['a','b','c'] is string[]. While this is correct, it's not as specific as the as const behavior would provide. With as const the type would be inferred as ['a','b','c'], which is the desired state per the code examples.

In Typescript, this is achievable by casting the literal, but javascript supports no such option (which is the problem). The as const behavior is desirable (as it provides better typing information, and more expressiveness) and Javascript is currently unable to benefit from that information.

Hope that clarifies the desired goal.

[jcalz]

So you want to annotate fromCSV() and pick() so as to infer narrower types from literal arguments? If so, this is related to #30680.

[arciisine]

That looks to be exactly the right issue. Will close in lieu of #30680.