This tool is used to generate the web-based
lib.dom.d.ts file which is included with TypeScript releases, and as the
Why is my fancy API still not available here?
A feature needs to be supported by two or more major browser engines to be included here, to make sure there is a good consensus among vendors: Gecko (Firefox), Blink (Chrome/Edge), and WebKit (Safari).
If the condition is met but still is not available here, first check the contribution guidelines below and then please file an issue.
To get things setup:
To generate the
npm run build
npm run test
@types/[lib] to TypeScript Versions
||TypeScript Version||Minimum TypeScript Support|
@types/[lib] Minimum Target
The files in the
baselines/ directory from the TypeScript repo are used as baselines.
For each pull request, we will run the script and compare the generated files with the baseline files.
In order to make the tests pass, please update the baseline as well in any pull requests.
When the type is missing
It's possible that the automated algorithm decided that it's not well supported by browsers and thus removed it. Say we want to add a new interface named
Foo. Check if there is a document about that interface in MDN. If there is, see the browser compatibility section and check whether it's supported by two or more browser engines. (Note that Chromium-based browsers use the same browser engine and thus support from them counts as a single support.)
If all the conditions are fulfilled, it could be that the type is incorrectly removed by
inputfiles/removedTypes.jsonc. Try finding and removing the relevant item there and run
npm run build && npm run baseline-accept.
If conditions are not fulfilled but you think MDN is wrong, please file an issue at https://github.com/mdn/browser-compat-data/issues/. The type will be automatically added in a few weeks when MDN fixes their data.
When the type exists but is wrong
It's possible that the type is too specific or too general. First you need to check whether
inputfiles/addedTypes.jsonc have a relevant item, which can be fixed if exists. If they don't, add one in
npm run build && npm run baseline-accept to make sure the resulting changes are what you want.
If you are familiar with Web IDL, you may also want to check whether the upstream IDL itself can be made more specific. Doing so will reduce the need for manual overrides in this repository and thus can be more helpful.
src/build.ts: handles the emitting of the
src/test.ts: verifies the output by comparing the
mdn/apiDescriptions.json: a JSON file generated by fetching API descriptions from MDN. Do not edit this file.
addedTypes.jsonc: types that should exist but are missing from the spec data.
overridingTypes.jsonc: types that are defined in the spec but have TypeScript-friendly modifications in the json files.
removedTypes.jsonc: types that are defined in the spec but should be removed.
comments.json: comment strings to be embedded in the generated .js files.
deprecatedMessage.json: the reason why one type is deprecated. The reason why it is a separate file rather than merge in comment.json is mdn/apiDescriptions.json would also possibly be deprecated.
Deployment to TypeScript
To migrate the *.d.ts files into TypeScript:
Trigger the workflow here - this will send a PR to TypeScript under your alias.
Update the README table with the mappings for versions in the
@types/[lib]. E.g. TS 4.5 ->
0.0.23. Find that number here: https://www.npmjs.com/package/@types/web
Generate a CHANGELOG for the releases:
# lib from to npm run ts-changelog -- @types/web 0.0.2 0.0.23
You might need to run
git pull origin main --tagsto run this ^
Add the CHANGELOG to the release issue