mirror of
https://github.com/facebookarchive/prepack.git
synced 2024-08-16 18:10:33 +03:00
81bc21fad8
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 |
||
|---|---|---|
| .. | ||
| css | ||
| js | ||
| scripts/prettier | ||
| static/images | ||
| .gitignore | ||
| circle.yml | ||
| CNAME | ||
| favicon.ico | ||
| frequently-asked-questions.html | ||
| getting-started.html | ||
| index.html | ||
| package.json | ||
| README.md | ||
| repl.html | ||
| yarn.lock | ||
prepack.io
This website lives at prepack.io.