Fix workspace member node_modules detection#23264
Fix workspace member node_modules detection#23264jackjennings wants to merge 2 commits intopantsbuild:mainfrom
node_modules detection#23264Conversation
node_modules detection
9c4e47a to
ec80f05
Compare
tobni
left a comment
There was a problem hiding this comment.
Tricky!
But LGTM. When CI is happy I will approve.
|
Hey @tobni — I'm running into some issues with running pants locally that I haven't been able to resolve (posted about them in the #development slack channel). If this seems valuable to land, feel free to take over the pull request -- otherwise my entire team just got laid off yesterday so our need to patch this has suddenly become less critical. |
sureshjoshi
left a comment
There was a problem hiding this comment.
Thanks for the contribution. We've just branched for 2.32.x, so merging this pull request now will come out in 2.33.x, please move the release notes updates to docs/notes/2.33.x.md if that's appropriate.
|
@sureshjoshi please see my comment above; if there's value here I'd like to hand this off to the team to land. Our company has been effectively dissolved so I personally don't have immediate need / ability to make the required changes. |
I've run into an issue with the JavaScript backend: when a workspace member has its own
node_modules(e.g. in the case that there is a version conflict between the member's package version and the root packages) the member'snode_modulesare present in the Pants sandbox.The
node_modules_directoriesmethod innodejs_project_environment.pywas designed to yield workspace membernode_modulespaths, but the conditionif self.packagewas always the resolve root (because_run_tool_with_resolvealways callsinstall_node_packages_for_addresswith the root package's address).