Add Intl.Locale to es2020 lib

[boenrobot]

Search Terms

Locale, intl

Suggestion

Add Intl.Locale to the es2020 build target libs. It is supported in recent NodeJS versions, and recent Chrome versions, making it a suitable feature for inclusion.

Use Cases

Using the new Intl.Locale feature.

Examples

console.log((new Intl.Locale('en-US')).language); // Outputs "en"

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.

[RyanCavanaugh]

We'd prefer things be more broadly adopted (e.g. in Safari) before adding them to the built-in definitions.

[Dangoo]

Thanks @boenrobot for bringing this up!

This was added in Safari TP 107 (261215) as listed here on May 28th:
https://webkit.org/blog/10585/release-notes-for-safari-technology-preview-107/

Implemented Intl.Locale

[Dangoo]

Already have the types prepared. So just let me know when you are ready to accept a PR for that.

[boenrobot]

Cool!

About the types... I think it's a bit too restrictive and not future proof to require only the enumerated values in the option, especially since the standard isn't fixed... Maybe add "| string" as a possible option, so that IDEs can assist, but also have TS not complain if a different value is supplied? Keep (and maybe even export) the enumerations, so that if one wants to force the value to be among the enumerated, they can?

[Dangoo]

@boenrobot good catch!
I think this would do?

interface LocaleOptions {
    baseName?: string;
    calendar?: LDMLCalendarKey | string;
    caseFirst?: LDMLCollationCaseFirst | string;
    collation?: LDMLCollationKey | string;
    hourCycle?: LDMLHourCycleKey | string;
    language?: string;
    numberingSystem?: LDMLNumberingSystemKey | string;
    numeric?: boolean;
    region?: string;
    script?: ScriptCode | string;
}

Regarding the export this should already be the case since declared as namespace. So e.g. Intl.LDMLCalendarKey should already be available.

[longlho]

Couple of comments here:

• LMDLCalendarKey should just be a string. See https://ecma-international.org/ecma-402/7.0/index.html 10.1.3 Intl.Locale. There's no verification for calendar.
• LMDLCaseFirst should not be | string. Invalid value will trigger RangeError, see https://ecma-international.org/ecma-402/7.0/index.html#sec-Intl.Locale
• LDMLCollationKey should just be string.
• LDMLHourCycleKey should not be | string. Any value that's not h11, h12, h23, h24 will throw a RangeError. See https://ecma-international.org/ecma-402/7.0/index.html#sec-InitializeDateTimeFormat
• LDMLNumberingSystemKey should not be | string. See https://ecma-international.org/ecma-402/7.0/index.html table 4. Future addition to this will require a Normative spec change. See Normative: Update Table 4 Numbering systems tc39/ecma402#438 for example.
• ScriptCode should just be string.

The main reason for string type instead of enum is bc ECMA402 does not require CLDR so those are considered implementation details. You can have a runtime env that does not support those things.

[longlho]

@RyanCavanaugh shouldn't the criteria be stage 4? Stage 4 does include adoption criteria of at least 2 tst262-compatible implementations

[Dangoo]

@longlho thanks for your comments.
I brought it up as draft PR against this repo and removed the enum for numberingSystem as well.
Let's see when we get green lights from the maintainers for this.

It appears Intl.Locale will be available with Safari 14:

[orta]

Yeah, this should be OK to go now, tested it in Firefox too. 👍

[hbroer]

Hi, I need the types for a project. I have copied it from the PR to a .d.ts file but that only works while development within jest. I can't build it with my tooling (microbundle -> rollup -> rollup-plugin-typescript2) because the types are missing then. I did not found any @types or other solution to get it working. I wonder that this types is not supported by typescript at esnext/es2020 yet. Has anyone a idea how to add the types until this is supported by TS?

[longlho]

You can use @formatjs/intl-locale

[hbroer]

Thanks @longlho will try that out.