I’m trying to modify a JS/node project which has package.json
but not package-lock.json
file committed. The author also does not have the original package-lock.json
because newer versions has been developed.
However, generating a new package-lock.json
makes the project failure to run, due to changes in the dependencies. This is because the generation happens now and uses the up-to-date (compatible) dependencies.
So, is there a way to generate a package-lock.json
as if it was generated back at a specific date/time in history, using the up-to-date dependencies back then?
For manually debugging or relying on conventions
Unfortunately it’s very hard to tell (at least for a non-JS-native developer like me) which package is failing or to rely on SemVer. This is because the project is essentially a Zotero extension, which means:
- It has to be packaged and loaded into Zotero for testing, and the package is compiled/packaged in to bundled JS files such that dependency/library information is gone; and
- There are special restrictions under Zotero’s JS environment (rather than a standard node environment).
2
Answers
After searching around harder, I found an answer to the question myself: use the npm-registry-time-machine project.
It sets up a proxy to npm registry on my local computer, and automatically filters out newer versions of packages, according to the date argument.
What I need to do is:
npm-registry-time-machine
with the date from git commitnpm
to uselocalhost:3000
as the registry (see its documentation)npm i
as usual in the projectp.s. Thanks everyone for your comments and suggestions.
The point of
package-lock.json
is to get a record of package versions at a specific point in time. There’s no secondary way to get this with out of the box tooling.Is it possible to accomplish this? Yes, you could write a set of scripts that talk to the NPM api and find release dates for each package before a given date.
Note that if you uses semver, and any packages that use semver shouldn’t ideally have a problem like this, because as long as the first digit didn’t change, they should have remained compatible. So you might only have to deal with a few bad apples. You’re more screwed if you used
*
for versions everywhere.Regardless I would imagine that unless you have a very high number of packages, it will be easiest to run through the likely culprits and find era-appropriate versions to install and test again. A good test suite would help with this as well.