Definitelytyped: typesVersions gets mangled in the published package

[ulrichb]

Compare https://github.com/DefinitelyTyped/DefinitelyTyped/blob/e9103792668257b6cc86cd21d6c455ecb5fae1ea/types/node/package.json#L4-L18 with https://unpkg.com/@types/node@13.13.2/package.json

Screen:

You see the order is reversed therefore doesn't work as the order must be high to low version. see https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-1.html#multiple-fields.

[ulrichb]

@sandersn:

This seems to be a general problem (not node-typings specific) in the publishing process, as e.g. the jsdom typings have the same problem. Compare https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jsdom/package.json vs. https://unpkg.com/@types/jsdom@16.2.1/package.json.

[G-Rath]

Hey look its me!

~This could maybe be the cause of #44142 🤔~ false alarm, it's not 🙂

Can confirm that this does mean the new asserts guards can't be used :(

[sandersn]

Looks like I can't transfer issues across orgs :angry: I created microsoft/types-publisher#772 to track this.

[ulrichb]

@sandersn Okay cool. Thx

[sandersn]

@rbuckton points out that dtslint currently requires one-sided ranges like >=3.1 but should actually require two-sided ranges for all but one of the typesVersions entries. That way order would not matter.

(I'm going to fix the re-ordering first, but changing the range lint check is definitely better long-term.)

[Gerrit0]

It seems like the reordering is fixed, at least for @types/node.

https://unpkg.com/@types/node@13.13.5/package.json

[ulrichb]

@sandersn Can we close this issue?

[sandersn]

Yep!