Proposal: bundle packagemap into file instead of separate script tag about import-maps

[Pauan]

This proposal...

//# packageMappingURL:moment=/node_modules/moment/src/moment.js

import moment from "moment";

...is exactly the same as this:

import moment from "/node_modules/moment/src/moment.js";

Except that the second code block is already fully supported by browsers (no need for a new proposal).

In other words, you can already do that right now, you don't need to wait for this proposal. Just create a tool which takes an npm package and replaces all the imports with absolute paths. There are already tools that do similar things.

In addition, how will your proposal handle transitive dependencies? In other words, if you have a file foo.js that imports bar, and then bar imports qux, and then qux imports corge, etc.

With your proposal, wouldn't the browser have to download foo.js, then lookup and download bar, then lookup and download qux, then lookup and download corge? With a package map all of the information is contained in one place, so the browser can prefetch and download the modules in parallel.

---

If you want to avoid the overhead of the extra HTTP request, you can use the proposed inline <script>:

<script type="packagemap">
{
  "packages": { ... },
  "scopes": { ... }
}
</script>

Or you can use HTTP2 to preload the package map, etc.

[vitalets]

I agree with some your points but not totally.

1. This is not exactly the same:

//# packageMappingURL:moment=/node_modules/moment/src/moment.js
import moment from "moment";

...as

import moment from "/node_modules/moment/src/moment.js";

because the first example works in both Node and browser without any changes.

In other words, you can already do that right now, you don't need to wait for this proposal. Just create a tool which takes an npm package and replaces all the imports with absolute paths.

Isn't it can apply to the whole idea of package-name-maps proposal?
I mean, how many developers will manually maintain packagemap.json without any tool? In real project with 3+ modules it seems to become a problem.

In addition, how will your proposal handle transitive dependencies? In other words, if you have a file foo.js that imports bar, and then bar imports qux, and then qux imports corge, etc.

Each module has all needed packageMappingURLs in the header.
foo.js:

//# packageMappingURL:bar=/node_modules/bar/bar.js
import bar from "bar";

bar.js:

//# packageMappingURL:qux=/node_modules/qux/qux.js
import qux from "qux";

etc..

With your proposal, wouldn't the browser have to download foo.js, then lookup and download bar, then lookup and download qux, then lookup and download corge? With a package map all of the information is contained in one place, so the browser can prefetch and download the modules in parallel.

It depends on how browser process es-modules and what you mean under "lookup". I'm not sure, but seems browser can read mapping urls as well as imports statements and download modules as usual.

[Pauan]

@vitalets because the first example works in both Node and browser without any changes.because the first example works in both Node and browser without any changes.

Ah, you're right, that is a benefit. Of course package maps also give that same benefit.

I mean, how many developers will manually maintain packagemap.json without any tool? In real project with 3+ modules it seems to become a problem.

Your approach isn't any better for maintenance: you have to specify the same amount of information as package maps. In some cases you have to specify more information (because of duplication), which makes the maintenance burden worse, not better.

Personally I imagine most developers will use a tool to generate the package map (except in very simple cases with a small number of packages).

Each module has all needed packageMappingURLs in the header.

If every module has all of the information it needs, then that means you are duplicating information.

What if foo.js and bar.js both import qux? Well, then they need to duplicate the //# packageMappingURL:qux=/node_modules/qux/qux.js comment.

Your approach could be made to work if you had a single index.js file which contains packageMappingURL comments for everything in your program:

//# packageMappingURL:foo=/node_modules/foo/foo.js
//# packageMappingURL:bar=/node_modules/bar/bar.js
//# packageMappingURL:qux=/node_modules/qux/qux.js

...but in that case your proposal is the same as package maps (except using comments rather than JSON syntax)

And what if your website has two or more entry points? Then each entry point needs to duplicate the information.

Package maps have no duplication at all.

Also, your approach won't work for npm dependencies. Let's say I create a webapp that uses the npm foo package, and the foo package has a dependency on the npm bar package.

The foo package isn't using the packageMappingURL comments, so the browser doesn't know how to handle the bar package.

So I would have to add in packageMappingURL comments for the bar package to make it work (even though I'm not using bar).

But now what if my webapp is also using the bar package, but with a different major version than the bar package which is used by foo?

With your proposal, it's impossible to handle that situation. But package maps can handle that situation.

Package maps may seem complicated, but they're complicated because they need to be: they need to handle many complex situations (like the above example with foo and bar).

It depends on how browser process es-modules and what you mean under "lookup". I'm not sure, but seems browser can read mapping urls as well as imports statements and download modules as usual.

I made a mistake. Earlier I mentioned prefetching and parallel downloading, and it's true that the packages specified in the package map can be downloaded in parallel, however that would only help with bare imports, not relative imports.

So a true solution is to enable prefetching of all .js files (both bare imports and relative imports). So in that case your proposal would also allow for parallel downloading.

[vitalets]

Ok, I think our discussion would help to clarify advantages and caveats of this project :)

[domenic]

Hi all,

As noted in the readme, the current proposal presents you a choice: you may either inline the package map, or you may include it in a separate file. Which is best for your project is generally going to be a project-specific decision, as it is today for JS and CSS resources.

As such, let me close this, as it seems to ask for a capability which is already in the proposal.