[Feature] Flag to disable builtin package patches

[Silic0nS0ldier]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story

As a developer, I often need to maintain temporary dependency forks, but I am prevented by default patches applied to some packages.

Describe the solution you'd like

A clear and concise description of what you want to happen. Consider that Yarn is used
by many people, and your particular use case might not make sense to implement in the core.

A flag introduced that disables the package patches automatically applied by Yarn. The focus is on patches provided by the builtin @yarnpkg/plugin-compat plugin.

The motivation here is to unblock the migration to Yarn Berry from Yarn Classic at Canva. The patches are problematic as they introduce another constraint for dependency updates and when incompatible they manifest as obscure errors such as the following (likely a bug in error reporting).

➤ YN0001: │ Error: fsevents@patch:fsevents@file%3A../tools/npm-throw%[truncated]:
  ENOENT: no such file or directory, lstat '/node_modules/fsevents/fsevents.js'

For context, the goal is a drop-in replacement for Yarn Classic. Investigations with 3.2.1 have gotten very close, package patches and some node-gyp issues that I'm still looking into appear to be the only holdups.

Describe the drawbacks of your solution

Misuse of the flag could result in PnP users raising reports for apparent bugs that are just misconfigurations, though its more likely these will appear at specific package repos first. I can't see this becoming common issue.

Worth being aware of the flag state in some bug reports, as in some cases it will represent a content difference.

Stability of the feature will depend on how the patches plugin is integrated. Since I've yet to take a look, I can't yet comment.

Describe alternatives you've considered

An attempt was made to disable the patches builtin plugin, however builtin plugins cannot be disabled via the CLI.

There are plans forming around how dependencies are managed and integrated with Bazel (our build system). Upgrading to Yarn Berry is being considered as a short-term improvement to developer experience while longer term efforts are underway. Forking is an option if this feature (or an analogue) isn't desired by maintainers.

[cspotcode]

This is blocking a switch to yarn from npm for me as well.

My use-case:

I consume the typescript package as a peer dependency and need to support a range of versions. I use @internal APIs. I stay on npm to get simplicity and predictability when doing this testing and development. Yarn's patching has broken things for me in the past, so I don't want to risk the wasted time and the additional variables when I need to diagnose an error.

I understand there are hacks to avoid patches, but if I recall correctly, they require very specific, verbose version specifiers. Right now my tests run npm install typescript@version-to-test-against to mimic what an end-user is likely to do. I don't want to complicate that with yarn-specific details.

I understand that the patches are necessary to support PnP, and I will deliberately use the node-modules linker to avoid the need for patches.

---

Is it possible to block plugin-compat with my own yarn plugin?

[arcanis]

Duplicate of #3275

Yarn's patching has broken things for me in the past, so I don't want to risk the wasted time and the additional variables when I need to diagnose an error.

We would rather fix the problems that occur with the patches than allow disabling them. This is important if we want the upstream changes to ever be merged. At the moment, I'm not aware of issues, so please open some if you find any.