-
-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not detecting shrinkwrap #10
Comments
patch-package doesn't support shrinkwrap at the moment. It shouldn't be difficult to add support, although it's not a priority for me. Happy to accept PRs though! |
I'm also happy to provide guidance for anyone wanting to give this a go. Probably the first places to look are |
Why does patch-package need to access the package-lock.json/npm-shrinkwrap.json at all? I kind of assumed it was only creating and applying diffs - not sure where the lock-file comes in? |
patch-package uses the lock files to build a 'clean' version of your node_modules folder when creating patches. I decided to err on the side of reproducible builds for safety. |
Is that not just a case then of checking for the existence of a |
It is my understanding that without a lock file you can't guarantee that
the same versions of dependencies will be installed on different machines.
That would be highly undesirable for users of this tool. Given the current
and inevitable proliferation of lock files i saw no reason to support the
previous generation of package managers. Is there some issue preventing you
from using lock files?
…On 12 Sep 2017 12:25 pm, "rhys-e" ***@***.***> wrote:
Is that not just a case then of checking for the existence of a
package-lock.json and then doing an npm install? In which case, could you
not just check for the existence of a package-lock.json or an
npm-shrinkwrap.json and then do an npm install given that if they're
present, they'll be used automatically by npm? Am I missing some subtlety?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABL1qRjul43wnVtSrBEyUtMF2WdZkmYzks5shmomgaJpZM4O2ScZ>
.
|
I'm not suggesting not to use a lock-file, just that they get automatically
used by npm if they're present. In which case, it seems like supporting
shrinkwrap and package-lock would only require that patch-package just
check to make sure one or the other exists which seems simple, unless I'm
missing some subtlety about how patch-package does its thing.
In terms of shrinkwrap vs package-lock, I'm using shrinkwrap right now - I
haven't moved over to package-lock yet due to concern over some bugs with
package-lock, otherwise I would (the format of shrinkwrap is identical to
package-lock right now so you can just rename one to the other - that's
actually what I did to try patch-package out).
Having said that I'm not sure it's quite time to look at shrinkwrap as a
legacy package manager yet - it hasn't been deprecated and I haven't seen
any mention yet of it going away.
|
Ah I see. Sorry I was a bit distracted when I read your previous reply. Yes, to support shrinkwrap we'd need to check whether the json file exists and then copy it to the temporary directory that is used for generating the 'clean' node modules. That happens in |
Just about to publish a fix for this. Feel free to reopen if you still have issues. |
I'm receiving an error that it's not finding package-lock.json or yarn.lock however I am using shrinkwrap. Any suggestions?
The text was updated successfully, but these errors were encountered: