Esm: caching and containers (AWS Lambda, Docker etc.)

[dnalborczyk]

_this is not necessarily a bug, depending on the implementation, just something to think about or to consider_

as mentioned in the other thread, my new employer is using AWS Lambda with serverless and needless to say, I brought in esm, which works great in bridge mode! as far as I understand the --require flag, or any flag for that matter, is not supported. 😕

AWS Lambda spins up a "container" as needed, keeps it up (warm) for a while, re-uses it when needed, and if not, takes it down (after a certain amount of time). This makes essentially caching useless.

Instead of just turning caching off with the esm options, I thought I'll give it a try and deploy the cache files as part of the deployment package in order to hopefully bring in some performance gains when the newly created instance is loading modules. (that is not to say that non-cached loading wasn't performant enough - I haven't measured the differences). unfortunately that didn't work, as esm created new caching files.

I'm guessing that esm might be using the absolute path for the file cashing hash?

(local) repro:
if one has a project in folder foo, and copies it's entire content to a folder named bar, fires it up, esm would create every cache file again. That's what also happens when deployed to AWS.

I wonder if a relative path could be considered in this case, or if it could have any unforseen implications, also in regards to the explicit esm cache path option.

it might be something to consider for any kind of "stateless" container instance, be it AWS Lambda, Azure Functions, Google Functions, or Docker etc.

_as a side note for other readers:_
I also considered https://github.com/zertosh/v8-compile-cache, but didn't give it a try (yet) as it seems to be environment dependent (CPU model and what not). I also tried a quick run with rollup (with the commonjs plugin), but that seemed to be too ambitious a well, as the plugin didn't seem to support any "non-standard" ways of commonjs exports (e.g. Object.defineProperty(exports, {})).

[jdalton]

I patched it https://github.com/standard-things/esm/commit/f61561ce6e5f291bd09a4c0df4de06a6fa3f979c. Let me know if it helps 🤙

[dnalborczyk]

thanks @jdalton for looking into this!

unfortunately it didn't seem to work, if I did the build correctly.

esm is still creating extra cache files, and also doesn't seem to consider loading the previously created ones. I checked last access with stats, because in theory esm could have created extra cache files and still loaded the previously created ones (although unlikely, but nonetheless possible).

I checked both, the default cache path (node_modules/.cache/esm) as well as an explicit cache path set in options.

would you rather have a repro for this? I can spin one up if needed.

[jdalton]

No worries, I can experiment with it locally using different locations and Node versions. I'll work on it a bit more and report back.

Update:

Ok so I tried it out locally and cache wasn't recreating for me when I moved folders or changed the Node version. I patched esm to use relative paths for its name generation so as long as the cache path is relatively the same _(in my case the default path)_ it should run without creating more cache files.

[dnalborczyk]

Let me check again on master.

edit:

yep, default cache path seems to work now! although the explicit cache path does not.

I tried it with ESM_OPTIONS='{cache:"./tmp"}' node -r esm file.js and then duplicated the root folder, switched folders, and run the same again. (macOS Mojave, node v10.9.0)

unrelated to any of this, there's another oddity I just noticed, which is probably not intended. I'll open a separate issue for tracking.

[jdalton]

I tried it with ESM_OPTIONS='{cache:"./tmp"}' node -r esm file.js and then duplicated the root folder, switched folders, and run the same again. (macOS Mojave, node v10.9.0)

Using a custom path worked for me. I have a path:

/Users/jdalton/projects/demo/a

I moved it to

/Users/jdalton/projects/demo/c/d/e/

With a custom tmp folder in each and it worked without duplicating caches.

[dnalborczyk]

I have a local Docker container for Travis. I'll try to repro it there. Thanks again for the fix!

[dnalborczyk]

I couldn't repro it on the Travis Docker container (Ubuntu Linux), and afterwards I couldn't repro it locally on macOS either 😄

I must have made a mistake somewhere ...

btw, good idea to leave the node version out of the hash as well, assuming that esm doesn't create different cache code for different node versions (other than supported syntax e.g. async, await etc.)

[jdalton]

The node/engine version would be for the compile code data.blob but the engine itself handles validation/rejection of those without us needing to muck with it.

Update:

v3.0.82 is released :tada: