Relaxing the '#' restriction on imports about modules

[guybedford]

@ljharb the thing is, it is very hard to ask Web Assembly developers to very nicely get LLVM and WASI to change the default conventions to support such a thing!

The alternative may be not being able to import WASI using the ESM integration...

[ljharb]

The alternative seems better; by removing the # prefix, it expands it from "internal imports" to "package-scoped overrides", which is a very very large can of worms to open.

[guybedford]

Actually package name self-resolution could provide a route here too --- have a subfolder with a package.json "name" field equal to "wasi_snapshot_preview1" which then has a main pointing to the local wasi instance.

[robpalme]

Letting # naturally become best practice sounds ok to me. We can obviously do more to communicate this over time.

IMO this relaxation would harm that adoption story because it makes it less obvious as to whether a package is following these good conventions.

[guybedford]

Thanks @ljharb @robpalme, helps to know. I have started the conversations with some Wasm folks to try and encourage having LLVM emit "#env" / "#wasi_snapshot_preview1" etc style specifiers. I am not even slightly hopeful I will make any progress in convincing anyone here though :)

Alternatives are to have LLVM / toolchain permit alternative names for these, rebuild Wasm when publishing it into the JS ecosystem or to have the JS esm integration return uninstantiated modules for a more flexible instantiation process. Will follow up appropriately.

[guybedford]

Thanks for the response - yes I was exactly thinking the explicit # for an internal pattern is actually clearer too. Just trying this out on a package myself where I have separate sub packages and really liking the pattern so far of having a single ‘interface’ package.json.

…

On Mon, Sep 14, 2020 at 16:48 Jordan Harband ***@***.***> wrote: What would it enable that they can't do now by using #-prefixed paths throughout the monorepo? iow, many monorepos make it explicit and clear when a specifier is "inside the monorepo" by prefixing it like @/blah or ~/blah, etc, and transforming those specifiers to relative paths. In this case, you could do the same with #blah at the root, no? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESFSXM55SXIZH2ZY65C43SF2TWVANCNFSM4Q5HSV2Q> .

[guybedford]

Just thinking about another use case here - there is another argument that disabling this restriction could enable self-contained monorepos. I wonder if anyone else has considered this use case too @ljharb @robpalme?

[ljharb]

What would it enable that they can't do now by using #-prefixed paths throughout the monorepo?

iow, many monorepos make it explicit and clear when a specifier is "inside the monorepo" by prefixing it like @/blah or ~/blah, etc, and transforming those specifiers to relative paths. In this case, you could do the same with #blah at the root, no?