commit | 8a70d3e4040b2b1ae02b585dedb620eac9e3fdb5 | [log] [tgz] |
---|---|---|
author | Natalie Weizenbaum <nweiz@google.com> | Mon Aug 08 23:23:50 2016 |
committer | Natalie Weizenbaum <nweiz@google.com> | Mon Aug 08 23:23:50 2016 |
tree | a6c6a0933717a5825239cf8bd026fac192ec477b | |
parent | 0b63bf3d6c62adec83638565fcbc71ae7406c8d9 [diff] |
Fix current_isolate_info_test. This test didn't actually work when run with a package root rather than a package config, as is the case in Google-internal tests. R=jmesserly@google.com Review URL: https://codereview.chromium.org//2224203002 .
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.