Improving asbuild

[dcodeIO]

From discussion in Discord lately it appears that there are some problems introduced by the asbuild package that may or may not have been avoidable, not sure. I am certain that there are good reasons to provide asbuild separately, but given that I raised concerns initially in an attempt to avoid as many problems as we can, even though matters didn't go as I had wished, I'd like to reconsider what we can do from here to improve the situation.

• What are the concrete problems with asbuild currently?
• What does asbuild provide concretely that the main package doesn't?
• And an inconvenient one: Would an asbuild script next to asinit, as initially planned (more powerful npm run asbuild), be sufficient already?

[dcodeIO]

Related: https://github.com/ColinEberhardt/assemblyscript-regex/commit/c6118315ef0f9081b84fa511c49f5cb189143ea6 cc @ColinEberhardt

[willemneal]

Thanks for looking into this. For the first, it seems that @MaxGraey found the root of the issue mentioned above and I have an open PR to fix it.

As I've mentioned previously the goal of asbuild is to be a tool on top of the compiler. Currently this means:

• defaults for entry file (assembly/index.ts) if none is provided
• defaults for where to place the binaries, what its name should be, and allowing --wat to produce a wat file.
• allows for workspaces
• defaults for targets, debug and release are what you would expect if you don't provide them

Goals for what it could be:

• handle binary caching.
• package as-pect to allow for asb test.
• Make it more modular like cargo, so that other tools can integrate with it.
• Could replace npm for AS projects with dependencies on other Wasm projects
• Handle merging Wasm binaries (given an interface types section)

Other thoughts

As we move asc to AS, it could be a good time to separate out the configuration logic for parsing asconfig.json files, which then asbuild could borrow, (currently this is a limitation of asbuild since it doesn't merge configuration files like asc does).

As you can tell my dream for this project has perhaps a broader scope than just asbuild as that is but one portion of the larger project management features listed above.

Perhaps we could rename this project to hanger (for a rocket ship hanger)

[ColinEberhardt]

As I've mentioned previously the goal of asbuild is to be a tool on top of the compiler. Currently this means:

• defaults for entry file (assembly/index.ts) if none is provided
• defaults for where to place the binaries, what its name should be, and allowing --wat to produce a wat file.
• defaults for targets, debug and release are what you would expect if you don't provide them

Personally I'd suggest that these are features / fixes that should be applied to asc directly, rather than indirectly via a tool that wraps asc.

The other goals mentioned sound like more useful extensions :-)

[willemneal]

@ColinEberhardt, well I personally agree too my main argument against those features in asc is that we should aim to keep as simple; the same reason those are not provided in projects like rustc. Plus it makes it less opinionated if you wanted to build a different build tool.