Summary: Since I'm adding a new experiment I figured I'd delete an equivalent sized one. Last year I added an option that runs the Prepack program by invoking Node.js JS runtime which lets us prepack the whole module system and initialization. It's essentially a packager with perfect Node.js module resolution semantics. It did this by modeling Node's native environment as Prepack bindings. This PR removes that whole option. There's a few reasons why I don't think that worked out as a good idea. - It's not solving a real need. It is hard to keep different module systems in tact. There is always something in the ecosystem that breaks down and using the canonical one solves that. However, in practice, if there is a need for bundling the ecosystem itself adapts to the toolchain. So it's not actually that hard to bundle up a CLI even with Webpack, even if it's strictly not 100% compatible, by tweaking a few downstream depenencies. - Running the resulting bundle is tricky. The resulting bundle includes the JS parts of Node. This overlaps with what Node.js adds at runtime so it runs it twice. The ideal is actually to build a custom distribution of Node.js but this is generally overkill for what people want. - Bindings change a lot. While Node.js's API notoriously doesn't change much. The internals do change a lot. By picking the API boundary in the middle of the internals of Node.js, it risks changing with any version. While technically observable changes, nobody else relies on these details. If this option was worth its weight, someone could probably maintain it but so far that has not been the case so we had to disable this option in CI to upgrade Node. However, going forward I think there are alternative approaches we can explore. - First class module system. This is something we really need at some point. A first class module system would be able to load Node.js module files from disk and package them up while excluding others. It doesn't have to be literally Node.js's module system. Close enough is ok. Especially as standards compliant ECMAScript modules get more popular. This lets us target compiling output that runs after Node's initialization. - By introducing havocing and membranes in the boundaries, it becomes possible to initialize Node.js modules without actually knowing the internal of the boundaries. - We've started optimizing residual functions which is much more interesting. However, this requires that code puts some constraints on how it works with its environment. It's not designed to be fully backwards compatible. That's probably a good thing but that also means that we can put constraints on the modules being Prepacked. This removes the ability to prepack Prepack itself which is unfortunate but already wasn't being tested. To speed up Prepack itself, the [LLVM backend](https://github.com/facebook/prepack/pull/2264) seems much more useful if it can ever work on Prepack itself. Pull Request resolved: https://github.com/facebook/prepack/pull/2267 Differential Revision: D8863788 Pulled By: sebmarkbage fbshipit-source-id: d777ec9a95c8523b3386cfad553d9f691ec59074 |
||
---|---|---|
.circleci | ||
assets | ||
bin | ||
fb-www | ||
flow-libs | ||
flow-typed/npm | ||
scripts | ||
src | ||
test | ||
website | ||
.eslintignore | ||
.eslintrc | ||
.flowconfig | ||
.gitignore | ||
.gitmodules | ||
.prettierrc | ||
.watchmanconfig | ||
babel.config.js | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
package.json | ||
PATENTS | ||
README.md | ||
webpack.config.js | ||
yarn.lock |
Prepack ![Circle CI](https://circleci.com/gh/facebook/prepack.png?style=shield&circle-token=1109197a81e634fd06e162c25d309a420585acd5)
![](/facebookarchive/prepack/media/commit/81bc21fad8da5132d646c74a2045caf20d464573/assets/PrepackLogo.png)
Prepack is a partial evaluator for JavaScript. Prepack rewrites a JavaScript bundle, resulting in JavaScript code that executes more efficiently. For initialization-heavy code, Prepack works best in an environment where JavaScript parsing is effectively cached.
See the official prepack.io website for an introduction and an interactive REPL playground.
How to use Prepack
Install the CLI via npm,
$ npm install -g prepack
Or if you prefer yarn, make sure you get yarn first,
$ npm install -g yarn
and then install the Prepack CLI via yarn:
$ yarn global add prepack
You may need to prepend
(pun intended!) the command with sudo
in some cases.
Let the party begin
To compile a file and print the output to the console:
$ prepack script.js
If you want to compile a file and output to another file:
$ prepack script.js --out script-processed.js
Detailed instructions and the API can be found at Prepack CLI: Getting Started
Plugins to other tools
The following are a few plugins to other tools. They have been created and are maintained separately from Prepack itself. If you run into any issues with those plugins, please ask the plugin maintainers for support.
- A Rollup plugin for Prepack
- A Webpack plugin for Prepack
- A Parcel plugin for Prepack
- A Visual Studio code plugin for Prepack
- A babel plugin which transforms Flow annotations into prepack model declarations.
Status
- test262 status on master branch
- code coverage report for serialization tests
- To see the status for a pull request, look for the message All checks have passed or All checks have failed. Click on Show all checks, Details, Artifacts, and then test262-status.txt or coverage-report-sourcemapped/index.html.
How to get the code
- Clone repository and make it your current directory.
git submodule init
git submodule update --init
- Get yarn and node, then do
yarn
Note: For development work you really need yarn
, as many scripts require it.
How to build, lint, type check
- Get the code
yarn build
You can later runyarn watch
in the background to just compile changed files on the fly.yarn lint
yarn flow
How to run tests
- Get the code
- Make sure the code is built, either by running
yarn build
oryarn watch
yarn test
You can run individual test suites as follows:
yarn test-serializer
This tests the interpreter and serializer. All tests should pass.yarn test-test262
This tests conformance against the test262 suite. Not all will pass, increasing conformance is work in progress.
How to run the interpreter
- Get the code
- Make sure the code is built, either by running
yarn build
oryarn watch
yarn repl
This starts an interactive interpreter session.
How to run Prepack
-
Get the code
-
Make sure the code is built, either by running
yarn build
oryarn watch
. -
Have a JavaScript file handy that you want to prepack, for example:
echo "function hello() { return 'hello'; } function world() { return 'world'; } s = hello() + ' ' + world();" >/tmp/sample.js
-
cat /tmp/sample.js | yarn prepack-cli
Try--help
for more options.
How to validate changes
Instead of building, linting, type checking, testing separately, the following does everything together:
yarn validate
How to edit the website
The content for prepack.io resides in the website directory of this repository. To make changes, submit a pull request, just like for any code changes.
In order to run the website locally at localhost:8000:
- Build prepack into the website:
yarn build && mv prepack.min.js website/js
- Run
python -m SimpleHTTPServer
(Python 2) orpython -m http.server
(Python 3) from thewebsite/
directory
How to contribute
To read more about the project, check out this suggested reading wiki
For more information about contributing pull requests and issues, see our Contribution Guidelines.
License
Prepack is BSD-licensed. We also provide an additional patent grant.