Skip to content

Conversation

pchickey
Copy link

@pchickey pchickey commented Sep 16, 2025

@dicej and I would like to add the component-init project to this repo. It has been developed at https://github.com/dicej/component-init. I moved the entire contents of that repo into the component-init/ subdirectory, and then merged the unrelated history into this repo.

Aside from changing the repository, this PR changes the license from MIT to Apache 2.0 WITH LLVM-Exception per Bytecode Alliance policy.

In the future, we will refactor and merge this tool into wizer itself. For now, we are just moving it to this repo so that its clear that its under Bytecode Alliance governance.

I tried to make as few changes as possible to wizer to land this. CI now tests the entire workspace. In order to maintain the RUSTFLAGS: -Dwarnings flag we used in .github/workflows/ci.yml for component-init, I put #[expect(...)] on benign uses of static mut in the tests. Nothing is added to .github/workflows/release.yml - we will figure out a release flow in a future PR.

dicej and others added 30 commits June 27, 2023 11:04
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
…c count

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Jamey Sharp <jsharp@fastly.com>
This allows the caller to specify two separate components during
pre-initialization: one to instrument (which we call "stage 1"), and the other
to which to apply the snapshot captured after pre-initialization (which we call
"stage 2").  Normally, you'll want these to be the same component, but there are
cases where they might not be: e.g. when the "stage 1" component needs access to WASI
imports during pre-init, but the "stage 2" component does not have those imports.

The second parameter to `initialize_staged` is an optional tuple of the "stage
1" component and a function which maps module indices from "stage 2" to "stage
1".

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
* Update deps

* switch back to upstream `wasm-convert` dep

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Co-authored-by: Joel Dice <joel.dice@fermyon.com>
* Update deps

* refactor: update float64 to new f64 keyword

* don't do function counting for new thread functions

* Move back to upstream wasm-convert
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
…ance#7)

* scaffold

* just enough machinery to run in a cli

* test-programs

* test: debug print

* wat component passes tests, idk whats going on with rust one

* fix rust guest to actually mutate shared state

* remove debug

* add github CI that runs tests, checks fmt and docs

* cargo +nightly fmt

* ci wibbles

* sort

* test program: use AtomicBool per Joel's code review

* add clippy to CI, and fix clippy lints
…ecodealliance#10)

* rename root `component-init` crate to `component-init-transform`

and move it to a child directory.

This leave the `component-init` crate name available for a guest crate
that creates a nice DX for this feature.

* nightly fmt

* cargo doc needs wasm32-wasip2 installed because test-programs-artifacts build.rs uses it
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
…ance#11)

* create a new component-init crate with an attr macro

wraps up wit-bindgen pretty trivially

* fmt
…ytecodealliance#12)

* restructure transform into more intermediate datatypes and functions

* clippy and rustfmt

* code review fixes
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
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

Successfully merging this pull request may close these issues.

5 participants