module: do not split a portable compile cache by uid

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6

[codebytere]

A portable compile cache is meant to be reused wherever the same module layout is found. One shape of that is a cache generated once, at build time, and shipped read-only with an application for whoever runs it. On platforms with uids the cache subdirectory is suffixed with the uid of the user who created it ($NODE_VERSION-$ARCH-$CACHE_DATA_VERSION_TAG-$UID), so such a cache is only ever found by that one user; the split exists so users sharing a writable directory do not trip over each other's file permissions.

This omits the uid suffix in portable mode only. A user who cannot write to the directory still reads it, and a failed write is only a cache miss (Persist already logs and skips a temp file it cannot create). Non-portable caches keep the suffix.

Docs updated for portable and NODE_COMPILE_CACHE_PORTABLE; test-compile-cache-api-portable now asserts the tag directory name.

Context: an Electron application generating its main-process cache at package time and shipping it beside its app.asar (module.enableCompileCache({ directory, portable: true }) at launch); measured on that app, the shipped cache roughly halves the launch bundle's load time, but with the uid in the tag it is only found by users whose uid matches the build machine's.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.34%. Comparing base (bc813a7) to head (cdb9ccf).
⚠️ Report is 95 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65293 +/- ##
==========================================
+ Coverage 90.32% 90.34% +0.01% 
==========================================
Files 751 751 Lines 249960 250332 +372 Branches 47204 47316 +112 ==========================================
+ Hits 225774 226160 +386 - Misses 15564 15566 +2 + Partials 8622 8606 -16 

Files with missing lines	Coverage Δ
src/compile_cache.cc	79.21% <100.00%> (+0.12%)	⬆️

... and 41 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GeoffreyBooth]

I like this. Could it be used to speed up startup of servers deployed in Docker containers? Like maybe I build the cache when I build the Docker image, and when the container starts up it should start a little faster?

[codebytere]

@GeoffreyBooth yep that's the idea. you could build the cache during docker build with NODE_COMPILE_CACHE=/app/.cache NODE_COMPILE_CACHE_PORTABLE=1 node server.js (or module.enableCompileCache({ directory, portable: true }) from the app) and exit; the entries are keyed by path relative to the cache directory, so they hit at run time as long as the app and the cache directory keep the same relative layout in the image.

the missing bit for read-only images is #65302 which just stops node from trying to write into the cache directory when it can't

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75895/

[GeoffreyBooth]

That sounds great. Once all the pieces land we should add a Docker example in the docs somewhere.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75941/

[codebytere]

@GeoffreyBooth any idea what's up with the commit queue?

[nodejs-github-bot]

Landed in adad4d6