Initial spec for compilation import attribute

[internettrans]

I'm looking for feedback on this, so I'm going to mention some people who I think might be more up-to-date than me on the ECMAScript ecosystem, import attributes, and open source developments in the past several years. I used to be more up-to-date with the ecmascript ecosystem, tooling, and spec developments, and also used to know some of the open source developers involved in it. It has been some years and I'm now trying to re-enter that world: any feedback is appreciated, even if sharply critical of it or pointing out other existing solutions to the problems described. I don't know all of you and you're involved in projects a lot more popular than the single-spa and microfrontends ecosystems that I am trying to revive. I appreciate any responses or feedback.

cc @guybedford @xtuc @littledan @MylesBorins @dandclark @nicolo-ribaudo @ibacher @alexander-akait @shellscape @lukastaegert @yyx990803 @evanw @kdy1

[nicolo-ribaudo]

I don't really know what this is about, but I suggest figuring out what happens when importing the same module from two different places with the compilation attribute set to two different values. Is it an error? Does it cause the imported module to be duplicated? Is one of the two sets of attributes ignored? Which one?

[internettrans]

@nicolo-ribaudo the same corner case occurred to me as well, regarding conflicting compilation attributes for the same import specifier. I think a compilation error would be best in that circumstance. However, if the compilation attribute exists in one import of a module but not another, the bundler should implement the compilation attribute’s behavior for both imports.

I don’t foresee the compilation import attribute being used in every single import within source code, but more in the corner cases where library authors need to ensure how consumers use specific imports

The motivation for this proposed spec is that the single-spa ecosystem uses a combination of bundling and runtime imports. In the npm library I am currently working on, there is a module that should be shared at runtime between separately-bundled modules, as well as an Angular Service class in a different module, which likely cannot be shared at runtime, due to Angular Ivy not providing a stable, shareable runtime and the preferred approach being to avoid runtime inclusion of the full angular ivy runtime. I’m planning on publishing to npm an Angular Service class that has been compiled with ngc but still contains the compilation import attribute so that consuming angular cli apps know that one of the imports must be provided at runtime rather than compile-time.

In the context of single-spa, it’s important to be able to guarantee that certain modules are never bundled into any apps and only provided at runtime via import map.

I appreciate any further feedback.