-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
coverage:test:frontend failing with syntax error #6753
Comments
Likely related to #6717 in that nyc is having issues with make-badge-urls.js |
I had a branch going where I tried to wrap the Added: Actually I think this is the same issue: the top-level await. I tried to reproduce this but couldn't. |
Should've noted in the description but the described behavior is reproducible in the latest versions of Node 14 and 16. The only difference between the two scripts is ultimately
On your Mac I presume? I'd be surprised if the behavior diverges by OS, but you can see this reproduced consistently on Circle as well (the daily-tests job is the only one running any coverage scripts AFAIK) |
Yea, on my Mac. I do see it happening in the daily-tests CI (where it's clear that the Node version is not the problem). One idea (since there's at least one environment where this is running): does it fail the same way in Circle on the main Shields repo or only in daily-tests? |
I suppose we could update the circle config temporarily and test with the PR jobs from a topic branch, but i'm not expecting to see anything different there since the daily test jobs just clones the repo, changes into the resultant directory, and then runs the script. I'm wondering if there were some parser plugins that were previously in the root of the project that were moved or removed as part of the ESM work, but it's almost enough to tempt one to take a closer look at c8 |
I went and did an |
As a quick diagnostic, a faster option is to re-run a job with SSH, connect to the build machine, and run anything you like (once the steps complete, anyway. I think you're probably right that it won't make a difference, but it would clarify that the problem is not anything odd happening in daily-tests. Not the only possible next step, but would help close the gap on why this sometimes works and sometimes doesn't. I might try that next time I did into this. On my Mac a fresh clone of Shields, Hmmm, any chance this could be related to the version of the npm CLI? |
Odd. I assume this is the case but to be overly explicit, by passing that does mean the script is also exiting with a 0 code correct?
I'm only using npm v7+ locally (v7.19.1 to be precise) since we require > v7, but in CI have tested and reproduced the behavior with both v6 and v7, consistently reproducible. Are you thinking this could be a minor/patch version related issue with npm? More generally to clarify for my own sake, is there an implication that you don't think there could be an issue with our scripts, nyc, or the esm pieces with the frontend, or are you just trying to think of other possible options?
If this was solely an issue in CI then I'd definitely agree. I actually started to do this originally when i wasn't convinced Circle was using the right version of Node, but validated that it was and abandoned the ssh approach (I also haven't done ssh key setup with circle yet) after also observing I could reproduce the behavior identically locally (also linux) where I find it easier to work. |
Yup, correct.
Indeed, I'm not sure, just trying to think of other possible options.
👍🏼 |
Gotcha. If nothing else I think it's fair to say that something's at least partially busted, to use the technical term 😆 I'll try to check on Windows later to see if it's in a similar "working after some coercion" like Mac or failing outright like on Linux |
Seems that NYC does not yet support loading native ESM modules: istanbuljs/nyc#1287. Top-level await is something specific to ESM modules. I've tried giving https://github.com/istanbuljs/esm-loader-hook a go, but wasn't successful.
That indeed seems to be one of the recommended stable alternatives. |
Probably going to c8 makes sense. As an alternative, we could probably revert the top-level await, though that seems like a step backwards. |
fwiw I had some success dropping c8 in without having to change a thing other than the |
Have been unable to identify a root cause, much less a resolution, but for some reason running
nyc
with our entrypoint tests is barfing on theawait
keyword and failing. This is problematic with the current structure of the daily service tests, that utilize npm scripts that include running this one:compared to just running the test script:
The text was updated successfully, but these errors were encountered: