Detailed Intl.DateTimeFormatOptions types#38522
Detailed Intl.DateTimeFormatOptions types#38522johan wants to merge 2 commits intomicrosoft:masterfrom
Conversation
|
FWIW: the failing tests here are present on master and probably every other branch too (covering whatever might be right or wrong about my implementation here). They look like this, if this is the first time you hear of them: |
cd31e67 to
7c00ace
Compare
…meFormatOptions types
7c00ace to
5d2e09e
Compare
|
@sandersn, are you taking the opportunity with the 4.0 major release to land PRs like this that stricten overly-loose types? |
|
For this PR, I'm waiting for the originating issue #35865 to be discussed and accepted. That happens during regular backlog triage meetings, and is sometimes followed by a design meeting discussion with the whole team. In general, Typescript doesn't follow semver for a couple of reasons. The first is historical -- we started with the old-school point-release version numbers on a regular release schedule. The second is that is our product is all interface -- every release breaks things, and it's not easy to predict which things will break in a large code base, so there's little value in major-vs-minor releases. |
|
This PR has been blocked for quite a while, so I'm going to close it to keep the number of open PRs manageable. We can re-open it if #35865 gets accepted. |
Fixes #35865: Missing specific types in DateTimeFormatOptions.
This narrows the type info for
Intl.DateTimeFormatOptionsto legal inputs.Existing code passing options satisfying the former (overly-lax) types in shipping typescript (and which browsers would thus throw a run-time
RangeErrorexception for), will now be flagged as typescript compile-time errors, instead.