Tool for generating dom related TypeScript and JavaScript library files
Перейти к файлу
Orta 3b0b89acc3 Uses unpkg to compare files 2021-08-25 18:22:17 +01:00
.github Update CODEOWNERS 2021-08-23 21:33:20 +01:00
baselines Merge pull request #1116 from microsoft/restore-HTMLDocument-constructor 2021-08-23 20:32:49 +00:00
deploy Uses unpkg to compare files 2021-08-25 18:22:17 +01:00
docs docs: try making the image more crisp on GitHub 2020-12-23 23:43:05 +01:00
inputfiles Merge pull request #1116 from microsoft/restore-HTMLDocument-constructor 2021-08-23 20:32:49 +00:00
src fix(41212,41334): removed duplicate interface extensions (#1112) 2021-08-23 19:56:08 +00:00
unittests Minimise assertions in htmldocument test 2021-08-23 12:34:35 -07:00
.eslintrc.cjs Use eslint+prettier 2021-03-08 16:38:51 +01:00
.gitattributes Initial commit 2015-10-01 01:12:06 -07:00
.gitignore Merge upstream 2021-06-29 13:30:48 +01:00
.mailMap Remove contributor info 2018-06-20 17:01:00 -04:00
.npmrc feat(package): add version hook 2021-06-12 16:56:15 +02:00
AUTHORS.md Update authors 2017-04-04 12:47:52 -07:00
LICENSE.txt add license 2015-11-11 10:35:24 -08:00
README.md Update README to match the new code (#1064) 2021-07-30 14:54:16 +00:00
dangerfile.js Omit the message when there's no changes 2021-01-13 12:09:59 +00:00
package-lock.json Update bcd to 4.0.0 2021-08-21 01:45:00 +02:00
package.json Update bcd to 4.0.0 2021-08-21 01:45:00 +02:00
tsconfig.json Merge upstream 2021-06-29 13:30:48 +01:00

README.md

TypeScript and JavaScript lib generator

This tool is used to generate the web-based lib.dom.d.ts file which is included with TypeScript releases, and as the @types/web package.

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.

Build Instructions

To get things setup:

npm install

To generate the .d.ts files

npm run build

To test:

npm run test

@types/[lib] to TypeScript Versions

@types/[lib] version TypeScript Version Minimum TypeScript Support
@types/web 0.0.1 ~4.3 4.4
@types/web 0.0.2 ~4.4 beta 4.4

@types/[lib] Minimum Target

The libraries available on @types/ like @types/web require a "target" of ES6 or above, because iterator APIs are included.

Contribution Guidelines

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/overridingTypes.jsonc or inputfiles/addedTypes.jsonc have a relevant item, which can be fixed if exists. If they don't, add one in overridingTypes.jsonc. Run 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.

This repo

Code Structure

  • src/build.ts: handles the emitting of the .d.ts files.
  • src/test.ts: verifies the output by comparing the generated/ and baseline/ contents.

Input Files

  • 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:

  1. Run:

    npm run migrate -- [previous_types_web_version]
    

    The script will look in for a clone of the TypeScript repo in "../TypeScript", or "./TypeScript" to move the generated files in. Or migrate the files manually, you do you.

  2. Update the README table with the mappings for versions in the @types/[lib]. E.g. TS 4.5 -> @types/web 0.0.23.

  3. Generate a CHANGELOG for the releases:

    #                       lib        from  to
    npm run ts-changelog -- @types/web 0.0.2 0.0.23
    
  4. Add the CHANGELOG to the release issue