Use conditional imports for `dart:isolate` (#21)

This is specified as not existing on the web platforms, although in
practice it can be imported an at least one API works on DDC but not
dart2js. Since this may become more strict, use conditional imports with
an explicitly non-working fallback when `dart:isolate` is not available.

- Make `CurrentIsolateResolver` private and add a top level method
  instead since it is easier to stub.
- Rename `util_stub.dart` to `util_io_sub.dart` to avoid confusion
  against the new `util_isolate_stub.dart`.
9 files changed
tree: ee324d19438bc95830e6ddb9dc45d5a3de0198bb
  1. .gitignore
  2. .test_config
  3. .travis.yml
  9. analysis_options.yaml
  10. codereview.settings
  11. lib/
  12. pubspec.yaml
  13. test/

A package that defines a common class, PackageResolver, for defining how to resolve package: URIs. This class may be based on the current isolate's package resolution strategy, but it may also be explicitly defined by the user—for example, you could create a resolver that represents the strategy used to compile a .dart.js file.

The Dart VM provides two mutually exclusive means of resolving package: URIs: a package spec and a package root.

  • A package spec usually comes in the form of a .packages file on the filesystem. It defines an individual root URL for each package name, so that package:$name/$path resolves to $root/$path.

  • A package root is a single URL that acts as the base for all package: URIs, so that package:$name/$path resolves to $base/$name/$path.

This normalizes access to these resolution schemes, and makes it easy for code to resolve package URIs no matter where the resolution information comes from.