dart2js: Implementing Resource class

[sethladd]

Tracking issue for the dart2js's implementation of Resource class.

See meta issue #23823

[sethladd]

fwiw, the VM landed support for Resource today, if you're curious to have a reference.

[harryterkelsen]

Do we care if Resource cannot read 'package:foo/foo.dart' assets? .dart files aren't copied into the packages directory in 'pub build'.
cc @lrhn @nex3

[nex3]

It's not a great idea to rely on pub build's inclusion/exclusion behavior for precedent; it's been consistently not helpful for users.

The VM will support reading Dart files, so it would be nice if dart2js did as well. It's not entirely clear to me where dart2js will look for resources at runtime, though.

[sethladd]

Do we care if Resource cannot read 'package:foo/foo.dart' assets?

The only guarantee should be: if the resource is loadable by the runtime, at runtime, it should be loaded. If a build process or a user omits a resource from their bundled/packaged deployment, that's their call.

The VM will support reading Dart files

Even in the case of a snapshot? Not sure what happens in that case.

[nex3]

Even in the case of a snapshot? Not sure what happens in that case.

If you stay within pub-world (that is, only run stuff in pub packages or via pub global run or a pub-created binstub) then yes, the code will be made available. If you're manually creating a snapshot and moving it around, it's up to you and your deploy process to take along any assets you need and a .packages file that says how to find them. That's as true for Dart code as it is for anything.

[harryterkelsen]

My main problem is deciding how to resolve 'package:' URIs at runtime. Currently I just resolve them with Uri.base.resolve('packages/$packageUri'); basically assuming the pub build structure. Should we be doing package resolution described in the .packages DEP (https://github.com/lrhn/dep-pkgspec/blob/master/DEP-pkgspec.md#resolving-package-uris) at runtime or just assuming pub build output?

[nex3]

Assuming pub build output won't necessarily be safe in the long term. The clear solution for users who want total control is to provide a --output-package-root flag that's a base URI used for resolving package: URLs at runtime, but what about the default case where it's not passed? I can see two options. One is to just default to interpreting the URIs relative to the entrypoint, which is historically consistent but may not make sense for all deployment scenarios; the other is to issue a static warning and fail at runtime if no configuration is provided, which is probably safest but not super friendly.

[sigmundch]

Another thing to consider: we likely don't want to expose the package-uri in the output program. Even the name of the package and it's structure can be considered internal private information for some developers. One way to address this is to place all resources next to the main output file (the name can be as simple as resourceID.extension or resource-hash.extension). Then dart2js can produce a secondary output containing a map from these URLs to the original package: urls:

resource1.txt: package:foo/bar.txt
resoruce2.png: package:my/image.png

Whoever embeds the output of dart2js can properly serve those resources by reading that map.

That's basically what we do for deferred imports when you pass the --deferred-map flag today. It was necessary in the case of deferred imports because the deferred chunks didn't have a name originally in the source program.