Initially I chose a single file from the JS compiler and made it conform
to the style.
There is currently no plan to extend this to libray code or JS code that
runs on the client. Partly for practical reasons, since that code all run
through a pre-processor, but also because we have very different JS
version requirements there.
This change was generated by running:
`npm install google-closure-compiler@latest`
I the removed the `^` which `npm install` put that beginning of the
version so that we are precise in the version we are using.
This prevents developers or tools such as closure or other js
optimization passes from inadvertently adding constructs that
are not ES5 compliant.
See #12128
The new WASM2C option makes us run wabt's wasm2c, combine the output
with an emscripten main() file + runtime in C, and emits a final
single C file of all that stuff. If that is built to a native executable it
does the same thing as the wasm(+js) would have done.
This has several potentially interesting use cases:
* If we can build the emsdk tools (llvm, clang, binaryen, etc.) to C files,
we can distribute those to users as an alternative for people that
can't use the emsdk builds for some reason. For example if binaryen
upgrades to c++20 but someone is on a linux distro that is too old for
our standard builds, and doesn't have a c++20 compiler, then giving
them a C file may help them.
* A C build is also easier to generate. We have infrastructure for
building on the 3 major OSes but it takes a bunch of work. A C build
could be generated on a developer's machine very easily and run
on all targets. This is the same as making a build that runs in node.js,
which also would have those benefits. A C build has different
tradeoffs, the main benefit being that it may be faster and in particular
faster to start up (in theory node with wasm code caching could be
similar, but that doesn't work atm - hopefully it will be possible eventually).
* C builds are also interesting for sandboxing untrusted C code in
a simple way.
Note that this PR uses an emscripten build of wasm2c, running on
node, instead of us needing to package normal binaries of wabt
(which is sort of an example of the second item in that list).
* html-minifier was buggy in minifying JS code, and author decided to drop support for minifying JS code in it altogether, so migrate to using html-minifier-terser that can minify <script> content inside HTML files.
* Add env_with_node_in_path()
* Update minimal runtime code sizes
* update test sizes
* Fix typo
* Update minimal runtime code size test
* Use env_with_node_in_path() with Closure
* Migrate Closure to be located via npm install
* Add node to PATH for Closure
* Remove littering source map file
* Update package-lock.json
* Add more heap space to Closure invocation
* Work around Closure bug(?)
* Skip asm3.test_files because it runs out of memory on CI
This is part of a larger change to remove the two checked in
node_modules trees that we have in the emscripten and rely instead
on developers running `npm install` after cloning/syncing.
- Switch ws dependency to devDevpendency since its only used
for testing
- Add private:true since we are not (yet) publishing emscripten as
a node package.
- Remove running on npm install from sockets test; We can rely on
developers doing this before running the tests.
- Don't try to run npm install in test_sockets.py. Assume that
developers to used "git clone" will also run npm install
Sam Clegg
태재영
Alon Zakai
juj
Alon Zakai
Haneef Mubarak
Anthony Pesch