You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an effort to improve iteration time when working only on JavaScript code,
we should consider having a way to rebuild and load the startup snapshot without
having to rebuild the whole binary.
This would be done by a combination of a Cargo feature flag (or env variable) to
instruct the cargo build process to not include the snapshot in the binary, and
a separate script that would be able to build the snapshot on demand.
This might require building a separate binary that would have a sole purpose of
building the snapshot (akin to V8's mksnapshot binary used to produce initial
snapshot with JS built-ins).
There is a challenge related to the fact that we currently snapshot "ops" that are
included in the binary, but it doesn't seem insurmountable.
The text was updated successfully, but these errors were encountered:
Last week, I faced this issue while working on the code for ext/node/polyfills. Each change required a lengthy build time. It would be tremendously helpful and significantly increase our development efficiency if we could reduce this time to just a few seconds. I fully support this proposal 😄
Closes#19399 (running without snapshots at all was suggested as an
alternative solution).
Adds a `__runtime_js_sources` pseudo-private feature to load extension
JS sources at runtime for faster development, instead of building and
loading snapshots or embedding sources in the binary. Will only work in
a development environment obviously.
Try running `cargo test --features __runtime_js_sources
integration::node_unit_tests::os_test`. Then break some behaviour in
`ext/node/polyfills/os.ts` e.g. make `function cpus() {}` return an
empty array, and run it again. Fix and then run again. No more build
time in between.
In an effort to improve iteration time when working only on JavaScript code,
we should consider having a way to rebuild and load the startup snapshot without
having to rebuild the whole binary.
This would be done by a combination of a Cargo feature flag (or env variable) to
instruct the
cargo build
process to not include the snapshot in the binary, anda separate script that would be able to build the snapshot on demand.
This might require building a separate binary that would have a sole purpose of
building the snapshot (akin to V8's
mksnapshot
binary used to produce initialsnapshot with JS built-ins).
There is a challenge related to the fact that we currently snapshot "ops" that are
included in the binary, but it doesn't seem insurmountable.
The text was updated successfully, but these errors were encountered: