-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
Next.js incorrectly patches package-lock.json version 3 #36816
Comments
Looks like #36813 partially resolved this. When using The |
Just curious: Why was the decision made by NextJS to modify the lock file at all? (as opposed to just providing remediation steps to the user)? This seems like a dangerous game to play given:
It seems like an all around better idea to just not do this, report an error, and move on. |
@jdharvey-ibm this is a very tricky bug for the user to fix depending on their Ideally the bug gets fixed upstream in |
Thanks for the reply! Though I don't agree with the approach, I can understand the motivation and that your goals with the framework and its adoption are likely much different than mine as a single user. I would still like to advocate for the ability to opt-out of this behavior (lock file modification of any kind). Perhaps with an environment variable which causes the app to abort with an error as opposed to modifying the lock file. Similar to how telemetry can be disabled. At IBM, it's fairly common for us to rely on npm repos outside of npmjs for security reasons, so the lack of configurability of this corrective action is a bit unfortunate. What would be the best way for me to pursue an enhancement of that sort? It sounds like this is falling more into the realm of a feature request issue? |
I opened a PR here #36959 to ensure the different lockfile versions are handled, thanks @remcohaszing for describing the differences there and also added an env variable |
This ensures different lockfile versions are handled and we skip patching when the version isn't supported. This also adds an env variable to allow skipping this check if desired. ## Bug - [x] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md` Closes: #36816
Hi, this has been updated in |
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Verify canary release
Provide environment information
What browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
Describe the Bug
There are 3
package-lock.json
versions. Version 1 uses thedependencies
field. Version 3 uses thepackages
field. Version 2 combines both for backwards compatibility.Next.js assumes the
dependencies
field as the source of truth with a fallback to an empty object, but this is absent inpackage-lock.json
version 3. It will then make unnecessary requests to the npm registry and wrongfully strip thedev
field for each dependencyThe logic for this is in
packages/next/lib/patch-incorrect-lockfile.ts
.Expected Behavior
Next.js patches the lockfile
packages
field only if thepackages
field is incomplete and not make unnecessary requests.To Reproduce
recma-nextjs-static-props is a minimal Next.js project. and can be used as a project. Clone it, regenerate the lockfile, git add it
Now run
npm run dev
to see the lockfile is being changed by Next.js.The text was updated successfully, but these errors were encountered: