this makes the docker node image believe package-lock.json is npm-shrinkwrap.json which allows prestart to use "npm i" to get a fixed set of dependencies.
normally "npm i" will automatically update package-lock.json and download new dependencies when they are available. to avoid that behavior, prestart had been using "npm ci". unfortunately, while ci preserves the lock file, it doesn't preserve the installed packages: it deletes and reinstalls the dependencies each time. therefore, restart times were long ( >40 seconds on production. ) using npm-shrinkwrap.json and "npm i" is the middle ground. it only downloads and updates dependencies when they are missing.
"ci" averaged 16 seconds on my windows box; "i" ( when nothing has changed ) is < 1 second.
note: i also removed the read-only flags from the json files. "npm ci" was fine with them as read-only, "npm i" wants the files to be writable, even though they aren't changed.
this makes the docker node image believe
package-lock.jsonisnpm-shrinkwrap.jsonwhich allowsprestartto use "npm i" to get a fixed set of dependencies.normally "npm i" will automatically update
package-lock.jsonand download new dependencies when they are available. to avoid that behavior,prestarthad been using "npm ci". unfortunately, while ci preserves the lock file, it doesn't preserve the installed packages: it deletes and reinstalls the dependencies each time. therefore, restart times were long ( >40 seconds on production. ) usingnpm-shrinkwrap.jsonand "npm i" is the middle ground. it only downloads and updates dependencies when they are missing."ci" averaged 16 seconds on my windows box; "i" ( when nothing has changed ) is < 1 second.
note: i also removed the read-only flags from the json files. "npm ci" was fine with them as read-only, "npm i" wants the files to be writable, even though they aren't changed.