-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
npm packages fail if package.json's type is set to "module" #447
Comments
Failing on lifecycle hooks? |
That's a bit of a mystery to me - shall I make a repro? |
Sure. Looks like an interesting one. |
Found a sec to look at your repro @paullewis . Thanks for putting it up. It's an interesting one. I can get the build working with package.json's type is set to "module" in two ways. Either set
on
on So that leads to the question of why the fsevents lifecycle hooks fails in this mysterious way if it sees the |
I also looked back at some previous work and I found that I hit a very similar issue before in the angular-ngc example we wrote https://github.com/aspect-build/bazel-examples/blob/861a7c5ab7e7073b879939b571e0420ab6c49dab/angular-ngc/WORKSPACE.bazel#L44. In that case I went with the |
|
Hmmm. The callstack on the failure comes from
and from that point, the nearest package.json when outside of the sandbox would indeed be the package.json at the root of the execroot. This differs from lifecycle hooks under pnpm which run from within the pnpm lifecycle npm package and will hit a package.json in that package instead of finding the user's package.json. In rules_js we bundle up pnpm's lifecycle hooks library into the |
Yup. That was it. The fix in rules_js is as simple as,
which adds a package.json in the runfile of the lifecycle hook bundle binary. 🤷 I'll put up a PR with a regression case. |
Ah so the fix is to present the "correct" Thanks so much for the explanation! |
Yeah. It was a sneaky one. Outside of the sandbox, node was looking all the way up the file tree from
to
to find the root user package.json. With the fix it now finds one without "type" = "module" at
Fix is landed so you can pick it up from the HEAD rules_js commit. |
Building on #446, the value of
"type"
inpackage.json
interacts badly with translated npm packages likemocha
, e.g.,Will fail:
I think something is anticipating CJS in the translated Mocha, yet if
package.json
's"type"
value is set to"module"
it getsThe text was updated successfully, but these errors were encountered: