Repository navigation
Tag Releases for Easier Versioning #1383
Description
Today, the DOM types are auto-deployed to npm, but the story there is extremely confusing. If breaks are introduced in a newer version of TypeScript, we can tell users to lock down their DOM types with @types/web, but there's no easy way to tell which version of @types/web corresponds to a specific version of TypeScript.
We need to come up with some stable scheme where
- TypeScript's (stable) publishing process has a corresponding release (or tag for an existing release) for
@types/web. - a tag should be relatively easy to identify - something like
npm install @types/web@ts-4.9 - The tagging mechanism should also correspond to that of
@typespackages from DefinitelyTyped.
Activity
orta commentedon Aug 26, 2022
FWIW, there is the table in the README of this project which lists the versions - https://github.com/microsoft/TypeScript-DOM-lib-generator#typeslib-to-typescript-versions
You can also extend the deploy process I used https://github.com/microsoft/TypeScript-DOM-lib-generator#deployment-to-typescript to generate tags and/or update the README though.
I avoided automating this part because it's not guaranteed that the PR send from the DOM version would get merged (too breaky, and/or required DOM changes to get merged)
That could probably be improved by having the DOM -> TSC process leave a commit or tag inside the TSC repo and then on a TSC release you could have it re-use that commit/tag to make the connection from typescript back to the DOM types. Maybe be a custom header in lib.dom.d.ts which lets people link to the DOM repo at the exact commit/tag which is pretty useful for everyone.
xiaoxiangmoe commentedon Sep 1, 2022
Do all the built-in type libraries, including
lib.es5.d.tslib.webworker.d.ts, etc. need to be added in@types/webor some lib like@types/ecmascript?orta commentedon Sep 8, 2022
Nah.
@types/webjust accounts for the DOM APIS - you can override any lib using the techniques documented in https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modulesI think it's a reasonable assumption for types/web that someone has the baseline JS types set up
mrienstra commentedon Oct 22, 2022
I'd like to update the README to include
4.8&4.9 beta(though I guessbetahasn't hit a proper release yet?), but I'm not confident about how to go about matching up versions.Jul 02, 2022: @types/web@0.0.69
Jul 25, 2022: @types/web@0.0.70
Aug 03, 2022: @types/web@0.0.71
Aug 18, 2022: @types/web@0.0.72
Sep 17, 2022: @types/web@0.0.73
Sep 21, 2022: @types/web@0.0.74
Sep 23, 2022: @types/web@0.0.75
July 20, 2022:
v4.8-rcUpdate DOM lib for 4.8 RCJune 17, 2022:
v4.8-betaUpdate 4.8 DOM from Typescript-DOM-lib-generatorSep 21, 2022:
v?DOM update 2022/09/21August 11, 2022:
4.8 rcAug 25, 2022:
4.8OK, let's see,
PictureInPictureEventwas added in @types/web@0.0.70, but didn't show up in TypeScript'sdom.generated.d.tsuntil DOM update 2022/09/21, so presumably @types/web@0.0.69 goes with both4.8 rc&4.8. I'll open a PR for that.eligrey commentedon Feb 8, 2023
If
@types/webis only for "DOM APIs" then why is it@types/weband not@types/dom? I would expect@types/webto include all Web Platform API types. I believe that many of the current built-ins should also be moved to such a package.saschanaz commentedon Feb 21, 2023
It's not for "DOM APIs" but for general web APIs that are exposed in the main thread. DOM-lib here is just some legacy way to call the lib, which IMO should be replaced at some point.