Skip to content

Update README to match the new code #1064

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 30, 2021
Merged

Update README to match the new code #1064

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
386dae1
Update README to match the new code
saschanaz Jul 9, 2021
feb9d7c
Merge remote-tracking branch 'upstream/main' into readme
saschanaz Jul 9, 2021
7eba60f
feedback
saschanaz Jul 9, 2021
2ce5f03
link to contribution guidelines
saschanaz Jul 9, 2021
4aabbfa
Update README.md
saschanaz Jul 16, 2021
d47bac7
Update README.md
saschanaz Jul 27, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 13 additions & 58 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ This tool is used to generate the web-based `lib.dom.d.ts` file which is include

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 heuristics below and then please [file an issue](hthttps://github.com/microsoft/TypeScript-DOM-lib-generator/issues/new).
If the condition is met but still is not available here, first check the [contribution guidelines](#contribution-guidelines) below and then please [file an issue](hthttps://github.com/microsoft/TypeScript-DOM-lib-generator/issues/new).

## Build Instructions

Expand Down Expand Up @@ -38,82 +38,37 @@ npm run test

## Contribution Guidelines

The `dom.generated.d.ts`, `webworker.generated.d.ts` and `dom.iterable.generated.d.ts` files from the TypeScript repo are used as baselines.
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.

It's recommended to first check which spec the wrong type belongs to. Say we are to update `IntersectionObserver` which belongs to [`Intersection Observer`](https://www.w3.org/TR/intersection-observer/) spec, and then we can do:
### When the type is missing

1. First check we have the spec name `Intersection Observer` in `inputfiles/idlSources.json`. If not, add it.
2. Run `npm run fetch-idl "Intersection Observer" && npm run build && npm run baseline-accept`.
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](https://developer.mozilla.org/). 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 the above didn't fix the type issues, we can fix them via json files as a last resort.
There are three json files that are typically used to alter the type generation: `addedTypes.json`, `overridingTypes.json`, and `removedTypes.json`.
`comments.json` can used to add comments to the types.
Finally, `knownTypes.json` determine which types are available in a certain environment in case it couldn't be automatically determined.
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`.

The format of each file can be inferred from their existing content.
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.

The common steps to send a pull request are:
### When the type exists but is wrong

0. Open or refer to an issue in the [TypeScript repo](https://github.com/Microsoft/TypeScript) which might get moved back to this repo.
1. Update an IDL or add missing elements to `inputfiles/addedTypes.json`, overriding elements to `inputfiles/overridingTypes.json`, or elements to remove to `inputfiles/removedTypes.json`.
2. Run the build script locally to obtain new `dom.generated.d.ts` and `webworker.generated.d.ts`.
3. Update the files in the `baselines` folder using the newly generated files under `generated` folder (`npm run baseline-accept`).
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.

### What are the TypeScript team's heuristics for PRs to the DOM APIs

Changes to this repo can have pretty drastic ecosystem effects, because these types are included by default in TypeScript.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is mostly still true, right? I know we are less conservative than before, but the idea is that every update to @types/web will eventually ship with Typescript by default means that there are some changes that will not be OK until there's a way to publish other packages from here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, maybe it's good to keep the sentence for maintainers. It has minimal meaning for contributors though, since nearly all changes will now be from webref and MDN rather than manual PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know we are less conservative than before

I'm not sure, as quite a lot types are removed for lack of broad browser support?

Due to this, we tend to be quite conservative with our approach to introducing changes.
To give you a sense of whether we will accept changes, you can use these heuristics to know up-front if we'll be open to merging.

#### Fixes

> For example, changing a type on a field, or nullability references

- Does the PR show examples of the changes being used in spec examples or reputable websites like MDN?
- Did this change come from an IDL update?
- Does the change appear to be high-impact on a well-used API?
- Would the changes introduce a lot of breaking changes to existing code? For example the large corpus of typed code in DefinitelyTyped.

#### Additions

> For example, adding a new spec or subsection via a new or updated IDL file

- Does the new objects or fields show up in [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data)? If not, it's likely too soon.
- Is the IDL source from WHATWG?
- Are the additions available in at least two of [Firefox](https://searchfox.org/mozilla-central/search?q=&path=), [Safari](https://webkit-search.igalia.com/webkit/search?q=&path=) and Chromium?
- Is the IDL source from W3C?
- What stage of the [W3C process](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Specification_maturation) is the proposal for these changes: We aim for Proposed recommendation, but can accept Candidate recommendation for stable looking proposals.
- If it's at Working draft the additions available in all three of Firefox, Safari and Chromium
- Could any types added at the global scope have naming conflicts?
- Are the new features going to be used by a lot of people?

#### Removals

> For example, removing a browser-specific section of code

- Do the removed objects or fields show up in [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data)? If so, are they marked as deprecated?
- Does an internet search for the fields show results in blogs/recommendations?
- When was the deprecation (this can be hard to find) but was it at least 2 years ago if so?

## Build Instructions
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/index.ts`: handles the emitting of the `.d.ts` files.
- `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

- `browser.webidl.preprocessed.json`: a JSON file generated by Microsoft Edge. **Do not edit this file**.
- Due to the different update schedules between Edge and TypeScript, this may not be the most up-to-date version of the spec.
- `mdn/apiDescriptions.json`: a JSON file generated by fetching API descriptions from [MDN](https://developer.mozilla.org/en-US/docs/Web/API). **Do not edit this file**.
- `addedTypes.json`: types that should exist in either browser or webworker but are missing from the Edge spec. The format of the file mimics that of `browser.webidl.preprocessed.json`.
- `overridingTypes.json`: types that are defined in the spec file but has a better or more up-to-date definitions in the json files.
- `removedTypes.json`: types that are defined in the spec file but should be removed.
- `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.

Expand Down