Skip to content
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

[BUG] When reinstalling, the package-lock.json is updated (local packages) #7166

Closed
2 tasks done
dartess opened this issue Jan 22, 2024 · 0 comments · Fixed by #7602
Closed
2 tasks done

[BUG] When reinstalling, the package-lock.json is updated (local packages) #7166

dartess opened this issue Jan 22, 2024 · 0 comments · Fixed by #7602
Assignees
Labels
Bug thing that needs fixing Priority 2 secondary priority issue Release 10.x

Comments

@dartess
Copy link

dartess commented Jan 22, 2024

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

If you run a re-installation, changes occur in the package-lock file for a dependency from a local subdirectory - a “name” field for this dependency appears.

Expected Behavior

re-installation does not change the package-lock file:

  • the name field should appear during the first installation.
  • or the name field should not appear during re-installation.

Steps To Reproduce

  1. add local dependency in subdirectory

package.json

{
  "dependencies": {
    "wasm": "file:wasm/build"
  }
}

wasm/build/package.json

{
  "name": "wasm",
  "version": "0.1.0"
}
  1. npm i

lock-file is:

{
  "name": "projectname",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "dependencies": {
        "wasm": "file:wasm/build"
      }
    },
    "node_modules/wasm": {
      "resolved": "wasm/build",
      "link": true
    },
    "wasm/build": {
      "version": "0.1.0"
    }
  }
}
  1. npm i again

now lock-file is:

{
  "name": "projectname",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "dependencies": {
        "wasm": "file:wasm/build"
      }
    },
    "node_modules/wasm": {
      "resolved": "wasm/build",
      "link": true
    },
    "wasm/build": {
      "name": "wasm",
      "version": "0.1.0"
    }
  }
}

Environment

  • npm: 10.3.0
  • Node.js: v21.6.0
  • OS Name: macOS 14.2.1 (23C71)
  • System Model Name: Macbook Pro
  • npm config:
; "user" config from /Users/username/.npmrc

//registry.npmjs.org/:_authToken = (protected) 
auto-install-peers = true 

; "project" config from /Users/username/git/projectname/.npmrc

engine-strict = true 

; node bin location = /usr/local/bin/node
; node version = v21.6.0
; npm local prefix = /Users/username/git/projectname
; npm version = 10.3.0
; cwd = /Users/username/git/projectname
; HOME = /Users/username
; Run `npm config ls -l` to show all defaults.
@dartess dartess added Bug thing that needs fixing Needs Triage needs review for next steps Release 10.x labels Jan 22, 2024
@milaninfy milaninfy added Priority 2 secondary priority issue and removed Needs Triage needs review for next steps labels May 8, 2024
@milaninfy milaninfy self-assigned this Jun 17, 2024
wraithgar pushed a commit that referenced this issue Jun 27, 2024
…7602)

When metadata is committed for the first time when there is no
package-lock, when target node has the same name field value as target
package name and link node also share the same name field, name field is
omitted from lock file, in subsequent times when there is already a lock
file, it reads target node with name field derived from realpath value
of the node and included in lock file. this creates mismatch of lock
file between installs.

This PR adds additional condition to check if name derived from realpath
is the same name as package and adds the name property.

Fixes: #7166
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 2 secondary priority issue Release 10.x
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants