Esm: Caching & interaction with nyc

Created on 17 May 2018  路  7Comments  路  Source: standard-things/esm

I'm using esm programmatically. Caching is enabled.

I can run my tests fine without nyc. However if I do this first, and then run with nyc, no coverage is reported. If I delete node_modules/.cache/esm and try again I do get coverage results.

Does esm discard the instrumented code and load from its cache instead? What does it use as the cache key?

bug needs tests

Most helpful comment

When running as nyc npm test there's no way to detect we're being run by nyc so the only safe option is to punt on caches when we detect an nyc cache folder.

nyc exposes some environment variables: https://github.com/istanbuljs/nyc/blob/bc9ffe59370da43daa62853992402d83c0d17dd4/bin/nyc.js#L44:L49

NYC_CWD or NYC_ROOT_ID seem like good ones to detect.

This seems preferable to the current approach, which will prevent caching once you've run nyc once in your development environment. Caching in nyc can also be disabled, or the caches stored in a different directory.

All 7 comments

Hi @novemberborn!

Could you create a repro repo for me to look at?

Thanks @novemberborn!

This is fixable 馃榿

Update:

When running as nyc npm test there's no way to detect we're being run by nyc so the only safe option is to punt on caches when we detect an nyc cache folder.

Update:

Follow up patch https://github.com/standard-things/esm/commit/0a0cdf9ae7e2298b55ae63918ac0be5348ae6eca to only avoid esm cache when the nyc cache is empty
_(so about to be populated)_.

Hi @jdalton,

Does your fix work for monorepos? Collecting coverage via nyc when running under esm has been broken for me off and on for a while now. So last week I started to aggressively dig into their interaction and it became apparent that caching was to blame. My work-around was to simply nuke __all__ node_modules/.cache directories between runs. See js-junction; though tests are currently broken 馃槩.

I emphasized "all" because whereas nyc appears to only rely on the eponymous subdirectory of node_modules/.cache, esm does create subdirectories for each package as well, i.e., under packages/*/node_modules/.cache.

Hi @apparebit!

I'm guessing we'll look at the current-working-directory node_modules/nyc but would need to a repro to confirm. If you give me a repro step I can dig into it.

Update:

Patched https://github.com/standard-things/esm/commit/dfa26a297b7a7095cb8dc9615e4b910fff6e6557.

When running as nyc npm test there's no way to detect we're being run by nyc so the only safe option is to punt on caches when we detect an nyc cache folder.

nyc exposes some environment variables: https://github.com/istanbuljs/nyc/blob/bc9ffe59370da43daa62853992402d83c0d17dd4/bin/nyc.js#L44:L49

NYC_CWD or NYC_ROOT_ID seem like good ones to detect.

This seems preferable to the current approach, which will prevent caching once you've run nyc once in your development environment. Caching in nyc can also be disabled, or the caches stored in a different directory.

Ohhhh nice! Thank you @novemberborn!

Update:

With that I was able to simplify detection. Now when running by way of nyc we check if we have an existing .nyc marker file in our cache. If we don't find it we ignore the existing cache and create the .nyc marker. On the next run if we do see the .nyc marker then we know we can use the cache.

Patched https://github.com/standard-things/esm/commit/030f60af7594472d411e27e7c1cb5277bdb24511 and https://github.com/standard-things/esm/commit/3946a6c7293590111ec25780f6282a23c1dd0054.

Update:

v3.0.35 is released :tada:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MVSICA-FICTA picture MVSICA-FICTA  路  3Comments

StphamZ picture StphamZ  路  3Comments

deepsweet picture deepsweet  路  3Comments

clock157 picture clock157  路  3Comments

mAAdhaTTah picture mAAdhaTTah  路  3Comments