Generating Compile Cache Ahead of Runtime

[beeequeue]

What is the problem this feature will solve?

It is currently not possible to generate the compile cache without executing the files that will be cached.

Currently, container images and lambda functions can't easily generate code caches ahead of the actual runtime, since the code may have effects you may not want to execute early.

What is the feature you are proposing to solve the problem?

Would it be possible to add a way to generate the compile cache without executing the relevant files, i.e. walking the module tree from the entry point, generating caches along the way?

Perhaps something like node --generate-compile-cache path/to/entrypoint.mjs
and/or

module.generateCompileCache("path/to/entrypoint.mjs")

What alternatives have you considered?

You may be able to work around this by adding "dry-run" code paths specifically for code cache generation, but this is a hacky workaround that can require massive effort.

[joyeecheung]

I think theoretically yes, but in practice it is more subtle:

1. Static analysis only goes so far for statically imported ESM - if there's any CJS in the graph (even if it's imported) their dependencies would be excluded because require() is not very reliable for walking. If there's any dynamic import() in the graph with dynamic module request it would also not be reliable. Considering how common it is for CJS to show up in the wild in dependencies it might result in a lot of cache miss in the real world.
2. If there's any loader hooks used to mutate resolution the walk again would be unreliable without executing the hooks.

That is technically a bundler problem and different bundlers can have different behaviors, with varying degree of accuracy. The accuracy of the graph would only be a best effort if it's implemented by Node.js alone without actually executing the code. It would probably be more effective for Node.js to just provide an interface that just takes a list of files and their formats to generate the cache from, and leave the walking and the generation of that list to a third party, so that users can edit the list to make up for any misses or they can use more advanced tools to generate more accurate graphs.

There are already some pretty good existing tools in the wild that should be able to generate this list e.g. madge, dependency-cruiser, and there might be more in the future, there's no need to re-invent a non-perfect wheel in core that might not necessarily be as good as new tools that might show up in the future.

[bnoordhuis]

Joyee says it more eloquently but I can perhaps phrase it more succinctly: too fragile to be viable.

[beeequeue]

So what if we skip walking the module tree path and only consider receiving a list of paths to generate a cache for, would that be achievable?

[bnoordhuis]

Possible, yes, but it seems kind of pointless. It'd be useless for the average node app.

Depending on what you want to do, you can maybe already achieve it through the vm module's produceCachedData option.

[joyeecheung]

I think a list-based approach is still practical and wouldn't be too difficult to implement. So instead of the proposal in OP, an alternative workflow (using https://github.com/sverweij/dependency-cruiser, which provides a lot of powerful options, and this is using the most basic ones) can be

npx depcruise --output-type json --no-config ./entrypoint.js | jq '[.modules[].source] | unique' > deps.json
NODE_COMPILE_CACHE=/path/to/cache/dir node --generate-compile-cache deps.json
NODE_COMPILE_CACHE=/path/to/cache/dir node entrypoint.js

Using the vm module doesn't exactly provide the same thing (e.g. cache miss handling and a directory structure that is compatible with the built-in compile cache)

[beeequeue]

I would be open to writing a simple CLI npm package to generate a list for this if needed :)

Should I update the OP to this new approach, or just add a link to the new comment?

[joyeecheung]

Updating the OP or adding a link SGTM.

I think this may also work nicely with #58755 so that the bundle would be portable.

[joyeecheung]

Actually now I realize that the list needs more than just the paths, it also needs the module type e.g. CommonJS/ESM/TypeScript. It may also be better paired with #55756 if support for TypeScript is needed.