| commit | 84d76a431953f7da4f70abf237fc80b9eee9ad0a | [log] [tgz] |
|---|---|---|
| author | Nate Bosch <nbosch1@gmail.com> | Fri Feb 22 10:27:31 2019 -0800 |
| committer | GitHub <noreply@github.com> | Fri Feb 22 10:27:31 2019 -0800 |
| tree | ee324d19438bc95830e6ddb9dc45d5a3de0198bb | |
| parent | f03ff4fe8892fe6592446a7c8d8e2f19ac4b137f [diff] |
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`.
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.