Deno: Support dynamic import maps

[kripod]

As hinted by the corresponding repo, import maps could be specified dynamically. I think there is a potential for choosing between development and production distributions of a given library based on Deno.env.get("DENO_ENV"):

// import_map.ts
export default {
   imports: {
      pkg: `https://cdn.pika.dev/pkg?variant=${
          Deno.env.get("DENO_ENV") === "production"
          ? "deno"
          : "deno/dev"
        }`
   }
}

For a more specific use-case, CSS-in-JS libraries could benefit from this by using a debuggable DOM-based style injection logic in development and a more performant CSSOM-based solution in production.

[Wallacy]

I’m was thinking about this yesterday! Luckily someone already did a great job in this document that you linked!

My 2c:

Deno.importMap(“someFile.ts”);
// rest of the module...

If this can be used per module basis will be very handy to public libraries.

[Wallacy]

Also, I'm in favor to drop de support of the json import_map from cli;

After change the module definition, you will need to keep import_map as part of the live cycle anyway and always use it. Using a ts/js as regular part of the module can be more useful;

[caspervonb]

Any kind of module import would be at odds with the import-map specification because all import-maps have to be fully resolved before any imports take place.

So, your example:

export default {
   imports: {
      pkg: `https://cdn.pika.dev/pkg?variant=${
          Deno.env.get("DENO_ENV") === "production"
          ? "deno"
          : "deno/dev"
        }`
   }
}

Uses an default module export, which has to be imported, but imports can't be resolved before all import-maps have been resolved... basically it's a chicken and egg problem and it's explicitly disallowed.

The next example

Deno.importMap(“someFile.ts”);
// rest of the module...

Also suffers from the same problem; this would have to be called from inside an imported module, but can't because it would change the module resolution.

What's the problem with just using a different import-map for special environments? You can wrap it in whatever convenience script you want, including one written in TypeScript running on Deno.

This is fairly consistent with how it works in web browsers where you can configure import-maps before the first import in the old school script tags; in Deno you can only change the import environment in a script before running Deno.

[Wallacy]

This docs already cover those concerns: https://github.com/WICG/import-maps#dynamic-import-map-example

Let's remember that is a in browser proposal first, not Deno specific, of course any way that Deno choose to implement may influence on browsers in the future. (the doc cites Deno too)

Also i don't see chicken and egg problem. For me is very clear: Load the import map will change the subsequent imports. Don't need to be more complex than this. That's not inherently bad Deno.importMap(something) or any other kind of file load before any import statement; I don't know much about Deno internals, but i suppose that not a big deal change after some import statement too.

The CLI only solution is not much useful, in the fact, in my humble opinion its better to not have any kind of import maps if be a CLI only.

[mathiasrw]

For me is very clear: Load the import map will change the subsequent imports. Don't need to be more complex than this.

This is spot on!

[caspervonb]

Let's remember that is a in browser proposal first, not Deno specific, of course any way that Deno choose to implement may influence on browsers in the future. (the doc cites Deno too)

Right now Deno is the only implementation apart from a seemingly dead origin trian in Chrome, so fair enough.

Also i don't see chicken and egg problem. For me is very clear: Load the import map will change the subsequent imports. Don't need to be more complex than this. That's not inherently bad Deno.importMap(something) or any other kind of file load before any import statement; I don't know much about Deno internals, but i suppose that not a big deal change after some import statement too.

These issues have been discussed on the import-maps repository plenty of times; the application is supposed to have authority over the import-map and the resulting module graph; if a module in the graph was allowed to change the graph then that would no longer be the case and fundamentally not be compatible with the import-maps proposal.

The CLI only solution is not much useful, in the fact, in my humble opinion its better to not have any kind of import maps if be a CLI only.

Still a useful feature, portable WebAssembly modules for example tend to import bare "system level" imports; which can resolve to either WebAssembly modules or ECMAScript modules.

It might not be the feature you're looking for but going "if they don't behave the way I want them to then lets dump them all together" seems silly.

[Wallacy]

These issues have been discussed on the import-maps repository plenty of times; the application is supposed to have authority over the import-map and the resulting module graph; if a module in the graph was allowed to change the graph then that would no longer be the case and fundamentally not be compatible with the import-maps proposal.

I think the proposal talk about that on "Multiple import map support". If this cannot be made "per module" library owners can supply they import-map via some kind of lazy load call/object... Ignoring any implementation details. My point is much more in relation to the dynamism for the app owner. Its okay be a one time thing or "per app"...

It might not be the feature you're looking for but going "if they don't behave the way I want them to then lets dump them all together" seems silly.

My point is just that the current "Ahead-of-time" static json file, is nice but so limited that the current "deps" file hack/sugestion not only solve the same problem better but is easy to maintain!

Its not about "my way", sorry if i made it look like that. Its just about maintain code on Deno tree that is very limited and better handled on the "deps file" hack;

Its that hard do change the imports per module/context/namespace/project etc? If is... Okay, one per entire app is fine.