emit() should allow importMaps about deno_emit HOT 9 CLOSED

This is done in dnt: https://github.com/denoland/dnt#import-map--denojson-support

We could do something similar here by copying that code:

https://github.com/denoland/dnt/blob/fbf36c6ad8136a18e6337fc48cd063cb292793e3/rs-lib/src/graph.rs#L49-L56
https://github.com/denoland/dnt/blob/fbf36c6ad8136a18e6337fc48cd063cb292793e3/rs-lib/src/graph.rs#L219-L256

from deno_emit.

@kitsonk If someone could provide a sketch of an implementation plan, I think there are lots of folks willing to take a stab at this issue.

from deno_emit.

It was to get it out the door, not long term intentional. The underpinnings in Rust still support import maps, but it isn't exposed.

from deno_emit.

gotcha, that's great to hear. do you have any sense what the timeline might be for getting them back?

from deno_emit.

Also interested in knowing if there's any approximative ETA for this too, since it prevents moving out from v1.21

from deno_emit.

It was to get it out the door, not long term intentional. The underpinnings in Rust still support import maps, but it isn't exposed.

Any links/references/leads to if someone would like to open a PR for this ?

from deno_emit.

The underpinnings in Rust still support import maps, but it isn't exposed.

The implementation of the CLI seems to suggest that import map resolution is part of deno and not deno_graph. Should that be reimplemented in deno_emit or pushed down to deno_graph?

from deno_emit.

Kitson Kelly is not working at Deno Land anymore. Paging @bartlomieju instead.

from deno_emit.

I am currently working on this.

The implementation of the CLI seems to suggest that import map resolution is part of deno and not deno_graph. Should that be reimplemented in deno_emit or pushed down to deno_graph?

I saw that it was by design that deno_graph didn't embed the import map logic. Instead it expects a customer resolver that peforms the import map resolution, which in turn would rely on the import_map create. So, we have to reproduce the logic from the deno CLI in deno_emit, until there is either:

• An agreement that this logic should be in deno_graph
• An other layer abstraction that both the deno CLI and deno_emit would tap into.

I have something going but I am hitting a blocker: import maps expect a base URL as an import map can (and often does) contain relative paths. However I don't see any existing option or heuristic to derive the base URL from the input of bundle(). Shall I add another option to provide the base URL? Shall that option be tied to import maps, or generic — assuming that other future behavior would depend on such base URL? Shall the option have a default value, and if so, how would that be derived?

I can get to something that works but I'd like some design guidance.

from deno_emit.