chore(ci): when generating patches, keep package.json from latest npm version

[davidgovea]

Related issues

Fixes #4331

Description

👋 Hi @mikehardy!
The patch-package failure was being caused by incomplete npm publish tasks. (repo versions higher than npm versions) (Related: #4283)
Looks like #4330 did not fix the issue

I've detailed that in a new issue #4343, and I suppose if that is fixed, then #4331 becomes a non-issue, but still, I've taken a self-contained approach based on the following assumptions:

1. The generated patches should always be for the latest npm version, regardless of repo state.
2. patch-package does not work well with package.json, so we can safely ignore package.json changes in the patches.

In the patch generation task, the package.json from the "live" version is now preserved.

Release Summary

N/A

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android N/A
  • iOS N/A
  • CI onlu
• My change includes tests;
  • N/A
• I have updated TypeScript types that are affected by my change. N/A
• This is a breaking change;
  • Yes
  • No

Test Plan

I made a thrash-branch in my fork, adding bogus changes to each package to test the package generation.
It's very messy, but here are 2 Action runs:

• Bad (observe lock issues, only several generated patches): https://github.com/davidgovea/react-native-firebase/pull/1/checks?check_run_id=1195395418#step:7:1291
• Good (all patches generated once the package.json-preservation in place: https://github.com/davidgovea/react-native-firebase/pull/1/checks?check_run_id=1195543383#step:7:1174

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/invertase/react-native-firebase/ddwya8ul4
✅ Preview: https://react-native-firebase-git-fork-davidgovea-patch-latest-version.invertase.vercel.app

[mikehardy]

I was literally just going to sit down and look at this with the idea the publish issue broke it, and here it appears you've done it ahead of me, you have my sincere gratitude as that leaves a lot more time for other things, like I think I'll have enough time to finish the latest stable release of AnkiDroid, so you're indirectly helping 1.7M people become doctors or fluent in a second language :). Most excellent

By the way - my hope for this approach was to package it up as an action to make it generally available for react-native projects so any PR got a patch-package. If you have any interest in becoming "Patch-Package Action Person" you have my blessing and best wishes, otherwise I'll keep it on my backlog. Just needs generalization to handle monorepos and non-monorepos

[mikehardy]

Nice surgical fix, I like the underlying reasoning as well. Thanks

[mikehardy]

the only downside to this one - a rare thing, but... - if there is a necessary change to package.json, like a new devDependency or something - no patch is generated

[davidgovea]

@mikehardy I've never been able to apply a patch to package.json using patch-package successfully. I noted this in assumption 2.

There are workarounds to --exclude <nothing> in the patch creation, to side-step patch-package's default exclusion of package.json.. some related issues:
ds300/patch-package#250
ds300/patch-package#179

npm mangles the package.jsons of installed dependencies. Perhaps yarn does not? That could explain the inconsistent issue reports. If that were the case, then npm-users still could not use the generated patches.

[mikehardy]

Oh interesting - thanks for the extra info there. I'd say "no change" here then, and we'll just treat it as a known thing. I don't imagine most user-generated PRs will change those, and my biggest goal with the patch generation was that users could post a PR and with no effort from maintainers other users could easily test - thus reflecting the testing need back to the community but in an empowered way instead of just begging. The current capability serves that fine