You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This works great overall, so thanks for your work on it!
Issue
We currently use a checksum of package-lock.json as a cache key on our CI. Should patch-package save the fact that it's patched a given module into that lock file (or the yarn equivalent) so anything doing a checksum off of those lock files has an accurate view of the what's truly there or what has changed?
Something like a "patched": <hash of patch file(s) applied to this module> would be the most robust.
Related
This relates to #37 (essentially asking for something like Option 1 there but in this case it manifests itself in the package/yarn lock files).
The text was updated successfully, but these errors were encountered:
We're open to using yarn as well, so either would work.
It seems like package-lock.json doesn't have any integrity checks since patch-package modifies the source tree after a fresh package install. Since the lockfile is re-generated each npm install, modifying it after the fact to act as a cache checksum should be safe (and it didn't barf on a "patched": "hash1234" key that I added as a quick test)
This works great overall, so thanks for your work on it!
Issue
We currently use a checksum of
package-lock.json
as a cache key on our CI. Shouldpatch-package
save the fact that it's patched a given module into that lock file (or the yarn equivalent) so anything doing a checksum off of those lock files has an accurate view of the what's truly there or what has changed?Something like a
"patched": <hash of patch file(s) applied to this module>
would be the most robust.Related
This relates to #37 (essentially asking for something like Option 1 there but in this case it manifests itself in the package/yarn lock files).
The text was updated successfully, but these errors were encountered: