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

git modules updates within Dockerfile build #6106

Open
2 tasks done
kudla opened this issue Jan 30, 2023 · 1 comment
Open
2 tasks done

git modules updates within Dockerfile build #6106

kudla opened this issue Jan 30, 2023 · 1 comment
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release

Comments

@kudla
Copy link

kudla commented Jan 30, 2023

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

1

package.json

...
"dependencies': {
 "pack": "gitlab:ns/pack.git#v1.0.1"
}

2

run

npm i

This would successfully install pack@1.0.1

3

changing package.json to

...
"dependencies': {
 "pack": "gitlab:ns/pack.git#v1.0.2"
}

4

run again

npm i

this would update correctly package-lock.json still node_modules would still contain outdated package version

Expected Behavior

There's two confusions here

  • As mentioned in npm/npm#1727 npm i shouldn't update anything once module installed. Yet I've tried on regular (non a git) modules the version is updated correctly for the flow. And why package-lock.json is updated for git modules anyway becoming diverged from node_modules state
  • Another point is related to the same flow within Dockerfile
    e.g having one
copy package* .
npm --mount=type=ssh i

once an image is built updating deps version in package* repeated build would have still updated package* instances but yet has as well outdated package version in node_modules

So for docker in this case npm i even shouldn't be like update on installed deps since mutation in layer

copy package* .

should reject the previous state for next instruction so that npm i should be just as pure initial run

and the behavior is not changing even for hucks like

rm -rf node_modules
npm --mount=type=ssh I --cache=/tmp/skip-cache

so what might be a solution here (the main subject for dockerfile case) except manual retyping explicitly npm i ... per every single git module?

thx

Steps To Reproduce

see Current Behavior

Environment

  • npm: 8.19.3
  • Node.js: 16.19.0
  • OS Name: MacOs. Monterey 12.4
  • System Model Name: Macbook Pro
  • npm config:
; "project" config from /path/to/project/.npmrc

fetch-retries = 0 # gitlab modules related

; node bin location = /home/.nvm/versions/node/v16.19.0/bin/node
; node version =v16.19.0
; npm local prefix = /path/to/project
; npm version = 8.19.3
; cwd = /path/to/project
; HOME = /home
@kudla kudla added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Jan 30, 2023
@kudla
Copy link
Author

kudla commented Mar 18, 2023

It looks it is nothing with docker nor cache.
My issue was related to package-lock.json

So while one bumps a version of a git based module just manually over a package.json and run npm i in that case module meta within package-lock.json is updated only for version property yet for the resolved it keeps the old one including outdated revision. Which might be using for further payload fetches.

So to make a proper bump one should run explicitly

npm i gitlab:ns/repo#new-ref

which works fine

So I totally resolved my issue but I'm not sure whether described is intended behavior or still a point to discover the bug more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release
Projects
None yet
Development

No branches or pull requests

1 participant