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 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
I am using npm as a build tool and so in my package.json, and some of my scripts depend on other scripts:
{
"test": "npm run lint && mocha"
}
This hardcodes the npm package manager into package.json. How can make this approach to expressing dependencies work with both npm and yarn?
The $npm_execpath environment variable refers to the build tool, so just replace npm with the $npm_execpath:
{
"test": "$npm_execpath run lint && mocha"
}
Both npm test and yarn test will work, and will use the appropriate build tool.
While mjs' answer is great, there's also a small package that is purported to work on all environments including Windows: https://www.npmjs.com/package/yarpm
To use in a project, run yarn add yarpm --dev / npm i -D yarpm and then just use yarpm in your scripts like this:
{
"test": "yarpm run lint && mocha"
}
As the package README notes, you just need to make sure your commands would be suitable for passing through to either yarn or npm: you cannot use arguments/flags that only work on one package manager.
I want to do something like this, so npm install also installs the package.json of ../somelocallib or more importantly its dependencies.
"dependencies": {
"express": "*",
"../somelocallib": "*"
}
npm >= 2.0.0
This feature was implemented in the version 2.0.0 of npm. Local paths can be saved using npm install -S or npm install --save, using any of these forms:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
Example package.json:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
npm ls:
app#0.0.1 /private/tmp/app
└── somelocallib#0.0.1 -> /private/tmp/somelocallib
npm < 2.0.0
Put somelocallib as dependency in your package.json as normal:
"dependencies": {
"somelocallib": "0.0.x"
}
Then run npm link ../somelocallib and npm will install the version you're working on as a symlink.
Reference: link(1)
It is now possible to specify local Node module installation paths in your package.json directly. From the docs:
Local Paths
As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using npm install -S or npm install --save, using any of these forms:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
in which case they will be normalized to a relative path and added to your package.json. For example:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing packages to the public registry.
This works for me.
Place the following in your package.json file
"scripts": {
"preinstall": "npm install ../my-own-module/"
}
This is how you will add local dependencies:
npm install file:src/assets/js/FILE_NAME
Add it to package.json from NPM:
npm install --save file:src/assets/js/FILE_NAME
Directly add to package.json like this:
....
"angular2-autosize": "1.0.1",
"angular2-text-mask": "8.0.2",
"animate.css": "3.5.2",
"LIBRARY_NAME": "file:src/assets/js/FILE_NAME"
....
If you want to further automate this, because you are checking your module into version control, and don't want to rely upon devs remembering to npm link, you can add this to your package.json "scripts" section:
"scripts": {
"postinstall": "npm link ../somelocallib",
"postupdate": "npm link ../somelocallib"
}
This feels beyond hacky, but it seems to "work". Got the tip from this npm issue:
https://github.com/npm/npm/issues/1558#issuecomment-12444454
Master project
Here is the package.json you will use for the master project:
"dependencies": {
"express": "*",
"somelocallib": "file:./somelocallib"
}
There, ./somelocallib is the reference to the library folder as relative to the master project package.json.
Reference: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#local-paths
Sub project
Handle your library dependencies.
In addition to running npm install, you will need to run (cd node_modules/somelocallib && npm install).
This is a known bug with NPM.
Reference: https://github.com/npm/npm/issues/1341 (seeking a more up-to-date reference)
Notes for Docker
Check in your master package.lock and your somelocallib/package.lock into your source code manager.
Then in your Dockerfile use:
FROM node:10
WORKDIR /app
# ...
COPY ./package.json ./package-lock.json ./
COPY somelocallib somelocallib
RUN npm ci
RUN (cd node_modules/zkp-utils/ && npm ci)
# ...
I use parenthesis in my (cd A && B) constructs to make the operation idempotent.
Two steps for a complete local development:
Provide the path to the local directory that contains the package.
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
Symlink the package folder
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
Here in 2020, working on a Windows 10, I tried with
"dependencies": {
"some-local-lib": "file:../../folderY/some-local-lib"
...
}
Then doing a npm install. The result is that a shortcut to the folder is created in node-modules.
This doesn't work. You need a hard link - which windows support, but
you have to do something extra in windows to create a hard symlink.
Since I don't really want a hard link, I tried using an url instead:
"dependencies": {
"some-local-lib": "file:///D:\\folderX\\folderY\\some-local-lib.tar"
....
}
And this works nicely.
The tar (you have to tar the stuff in the library's build / dist folder) gets extracted to a real folder in node-modules, and you can import like everything else.
Obviously the tar part is a bit annoying, but since 'some-local-lib' is a library (which has to be build anyway), I prefer this solution to creating a hard link or installing a local npm.
I know that npm install ../somelocallib works.
However, I don't know whether or not the syntax you show in the question will work from package.json...
Unfortunately, doc seems to only mention URL as a dependency.
Try file:///.../...tar.gz, pointing to a zipped local lib... and tell us if it works.
With yarn it can be done as
yarn add file:../somelocallib
Curious.....at least on Windows (my npm is 3.something) I needed to do:
"dependencies": {
"body-parser": "^1.17.1",
"module1": "../module1",
"module2": "../module2",
When I did an npm install ../module1 --save it resulted in absolute paths and not relative per the documentation.
I messed around a little more and determined that ../xxx was sufficient.
Specifically, I have the local node modules checked out to say d:\build\module1, d:\build\module2 and my node project (application) in d:\build\nodeApp.
To 'install', I:
d:\build\module1> rmdir "./node_modules" /q /s && npm install
d:\build\module2> rmdir "./node_modules" /q /s && npm install
d:\build\nodeApp> rmdir "./node_modules" /q /s && npm install
module1's package.json has a dependency of "module2": "../module2"; module2 has no local dependency; nodeApp has dependencies "module1": "../module1" and "module2": "../module2".
Not sure if this only works for me since all 3 folders (module1, module2 and nodeApp) sit on that same level.......
This worked for me: first, make sure the npm directories have the right user
sudo chown -R myuser ~/.npm
sudo chown -R myuser /usr/local/lib/node_modules
Then your in your package.json link the directory
"scripts": {
"preinstall": "npm ln mylib ../../path/to/mylib"
},
"dependencies": {
"mylib" : "*"
}
Actually, as of npm 2.0, there is support now local paths (see here).
There is great yalc that helps to manage local packages. It helped me with local lib that I later deploy. Just pack project with .yalc directory (with or without /node_modules). So just do:
npm install -g yalc
in directory lib/$ yalc publish
in project:
project/$ yalc add lib
project/$ npm install
that's it.
When You want to update stuff:
lib/$ yalc push //this will updated all projects that use your "lib"
project/$ npm install
Pack and deploy with Docker
tar -czvf <compresedFile> <directories and files...>
tar -czvf app.tar .yalc/ build/ src/ package.json package-lock.json
Note: Remember to add .yalc directory.
inDocker:
FROM node:lts-alpine3.9
ADD app.tar /app
WORKDIR /app
RUN npm install
CMD [ "node", "src/index.js" ]
I wanted to use a set of local dependencies written in TypeScript, and none of the answers here worked for me. npm install would simply refuse to build the dependencies.
I had to resort to using tsconfig.json to add the packages to my project without marking them as dependencies. My usecase is further complicated by the fact that some dependencies depend on each other, and I wanted all of them to come from the local folder.
Here is my solution:
// tsconfig.json
{
"compilerOptions": {
"baseUrl": "./",
"paths": {
"#tiptap/*": [
"tiptap/packages/*/src"
]
}
}
}
In the example above, I have a local project subfolder named tiptap/ and there are many packages in tiptap/packages/*. The "paths" option will rewrite all #tiptap/foo imports into ./tiptap/packages/foo/src, across both my own files and the files in tiptap/.
It's not a good solution, but it is the only thing that worked for me.
use workspaces
the disadvantage using the file:../path/to/your-library is that you either have to npm install or using npm link in order to to the changes to take effect in the packages that import your package.
if you using pnpm: a better solution is using workspace: protocol: workspace:../path/to/your-library. it will symlink the directory to your node_modules rather than copying it, so any changes at the source immediately take effect.
for example:
...
"dependencies": {
...
"my-package": "workspace:../../dist"
},
note: this solution is intended to be used in a workspace, so you may need to create pnpm-workspace.yaml (even an empty one) file in the root of your project.
In 2021 you need to use it like:
npm i my-pkg#file:./path-to-my-pkg.js
# To remove it later
npm un my-pkg
Use .js in the end if its file OR path to folder if its complete package with package.json.
Usage
const myPkg = require('my-pkg')
That works like charm!
Complete local development guide for yarn users:
First add dependency to your main project:
cd main-project
yarn add file:../path/to/your-library
Next, if you want to avoid re-building this dependency every time you change it's source:
cd your-library
yarn link
This will register a link to your-library. Next, use the link you just created in your main project.
cd main-project
yarn link your-library
Now every time you change code in your-library, you don't need to rebuild it and it will automatically be included in your main-project. Yarn link works by creating symlinks in your node_modules folder, read more about it here: https://classic.yarnpkg.com/lang/en/docs/cli/link/
Using Module Alias
Install the module-alias package:
npm i --save module-alias
Add paths to your package.json like this:
{ "_moduleAliases": { "#lib": "app/lib", "#models": "app/models" } }
In your entry-point file, before any require() calls:
require('module-alias/register')
You can now require files like this:
const Article = require('#models/article');