What is package root:root or World root

[rowanfr]

Whenever I compile a WASM component and use wasm-tools component wit some.wasm I always get a response that starts with:

package root:root;

world root {
  export respond: func(name: string) -> string;
}
package test:resp {
  world test {
    export respond: func(name: string) -> string;
  }
}

I wrote package test:resp as part of my WIT file and everything is there as expected but I don't understand why there are additional root worlds or packages or what they are there for. Any explanation would be appreciated

[alexcrichton]

What you're seeing here is an artifact of how the componentization process works. Each source language that goes into a single component encodes information in a custom section of the WIT that it used. This also happens for each library in each language. That means that a core wasm coming out of LLD and LLVM may have multiple custom sections describing WIT types. The wasm-tools component subcommand then is tasked with merging all of these sections and pieces of type information into one world which represents the final component itself.

So effectively what you're seeing here is the merging process. That works by starting with an empty world of a synthesized name (package root:root and the world named root). Each custom section is then merged (e.g. the respond function here from test:resp/test) into the root world to produce the final product.

When you create an actual component, the test:resp bits will go away. For example if you run wasm-tools component new some.wasm | wasm-tools component wit you probably won't see test:resp

[rowanfr]

Just for further clarification this produces:

package root:component;

world root {
  export respond: func(name: string) -> string;
}

This final compiled WASM file merges the various worlds into a single world with a singularly defined interface. Is this correct and if so why don't we just immediately produce this final compiled World by default?

Further does wasm-tools component new some.wasm > bin.wasm produce what we can consider to be the final fully pre-compiled stage of a WASM component that can be used elsewhere efficiently or no?

[alexcrichton]

Is this correct and if so why don't we just immediately produce this final compiled World by default?

Right yeah. The question of why isn't this the default is a bit tricky to answer though. To accurately answer I think you'll need to be more precise in what you're asking, for example what step in the compilation process is the "we" for producing the final world? Is it the input to wit-component (e.g. wasm-tools component new), the input to a bindings generator like wit-bindgen, or otherwise?

More-or-less though I think the answer lies in the precision of the question. It's not possible for wit-bindgen to have a single world since it's intended to support multiple worlds in multiple libraries. Similarly it's also not possible for the input to wit-component as it's also intended to support multiple wit-bindgen invocations and custom sections. The output of wasm-tools component new is itself a component which is where there's only one world, the component itself, and that's also by definition at that point basically.

Further does wasm-tools component new some.wasm > bin.wasm produce what we can consider to be the final fully pre-compiled stage of a WASM component that can be used elsewhere efficiently or no?

Yes. You can technically use some.wasm if you want. The bin.wasm file is "just another wasm file". The difference is that some.wasm is a core module and bin.wasm is a component. Some runtimes take one or the other, some take both.

[rowanfr]

Thank you for the further clarification. I think I understand better that at the point of compiling for target wasm32-unknown-unknown using wit-bindgen one can optionally convert the module to a component with wit-component for a single defined world and interface or use the module as some input to other orchestration mechanisms which allow users to include libraries for example. As a result we can't prematurely convert to a component as that would preclude a lot of other potential model modifications to do with its interfaces.