ESM integration namespace tweaks

[guybedford]

After discussion with @lukewagner about the current design, we determined some tweaks may still be necessary to the namespace conventions implemented in #86.

Consider:

world test {
  export wasi:filesystem/types
  export my:app/iface
}

We should actually be generating the canonical string names, instead of the combined kebab name of the package and interface:

// initial interface definitions are now just local variables
// with internal naming (ie not exposed to consumers)
const wasiFilesystemTypes = {
  // ... fns
};
const myAppIface = {
  // ... fns
};

// these are the "canonical export name" exports of these interfaces
export { wasiFilesystemTypes as 'wasi:filesystem/types', myAppIface as 'my:app/iface' }

// interface names can still be exported directly as
// being nested under the namespace when there is no conflict
// (as currently)
export { wasiFilesystemTypes as types, myAppIface as iface }

Future additions may include package or function lowering or aliasing, but the above should capture the major use case for now, while remaining compatible on the direct interface exports anyway.

For imports of namespaces, strictly speaking the ESM integration model should be based on the full string - ns:pkg/iface, and not do any handling of this. For our own handling of WASI shims, we do custom rewriting here in order to support a nice integration model, but this is more of a build exception than a standard interface model.

For non-WASI interfaces, we currently convert:

world test {
  import my:package/iface
}

into a JS import of the rough form:

import { iface } from 'my:package'

where the my:package module effectively exports multiple interfaces or functions corresponding to the implementation. This structure should instead be reverted to:

import * as iface from 'my:package/iface'

While this breaks reciprocal dependence for namespace linkage graphs (ie it is not possible for a component to link against another component in the implicit ESM integration without kebab names), instead we will separately have techniques for constructing implementation dependence graphs, which are instead not possible with the current namespacing model by design since it is primarily focused on host-level interfaces instead of implementation interfaces.

//cc @lukewagner let me know if this seems like a good summary of our discussion to you.

[lukewagner]

Looks perfect, thanks for writing this up!

[guybedford]

Landed in #92.