Skip to content

[Bug]: public_hoist_pattern behaves different to public_hoist_pattern in pnpm #1884

Open
@fa93hws

Description

@fa93hws

What happened?

public_hoist_pattern behaves different to public_hoist_pattern in pnpm.

rules_js behavior

Take examples in rules_js repository as an example (I'm at acb0f7e), where ms is listed in the public_hoist_pattern.
What left in the sandbox becomes the following after bazel test examples/npm_deps:test6 --sandbox_debug is ran.
image
It's clear that ms is hoisted to <runfile>/examples/npm_deps/node_modules. However, it's not hoisted to <runfile>/node_modules. (I tried set "[email protected]" to ["examples/npm_deps", ""] or just [""] in public_hoist_packages but that doesn't make any difference).

pnpm behavior

Running pnpm install in rules_js repository root gives the following node_modules structure:
image
It hoists the ms packages under <repo_root>/node_modules/ms instead of <repo_root>/examples/npm_deps/node_modules.

Config to mimic the pnpm behavior

After a few try&error when writing this issue, I finally managed to get what I want, so in order to mimic node_modules hoisting behavior in pnpm, "[email protected]" need to be configured as an array that contains [""], and use //:node_modules/ms instead of //examples/npm_deps:node_modules/ms.

And here is what confuse me

The problem I have is the node_modules resolution when a plugin comes into play and hence I got the doc.

Note that public_hoist_packages affects the layout of the node_modules tree, but you still need to depend on that hoisted package, e.g. with deps = [":node_modules/hoisted_pkg"]. Continuing the example:

Since it says :node_modules/hoisted_pkg instead of //:node_modules/hoisted_pkg, I believe it will do the hoisting just like what pnpm does, and the doc of public_hoisted_packages implies so as well.
https://docs.aspect.build/rulesets/aspect_rules_js/docs/npm_translate_lock#public_hoist_packages

This is similar to setting https://pnpm.io/npmrc#public-hoist-pattern in an .npmrc file outside of Bazel, however, wild-cards are not yet supported and npm_translate_lock will fail if there are multiple versions of a package that are to be hoisted.

Question

So first of all, I'm not sure what's the expected behavior of public_hoist_packages? Should it do what pnpm does, to hoist the dependency into the root node_modules, or like what it is now, to hoist the dependency to the specific package?

If the later is the case, maybe the doc can be improved to be less confusing?

Version

Development (host) and target OS/architectures: MacOS (pretty irrelevant I think)

Output of bazel --version:

> bazel --version
aspect 5.9.25

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: "0.0.0", as I managed to reproduce it in rules_js's repository. It's latest main at acb0f7e

Language(s) and/or frameworks involved: Nothing.

How to reproduce

No response

Any other information?

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions