Description
First of all, thanks for creating and maintaining this package!
We recently landed a similar built-in API in Node.js core (nodejs/node#54501) in an effort to support the ESM use cases and reduce CJS loader monkey-patching in the wild. The built-in compile cache has a few architectural differences in cache storage spelled out in nodejs/node#53639. I wonder if it's acceptable to migrate this package to use module.enableCompileCache() on newer Node.js versions (this can be done by just checking if require('module').enableCompileCache exists), which helps solving some of the open issues here & reduce CJS loader monkey-patching in general in the wild (there are some plans to no longer maintaining compatibility for monkey-patchers in the CJS loader, as that has been making refactoring and any improvements to the CJS loader very challenging).
There would be some open questions in how to solve the differences in the storage design, though, since module.enableCompileCache() enables caching for all modules loaded in the thread, and the cache can be shared by code loaded from any entrypoint. The cache file also corresponds one-to-one to source files, as that allows reading cache files on-demand & cheaper invalidation (skip immediately when the source hash at the beginning doesn't match), this actually seems faster than reading one giant blob per entrypoint in my testing in nodejs/node#47472.