* Add fractionalSecond part type to DateTimeFormat().formatToParts
This change adds the `fractionalSecond` part type as a valid part
to be returned from Intl.DateTimeFormat().formatToParts().
Fixes microsoft#48882
* fixup
* Improve reduction of intersection types
* Accept new baselines
* Improve CFA for truthy, equality, and typeof checks
* Accept new baselines
* Remove special case for Function type
* Don't reduce intersections of form {...} & object
* Accept new baselines
* Anything is assignable to unknown-like union
* Accept new baselines
* Tweak subtype check
* Recombine unknown type from unknown-like union in more cases
* Display union origin only if it is shorter than union itself
* Accept new baselines
* Add tests
* Only attach origin type when it is shorter than union itself
* Specially preserve string & {}, number & {}, bigint & {}
* Accept new baselines
* Add additional tests
* Fix getNormalizedType and getNarrowableTypeForReference for intersections
* Switch NonNullable<T> to use T & {}
* Accept new baselines
* Use NonNullable<T> in place of anonymous T & {}
* Accept new baselines
* Add fourslash test
* More fourslash tests
* Fix getFalsyFlags handling of intersections
* Accept new baselines
* Add constraint to compareProperties type parameter
* Unconstrained type parameter not assignable to {} with strictNullChecks
* Accept new baselines
* Add es2018.intl ref to es2020.intl
es2020.intl refers to NumberFormatPartTypes declared in es2018.intl
as of #46508.
I'm not sure how to test this; it repros on Definitely Typed in
types/ndarray, but when I copy the same files into a compiler test it
passes without a problem.
* Add a test that shows the change works
It doesn't actually show that the original bug has been fixed,
though.
This commit updates the type of `RelativeTimeFormatPart` to clarify that
the `unit` prop is always singular, unlike the plural or singular values
that are accepted as inputs.
This also changes `RelativeTimeFormatPart` to be a discriminated
union type because the `unit` prop is only present if the `type` prop's
value is not "literal".
Fixes#46245
* Fix jsdoc of some `DataView` method.
* Add author by 'Fix jsdoc of some `DataView` method'.
* Fix jsdoc of some `DataView` method.
change 'written' to 'read' by `getXXX` methods, and remove 'otherwise' by every method which has `littleEndian` param.
* Fix jsdoc of some `DataView` method in `es2020.bigint.d.ts`.
change 'written' to 'read' by `getXXX` methods, and remove 'otherwise' by every method which has `littleEndian` param.
* feat(46907): Add ListFormat type declarations
* feat(46907): Fix JSDoc return type
* feat(46907): Use correct formatToParts list parameter type description, link to Array MDN page
* refactor(46907): Change ListFormatLocaleMatcher MDN link to match the rest
* feat(46907): Add explicit undefined to ListFormatOptions
* add Intl.Locale param type to locales argument in BigInt, Number, and Date methods
* update baselines
* add test for locales object arguments
* fix indentation
`ThisParameterType<(...args: X) => void>` expands to
`(...args: X) => void extends (this: infer U, ...args: any[]) => any`.
When `X` is an unresolved type parameter it is not possible to determine
that `any[]` is assignable to `X`. However `never` is always assignable
to `X`, so we use that instead.
Same as #47643, I just missed it until looking at remaining DT failures.
I need to update the DOM-lib-generator automation, but for now I want to
get TS types corrected.
* Add missing currencyDisplay to resolved number format options
* Move declaration to es2020
* Update es2020.intl.d.ts
* Fix bad merge
Co-authored-by: Orta Therox <ortam@microsoft.com>
Co-authored-by: Orta Therox <git@orta.io>
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Make Iterable Map constructor argument optional
Fixes#37779
* Change Map constructor in iterable to accept both null and undefined.
According to the spec (https://tc39.es/ecma262/#sec-map-iterable), the sole argument passed to Map is allowed to be null or undefined.
* Changed Map constructor to ensure new Map() still types as Map<any, any>.
* Add map constructor test.
This proves that the previous commit fixes#37779, as well as that new Map() still types as Map<any, any>.
* Update baseline.
Co-authored-by: Jared Neil <jaredneil@lucidchart.com>
