Love to see this work 👀

Does it contain workspace support?

Yes

I will probably be able to implement it only with some restrictions. I don't think we can allow publishing packages with patched dependencies. pnpm cannot have two copies of the same package (with the same version) inside one node_modules (unless that package has peer dependencies).

If we allow packages to be published with patched dependencies, then pnpm will have to be able to write different variations of the same package, as it may be patched in one of the dependencies and not patched in some other dependencies.

I can implement something like the following, that you would put to the package.json of your project:

{
  "patchedDependencies": {
    "express@3": "patches/express.patch"
  }
}

and it would patch all express v3 packages in the node_modules.

and it would patch all express v3 packages in the node_modules.

patch-package requires the version is pinned. Allowing this board version might fail to patch the package at some time. (conflict changes)

OK, the version can be pinned. But that version of the dependency will have to be patched in subdependencies as well. Not only when it is a direct dependency.

I'll add the patch and patch-commit commands in a separate PR.

No, it will work as in Yarn with the patch and patch-commit commands.

Editing files inside node_modules is problematic because you would change the file in the store as well, when the file is a hard link.

No, it will work as in Yarn with the patch and patch-commit commands.

Just read the document of yarn, I found it is better!

Next PR in progress: #4900

Super useful feature, thanks! Have recently been trialing this in a monorepo workflow, couple of issues:

• am finding that the temporary package created for patching contains the compiled dist only. Is this down to per-package configs or how pnpm works?
• Attempting to patch an org-owned package at an application-level, prior to upstreaming (i.e. that should remain un-patched in other monorepo applications). Assume this is a fairly common requirement. Open to aliases, hoisting overrides, postinstall solutions. Is this possible?