how-to-proceed-scala-wasi.md

How to proceed the development to standalone wasm

We (I?) want to make the scala-js wasm backend generate wasm binaries that can run on stand-alone wasm runtime. However, that requires a lot of changes, and most of them are not self-contained (for example, WASI preview 1/2 support alone doesn't mean anything to users).

It's not desirable to add such non-self-contained changes to the main branch of scala-js. Only changes that are meaningful to users should be merged into the main branch.

Therefore, if we use the main branch as the target branch for stand-alone wasm development, we'll inevitably end up holding a gigantic changes locally and submitting extremely large pull requests. This puts a significant burden on reviewers and is undesirable. We want to proceed with frequent reviews and agreements among tanishiking, sjrd, and gzm0 on changes.

For this reason, it would be better to use a different target branch for development instead of main.

There are two candidates:

• (1) Use a separate branch in scala-js:
  • This allows us to use Jenkins CI as is.
  • However, even though it's a separate branch, it's still within the scala-js/scala-js repository, so adding changes here might require a certain quality. It's ok, but it might not be very efficient for exploratory development.
• (2) Develop in a separate fork repository:
  • This would allow us to proceed with development aggressively, similar to development in the tanishiking/scala-wasm repository.
  • The problem is that Scala.js CI Jenkins won't run
  • Can we port some important pipelines to GitHub Actions? 🤔

What should we do?

How about using both (1) a separate branch within scala-js, and (2) a forked repository?

In the forked repository, we can develop exploratively and aggressively. Reviews here would be light, similar to what we did in tanishiking/scala-wasm. We would need to port some scala-js Jenkins pipelines to github actions.

Once development has progressed to a certain point and simple applications start working (not all features need to work), we can submit pull requests to a separate branch within scala-js (let's call it the wasi branch). At this point, the code would need to meet the quality requirements of scala-js repo.

(Both of these branches would need to be regularly rebased with changes from scala-js main.)

Then, when the wasi branch has matured and reached a stage where it's ready for user release, we can finally submit the changes into the main branch.

This approach allows for aggressive development in the forked repo while maintaining the high standards of the scala-js project in its own repository.