I'm using the scripts section of the package.json to force resolutions:
"preinstall": "npx npm-force-resolutions"
in the resolutions section, I have entered graceful-fs with a specified version:
"resolutions": {
"graceful-fs": "^4.2.4",
},
When i run npm i everything is installed correctly, the set versions are taken in to account. But later on when I install an additional module, e.g. npm i random-package, my set versions are being thrown away and I endup with graceful-fs#1.2.3 and other low versions in some dependencies.
If I clear the node_modules folder and run npm i again, everything is alright again.
I also tried setting the resolution more specific, like
"resolutions": {
"glob/**/graceful-fs": "^4.2.4",
},
but this doesn't help.
I also tried:
adding the module as dependency, devDependency or peerDependency
using a shrinkwrap and overriding it there
but no luck.
what am I missing?
The best solution for me to automate this was modifying preinstall script as above:
"preinstall": "npm install --package-lock-only --ignore-scripts && npx npm-force-resolutions",
Best way is to change the preinstall script to this:
"preinstall": "([ ! -f package-lock.json ] && npm install --package-lock-only --ignore-scripts --no-audit); npx npm-force-resolutions"
This will only run npm install to create your initial package-lock.json when it does not exist yet.
This is much faster than always running both (npm + npx).
As of npm 8.3.0, you can also use npm's override:
{
"overrides": {
"graceful-fs": "^4.2.4"
}
}
in the resolutions section, you must fix version
"resolutions": {
"graceful-fs": "4.2.4",
},
Hi #NthDegree the only way which worked for me was to first run the normal npm install and then add the packages-lock.json file to git. After doing that when you add "preinstall": "npx npm-force-resolutions", it always updates the dependency resolution to the version mentioned.
I am not sure if adding packages-lock.json file to git is good or bad but by using this method the CI/CD pipeline works as well.
If all of the above answers don't work and you still get sh: npm-force-resolutions: command not found
try the following:
Just change:
"preinstall": "npx npm-force-resolutions"
To:
"preinstall": "npx force-resolutions"
npx force-resolutions does not run when no package-lock.json is detected, and allows the next command inline to be executed as normal
Credit to: https://github.com/rogeriochaves/npm-force-resolutions/issues/10#issuecomment-885458937
Related
I've setup a node project with husky but when my collegue tries to run npm install on his Mac he gets the following error :
noa-be#1.0.0 prepare
husky install
sh: husky: command not found
npm ERR! code 127
npm ERR! path /Users/X/Desktop/Workspace/project
npm ERR! command failed
npm ERR! command sh -c husky install
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/X/.npm/_logs/2021-04-12T13_07_25_842Z-debug.log
These are the relevant package.json parts:
{
"scripts": {
"prepare": "husky install"
},
"devDependencies": {
"husky": "^5.2.0",
}
}
I thought this would be enough for husky to be installed when running npm install, but it's not. What am I missing?
If you are using nvm, you might want to create a file called .huskyrc in your home directory and add the following lines of code to it:
~/.huskyrc
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
I was struggling with the same exact problem for hours. Finally, I could install dependencies and start working on my project by doing this:
Temporarily remove the "prepare": "husky install" script from the package.json file.
Run npm i (npm install). Dependencies installed successfuly.
Add again the "prepare" script that you removed in step 1.
Run again npm i to install the husky git hooks, so husky can do its job from now on.
This error is also thrown by npm ci if the NODE_ENV is set to "production" pre-install
I've been able to solve the problem by upgrading to latest Husky version (7.0.1, from 5.2.0).
Git was also helpful, and told me that the files weren't executables. (Git V 2.24.1)
So I give them executable rights :
chmod +x PATH_TO_HUSKY_FILE
You'll need to execute this command for every hooks
I believe it could be version specific issue. Install version 6, npm i husky#6.0.0 --save-dev, and it should work as the husky doc says.
Apparently, when I did npm i husky --save-dev, it was installing "husky": "^0.8.1" for me for some strange reason, giving me the exact same error: sh: husky: command not found.
Method 1:
Update manually, in your package.json:
{
"scripts": {
"prepare": "husky install",
"create-hook": "husky add .husky/pre-commit \"npm test\"",
}
}
Then, run npm run prepare && npm run create-hook.
It should create .husky directory with .pre-commit file in it.
Method 2:
npx husky install
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npm test"
It worked in my terminal but not in VSCode version control. So had to force quite the vscode app and restarting it worked.
Faced this issue in Github Desktop.
solved it by quit Github Desktop and re-open it.
I was able to fix this by providing an explicit location for husky
"scripts": {
"prepare": "node_modules/.bin/husky-run install"
},
Using Lerna
When I upgraded husky from version 4 to 8 there was information todo first pre commit manually. For this purpose pre-commit bash script was generated in .husky directory.
What I had todo was simply run the command included in this file:
lerna run precommit --concurrency 2 --stream
If I have a NPM 7 workspace like this:
root
- submodule0
- submodule1
- submodule2
and I navigate to the submodule0 directory and run npm i somepackage it seems to "break" the workspace by creating a new package-lock.json in the submodule0 directory and installing all the dependencies there. In other words, it just does the old behavior that existed before I created the workspace.
I was hoping for a command similar to lerna where I can install a new package in submodule0 from the root. Something like:
npm i somepackage --scope submodule0
So far, the only workaround I can find is to edit the submodule0 package.json and add the somepackage manually. Then run npm i from the root. Obviously this is not ideal because I need to look up the #latest version, navigate to the subdirectory, open the package.json, etc. etc. as opposed to just typing one line in the root.
Workspace support for npm install and npm uninstall was added in npm v7.14.0. You can now just do:
npm i somepackage --workspace=submodule0
Uninstalling modules has been the biggest pain, so this is really exciting. The npm team seems to be slowly adding support to commands one by one. Follow updates here: https://github.com/npm/cli/blob/latest/CHANGELOG.md.
I'm also baffled with why npm workspaces has been released without this functionality.
My current workaround uses the add-dependencies package, which adds dependencies to a declared package.json file, whilst skipping the installation process.
npm i add-dependencies -g
Then, from top level of the monorepo, you can run:
npx add-dependencies ./submodule0/package.json somepackage && npm i
Hopefully a --workspace argument will be added to npm i soon to avoid this faff.
Please refer to the answer of mattwad above if you have NPM v7.14.0 or above
Original answer
I wasn't quite happy with the suggestions, but combined all of them to use it in a npm script without any dependencies:
{
"add": "npm install --package-lock-only --no-package-lock --prefix",
"postadd": "npm install"
}
This can be used like following: npm run add -- submodule0 somepackage
Add only into package.json
U can use this to install package only into package.json ( you don't need external dependencies )
npm i --prefix packages/test --save --package-lock-only --no-package-lock express
followed by npm i to install specified dependency into mono repository root node_modules
Lerna
Also can use lerna to use workspace name to install dependency into
package.json
{
"name": "mono",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"wsi": "function workspaceinstall() { ( scope=$1; shift; lerna exec --scope \"$scope\" -- npm install --package-lock-only --no-package-lock \"$#\") }; workspaceinstall"
},
"author": "",
"license": "ISC",
"workspaces": {
"packages": [
"packages/**"
]
}
}
lerna.json
{
"version": "1.0.0",
"npmClient": "npm",
"packages": ["packages/**"]
}
npm run wsi [workspace name] [dependency name to install]
npm run wsi #workspace/test express
npm run wsi #workspace/test express --save-prod
npm run wsi #workspace/test #types/express --save-dev
wsi script only modify package.json for provided workspace name, to actually install dependencies u have to run npm i
In my case, which is similar to yours, I deleted all dependencies from all the inner projects, deleted also the package-lock.json, and installed everything in the root.
/
node_modules
package.json >> all dependencies
package-lock.json >> the only lock file that exists in the repo
/packages
/A
package.json >> no dependencies
-- no package-lock.json
/B
package.json >> no dependencies
-- no package-lock.json
/C
package.json >> no dependencies
-- no package-lock.json
This way, the node_modules folder ONLY resides on the root, and also the package-lock.json file is in the root.
If I allowed to have each project it's own package-lock.json I started seeing installation and runtime errors (because each project could have its own node_modules and its own version of a dependency).
This is the best way I see it works.
After trying to use the npm install with the --prefix --save --package-lock-only --no-package-lock options, npm always give the the error E404 - Not Found for my own packages of the monorepo that are not yet published to a registry. So even when trying to install external packages it fails because of my current dependencies in the package.json.
To workaround this issue I ended up with a mix of the previous suggestions:
"scripts": {
"add": "add-dependencies $npm_config_scope/package.json",
"postadd": "npm i",
},
"devDependencies": {
"add-dependencies": "^1.1.0"
},
Then I can do:
npm run add --scope=packages/app express
npm run add --scope=packages/core eslint jest -D
This works fine for installing external packages. To install my own packages that lives inside the monorepo, I still have to manually edit the package.json, otherwise I get the package not found error.
I'm looking for a pattern to avoid the need of global packages when working with node, I'd like to install everything I need with npm install and then just running every command with npm run xxx, without any global package installed.
For example, I have jest configured to run my tests.
These are the dependencies in my package.json:
[...]
},
"author": "",
"license": "ISC",
"dependencies": {
"#types/express": "^4.16.1",
"#types/node": "^11.10.5",
"express": "^4.16.4",
"ts-node-dev": "^1.0.0-pre.32",
"typescript": "^3.3.3333"
},
"devDependencies": {
"#types/jest": "^24.0.9",
"#types/supertest": "^2.0.7",
"jest": "^24.3.1",
"nodemon": "^1.18.10",
"supertest": "^4.0.0",
"ts-jest": "^24.0.0"
}
[...]
and these are some scripts I have configured:
[...]
"scripts": {
"test": "jest --coverage",
"tsc": "tsc",
"watch": "nodemon --watch 'src/**/*.ts' --exec 'ts-node' src/server.ts"
},
[...]
But when I issue npm run test I get this error:
$ npm run test
> ci-test#0.0.1 test /home/sas/devel/apps/vue/ci-test
> jest --coverage
sh: 1: jest: not found
npm ERR! file sh
[...]
If I install jest globally with npm install -g jest everything runs fine, but that's precisely what I'm trying to avoid.
A few assumptions I made that might be wrong:
when running scripts node first looks for commands in node_modules/.bin (in order to use locally installed packages)
when I issue npm install every command line command is installed to node_modules/.bin
This last one is not working, because even though I have jest in my devDependencies there's no node_modules/.bin/jest file in my project
$ ls node_modules/.bin/
acorn cdl esgenerate esvalidate is-ci json5 loose-envify mime nodetouch parser semver sshpk-sign strip-indent watch
atob escodegen esparse import-local-fixture jsesc js-yaml marked mkdirp nopt rc sshpk-conv sshpk-verify uglifyjs
On the other hand, as a workaround, the following seems to work:
"scripts": {
"test": "npx jest --coverage",
But it takes more than 10 seconds for npx to install jest everytime I run npm run test
So, what would be the correct way to achieve it? O how can I tell npm to install jest to node_modules/.bin and use it whe I reference it in my scripts?
It seems like it was easier than expected, I just had to issue:
npm install --only=dev
seems like by default npm won't install dev dependencies
I did a couple more tests, playing with the NODE_ENV var, and after unsetting it npm install seems to install also devDependencies, along with jest in node_modules/.bin/jest. It seems like somehow it was assuming I was in production mode.
Another trick I learned to avoid installing global dependencies is to install it with --save-dev, and then adding a script to run it with npm run. For example, to avoid installing jest globally but still be able to use it from the command line you should:
npm install jest --save-dev
Then add the following to your package.json
scripts: {
"jest": "jest"
}
And then you can run it from the command line with npm run jest. To pass params from the command line you have to add a '--' before the params, like this: npm run jest -- --coverage. Or you could just issue npx jest --coverage, if installed, npx will use jest from node_modules/.bin. (check this for more info)
BTW, this answer to a similar question might be useful
How to save the installation of global package using package.json?
I couldn't find any good solutions but I did this like below:
In package.json I added the following:
"scripts": {
"preinstall": "npm install babel babel-cli -g"
},
It would run and install the above packages globally before installing all the dependencies and devDependencies in package.json.
But the problem would be that I would not be able to find out, are those packages installed globally in any of the machines.
Please help, if anyone have any better solution of this.
It's a bad practice to force global install of a module. You can put babel and babel-cli in your devDependencies and then use them in your npm scripts :
{
"build" : "babel src -d build"
},
"devDependencies": {
"babel-cli": "^6.18.0"
}
If you are looking to run your package via CLI, you need to set up using bin approach.
Here's one of my libraries for example, fol. It is meant to be ran via command line only.
At the most minimal setup, you would wire both main and bin to the same JS file, for example, adding the following in package.json:
"main": "./bin/fol.js",
"bin": {
"fol": "./bin/fol.js"
},
Then, put the files into bin folder for the same of consistency, everybody will recognise that's CLI app stuff if it's in /bin/.
Bower is for client side Javascript what npm is for the server side and reads a component.json file to recognize dependencies that should be fetched at deploy time so I'd be happy it heroku would run it at slug compilation time.
Unfortunately I can not invoke npm or bower from a heroku console or one-off command (heroku run "npm help") (heroku run bash -> npm help) as it's possible with ruby's rake. I've put npm and node (latest/x versions) in my package.json but in the engines section, not the dependencies.
I think this could be solved by customizing the node buildpack but I consider this a little too heavy task just for activating something so obvious.
You can also setup a postintall command, something like this in your package.json
"dependencies": {
"bower": "0.6.x"
},
"scripts": {
"postinstall": "./node_modules/bower/bin/bower install"
}
Then npm install will also install bower dependencies.
Pros : one command to rule them all.
Cons : you unnecessarily embed bower as a dependency.
You can use run like this:
heroku run npm install git://github.com/webjay/kaiseki
You should declare NPM dependencies in the package.json file
All you install from shell will be deleted on exit shell. You are in a cloned instance.
You can use bower directly like this
"dependencies": {
"bower": "^1.7.9"
},
"scripts": {
"postinstall": "sudo bower install --allow-root "
}