Not able to include package.json in the patch about patch-package

[dawnmist]

The --include and --exclude options are there - but they're used when creating patches for other packages, not during postinstall (where you're applying patches to the various npm packages). You also need to be providing the --exclude option to override the default setting if you want to include changes to the package.json in the patch.

So to use it, you would first:

• Modify the files inside the node_modules/package-to-be-patched so that they contained what you needed, then
• Create the patch for the package using:

patch-package --exclude 'nothing' package-to-be-patched

• Check that the patch file generated contains what you expected it to. If not, return to step 1 to update the contents of the package that you want to patch so that it reflects the correct information and redo the patch creation again.
• Then set up postinstall so it applies the generated patches after each installation:

"postinstall": "patch-package && jetify"

You won't be able to change the dependencies in another project's package.json, because the patch is only applied after the dependencies have been installed. But you can do things like add a typescript type definition file to a project and update its package.json file to point to your new types.

[JellyL]

I think --exclude 'nothing' should be the default setting

[dawnmist]

If you can add an example for disabling the default exclude, that'd be fantastic.

The other time that being able to patch package.json is desirable is when adding typescript type definitions to a package that doesn't have its own type definitions, so that you can add the "types" field to the package's package.json file pointing to your new type definition file.

Edit: It doesn't seem to matter what the exclude regex is, package.json is hardcoded to be excluded in the diff inside makePatch at:

patch-package/src/makePatch.ts

Lines 123 to 126 in 10c0a51

	// don't commit package.json though
	fs.unlinkSync(
	path.join(tmpRepo.name, "node_modules", packageName, "package.json"),
	)

and:

patch-package/src/makePatch.ts

Lines 135 to 138 in 10c0a51

	// remove package.json again
	fs.unlinkSync(
	path.join(tmpRepo.name, "node_modules", packageName, "package.json"),
	)

At present, the only way to be able to include package.json in the diff is to first patch patch-package to comment out those two lines in the compiled code. There's a bit of humour there in using patch-package to patch patch-package itself...

Patch: patch-package+5.1.1.patch - to allow enabling patching of package.json if you also use a regex that doesn't include it (e.g. --exclude '\*.txt').

patch-package
--- a/node_modules/patch-package/dist/makePatch.js
+++ b/node_modules/patch-package/dist/makePatch.js
@@ -66,14 +66,14 @@ function makePatch(packageName, appPath, packageManager, includePaths, excludePa
         fs.writeFileSync(path.join(tmpRepo.name, ".gitignore"), "!/node_modules\n\n");
         tmpExec_1("git", ["init"]);
         // don't commit package.json though
-        fs.unlinkSync(path.join(tmpRepo.name, "node_modules", packageName, "package.json"));
+        // fs.unlinkSync(path.join(tmpRepo.name, "node_modules", packageName, "package.json"));
         tmpExec_1("git", ["add", "-f", slash(path.join("node_modules", packageName))]);
         tmpExec_1("git", ["commit", "-m", "init"]);
         // replace package with user's version
         rimraf.sync(tmpRepoPackagePath);
         fsExtra.copySync(packagePath, tmpRepoPackagePath, { recursive: true });
         // remove package.json again
-        fs.unlinkSync(path.join(tmpRepo.name, "node_modules", packageName, "package.json"));
+        // fs.unlinkSync(path.join(tmpRepo.name, "node_modules", packageName, "package.json"));
         // stage all files
         tmpExec_1("git", ["add", "-f", slash(path.join("node_modules", packageName))]);
         // unstage any ignored files so they don't show up in the diff

[perrin4869]

I think the biggest case for --exclude 'nothing' is that one common requirement is to modify the exports field of a package.json file - due to many of them lacking exports for esm modules yet

[dawnmist]

@dawnmist why not remove the default for --exclude? If we don't make changes to the package.json it wouldn't be picked up anyway, right?

@DominikGuzei You'd probably be better asking the project maintainer that question. I am just someone who uses patch-package (and highly recommends it for certain tasks) who also had to work out how to make changes to the package.json work (for adding typescript types to a few packages).

That said, my suspicion is that it's because any patch you apply to the npm package's package.json is only applied after all its dependencies have already been installed - so most changes you could potentially make to the npm package's package.json file would be applied too late for them to actually do what you intend them to do. If those changes were included by default, many people would try to use them in situations where they do not work and the maintainer would forever be answering issues about things like "I modified the package's dependencies using patch-package, but npm/yarn are still installing the old ones!?" due to people not understanding that the modification only gets applied after all packages are installed.

[karlhorky]

To really exclude everything without choosing a filename that doesn't exist (which could lead to weird unexpected edge cases), use a regular expression pattern containing an empty string to exclude everything:

$ yarn patch-package react  --exclude '^$'

[ds300]

Hi @brunolemos 👋 !

Unfortunately what you want to do is not possible 😢 This is a common question about patch-package. I don't know of a way to get absolute control over which transient dependencies get installed. The best thing I've found is manually editing your own lock file, but that's only useful for making sure a specific version gets installed.

[ds300]

Just published a fix for this in [email protected] – Thanks for pointing this out @dawnmist and @davidlampon 🙇 ❤️

I'll close this once v6 leaves beta.

[devinrhode2]

I don't think anyone mentioned this idea yet
But as typically we have 1000's of npm packages, this means most individual npm packages are not that huge.

If we tweak our gitignore to ignore all node_module sub-folders like so:

node_nodules/*

We can then INCLUDE a certain node_module sub-folder in our git repo:

!node_modules/rc-slider

I think this may altogether be a better approach than patch-package, unless the package you are touching is huge. By simply checking the node module into git directly, there's a lot of nice simple benefits

[DominikGuzei]

@dawnmist why not remove the default for --exclude? If we don't make changes to the package.json it wouldn't be picked up anyway, right?

[dawnmist]

@nerdaliciousCH try making up a string that might be a filename but isn't.
e.g. --exclude 'IAmNotARealFile.txt'

The '$' in a regexp string means "at the end of the line" (or "end of the string" for something like filename strings). By having nothing before the $, you're actually matching every filename because every filename will have an end of the string.

[DominikGuzei]

@dawnmist makes sense, thanks for the detailed explanation! 👍 sorry for the mistake 😅

[ds300]

Hi! 👋 Thanks for the thorough explanation :-)

The first thing I noticed is that you're using JS-style regexp literals with the --exclude override. Instead you should use regular strings. See the examples in include-exclude-paths.sh – particularly this one which uses interesting regexp syntax. Imagine you were passing the string to new RegExp(...)

Thanks for bringing this issue to my attention. I'll try to improve that section of the readme.

[ds300]

Oh yes, you're right! Really sorry about the mixup. I think those lines should have been removed when I added the --include and --exclude options.

[brunolemos]

I'm using 6.0.0-7 and I'm not able to patch a package.json from another package, how can I do that?

EDIT: Adding a --exclude '\*.txt' made it work.

I removed a package from a third party package.json but when I run yarn it gets added to yarn.lock anyway :( It makes sense, as it run a postinstall script.

Tried this but did not work: "preinstall": "patch-package --include 'package\\.json$'"

[ivikash]

I am trying to patch a dependency of a dependency in the package.json. It does generate the patch file with a little noise (using npm) but is unable to apply the patches -> **ERROR** Failed to apply patch for package somePackage. Can you include a short summary or documentation on the usage, like how to generate the patch file and especially what should be done in prepare step. I am currently using 6.0.0-v5 due to some constraints.

[ivikash]

@ds300 Any update on this? Also, as I am using npm so should the patch-package be applied on prepare or postinstall? While trying with preinstall its throwing an error saying patch-package is not found.

[danieldunderfelt]

@ds300 so when will v6 leave beta? At least the beta is installable with npm, so it's not a huge issue, but people who are looking to patch package.json need to be aware about the beta and actively install it.

And yes, the beta works very well, so far as this issue is concerned!

[ds300]

Closing this to tidy up, final 6.0.0 release will happen soon 🎉

[nerdaliciousCH]

How to make an empty --exclude that doesn't match anything?? so --include 'package\.json$' --exclude '$'. That doesn't work for me :D

[xstable]

I use npx to run patch-package.
If I check for the Version I got:

npx patch-package -v
patch-package 6.2.0

So I'm right, that the include && exclude funcitonality still not implemented?
I use this:
postinstall": "patch-package --include 'package.json$' && jetify"
or double-escaped like this:
"postinstall": "patch-package --include 'package\\.json$' && jetify"

Both don't recognize the changes in package.json.

[pkit]

For people who want to actually change dependencies: use yarn "resolutions" although it's not perfect (cannot install a new package that didn't exist before), it covers a lot of cases.

[pkit]

By simply checking the node module into git directly, there's a lot of nice simple benefits

Dunno, looks like that approach gives zero new features compared to patch-package, but pollutes the repo with a bunch of garbage.
Any examples of the benefits?