Upgrade to Latest WIT

[guybedford]

Tracking issue to upgrade ComponentizeJS to the latest WIT syntax.

For kebab names, the integration remains identical to the current implementation, ie:

package local:app

world app {
  import fn: func () -> string;
  import iface: interface {
    test: func () -> string
  }
  export fn: func () -> string;
  export iface: interface {
    test: func () -> string
  }
}

can be represented by the JS ESM source:

import fnImport from 'fn';
import { test } from 'iface';

export function fn () {
  return fnImport();
}

export const iface = {
  test () {
    return test();
  }
};

In the recent jco@0.8.0 release, the WIT wasn't quite represented correctly for namespaces which require a conversion, resulting in a need for some further refinements described in bytecodealliance/jco#91.

When handling namespaces, we effectively perform a "conversion" from the namespace semantics to the ESM semantics, exactly as described in the JCO issue there.

The convention with aliasing semantics becomes for componentizing a world:

package my:package

interface test {
 hello: func () -> string
}

world test {
  import wasi:filesystem/types
  import test

  export wasi:filesystem/types
  export test
}

becomes the corresponding ESM source written by the user:

import * as types from 'wasi:filesystem/types';
import { hello } from 'test';

// export aliases 
export const types = {
  fn () {], // ...
};
export const test = {
  hello () {}
};

If there were an aliasing conflict, say there already existed interface name exports for test and types, then we would need the code author to instead write:

import * as types from 'wasi:filesystem/types';
import { hello } from 'test';

// when the world has these namespace interface exports already,
// eg from another interface via:
//   export another:package/types
//   export another:package/test
// then the base alias can only be the first or neither
export const types = /*...*/;
export const test = /*...*/;

// now we must then export the full canonical names for the duplicates,
// by defining local variables,
const wasiFilesystemTypes = {
  hello () {}
};
const myPackageTest = {
  fn () {], // ...
};
// then we export them using the "string export" syntax for ES modules
export { wasiFilesystemTypes as 'wasi:filesystem/types', myPackageTest as 'my:package/test' }

The major concern with this Componentize convention for implementing external namespaces, is that when there is a conflict this new authoring style wouldn't be known to the user, so they would need to be informed that they must switch authoring modes into this full convention.

The alternative would be to always require the full verbose export mode without aliasing in componentize workflows to avoid such a cliff.

[lukewagner]

This looks generally great, thanks for writing it up!

One question: in addition to the 2 ways you showed above to export wasi:filesystem/types, could you additionally write the following 3, thus allowing 5 potential ways to export fn (assuming fn is a field of wasi:filesystem/types):

• export const wasi = { http: { types: { fn() {}, ... } } };
• export const http = { types: { fn() {}, ... } };
• export fn() {}

One tangentially-related comment is that, as of component-model/#164, we tightened up the validation rules to disallow using the same kebab-name in both imports and exports, since it avoids various whole cases of ambiguities that otherwise need to be handled. Thus, you wouldn't be able to both import and export the kebab-name test.

[guybedford]

Yes, all the other nesting options remain as potential aliases, down to themselves having conflicts of course (ie wasi or http as kebab exports).

Function flattening is still somewhat uncertain since unlike the other cases, the function names come from the third-party dependency so the flattening aliasing becomes dependent on hidden names that could possibly vary on feature versions.

Thanks for reminding me of the import / export kebab deconflicting, that is another case to bear in mind, but doesn't have any immediate implications here I don't believe.

Another point on this topic is the self-interface exports of a package:

package local:app
inteface iface {
  fn: func test() -> string
}
world app {
  export iface
}

In theory we could detect these "own" interface exports, and give them aliasing precedence if there is an aliasing conflict. So that the own exported interfaces get the best aliases in that case.

[lukewagner]

Ah, interesting idea. I suppose this is already the case when using inline interface exports: the kebab-name gets precedence over any other interface-id exports, and this handles the common case where I'm building my own component with non-interface exports (and, orthogonally, add a Wit syntax for exporting non-inline interfaces without giving them interface-ids).

[guybedford]

Exactly, one semantic distinction worth making here is that for kebab names, that is the canonical export name or import specifier (which are camel cased and kebab cased respectively), whereas for namespaces they are always aliases of the main canonical export to begin with.

[guybedford]

Landed in #32 and released in 0.0.8.