Skip to content
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

yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder #802

Closed
gregmagolan opened this issue May 29, 2019 · 14 comments · Fixed by #864
Assignees
Labels

Comments

@gregmagolan
Copy link
Collaborator

gregmagolan commented May 29, 2019

In nodejs rules 0.30.0, the yarn_install & npm_install rules now use the new managed directories Bazel 0.26.0 feature so the bazel build will use the user's node_modules folder (eliminating the need to install node_modules twice: once locally and once for the bazel build).

Originally, when the managed director feature was in design phase, it handled the case where node_modules was deleted or recreated manually (via yarn or npm) and the repository rule would re-run and everything would work. However, some of this design and scope of the feature changed and the repository rule is no longer run if node_modules is deleted or manually recreated. It only runs after a full bazel clean --expunge or when one of its inputs such as package.json or yarn.lock or package-lock.json changes.

This means that if you manually rm -rf your node_modules folder the bazel build will no longer work. You'll see an error that looks like this:

greg@macbook bazel_with_users_node_modules (master) $ bazel test ...
...
INFO: Found 1 test target...
Target //:main up-to-date:
  bazel-bin/main_bin.sh
  bazel-bin/main
INFO: Elapsed time: 16.640s, Critical Path: 2.44s
INFO: 2 processes: 2 darwin-sandbox.
INFO: Build completed successfully, 7 total actions
//:main                                                                  PASSED in 0.4s

Executed 1 out of 1 test: 1 test passes.
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these arINFO: Build completed successfully, 7 total actions

greg@macbook bazel_with_users_node_modules (master) $ rm -rf node_modules

greg@macbook bazel_with_users_node_modules (master) $ bazel test ...
ERROR: /private/var/tmp/_bazel_greg/8cb9ee79286b251e74f070e4ed053074/external/npm/typescript/BUILD.bazel:123:1: no such package '@npm//node_modules/typescript': BUILD file not found on package path and referenced by '@npm//typescript:typescript'
ERROR: Analysis of target '//:main' failed; build aborted: Analysis failed
INFO: Elapsed time: 0.224s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
greg@macbook bazel_with_users_node_modules (master) $ 

Running yarn or npm install at that point still will not fix the build as the repository rule needs to rerun to create the npm fine grained build targets.

greg@macbook bazel_with_users_node_modules (master) $ yarn
yarn install v1.13.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 🔨  Building fresh packages...
✨  Done in 0.34s.

greg@macbook bazel_with_users_node_modules (master) $ bazel test ...
ERROR: /private/var/tmp/_bazel_greg/8cb9ee79286b251e74f070e4ed053074/external/npm/typescript/BUILD.bazel:123:1: no such package '@npm//node_modules/typescript': BUILD file not found on package path and referenced by '@npm//typescript:typescript'
ERROR: Analysis of target '//:main' failed; build aborted: Analysis failed
INFO: Elapsed time: 0.210s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

The fix for this will likely come in Bazel 0.26.1 so this is mainly a tracking issue here.

@gregmagolan gregmagolan self-assigned this May 29, 2019
@gregmagolan
Copy link
Collaborator Author

/cc @alexeagle

@gregmagolan gregmagolan changed the title yarn_install & npm_install managed directories can't handle deleted or manually regenerated node_modules folder yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder May 29, 2019
@gregmagolan
Copy link
Collaborator Author

Note: if this issue is a blocker for you, you can easily opt out of managed directories: https://github.com/bazelbuild/rules_nodejs/wiki#opting-out and wait for the fix to come in Bazel 0.26.1

@gregmagolan
Copy link
Collaborator Author

gregmagolan commented Jun 10, 2019

Underlying Bazel issue here: bazelbuild/bazel#8487

gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 10, 2019
…SPACE and bazel schematics

This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]
Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 10, 2019
…SPACE and bazel schematics

This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]
Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 10, 2019
…SPACE and bazel schematics

This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]
Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet
IgorMinar pushed a commit to angular/angular that referenced this issue Jun 11, 2019
…SPACE and bazel schematics (#30627)

This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]
Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet

PR Close #30627
@gregmagolan gregmagolan pinned this issue Jun 11, 2019
@gregmagolan
Copy link
Collaborator Author

gregmagolan commented Jun 11, 2019

Fix for this has landed in Bazel bazelbuild/bazel@6efc5b7 but did not make it into the 0.26.1 release.

It may make it 0.27 which is currently in rc. If not, 0.28 is scheduled for July so should be 0.28.rc0.

gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 11, 2019
* Entry_point attribute of nodejs_binary & rollup_bundle is now a label
* Nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this
* Symlinking of node_modules for yarn_install temporarily disabled (except for integration/bazel) until the fix for bazelbuild/bazel#8487 makes it into a future bazel release. This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]. Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 11, 2019
* entry_point attribute of nodejs_binary & rollup_bundle is now a label
* nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this
* Symlinking of node_modules for yarn_install temporarily disabled (except for integration/bazel) until the fix for bazelbuild/bazel#8487 makes it into a future bazel release. This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]. Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet
AndrewKushnir pushed a commit to angular/angular that referenced this issue Jun 11, 2019
* entry_point attribute of nodejs_binary & rollup_bundle is now a label
* nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this
* Symlinking of node_modules for yarn_install temporarily disabled (except for integration/bazel) until the fix for bazelbuild/bazel#8487 makes it into a future bazel release. This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]. Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet

PR Close #30965
@Toxicable Toxicable unpinned this issue Jun 12, 2019
@Toxicable Toxicable pinned this issue Jun 12, 2019
ayazhafiz pushed a commit to ayazhafiz/angular that referenced this issue Jun 12, 2019
…SPACE and bazel schematics (angular#30627)

This is needed to work-around issue: yarn_install & npm_install with managed directories can't handle deleted or manually regenerated node_modules folder [bazel-contrib/rules_nodejs#802]
Underlying issue has been fixed in Bazel bazelbuild/bazel#8487 but hasn't landed in a release yet

PR Close angular#30627
@gregmagolan
Copy link
Collaborator Author

gregmagolan commented Jun 12, 2019

So some good news and bad news:

Bazel 0.27.0rc5, which is now mirrored in the npm package @bazel/bazel next, solves the issue when node_modules is deleted. Thanks @irengrig for getting that fix into Bazel. This solves the most common use case when you delete your node_modules folder and then re-run the bazel build.

The case where you rm -rf node_modules and then manually re-create it by running yarn install or npm install is not yet fixed in 0.27.0rc5. In that case, you'll still have to either

  1. delete your node_modules folder and let Bazel create it on the next build via your yarn_install or npm_install rule

  2. run bazel clean --expunge before running your build

The first of these two options is going to be faster so that your build remains incremental.

gregmagolan added a commit to gregmagolan/rules_nodejs that referenced this issue Jun 14, 2019
This will fix the bazel-contrib#802 case of deleting and manually re-creating node_modules by no longer writing any files under node_modules.

A few keys caveats:

1. The downside of this is that the root @npm BUILD file grows huge again as all files under node_modules need to be added to exports_files([...]). If Bazel had a method to export all files without explicitly listing them such as exports_files_all() that would solve this problem.

2. npm package that ships with BUILD files would now cause issues with labels used by yarn_install & npm_install generated targets. With this change, packages such as @bazel/typescript which install bazel workspaces now ship with _BUILD.bazel files. The bazel workspaces installer is already looking for files of this name since the current repo rule renames BUILD files for the same reason.

To solve (2), I propose publishing a tool that could be added as a postinstall step to rename all BUILD files under node_modules and prefix them with _. This should not be a common case as most npm packages don't ship with BUILD files but there are a few that do. For example, rxjs < 6.5.0 had build files for a few releases to support building it from source.
gregmagolan added a commit to gregmagolan/rules_nodejs that referenced this issue Jun 14, 2019
This will fix the bazel-contrib#802 case of deleting and manually re-creating node_modules by no longer writing any files under node_modules.

A few keys caveats:

1. The downside of this is that the root @npm BUILD file grows huge again as all files under node_modules need to be added to exports_files([...]). If Bazel had a method to export all files without explicitly listing them such as exports_files_all() that would solve this problem.

2. npm package that ships with BUILD files would now cause issues with labels used by yarn_install & npm_install generated targets. With this change, packages such as @bazel/typescript which install bazel workspaces now ship with _BUILD.bazel files. The bazel workspaces installer is already looking for files of this name since the current repo rule renames BUILD files for the same reason.

To solve (2), I propose publishing a tool that could be added as a postinstall step to rename all BUILD files under node_modules and prefix them with _. This should not be a common case as most npm packages don't ship with BUILD files but there are a few that do. For example, rxjs < 6.5.0 had build files for a few releases to support building it from source.
gregmagolan added a commit to gregmagolan/rules_nodejs that referenced this issue Jun 14, 2019
This will fix the bazel-contrib#802 case of deleting and manually re-creating node_modules by no longer writing any files under node_modules.

A few keys caveats:

1. The downside of this is that the root @npm BUILD file grows huge again as all files under node_modules need to be added to exports_files([...]). If Bazel had a method to export all files without explicitly listing them such as exports_files_all() that would solve this problem.

2. npm package that ships with BUILD files would now cause issues with labels used by yarn_install & npm_install generated targets. With this change, packages such as @bazel/typescript which install bazel workspaces now ship with _BUILD.bazel files. The bazel workspaces installer is already looking for files of this name since the current repo rule renames BUILD files for the same reason.

To solve (2), I propose publishing a tool that could be added as a postinstall step to rename all BUILD files under node_modules and prefix them with _. This should not be a common case as most npm packages don't ship with BUILD files but there are a few that do. For example, rxjs < 6.5.0 had build files for a few releases to support building it from source.
gregmagolan added a commit to gregmagolan/rules_nodejs that referenced this issue Jun 14, 2019
This will fix the bazel-contrib#802 case of deleting and manually re-creating node_modules by no longer writing any files under node_modules.

A few keys caveats:

1. The downside of this is that the root @npm BUILD file grows huge again as all files under node_modules need to be added to exports_files([...]). If Bazel had a method to export all files without explicitly listing them such as exports_files_all() that would solve this problem.

2. npm package that ships with BUILD files would now cause issues with labels used by yarn_install & npm_install generated targets. With this change, packages such as @bazel/typescript which install bazel workspaces now ship with _BUILD.bazel files. The bazel workspaces installer is already looking for files of this name since the current repo rule renames BUILD files for the same reason.

To solve (2), I propose publishing a tool that could be added as a postinstall step to rename all BUILD files under node_modules and prefix them with _. This should not be a common case as most npm packages don't ship with BUILD files but there are a few that do. For example, rxjs < 6.5.0 had build files for a few releases to support building it from source.
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 20, 2019
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 21, 2019
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 21, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 21, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 21, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 25, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 25, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 25, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 28, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 28, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 28, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jun 30, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
gregmagolan added a commit to gregmagolan/angular that referenced this issue Jul 1, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0
pull bot pushed a commit to Mattlk13/angular that referenced this issue Jul 1, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0

PR Close angular#31325
alxhub pushed a commit to angular/angular that referenced this issue Jul 1, 2019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)

@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib/rules_nodejs#802

also updates to rules_rass commit compatible with rules_nodejs 0.32.0

PR Close #31326
@gregmagolan
Copy link
Collaborator Author

PSA: https://github.com/angular/angular-bazel-example is finally updated to rules_nodejs 0.32.2. This shows working example of using symlinked node_modules with Angular & Bazel and the new managed directories features in Bazel 0.27.0.

@ashi009
Copy link
Contributor

ashi009 commented Jul 10, 2019

I'm still seeing this issue from time to time with rules_nodejs 0.32.2 and bazel 0.27.0:

ERROR: <redacted>/BUILD.bazel:21:1: every rule of type ts_devserver implicitly depends upon the target '@build_bazel_rules_typescript_devserver_deps//node_modules/requirejs:require.js', but this target could not be found because of: no such package '@build_bazel_rules_typescript_devserver_deps//node_modules/requirejs': BUILD file not found in directory 'node_modules/requirejs' of external repository @build_bazel_rules_typescript_devserver_deps
ERROR: Analysis of target '<redacted>' failed; build aborted: no such package '@build_bazel_rules_typescript_devserver_deps//node_modules/requirejs': BUILD file not found in directory 'node_modules/requirejs' of external repository @build_bazel_rules_typescript_devserver_deps

The host with this issue has a bad network connection. The host runes rm node_modules && bazel clean --expunge && bazel build //... on a daily cronjob. During the process, yarn may fail due to timeout, but it seems that yarn_install will continue to generate BUILD files for the incomplete node_modules.

@a-ignatov-parc
Copy link
Contributor

@ashi009 we had the same problem with node_modules in an external repository. The only solution that helped us was to opt-out symlinked node_modules.

@gregmagolan
Copy link
Collaborator Author

gregmagolan commented Jul 18, 2019

@ashi009 we had the same problem with node_modules in an external repository. The only solution that helped us was to opt-out symlinked node_modules.

Yes. Thanks for pointing that out.

That's a known issue as there is no way to express to managed_directories in your WORKSPACE file that a symlinked node_modules folder in an external repository is managed. Also, if symlinked that node_modules folder ends up being in an external repository anyway so there is not much gained by symlinking in that case.

@ashi009
Copy link
Contributor

ashi009 commented Jul 25, 2019

Canceling a build at its loading phase will also trigger this.

The first build:

Loading:
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
# Received cancellation signal, interrupting

The second build:

Loading:
Loading: 0 packages loaded
ERROR: error loading package '': in /var/lib/buildkite-agent/builds/buildkite-agents-preemptible-nzjp-2/<redacted>/javascript/npm.bzl: Every .bzl file must have a corresponding package, but '@npm//:install_bazel_dependencies.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.
ERROR: error loading package '': in /var/lib/buildkite-agent/builds/buildkite-agents-preemptible-nzjp-2/<redacted>/javascript/npm.bzl: Every .bzl file must have a corresponding package, but '@npm//:install_bazel_dependencies.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.
INFO: Elapsed time: 0.200s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)
INFO: Build Event Protocol files produced successfully.
FAILED: Build did NOT complete successfully (0 packages loaded)

My speculation is that repository_ctx doesn't have a way to tell if a repository has been fully loaded or not, so it will use a corrupted external repository without loading it again.

@irengrig
Copy link

Hi @ashi009 , thank you for reporting this.

My speculation is that repository_ctx doesn't have a way to tell if a repository has been fully loaded or not, so it will use a corrupted external repository without loading it again.
Actually, it has the logic to only record the repository value as complete after the corresponding Starlark code of repository rule runs.

I created an issue in Bazel project to investigate this behavior.

@Toxicable Toxicable unpinned this issue Aug 27, 2019
@uri-canva
Copy link

Can this issue be re-opened? Or should we create a new one?

@uri-canva
Copy link

New issue: bazelbuild/bazel#8487

alexeagle pushed a commit to alexeagle/rules_nodejs that referenced this issue Oct 17, 2020
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib#802

See bazel-contrib#458

PiperOrigin-RevId: 254046674
alexeagle pushed a commit to alexeagle/rules_nodejs that referenced this issue Oct 18, 2020
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazel-contrib#802

See bazel-contrib#458

PiperOrigin-RevId: 254046674
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants