Any reason to ignore the package-lock.json in .gitignore

[elchininet]

Hello:

I’ve noticed that package-lock.json is ignored in .gitignore. This change was introduced in #2149 and there is a comment asking for its deletion and another comment stating that it is generated automatically by npm so it has been added to .gitignore.

But it is important to know what is the intention of package-lock.json and why it is important to keep it in the repository:

• Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
• Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
• To facilitate greater visibility of tree changes through readable source control diffs.
• Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
• As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.

The most important thing about package-lock.json is to ensure when one runs npm install one will get a known-to-work state of the entire tree (which is not ensured if this file is removed and each user has their own version of the tree).

But maybe I don’t have the entire context of this change, there was any specific reason for it?

[acatzk]

• to stop tracking it, add the file to .gitignore (you already did that)

• to remove it from the repo without deleting the file, call git rm --cached package-lock.json

• call git status to see the file is marked as deleted, and the file is not listed as untracked (because it is gitignored), but it still exists

commit your changes and push if needed.

[elchininet]

Hi @acatzk,

I don't understand your comment, are you sure that you wanted to respond to my question?

Regards

[saper]

This is all correct if one uses node-sass as the standalone tool and does not want to risk breakage by uncontrolled dependency updates. But I guess in that situation you can either (1) freeze the versions yourself (2) control updates in your environment anyway.

Maybe I am not up to date with the newest npm development, but if node-sass is installed as a dependency of the actual project, this would mean that additional fixed dependencies will be collected only for node-sass, despite having a situation when a possibly updated version in the parent project would be just fine.

I think we should restrict versions installed in the case where we have a declared ("semantic versioning major update") or actual ("oh sorry this minor release actually broke $stuff") incompatibility.

[elchininet]

Hi @saper,

Thanks for your response but I think that you didn't get the point of the comment that I made three years ago.

This is an issue not even for the final clients using node-sass, the big issue is for node-sass development itself. This means owners and contributors.

You can potentially be publishing a code that is totally different to the code that was tested locally by the developers, because the tree in the developer machine could be potentially different to the tree that the CI environment generates. The code that you wrote is always the same, but the dependencies that your code uses are not.

Different developers developing node-sass will have potentially a different dependency tree each, which means that one of them could be having an error or an issue that the rest cannot reproduce (just because their dependency tree is different).

If the last minor or patch version of one of your dependencies gets a bug, a node-sass contributor that runs npm install will install it as a dependency, and they will not solve the bug until the dependency fixes the bug, a new version is published, and the contributor runs npm install again.

All of these issues are solved with a package-lock.json file. It is a snapshot of the dependency tree, so two, three, ten developers developing the package, a CI environment or whatever runs npm install will always get exactly the same dependency tree.

This issue affected me when in the past I wanted to contribute to the project and local tests were failing, so I opened the issue just because of that. But I never got to contribute and I am not using node-sass anymore, so this issue is not affecting me anymore, it can be closed if it is not something important for the owners and contributors of the project.

Regards