tree: e012963396212db49e9367a6f860038f964cddbc [search]
  1. bin/
  2. lib/
  3. test/
  4. package-lock.json
  5. package.json
  6. pubspec.yaml
  7. README.md
web_generator/README.md

This package contains generator scripts specific to package:web.

Web IDL Definitions

To generate Dart interfaces for a given .idl file, run the following at the root of this package:

dart bin/update_idl_bindings.dart

If multiple files are passed, the output option is regarded as an output directory instead.

To regenerate web bindings from the current IDL versions, run the entrypoint without any arguments:

dart bin/update_idl_bindings.dart

Update to the latest Web IDL versions and regenerate

To re-generate the package from newer IDL versions, you can either run:

dart bin/update_idl_bindings.dart --update

which installs the latest @webref/* and @mdn/browser-compat-data releases (including new major versions) into this package's package.json.

Alternatively, manually edit package.json to use specific versions, and re-run update_idl_bindings.dart.

Public API golden

web/tool/api.txt is a package:api_summary summary of package:web's public API, including member signatures, so API changes are visible in diffs. update_idl_bindings.dart regenerates it after generating the bindings, and web/test/api_test.dart verifies that it is up to date. To regenerate it manually, run the following in web/:

dart run api_summary --output tool/api.txt

The summary depends on the Dart SDK version, so regenerate it with a current dev or beta SDK (CI checks it on dev), not the minimum supported SDK.

Updating the dartdoc info from MDN

package:web's dartdoc comments come from the MDN Web Docs project. In order to update to the latest version of the documentation, run:

dart bin/scrape_mdn.dart

That will collect the MDN documentation into third_party/mdn/mdn.json; changes to that file should be committed to git. You'll need to run update_idl_bindings.dart to produce Dart code using the updated documentation.

Generation conventions

The generator scripts use a number of conventions to consistently handle Web IDL definitions:

Interfaces

  • Interfaces are emitted as extension types that wrap and implement JSObject.
  • Interface inheritance is maintained using implements between extension types.
  • Members of partial interfaces, partial mixins, and mixins are added to the interfaces that include them, and therefore do not have separate declarations.

Types

  • Generic types include the generic in the case of JSArray and JSPromise.
  • Enums are typedef'd to String.
  • Callbacks and callback interfaces are typedef'd to JSFunction.
  • In general, we prefer the Dart primitive over the JS type equivalent wherever possible. For example, APIs use String instead of JSString.
  • If a type appears in a generic position and it was typedef'd to a Dart primitive type, it is replaced with the JS type equivalent to respect the type bound of JSAny?.
  • Union types are computed by picking the least upper bound of the types in the JS type hierarchy, where every interface is equivalent to JSObject.
  • Dictionary and typedef types are only emitted if they're used by another API.

Compatibility

  • The generator uses the MDN compatibility data to determine what members, interfaces, and namespaces to emit. Currently, we only emit code that is standards track and is not experimental to reduce the number of breaking changes.

Generate all bindings

To ignore the compatibility data and emit all members, run:

dart bin/update_idl_bindings.dart --generate-all

This is useful if you want to avoid having to write bindings manually for some experimental and non-standard APIs.

Web IDL versions

Based on:

ItemVersion
@mdn/browser-compat-data5.6.42
@webref/css6.20.3
@webref/elements2.4.0
@webref/idl3.60.1