fix: update types for RTF.p.formatToParts() result

[justingrant]

This PR:

• updates the type of RelativeTimeFormatPart to clarify that the unit prop is always singular in the result's array elements, unlike the plural or singular values that are accepted as inputs. Spec: https://tc39.es/ecma402/#sec-PartitionRelativeTimePattern step 5
• changes RelativeTimeFormatPart to be a discriminated union type because the unit prop is only present if the type prop's value is not "literal". Spec: https://tc39.es/ecma402/#sec-makepartslist step 3

Fixes #46245

@orta - what are the right tests to add for this kind of change?

[typescript-bot]

It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src'. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src'.

[ghost]

All CLA requirements met.

[justingrant]

It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src'. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src'.

I was a little confused by these dual files because only the lib versions had links to the relevant parts of the ECMA-402 specification. If we're not allowed to change lib files in a PR, then how to add a specification link for a brand-new type?

[DanielRosenwasser]

You'll need to make the update in src/lib, sorry that the message isn't clearer.

[justingrant]

You'll need to make the update in src/lib, sorry that the message isn't clearer.

@DanielRosenwasser the src/lib files don't contain links to the spec, only to MDN. The files in lib do contain spec links. If I'm not supposed to edit lib, then is there some other file that I need to edit to map APIs to spec links? If not, how do the spec links get there?

[justingrant]

You'll need to make the update in src/lib, sorry that the message isn't clearer.

@DanielRosenwasser the src/lib files don't contain links to the spec, only to MDN. The files in lib do contain spec links. If I'm not supposed to edit lib, then is there some other file that I need to edit to map APIs to spec links? If not, how do the spec links get there?

Still hoping to get an answer to this question.

[DanielRosenwasser]

Sorry, if they're not from src/lib, they're from https://github.com/microsoft/TypeScript-DOM-lib-generator

[DanielRosenwasser]

I've updated the bot's message for the future, thanks for pointing out that it wasn't clear, and sorry for the confusion!

[justingrant]

Sorry, if they're not from src/lib, they're from https://github.com/microsoft/TypeScript-DOM-lib-generator

@DanielRosenwasser - Sorry I still don't understand what are the right next steps in this PR.

1. Should I revert changes to lib/lib.es2020.intl.d.ts?
2. If (1) is "yes" then should I put links to the ES spec in my changes to src/lib/es2020.intl.d.ts?
3. If (2) is "no" then how will the spec links get into lib/lib.es2020.intl.d.ts, given that the most relevant spec link is not what's linked by MDN but is a bit deeper in the 402 spec?

The specific spec link I'm concerned about is https://tc39.es/ecma402/#sec-singularrelativetimeunit which is the most relevant link for the RelativeTimeFormatUnitSingular type that's added in this PR. AFAICT, this spec link is not present in MDN at all, so I'm not sure how it can get into lib/lib.es2020.intl.d.ts without me adding the link somewhere.

[DanielRosenwasser]

Okay, I reread the changes - a double apology for the misunderstanding.

You'll need to back out lib because we only change those files when we update the last-known-good state of the compiler, or create a release. Your changes in src will eventually make their way into a published release though.

[justingrant]

You'll need to back out lib because we only change those files when we update the last-known-good state of the compiler, or create a release. Your changes in src will eventually make their way into a published release though.

@DanielRosenwasser - OK that answers question (1) above, but not the other two questions:

• If (1) is "yes" then should I put links to the ECMA-402 spec in my changes to src/lib/es2020.intl.d.ts?
• If (2) is "no" then how will the spec links get into lib/lib.es2020.intl.d.ts, given that the most relevant spec link is not what's linked by MDN but is a bit deeper in the 402 spec?

[DanielRosenwasser]

If it's important, would it just make more sense to add content to MDN than to deep link to the spec? I don't think most users are interested in parsing spec text.

[justingrant]

If it's important, would it just make more sense to add content to MDN than to deep link to the spec? I don't think most users are interested in parsing spec text.

I assumed it was mostly needed for the TS team to verify that the types match the spec. Anyway, sounds like it's not needed so I just reverted the changes to lib/lib.es2020.intl.d.ts as requested. This PR should now be ready to merge unless there's other concerns. Thanks!