feat: compile to WebAssembly to eliminate native dependencies

[dsanders11]

Still WIP, but this is a major rewrite of the project to use Emscripten to compile to WebAssembly and ship as an npm package. Roughly I'd say the current state is 80% there.

Needs emsdk to be installed on the system to work. I considered adding it to the vendorpull config, but that repo is over a gigabyte so for now leaving it as an external development dependency.

The basics machinery works, although it has only been tested on macOS so far , and the test is currently failing. I think there may be a LIEF issue causing that, as there are some codepaths which trying to detect the system and use that to determine page size for example, but further investigation needs to be done to determine root cause. (Root cause was in LIEF, patch created and PR opened upstream).

There's a couple of high level goals driving the decisions in this PR:

• Eliminate Makefiles
• Eliminate Bash scripts (use zx module instead)
• Use a JS test framework (mocha in this case) to allow for more detailed test coverage

Still to do:

• Update README
• ELF
• PE

Closes#10, #15, #16, #17.

[dsanders11]

Some CI jobs are failing for various reasons currently:

• Tests on Debian - seems to be a Node.js issue, unexpectedly. Might be a version issue.
• Build on Alpine - an unexpected error about emcc
• Tests on Windows - an issue with paths

[dsanders11]

For testing this PR locally, it's useful to use npm link and then use the CLI directly to get as close to the published package as possible and find any issues there.

[RaisinTen]

Is this going to enable us to generate a single postject.wasm file that would run on all platforms?

[dsanders11]

Is this going to enable us to generate a single postject.wasm file that would run on all platforms?

See these lines in scripts/build.mjs for the artifacts, or take a look at the CircleCI job artifacts. There's a .wasm file, and two .js files (the CLI interface is easiest to write in JS), and yes it will run on all platforms.

[RaisinTen]

Okay, I was wondering because we were generating separate postject.wasm files for all platforms we run the build step on, so it felt unclear which one of those we were supposed to use. I'm guessing unifying all of these to generate a single postject.wasm artifact is something that would get addressed by this PR?

[RaisinTen]

did a light round of review on things that are unlikely to drastically change in further commits

[dsanders11]

Ready for final review.

A couple of things will be done in follow-up PRs:

• Alpine is removed from the build matrix for the moment due to an emsdk issue there (cc @robertgzr)
• Windows is removed from the lint job matrix for the moment, should be able to be enabled after chore: enforce linefeeds at eols in the .gitattributes file [skip ci] #28 lands

[RaisinTen]

LGTM

@dsanders11 Can you respond to #8 (comment)?

[RaisinTen]

This would be needed for #14, merging. Maybe my comment will get addressed while resolving that issue?

[dsanders11]

Okay, I was wondering because we were generating separate postject.wasm files for all platforms we run the build step on, so it felt unclear which one of those we were supposed to use. I'm guessing unifying all of these to generate a single postject.wasm artifact is something that would get addressed by this PR?

@RaisinTen, I'm not sure what the proposed "unifying" would look like - the build jobs are still going to generate the artifacts regardless. I don't think it hurts to publish them for all build jobs, and if there's ever a discrepancy between them it would be easy to compare.

Since the artifacts are the same for all platforms, we should just publish from whichever platform is most convenient.

[RaisinTen]

Since the artifacts are the same for all platforms, we should just publish from whichever platform is most convenient.

@dsanders11 yes, that's exactly what I'm doing in #30. I chose linux. :)