Split asc.js to Compiler Frontend and CLI

[piotr-oles]

Hi!
I would like to improve AssemblyScript adoption by creating tools/integrations around it. To make it easier for me and other developers, I have a proposition for improving an API.

Currently, asc.js is one big file for everything. My proposition is to split it into 2 components - Compiler Frontend and CLI. The architecture would be like this:

The Compiler Frontend component would expose high-level API to build AssemblyScript projects (it would work with the WASM version of AssemblyScript OOTB). The API would be similar to TypeScript Compiler API to reduce the friction.

The CLI component would handle all CLI commands including building projects using Compiler Frontend. There would be no breaking change on the CLI interface.

@dcodeIO Would you be interested in such a contribution from my side?

[dcodeIO]

There's the plan on the horizon to port most of asc to AS, using WASI. Perhaps it would be best to think about splitting the CLI and the API while doing so.

[piotr-oles]

Do you mean the 'stw' branch?

[dcodeIO]

It has to do with that, yeah, but is a continuation effort. The stw branch that landed meanwhile made sure that the compiler, as a library, compiles to Wasm successfully without known issues. However, asc as the frontend, doing the I/O, is still in JS. But once we have the necessary WASI abstractions, we can think of porting most of asc to Wasm as well, which in turn may affect how things can be split.

More specifically, the API part sounds like it will become Wasm, while the CLI part may then again be split, e.g. as much of it as possible in Wasm, perhaps with just a very basic loader/wasi JS file to invoke what's in Wasm.

[piotr-oles]

Ok, I will start designing an API keeping in mind WASI and I will post it here to get your feedback :) I think we don't have to block on WASI support - if we split it before, it will be easier to port to WASM.

[AurelienRibon]

We had the same need at STOIC, and we also needed to be able to pass non-entry files (as well as entry files) to asc, from a web bundle (we do in-browser compilation). asc.compileString() can accept a bundle of files instead of a single string as first argument, however it treats the whole bundle as entry files, and there is no way (to my knowledge) to pass it non-entry files.

At first, I tried to use asc.main(), as it's more complete, but this requires manually stubbing stderr, stdout, readFile, etc.

In the end, I decided to rewrite an equivalent to asc.js, using only the API from assemblyscript.js. By understanding how asc.js works, and with a bit of trial and error, I got the following high-level algorithm.

Coding our own frontend allowed us to add some interesting perks, like supporting both .ts and .as extensions for AS files.

File parsing is quite simple, and inspired by how asc.js does it.

In the end, the frontend is 350 line long, but it does not support all options that asc.js supports (we have no need for --converge for instance, so no need to optimize the module in a loop).

If that is interesting to anyone, I can contribute that frontend in a gist (we have no intention of publishing it as an npm package for now, as we have no time to maintain it outside of our own needs, we're small :p).

[piotr-oles]

@AurelienRibon please share a gist if it's possible :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in one week if no further activity occurs. Thank you for your contributions!