Understanding difference between 'requires' and 'dependencies' in package-lock.json - npm

In order to understand difference between requires and dependencies in package-lock.json, I am checking the #angular/cli dependency object which looks as below.
Within #angular/cli the uuid package is listed with version 8.3.0 under both requires and dependencies fields.
"#angular/cli": {
"version": "10.1.7",
"resolved": "https://registry.npmjs.org/#angular/cli/-/cli-10.1.7.tgz",
"integrity": "sha512-0tbeHnPIzSV/z+KlZT7N2J1yMnwQi4xIxvbsANrLjoAxNssse84i9BDdMZYsPoV8wbzcDhFOtt5KmfTO0GIeYQ==",
"dev": true,
"requires": {
"#angular-devkit/architect": "0.1001.7",
"#angular-devkit/core": "10.1.7",
"#angular-devkit/schematics": "10.1.7",
"#schematics/angular": "10.1.7",
"#schematics/update": "0.1001.7",
"#yarnpkg/lockfile": "1.1.0",
"ansi-colors": "4.1.1",
"debug": "4.1.1",
"ini": "1.3.5",
"inquirer": "7.3.3",
"npm-package-arg": "8.0.1",
"npm-pick-manifest": "6.1.0",
"open": "7.2.0",
"pacote": "9.5.12",
"read-package-tree": "5.3.1",
"rimraf": "3.0.2",
"semver": "7.3.2",
"symbol-observable": "1.2.0",
"universal-analytics": "0.4.23",
"uuid": "8.3.0"
},
"dependencies": {
"ansi-colors": {
"version": "4.1.1",
"resolved": "https://registry.npmjs.org/ansi-colors/-/ansi-colors-4.1.1.tgz",
"integrity": "sha512-JoX0apGbHaUJBNl6yF+p6JAFYZ666/hhCGKN5t9QFjbJQKUU/g8MNbFDbvfrgKXvI1QpZplPOnwIo99lX/AAmA==",
"dev": true
},
"debug": {
"version": "4.1.1",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.1.1.tgz",
"integrity": "sha512-pYAIzeRo8J6KPEaJ0VWOh5Pzkbw/RetuzehGM7QRRX5he4fPHx2rdKMB256ehJCkX+XRQm16eZLqLNS8RSZXZw==",
"dev": true,
"requires": {
"ms": "^2.1.1"
}
},
"uuid": {
"version": "8.3.0",
"resolved": "https://registry.npmjs.org/uuid/-/uuid-8.3.0.tgz",
"integrity": "sha512-fX6Z5o4m6XsXBdli9g7DtWgAx+osMsRRZFKma1mIUsLCz6vRvv+pz5VNbyu9UEDzpMWulZfvpgb/cmDXVulYFQ==",
"dev": true
}
}
I have gone through the stackoverflow post based upon which it makes sense to have uuid listed under requires and dependencies field if the version is different.
However, in this case uuid has same version 8.3.0 under requires and dependencies field. So, why it is required to be listed at both the places?

According to the relevant documentation, a dependencies entry is not only populated for a dependency with a different version than used elsewhere. It will also be populated if the dependency is not used anywhere else. At least, that's my interpretation. If I'm right about that, running npm ls uuid in your project should show that only one uuid entry.
It needs to be listed in both places because dependencies has much more information than requires and that information is needed by npm. The broader answer to "why", though, is "why not?" The package-lock.json file is for npm internal use. The format changed between npm version 6 and npm version 7. It will probably change again. They'll probably do whatever works best for the npm command-line tool. That may involve duplicating information.

Related

WebdriverIO : Can we push code with dependencies only installed?

I am using webdriverIO v6
I have Installed just these two packages: npm install #wdio/cli as well as webdriverio
my tests are ruining smoothly in my local.
Is this ok to push to code-repo in git, does this work in Jenkis or Azure devops?
or is is required to install the --save-dev too to work in CI tools?
{
"name": "test-package",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"wdio": "./node_modules/.bin/wdio wdio.conf.js"
},
"author": "",
"license": "ISC",
"devDependencies": {
"#wdio/allure-reporter": "^6.1.23",
"#wdio/cli": "^6.1.25",
"#wdio/local-runner": "^6.1.25",
"#wdio/mocha-framework": "^6.1.19",
"#wdio/spec-reporter": "^6.1.23",
"#wdio/sync": "^6.1.14",
"chromedriver": "^83.0.1",
"wdio-chromedriver-service": "^6.0.3",
"webdriverio": "^6.1.25"
},
"dependencies": {}
}
This is nothing specific to wdio. This is a question which has been discussed multiple times in nodejs context.
Many developers suggest not to include node_modules in the repo because of various reasons which are logical. Then there are reasons which might force you to do it. if you are doing it just to reduce the build time, be prepared for other implications. Below are links which might help you.
https://flaviocopes.com/should-commit-node-modules-git/
Should "node_modules" folder be included in the git repository

Listed dependencies in package-lock.json file have mixed (sha1 / sha512) integrity checksum.

I understand npm have changed the integrity checksum from sha1 to sha512, But I am confused why few of the dependencies in package-lock json file still show sha1 integrity checksum.
Adding below few lines from the package-lock file, which has sha1 and sha512 mixed. As per my understanding all the sha1 should have been replaced by sha512.
"assign-symbols": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/assign-symbols/-/assign-symbols-1.0.0.tgz",
"integrity": "sha1-WWZ/QfrdTyDMvCu5a41Pf3jsA2c=",
"dev": true
},
"async": {
"version": "2.6.1",
"resolved": "https://registry.npmjs.org/async/-/async-2.6.1.tgz",
"integrity": "sha512-fNEiL2+AZt6AlAw/29Cr0UDe4sRAHCpEHh54WMz+Bb7QfNcFw4h3loofyJpLeQs4Yx7yuqu/2dLgM5hKOs6HlQ==",
"dev": true,
"requires": {
"lodash": "4.17.11"
}
},
"async-each": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/async-each/-/async-each-1.0.1.tgz",
"integrity": "sha1-GdOGodntxufByF04iu28xW0zYC0=",
"dev": true
},
"atob": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/atob/-/atob-2.1.2.tgz",
"integrity": "sha512-Wm6ukoaOGJi/73p/cl2GvLjTI5JM1k/O14isD73YML8StrH/7/lRFgmg8nICZgD3bZZvjwCGxtMOD3wWNAu8cg==",
"dev": true
},
"atob-lite": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/atob-lite/-/atob-lite-1.0.0.tgz",
"integrity": "sha1-uI3KYAaSK5YglPdVaCa6sxxKKWs="
},
"autoprefixer": {
"version": "6.7.7",
"resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-6.7.7.tgz",
"integrity": "sha1-Hb0cg1ZY41zj+ZhAmdsAWFx4IBQ=",
"dev": true,
"requires": {
"browserslist": "1.7.7",
"caniuse-db": "1.0.30000888",
"normalize-range": "0.1.2",
"num2fraction": "1.2.2",
"postcss": "5.2.18",
"postcss-value-parser": "3.3.0"
}
}
Any reference which would help me understand that will be helpful.
According to this post on the NPM Community Forum, only packages published with npm v5 or later will include an sha512 integrity hash.
If you are on npm v5 or later, and you're seeing this in your package-lock.json, one way to keep everything on sha512 instead of sha1 (according to this post) is to do the following:
Remove all sha1 integrity hashes from your package-lock.json
Run rm -rf node_modules
Run npm cache clean -f
Run npm install
This should result in a package-lock.json with the sha512 integrity hashes.

package-lock.json contains non-exact versions

According to package-lock.json's documentation
It describes the exact tree that was generated, such that subsequent
installs are able to generate identical trees, regardless of
intermediate dependency updates.
I'm looking at a package-lock.json file which contains versions like:
"less": "^3.0.4",
"less-loader": "^4.1.0",
"license-webpack-plugin": "^1.3.1",
"lodash": "^4.17.4",
"memory-fs": "^0.4.1
in the requires block of one of the dependencies.
While the child dependencies of the main project are "locked down" in that there is no version ambiguity, these transitive dependencies are not. But how is npm "able to generate identical trees, regardless of intermediate dependency updates" if any of the dependencies in the tree are subject to interpretation?
According to this thread, in npm#6 there was a change to how the package-lock.json represents dependency versions internally in that it records the originally requested ranged dependency, yet still locks down a specific version.
Previously, the package-lock did not record what version was originally requested by a dependency, only which version it resolved it to at the time of its creation.
Here's example:
package-lock.json
// OLD npm format
// Notice that ajv.requires contains specific version for 'fast-json-stable-stringify'
// also notice that 'fast-json-stable-stringify' entry **mentions for the second time** specific version
{
...
"dependencies": {
...
"ajv": {
"version": "6.11.0",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-6.11.0.tgz",
"integrity": "sha512-nCprB/0syFYy9fVYU1ox1l2KN8S9I+tziH8D4zdZuLT3N6RMlGSGt5FSTpAiHB/Whv8Qs1cWHma1aMKZyaHRKA==",
"dev": true,
"requires": {
"fast-deep-equal": "3.1.1",
"fast-json-stable-stringify": "2.1.0",
"json-schema-traverse": "0.4.1",
"uri-js": "4.2.2"
}
},
...
"fast-json-stable-stringify": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz",
"integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==",
"dev": true
},
...
}
...
}
And here's npm6 approach
// "new" npm format (as of npm#6)
// Notice that ajv.requires is not showing specific versions
// but instead shows same values as package.json contains
// However 'fast-json-stable-stringify' entry contains
// SPECIFIC version to have reproducible build
{
...
"dependencies": {
...
"ajv": {
"version": "6.11.0",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-6.11.0.tgz",
"integrity": "sha512-nCprB/0syFYy9fVYU1ox1l2KN8S9I+tziH8D4zdZuLT3N6RMlGSGt5FSTpAiHB/Whv8Qs1cWHma1aMKZyaHRKA==",
"dev": true,
"requires": {
"fast-deep-equal": "^3.1.1",
"fast-json-stable-stringify": "^2.0.0",
"json-schema-traverse": "^0.4.1",
"uri-js": "^4.2.2"
}
},
...
"fast-json-stable-stringify": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz",
"integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==",
"dev": true
},
...
}
...
}

npm publishing same version won't update dependencies from in package.json

For some reason I can't remove dependencies from my published npm package without changing the version.
When i first published it, package.json had some dependencies like:
"version": "1.0.0",
"author": {
"name": "me"
},
"dependencies": {
"#angular/common": "^4.2.0",
"#angular/core": "^4.2.0",
}
Later I removed the dependencies, changed the author and republished, what I get when I install the package is:
"version": "1.0.0",
"author": {
"name": "me-changed"
},
"dependencies": {
"#angular/common": "^4.2.0",
"#angular/core": "^4.2.0",
}
I'm using Nexus 2.14 as repository manager and NPM 3.10.
Is this a wanted feature? If not, what is causing it?
You can't change your package and publish it without updating the version. If you published one version it is fix and can't be changed afterwards.

package.json: Just download dependency but do not install it

I'm about to write a yeoman generator where the whole template is hosted on a git repository. So the package.json of my yeoman generator looks like
{
"name": "generator-foo",
"version": "0.1.0",
"description": "",
"files": [
"generators"
],
"keywords": [
"yeoman-generator"
],
"dependencies": {
"foo-template": "git://somewhere-in-the-world/foo-template.git#0.1.0",
"chalk": "^1.1.3",
"yeoman-generator": "^1.1.1",
"yosay": "^2.0.0"
}
}
Is there any way to prevent npm install from installing the foo-template package, i.e. running any postinstall script just for this package? Instead, it should be just downloaded to node_modules.
As describe here, postinstall scripts can be disabled globally for npm using --ignore-scripts flag.
As a complete solution, I would move your explicit dependency to foo-template to your local postinstall section with ignore scripts enabled:
{
"name": "generator-foo",
...
"postinstall": "npm install --ignore-scripts git://somewhere-in-the-world/foo-template.git#0.1.0",
"peerDependencies": {
"foo-template": "git://somewhere-in-the-world/foo-template.git#0.1.0"
}
}
Note that to make sure the dependency is explicitly described, we should mark it as a peerDependency (e.g. prevents package removal on prune).