If you need a tool to generate the map, just use a tool to rewrite them in the JS files

[fregante]

I fail to see the usefulness of this proposal. For anything other than demos with 3 imports, you probably want a tool that generates this mapping. If you need a tool to run on the graph every time the code has changed you might as well just use a tool that rewrites the path in the JS files, without needing for extra config elsewhere: no extra files to fetch, no extra tags in every HTML page.

If your intent is to avoid tools: you can't. You still need a minifier, so just add a path-rewriter tool in there and you're good to go.

[domenic]

https://github.com/domenic/package-name-maps/blob/master/README.md#ahead-of-time-rewriting

[fregante]

1. That does not address the need for a minifier.
2. The same limitation applies to the tool that should generate the packagemap.

Somehow those dynamic imports need to be detected and minified, so packagemap isn't better than a rewriter here.

[matthewp]

You're forgetting about dynamic imports, you can't rewrite this code as the identifier is only known at runtime:

import(`langs/${navigator.language}.js`).then(langPack => ...)

[fregante]

@matthew my second comment is specifically about dynamic imports and how you still need a way to detect the modules in there to build your packagemap

[matthewp]

As sophisticated as JS tooling is these days, it's still a dynamic language and there are limits to what can be detected. In this case, and many others, it's simple to manually create a packagemap for this case:

{
  "packages": {
    "langs": { "path": "/langs", "main": "en-US.js" }
  }
}

#14 discusses whether multiple packagemaps should be allowed and this is a good reason why they should! You might need one for the stuff you edit manually and one for stuff that a tool creates. Even if only one is allowed you could have a tool that combines multiple maps together.

[justinfagnani]

Besides the potential fragility and incompleteness of rewriting specifiers, there are other cases where package name maps are way more powerful specifically because they don't rewrite the source.

One is CDNs. A single version of a package can participate in many different concrete module graphs with different versions of its dependencies. With rewriting, the CDN needs to potentially serve a rewritten version of a module for every permutation of dependencies versions. In practice, this would have to be done dynamically, as new versions of dependencies can appear over time - you can see this in the real work with unpkg.com. That's a pretty big burden to put on CDNs, and now you need CDNs specific to a programming language... The rewriting also reduces cache hits - server-side, edge caching and client-side.

With package name maps you don't rewrite modules at all, meaning any static file server / CDN can serve as a module CDN.

The other case is related to asset versioning and cache-busting schemes that are common now. In a multi-file app, the file names are often rewritten to include their checksum so they can have a very long cache expiration. This means that imports of them need to be rewritten to include the versioned filename, and this causes a rewrite of much of the asset graph up to the entrypoints. This means that your most critical resources at the root of your graph are invalidated the most and cached the least.

With package name maps you can still encode the version in the filename, but you don't have to rewrite importers because you can just rewrite the package name map. Update a leaf file, and only that file needs to create a cache miss.

And with versioned package name maps you can serve multiple versions of an app simultaneously that still reuse the common resources between them.

[fregante]

Asset versioning/redirecting sounds reasonable, but how would the CDN work? Can I set a packagemap that applies only to scripts loaded from a domain? Because if my local script mentions lodash@3 and a CDN script imports lodash@4, how will you sort that out? Will the CDN have to also include package.json? Especially in the CDN case it sounds like you’re gonna have to download multiple maps, which means multiple requests, potentially before each aforementioned dynamic imports.

I think my main issue with it is that I don’t think we should be ever send non-bundled files for a variety of reasons (inefficient gzip, cascading import fetches). We already have tools for chunked loading and they are more efficient.

Maybe the only thing left would be the bare dynamic import(getModule()) that can’t be rewritten