Add external-id attribute - #672
Conversation
9e2219f to
eeb2ed0
Compare
ricochet
left a comment
There was a problem hiding this comment.
This looks good to me. I'd use it right away.
You may want to update Linking.md as well:
mutually known to later stages in the deployment pipeline (specifically with
the [depname] case ofimportnamein the text and binary format).
To something like:
mutually known to later stages in the deployment pipeline. (How an import
name is resolved to a particular registry artifact is left to the host or
build tooling; the optional [external-id] attribute can carry a
tooling-specific identifier such as a registry path or URL.)
|
I've got an initial implementation of this over at bytecodealliance/wasm-tools#2555 if you wouldn't mind skimming over the test I've added |
|
Awesome! Test looks good. |
…2555) * Initial work for `versionsuffix` and `external-id` This is intended to at least start laying groundwork and implementation for two features in the component model that this repository does not yet implement: * `(versionsuffix "...")` for components -- introduced in WebAssembly/component-model#536 this is intended to pave a path forward to canonicalizing versions in component imports/exports in the future. For example where today you'd import `a:b/c@1.0.0` tomorrow you'd import `a:b/c@1`. This is not yet fully integrated into `wit-component`, however, and further work will be necessary for bindings generators as well to take advantage of this. It's all encoded in the same place as `external-id`, though, so I figured I'd at least start to lay the groundwork. * `(external-id "...")` for components -- being introduced in WebAssembly/component-model#672 this is intended to attach arbitrary metadata to imports/exports in a component. This is surfaced in WIT as an `@external-id("...")` attribute. This should be hooked up throughout this implementation to WIT and such such that the implementation is intended to be complete. There's probably something I forgot, but all the major pieces should be there. The `versionsuffix` parsing/validation is gated by a new `cm-canon-names` feature, and the `external-id` parsing/validation is gated behind the preexisting `cm-implements` feature to match the specification's classification. * Fix msrv * Update expected stdout * Reduce debug mode stack size usage
|
Ok with bytecodealliance/wasm-tools#2558 that shoudl, I believe, implement all of this and have everything round-tripped in all the places |
|
That's great! I guess then I'll wait a bit to see if anyone else has comments and then merge, noting that the feature isn't yet released, so we can continue to iterate in subsequent issues/PRs. |
- task.return takes the functype resultlist, `0x00 t` or `0x01 0x00`; the AST keeps one optional result for functions and for task.return. - Accept only plain names and interface names as extern names: the dependency, url and integrity forms left the specification with the `external-id` attribute (WebAssembly/component-model#672), and their diagnostics go with them. - Name the canonical built-ins in the diagnostics as the specification spells them (thread.yield, stream.cancel-read, error-context.debug-message, thread.spawn-ref, thread.spawn-indirect, thread.available-parallelism). Assisted-by: Claude (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
The dependency, url and integrity forms left the extern-name grammar with the `external-id` attribute (WebAssembly/component-model#672): drop their parsing, their diagnostics and the tests that covered them. The wasm-core-20260922 wasm-tools suites still exercise those forms, so this change stays on the series, which pins wasm-dev/component. Assisted-by: Claude (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
The dependency, url and integrity forms left the extern-name grammar with the `external-id` attribute (WebAssembly/component-model#672): drop their parsing, their diagnostics and the tests that covered them. The wasm-core-20260922 wasm-tools suites still exercise those forms, so this change stays on the series, which pins wasm-dev/component. Assisted-by: Claude (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
The dependency, url and integrity forms left the extern-name grammar with the `external-id` attribute (WebAssembly/component-model#672): drop their parsing, their diagnostics and the tests that covered them. The wasm-core-20260922 wasm-tools suites still exercise those forms, so this change stays on the series, which pins wasm-dev/component. Assisted-by: Claude (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
The dependency, url and integrity forms left the extern-name grammar with the `external-id` attribute (WebAssembly/component-model#672): drop their parsing, their diagnostics and the tests that covered them. The wasm-core-20260922 wasm-tools suites still exercise those forms, so this change stays on the series, which pins wasm-dev/component. Assisted-by: Claude (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
This commit removes support for component names of the form `unlocked-dep=<...>`, `locked-dep=<...>`, `url=<...>` and `integrity=<...>`. These were removed upstream in WebAssembly/component-model#672 in favor of the `external-id` attribute/annotation. I'm not aware of anyone actually using these forms of imports anywhere in the ecosystem so the expected impact of this change in theory is negligible. If there are users, however, these can always be re-added with a more phased deletion plan.
This PR extends #613, which added an
(implements <interfacename>)attribute to imports and exports, with an(external-id <string>)attribute. Theexternal-idattribute is useful when a component import or export name wants to match some external identifier, but the kebab-case syntax is too restrictive. One example is ESM-integration, where Module Specifiers can (now) be arbitrary Unicode strings (including URLs). Another is when importing stateful stores, e.g.:(as enabled by #613) and the platform-defined identifier of these stores isn't a valid
<plainname>, so you'd either have to add a whole separate name-mapping scheme (e.g. mappingredisandmemcachedto their host IDs) or mangle the host IDs into the<plainname>(say, via URL-encoding; ew). Instead, with this PR, you can use the@external-idattribute in WIT:and the WAT
(external-id <string>)is plumbed into the host, alongside(implements <interfacename>), so that the host can reflect on it and act accordingly.As mentioned above,
@external-idcan subsume the use cases forurl=<...>names for ESM-integration. Moreover, the reasoning in #613 for movingimplementsout of the name and into a separate attribute I think similarly suggests that the<urlname>,<depname>and<hashname>cases of<importname>aren't really the right place to solve their associated use cases. IIUC, these 3 name cases aren't currently being produced since there's no WIT syntax to emit them. Thus, this PR tentatively proposes removing these 3 name cases. The use cases are still important, but I think when we're ready to prioritize adding them to WIT/tooling, we should consider adding them as attributes instead. In the meantime, it lets us mergeimportnameandexportnameintoexternname, which simplifies nicely things.The PR also tidies up some sloppiness in the text-format grammar around string literals (e.g.,
"foo-bar") vs. the contents inside the quotes (e.g.foo-bar), using<Xstr>for the former and<X>for the latter.