-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to dynamically mark ESM loader cache as dirty with Istanbuljs? #595
Comments
Hi @deepsweet! Yep, we can add another environment variable. You can also mark our cache as dirty in a more invasive way by creating a Have you checked to see if there's a way to detect standalone istanbul? |
The trick is not only to add another env var, but to check for it directly, not from the initially imported file, so that it will work if I set the var in between I'll try the Thanks! |
$ ls -la node_modules/.cache/esm/.dirty
-rw-r--r-- 1 deepsweet staff 0 Sep 9 22:19 node_modules/.cache/esm/.dirty
$ yarn start test
yarn run v1.9.4
$ node packages/cli/src/index.js test
file:///.../@start/packages/plugin-xargs/src/index.ts:1
ReferenceError: cov_1c3glvsx6u is not defined or, after another
So errors content and files are even different from time to time. |
Never happens with I found another place in ESM loader affected by |
Are you side loading |
The way I load it in Start CLI entry point: require = require('esm')(module, {
mainFields: ['module', 'main']
}) |
I did few tests and it seems to work with that latest change in your commit 🎉 Will test it more heavily ASAP. |
I can't reproduce it anymore after 15+ runs, changes and reinstalling modules back and forth. I believe that the issue has been fixed. |
Rock! I'm going to let this change marinate for a bit before publishing (just to make sure naming is solid). Update: OK. Here is my thinking on this. I want to be careful with one-off environment variables like |
I think it will become clear when you have more issues. |
v3.0.83 is released 🎉 |
Here is some not very helpul background on the issue from the past (clearing Babel cache manually doesn't help because it feels like ESM loader writes its cache on exit).
Start runner has a CLI entry point, which applies both ESM loader and babel/register, and then loads tasks from tasks file on the fly using that transpilation combo.
Start runner has its own Istanbuljs plugin, which instruments sources, runs tests and then collects and prints out coverage results. Kinda Nyc, but without the Nyc part, i.e. manually.
There is a task called "test" which contains Istanbuljs plugin. If I run Start own tests using this command:
yarn start test
Then everything is fine. Start loads ESM + babel/register, loads tasks file, loads Istanbuljs plugin, invokes "test" task, applies Istanbuljs instrumentation import-hook on Start own source files, runs tests that imports those sources so Istanbuljs applies instrumentation by the hook, collects coverage and reports it.
Then if I change some of the involved into test task source files, for example add some new variable to
packages/plugin-lib-istanbul/src/instrument.ts
and runyarn start test
again I get errors (sometimes it takes few runs) about instrumented by Istanbul code stored in Babel cache which is somehow wrong from ESM loader perspective:The only thing that helps:
And then to always use it like this:
env NYC_ROOT_ID=1 yarn start test
i.e. to pretend that it's Nyc to mark ESM cache as dirty.
But if I want to hide this from CLI part to internals of test task, or better of Istanbljs plugin, then it doesn't work – at that time ESM loader has been already loaded and
isNyc
isfalse
regardless any later changes ofNYC_ROOT_ID
env var.Is it possible to check for that env var explicitly every time
onExit
is called, not from../env/is-nyc.js
? From what I see it should help.Also, since it's not really Nyc, could you please add another more abstract env var?
ESM_DISABLE_CACHE
or something so that Start doesn't have to mimic.I've been struggling with this issue for many months since I started using ESM loader in my projects, but never had time to finally try to explain it, it all was very complicated and phantom even for me as the author of Start. Please end my suffering, @jdalton I know that you can handle even such a weird issues.
The text was updated successfully, but these errors were encountered: