I am trying to optimize my CI build step. I want to install certain dependencies before installing others. How can I achieve that?
For example, suppose my package.json file is:
{
"name": "my-project",
"version": "1.0.0",
"author": "krismath",
"dependencies": {
"lib-a": "^1.5.13",
"lib-b": "^0.7.2",
"lib-c": "^15.0.61"
}
I want to install lib-b first in order to use it in other build steps. If I do
npm install lib-b
this doesn't guarantee that the version of lib-b will be semantically compatible with the one in package.json.
Related
If a package version, or peer dependency version is unavailable during an npm install, is it possible to configure NPM to ignore the version, and downgrade to the next lower version automatically (perhaps with a warning)?
No matching version found for #babel/generator#^7.18.9.
In most cases you or one of your dependencies are requesting
a package version that doesn't exist.
However, it exists here. While this is a issue probably for babel, we run a private npm-read-group that updates only every few hours, and it can be an issue when downloading packages that have just been updated.
As long as I know you should define "latest" as value. For example:
{
"name": "name",
"private": true,
"description": "",
"dependencies": {
"lodash": "latest"
}
}
I do not recommend doing this, but it should work for what you wish.
If I have a monorepo with packageA and packageB, with the latter having a dependency on the former. If I then run lerna version major, for example, resulting in packageA's version number being bumped, does the listing of the dependency on it in packageB's package.json also get bumped automatically, or should that be done manually?
(I tried setting up a test repository to do this, but then Lerna was complaining it didn't have a remote yet, so I'm hoping someone with experience using Lerna knows the answer.)
For the sake of this answer, I'm going to assume you are not using conventional Commits. Please feel free to respond with more specifics if I assume wrong.
TL;DR
Yes, if you run lerna version major _all packages in your repo will be updated to a new major version and the package.json file for packageB will be updated with the new version number for packageA.
Details
Let's say you have your packageA and packageB packages in your monorepo and they have package.json files that look like this:
# packageA/package.json
{
"name": "packageA",
"version": "1.0.0,"
}
# packageB/package.json
{
"name": "packageB",
"version": "1.0.0",
"dependencies": {
"packageA": "^1.0.0"
}
}
When you run `lerna version major:
The version field in packageA/package.json will update to 2.0.0
The version field in packageB/package.json will update to 2.0.0
The dependencies.packageA field in packageB/package.json will update to ^2.0.0
# packageA/package.json
{
"name": "packageA",
"version": "2.0.0,"
}
# packageB/package.json
{
"name": "packageB",
"version": "2.0.0",
"dependencies": {
"packageA": "^2.0.0"
}
}
We want to update the lodash version to 4.17.11 but it is dependency of grunt-angular-translate . grunt-angular-translate is in package.json . If i am updating the grunt-angular-translate to 0.3.0 it is not updating the lodash to version 4.7.11 .How can we update the dependency which is in package-lock.json.
package.json:
"devDependencies": {
"grunt": "^1.0.3",
"grunt-angular-translate": "^1.0.0",
"grunt-bump": "^0.8.0",
package-lock.json:
"grunt-angular-translate": {
"version": "0.3.0",
"resolved": "https://registry.npmjs.org/grunt-angular-translate/-/grunt-angular-translate-0.3.0.tgz",
"integrity": "sha1-vQEYr6JNj1cCMf2NUtgp2AjFEbM=",
"dev": true,
"requires": {
"flat": "^1.2.0",
"json-stable-stringify": "^1.0.0",
"lodash": "~2.4.1"
},
"dependencies": {
"lodash": {
"version": "2.4.2",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-2.4.2.tgz",
"integrity": "sha1-+t2DS5aDBz2hebPq5tnA0VBT9z4=",
"dev": true
}
}
},
As per npm docs:
package-lock.json is automatically generated for any operations where
npm modifies either the node_modules tree, or package.json. It
describes the exact tree that was generated, such that subsequent
installs are able to generate identical trees, regardless of
intermediate dependency updates.
This file is intended to be committed into source repositories, and
serves various purposes:
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.
And optimize the installation process by allowing npm to skip repeated
metadata resolutions for previously-installed packages.
In package.json you specify which npm packages you are utilizing in your app. In other words on which you have a specific dependency so your package can function.
package-lock.json is a big "map" of each of the packages your app uses and their dependencies which you can not impact.
In your case grunt-angular-translate has its own dependency on "lodash": "~2.4.1" and you can not change it and should not try to since that package is supposed to work with that version and not with 2 versions higher package where there may be a bunch of breaking changes.
You can upgrade your direct dependency of lodash to its latest version but that would not update grunt-angular-translate dependency to lodash to that version and it really should not.
What should really happen is in your node_modules folder you will get your updated lodash (and you can check by looking at its package.json and the version inside). In that same folder if you go into the grunt-angular-translate folder and look at its own node_modules ... it should have its own lodash folder with lodash 2.4.1 in it.
I have a package.json file which has dependencies defined as below (i.e im using exact versions for every package):
"dependencies": {
"async": "0.9.2",
"body-parser": "1.15.1",
"cookie-parser": "1.4.2",
"csvtojson": "0.3.21",
"express": "4.13.4",
"jsonwebtoken": "7.1.9",
"lodash": "4.16.6",
"mongodb": "1.4.40",
"request": "2.78.0",
"seneca": "3.3.0",
"seneca-amqp-transport": "2.1.0"
}
When i run npm install on this package.json file twice and compare the node_modules folders generated, i see differences in the folder. The difference is usually in the readme,_from and url field of the packages (Refer attachments for the same).
Is this expected?
Does this difference have any impact on my application ?
Is there a way to avoid it?
You should use .gitignore (Or something like it) to ignore the node_module. There is no need to push them so you don't have to worry about this problem.
Our project uses npm for package management. After upgrading from npm 4 to npm 5, we decided to opt-in for the new package-lock.json.
After committing it and performing npm install on other machines, we spotted differences in the way the version and resolved entries are specified:
1) example of package-lock.json dependencies with version encoded as URL:
"jspm": {
"version": "https://registry.npmjs.org/jspm/-/jspm-0.16.52.tgz",
"integrity": "sha1-axhH4I8TGsm9JnzFiXSXmudnXS4=",
"dev": true
},
"systemjs": {
"version": "https://registry.npmjs.org/systemjs/-/systemjs-0.19.46.tgz",
"integrity": "sha1-wEV0szNfBSoOPHoA7kGIxuTB444=",
"dev": true
},
2) example of package-lock.json dependencies with version and resolved properties:
"jspm": {
"version": "0.16.53",
"resolved": "https://registry.npmjs.org/jspm/-/jspm-0.16.53.tgz",
"integrity": "sha1-VvNR9JWUyJM+XgG2UUWsrr/PtZ4=",
"dev": true,
"dependencies": {
...
}
},
"systemjs": {
"version": "0.19.46",
"resolved": "https://registry.npmjs.org/systemjs/-/systemjs-0.19.46.tgz",
"integrity": "sha1-wEV0szNfBSoOPHoA7kGIxuTB444=",
"dev": true
},
...
In addition to having an unstable package-lock.json, our build server is having issues when installing the first example.
Follow this procedure to produce a stable version of the package-lock.json:
delete the existing node_modules folder
delete the existing package-lock.json
perform npm install
commit and push the package-lock.json
For the rest of the team:
delete the existing node_modules folder
pull the new package-lock.json
perform npm install
Deleting the existing node_modules before continuing is an essential step because the package-lock.json does parse existing metadata from the node_modules folder.
This means that if your node_modules folder has leftovers, they may get added to the package-lock's dependencies, even if they're not an actual dependency (anymore).
You may want to check in this situation on both machines that:
your node + npm version are the same and maybe doing npm -g update npm.
the npm configuration property save-exact has the same value on both machines. (otherwise doing npm config set save_exact true/false)