Rewrite "package:" imports in Dart files in build output

[sigmundch]

Since pub conventions imply there is a packages/ directory next to each entrypoint file, you can often do things like this in an html file:

<script src="packages/browser/dart.js">

or for polymer apps:

<script src="packages/shadow_dom/shadow_dom.min.js">

When building with 'pub build' it seems that we only include a packages/ directory at the top level. So if you have an .html file in a subdir, for instance "web/dir/a.html", containing a url like above, then it wont work after building.

We should either create a packages dir under each sub level, or write a transformer that normalizes these urls.

[munificent]

We should either create a packages dir under each sub level,

We don't want to do that because it leads to a bunch of duplicate files.

or write a transformer that normalizes these urls.

Yeah, we should probably do something along these lines. We should spend some time thinking/talking and figure out how we want to holistically deal with paths like this.

[sigmundch]

Two temporary workarounds for users that get to this issue.

* (idea 1) create a symlink to add the missing packages folder. For example,

  ln -s $PWD/build/packages build/dir/packages

* (idea 2) refer to the 'packages/' folder inside web/, for example, instead of writing:

  <script src="packages/foo/bar.js">

use:

  <script src="../../../packages/foo/bar.js">

with as many '..' as you need to reach the 'web/' folder.

Note for polymer users: you also need to include some additional tags to load the polyfills. Polymer normally injects script tags in your html page to load these, but the injected tags will use the format that starts directly with 'packages/'. The good news is that polymer only injects the tags if you don't have them already in your page. So if your entrypoint already contains these tags, it will leave them as they are. So you can do this to work around this bug. You'll need a total of 3 tags:

  <script src="../../../packages/shadow_dom/shadow_dom.min.js"></script>
  <script src="../../../packages/custom_element/custom-elements.min.js"></script>
  <script src="../../../packages/browser/interop.js"></script>

as before, this is as many ../ as you need to get to the web/ directory. You can also choose between the '.min.js' or '.debug.js' versions of the polyfills.

[nex3]

I think the long-term correct solution here is to support "asset:" URLs in HTML and transform those. So the script tag in this case would be

    <script src="asset:browser/dart.js">

We want to get rid of physical "packages" directories in general, so any script tags pointing to them will fail to work eventually anyway.

[sigmundch]

I worry that 'asset:browser/dart.js' is not a valid URL and using that will force everyone to have to use pub-serve/pub-build even during development.

Alternatively, we could design some standard pub-transformers that can run directly in dartium.

[munificent]

Removed Priority-Unassigned label.
Added Priority-Medium label.

[nex3]

I worry that 'asset:browser/dart.js' is not a valid URL and using that will force everyone to have to use pub-serve/pub-build even during development.

This is the direction we're heading regardless. As the editor switches to use pub build/serve rather than its built-in functionality, they'll be the only way to run dart2js as well. As more packages provide and use transformers, transitive dependencies will cease to work without pub build/serve. I don't think this is necessarily a problem.

Alternatively, we could design some standard pub-transformers that can run directly in dartium.

I don't understand what you mean by "run directly in dartium". Transformers can only run within the context of pub, on the command line.

[munificent]

Collapsing some bugs here. Here's our current intention for this:

If you run pub build in debug, you'll get Dart files in the build output. There will likely be other ways in the future of getting Dart files in your output. If they contain "package:" imports, those will fail unless the Dart file happens to be in the top level of the build output where we put the one copy of "packages".

For all other cases, there is no adjacent "packages" directory. To fix that, we want a built-in transformer in pub that rewrites those imports to relative ones that walk up to the main "packages" directory.

[munificent]

Issue #16649 has been merged into this issue.

---

cc @nex3.
cc @sigmundch.

[munificent]

Changed the title to: "Rewrite "package:" imports in Dart files in build output".

[nex3]

If you run pub build in debug, you'll get Dart files in the build output.

I'm not sure this is the right behavior anymore. I don't think there's a lot of value in supporting packages directories everywhere in debug mode if we can't do it in release mode -- it just runs the risk of people writing their applications under the assumption that it will work everywhere. I think we should aim to eventually have only one top-level "packages" directory per root directory in both debug and release mode of both build and serve.

[munificent]

I think we should aim to eventually have only one top-level "packages" directory per root directory in both debug and release mode of both build and serve.

Yes, agreed. I think the comments here are more or less to that effect.

[munificent]

Removed Type-Defect label.
Added Type-Enhancement label.

[DartBot]

This issue has been moved to dart-lang/pub#799.