Add back APIs that are on the standard track even if they're not supported by all browsers #209
Assignees
Labels
area-api-missing
P1
A high priority bug; for example, a single project is unusable or has many test failures
type-enhancement
A request for a change that isn't a bug
Comments
srujzs
added
type-enhancement
This was referenced Mar 14, 2024
Closed
This was referenced May 8, 2024
srujzs
added a commit
to srujzs/web
that referenced
this issue
May 13, 2024
The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: dart-lang#209 dart-lang#234 dart-lang#216 dart-lang#205 dart-lang#203 dart-lang#192
srujzs
added a commit
to srujzs/web
that referenced
this issue
May 13, 2024
- Removes an unnecessary null-check - Refactors getTypeForUnionCalculation to a shared _getJSTypeEquivalent function - Avoids shadowing an instance variable
Closed
srujzs
added a commit
that referenced
this issue
May 21, 2024
* Only emit APIs that are standards track and not experimental The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: #209 #234 #216 #205 #203 #192 * Generate APIs based on standards track and not experimental * Handle some TODOs that came up when addressing #209 - Removes an unnecessary null-check - Refactors getTypeForUnionCalculation to a shared _getJSTypeEquivalent function - Avoids shadowing an instance variable * Address some lints * Update CHANGELOG and README * Add types to the field declaration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I thought this was being tracked in a previous bug somewhere, but can't find it.
Currently, we only emit members that are supported on all 3 browsers and are on the standard track. This is fairly limiting, as it excludes stuff like
TrustedTypes (which are allowlisted currently) andNavigator.deviceMemory, which are commonly used APIs. Instead, we should only care about whether something is on the standard track. TBD is whether we want to include stuff that is both experimental and standard track or only non-experimental.The text was updated successfully, but these errors were encountered: