skip to Main Content

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:

  1. 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
  2. There are special restrictions under Zotero’s JS environment (rather than a standard node environment).

2

Answers


  1. Chosen as BEST ANSWER

    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:

    1. Start npm-registry-time-machine with the date from git commit
    2. Configure npm to use localhost:3000 as the registry (see its documentation)
    3. npm i as usual in the project

    p.s. Thanks everyone for your comments and suggestions.


  2. 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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search