fix(npm): properly handle lock file maintenance for nested independent yarn workspaces #16451
Conversation
This file contains 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
…t yarn workspaces If a separate Yarn "project" is nested inside a project, `yarn install` cannot be simply run with Yarn Berry 2+ if there is no lock file. This check/enforcement makes sense because Yarn 2+ wants to make sure you either add this as a workspace using their workspaces feature, or you explicitly opt-in into a dedicated/independent "sub workspace". Currently when Renovate processes such an independent/isolated sub-workspace, it removes the `yarn.lock` for lock file maintancen. This will then result in the enforcement error when `yarn install` is executed to actually re-generate the lock file. See Yarn's error: ``` Usage Error: The nearest package directory (/tmp/renovate/repos/github/angular/dev-infra/tools/ts_proto) doesn't seem to be part of the project declared in /tmp/renovate/repos/github/angular/dev-infra. - If /tmp/renovate/repos/github/angular/dev-infra isn't intended to be a project, remove any yarn.lock and/or package.json file there. - If /tmp/renovate/repos/github/angular/dev-infra is intended to be a project, it might be that you forgot to list tools/ts_proto in its workspace configuration. - Finally, if /tmp/renovate/repos/github/angular/dev-infra is fine and you intend tools/ts_proto to be treated as a completely separate project (not even a workspace), create an empty yarn.lock file in it. ``` We can fix this, preserving the original decision (of the subdirectory being an independent workspace), by not deleting the lock file, but rather by just wiping it (to trigger the full regeneration). Example error PR without the fix: angular/dev-infra#676 (comment).
|
|
|
don't remove parts of PR template |
rarkins
approved these changes
Jul 6, 2022
|
Thanks for the review @rarkins! 🎉 |
|
Great PR, thanks :) |
|
🎉 This PR is included in version 32.105.3 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
devversion
added a commit
to devversion/dev-infra
that referenced
this pull request
Jul 10, 2022
Contains a fix we need: renovatebot/renovate#16451.
devversion
added a commit
to angular/dev-infra
that referenced
this pull request
Jul 10, 2022
Contains a fix we need: renovatebot/renovate#16451.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
If a separate Yarn "project" is nested inside a project,
yarn installcannot be simply run with Yarn Berry 2+ if there is no lock file.
This check/enforcement makes sense because Yarn 2+ wants to make sure
you either add this as a workspace using their workspaces feature, or
you explicitly opt-in into a dedicated/independent "sub workspace".
Currently when Renovate processes such an independent/isolated
sub-workspace, it removes the
yarn.lockfor lock file maintancen. Thiswill then result in the enforcement error when
yarn installisexecuted to actually re-generate the lock file.
See Yarn's error:
We can fix this, preserving the original decision (of the subdirectory
being an independent workspace), by not deleting the lock file, but
rather by just wiping it (to trigger the full regeneration).
Example error PR without the fix:
angular/dev-infra#676 (comment).
How I've tested my work (please tick one)
I have verified these changes via:
Note: Not actually tested in a full runtime, just unit tests which mock out the actual Yarn install though..