You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At tyler-breisacher-zipline@4e59a57 (first commit in this branch) I added @sentry/nextjs as a dependency. The bazel target for that package does not depend on esbuild: bazel query "deps(//examples/nextjs:node_modules/@sentry/nextjs)" | grep esbuild returns no results.
But then in tyler-breisacher-zipline@98c5145 (second commit) I also added storybook, and then the same bazel query shows that we do depend on esbuild.
@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl failed to build
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
bazel build @@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl
💡 To reproduce the test failures, run
bazel test //npm/private/test:write_npm_translate_lock_2_test //npm/private/test:write_npm_translate_lock_1_test //npm/private/test:write_npm_translate_lock_0_test
@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl failed to build
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
💡 To reproduce the build failures, run
bazel build @@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl
@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl failed to build
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
no such package '@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//': The repository
'@@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]' could not be resolved: No
repository visible as '@npm__next__15.2.6_1642820312__links' from main repository
💡 To reproduce the build failures, run
bazel build @@[unknown repo 'npm__next__15.2.6_1642820312__links' requested from @@]//:defs.bzl
Can you create an isolated pnpm-lock that reproduces this with the absolute minimum deps? This seems like a pnpm issue (adding one package causes the deps of another package to change) really, but seeing it in isolation will make that easier to under.
Here's what I have so far but to understand what's happening you kind of have to trace through a bunch of packages (storybook, webpack, terser-webpack-plugin...) so I'm going to try to simplify it more. The crux of it seems to be that terser-webpack-plugin has an optional dep on esbuild, but pnpm decides to create two different snapshots of it, one without esbuild, and one with (lines 3488 and 3498 of the lock file)
That seems to confirm that this is mainly a npm/pnpm usability issue? When you reach this level of peer+optional deps it can get quite complicated, but I think rules_js is just respecting the lockfile?
I agree, I don't think this is a bug in rules_js, and maybe not really a bug in pnpm, but it's a surprising behavior in both that I would like to understand better, especially if it turns out to be the cause of some of our ts_project() targets being slow.
It might be worth putting into troubleshooting.md or something like that, if we can provide a simple example and solution of the problem(s). A section titled something such as "slow builds due to unnecessary (transitive) npm deps" with an explanation and possible workarounds...?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
At tyler-breisacher-zipline@4e59a57 (first commit in this branch) I added @sentry/nextjs as a dependency. The bazel target for that package does not depend on esbuild:
bazel query "deps(//examples/nextjs:node_modules/@sentry/nextjs)" | grep esbuildreturns no results.But then in tyler-breisacher-zipline@98c5145 (second commit) I also added storybook, and then the same bazel query shows that we do depend on esbuild.