Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESM integration namespace tweaks #91

Closed
guybedford opened this issue Jun 15, 2023 · 2 comments
Closed

ESM integration namespace tweaks #91

guybedford opened this issue Jun 15, 2023 · 2 comments

Comments

@guybedford
Copy link
Collaborator

guybedford commented Jun 15, 2023

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
Copy link

Looks perfect, thanks for writing this up!

@guybedford
Copy link
Collaborator Author

Landed in #92.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants