feat: add opt-in default npm package excludes from yarn

[Mivr]

Closes #2110

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): yes
• Suggested release notes appear below: yes

Added option to use default package content exclusions similar to yarn autoclean.

With bzlmod extensions:

npm.npm_package_content_excludes(
    package = "*",
    use_defaults = True,
)

# Override for `my-pkg@1.2.3`
npm.npm_package_content_excludes(
    package = "my-pkg@1.2.3",
    excludes = ["README.md", "*.spec.js"]
)

For legacy WORKSPACE:

npm_translate_lock(
    package_content_excludes = {
        "*": True,
        "my-pkg@1.2.3": ["README.md", "*.spec.js"]
    )
)

Test plan

• Covered by existing test cases

[aspect-workflows]

Test

All tests were cache hits

223 tests (100.0%) were fully cached saving 34s.

---

Test

e2e/bzlmod

All tests were cache hits

5 tests (100.0%) were fully cached saving 539ms.

---

Test

e2e/gyp_no_install_script

All tests were cache hits

2 tests (100.0%) were fully cached saving 184ms.

---

Test

e2e/js_image_oci

All tests were cache hits

1 test (100.0%) was fully cached saving 6s.

---

Test

e2e/npm_link_package

All tests were cache hits

3 tests (100.0%) were fully cached saving 533ms.

---

Test

e2e/npm_link_package-esm

All tests were cache hits

3 tests (100.0%) were fully cached saving 630ms.

---

Test

e2e/npm_translate_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

---

Test

e2e/npm_translate_lock_empty

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

---

Test

e2e/npm_translate_lock_multi

All tests were cache hits

2 tests (100.0%) were fully cached saving 268ms.

---

Test

e2e/npm_translate_lock_partial_clone

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

---

Test

e2e/npm_translate_lock_replace_packages

All tests were cache hits

3 tests (100.0%) were fully cached saving 269ms.

---

Test

e2e/npm_translate_lock_subdir_patch

All tests were cache hits

1 test (100.0%) was fully cached saving 73ms.

---

Test

e2e/npm_translate_package_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

---

Test

e2e/npm_translate_yarn_lock

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

---

Test

e2e/package_json_module

All tests were cache hits

1 test (100.0%) was fully cached saving 324ms.

---

Test

e2e/pnpm_lockfiles

All tests were cache hits

52 tests (100.0%) were fully cached saving 6s.

---

Test

e2e/pnpm_workspace

All tests were cache hits

15 tests (100.0%) were fully cached saving 2s.

---

Test

e2e/pnpm_workspace_rerooted

All tests were cache hits

15 tests (100.0%) were fully cached saving 2s.

---

Test

e2e/repo_mapping

All tests were cache hits

3 tests (100.0%) were fully cached saving 410ms.

---

Test

e2e/rules_foo

All tests were cache hits

2 tests (100.0%) were fully cached saving 137ms.

---

Test

e2e/runfiles

All tests were cache hits

1 test (100.0%) was fully cached saving 107ms.

---

Test

e2e/vendored_node

All tests were cache hits

1 test (100.0%) was fully cached saving 114ms.

---

Buildifier      Format

[dzbarsky]

So I love this idea (and in fact I implemented the same thing last time I worked on a big JS monorepo), but I'm a bit worried about the perf of all these globs. Alternately, we could drop these tiles as part of the extraction step. @jbedard WDYT?

[jbedard]

These are globs evaluated by tar which I would think is the best place to do it. What do you mean "we could drop these tiles as part of the extraction step"?

[dzbarsky]

These are globs evaluated by tar which I would think is the best place to do it. What do you mean "we could drop these tiles as part of the extraction step"?

Oh right we invoke tar directly. In my fork we had a script action around the tar so I was thinking to put the expansion there and hide it from analysis.

Disregard me this approach is probably fine

[jbedard]

@Mivr can you confirm if these are actually enabled by default in yarn? Or is it only when you explicitly call yarn autoclean? That makes me wonder if this should be opt-in.

If it is opt-in, maybe should also make this feature opt-in and then we can merge this now (without waiting for rules_js v3). Can we do something like replacing True with the default list? So users can do exclude_package_contents = {"*": True} then it replaces True with this default list...

[CLAassistant]

All committers have signed the CLA.

[Mivr]

So in yarn it has to be enabled. It is disabled by default.

I added a magic string for now, not sure it will work with a Boolean and the string does allow for more flexibility like extending the defaults further for some packages.

It's interesting to discuss which option will be more user friendly.

I tried also with a constant but Module.Bazel does not work with a constant as it does not allow for load statements.

It can also be a rule, which by syntax for the user is a close to the magic string.

[Mivr]

The closest I could get this is:
In Module bazel the users will need to migrate to a string that contains a complex object:
'{ "*": True, "some-package": "pattern" }'
Instead of the current syntax with a dictionary.

For WORKSPACE it will just work both ways.

I am open to other approaches for this, for now this was was least intrusive way I could find for the users.