Related
Following this answer, I installed my local dependency like this:
{
"private": true,
"dependencies": {
"my_dependency": "../relative/path/to/my_dependency"
}
}
my_dependency depends on ESLint and its plugins:
{
"name": "my_dependency",
"dependencies": {
"#typescript-eslint/eslint-plugin": "5.25.0",
"#typescript-eslint/parser": "5.25.0",
"eslint": "8.16.0",
"eslint-plugin-import": "2.26.0",
"eslint-plugin-node": "11.1.0"
},
If I install my_dependency as a path, eslint and it's plugins are not installed in ./node_modules, therefore eslint CLI is not available.
However, if I publish my_dependency on npm and install it as package name and version,
{
"private": true,
"dependencies": {
"my_dependency": "0.0.0"
}
}
eslint and all plugins will be added in ./node_modules.
How to get the same effect for the local dependency?
I don't want to pollute npm registry with versions just for experiment each time I make changes in my_dependency.
The issue
Unfortunately those local path packages don't get their dependencies installed.
note: Packages linked by local path will not have their own dependencies installed when npm install is ran in this case. You must run npm install from inside the local path itself.
Source: docs.npmjs.com/...
The workaround
There are quite a few ways around it but in my opinion the best one is to use a GitHub repo and optionally a branch.
So just push your code to a github repo, let's say my-npm-playground, assuming your use your Github username is ada_lovelace, you can link the repo like so,
{
"private": true,
"dependencies": {
"my_dependency": "ada_lovelace/my-npm-playground"
}
}
I has been told
ESLint couldn't find the plugin "#typescript-eslint/eslint-plugin".
(The package "#typescript-eslint/eslint-plugin" was not found when loaded as a Node module from the directory "D:\XXX\NNN".)
It's likely that the plugin isn't installed correctly. Try reinstalling by running the following:
npm install #typescript-eslint/eslint-plugin#latest --save-dev
by ESLint. Why it's strange is the package with ESLint preset has #typescript-eslint/eslint-plugin among dependencies:
{
"name": "#yamato_daiwa/style_guides",
"dependencies": {
"#typescript-eslint/eslint-plugin": "5.19.0",
"#typescript-eslint/parser": "5.19.0",
"eslint": "8.13.0",
"eslint-plugin-node": "11.1.0"
},
"peerDependencies": {
"#typescript-eslint/eslint-plugin": "^5.18.0",
"#typescript-eslint/parser": "^5.18.0",
"eslint": "^8.13.0",
"eslint-plugin-node": "^11.1.0",
"typescript": ">=4.0.0 <4.7.0"
}
}
(I am not sure that peerDependencies are required but I must keep this question focues on one problem)
I expected that all dependencies will be automatically added to node_modules but it has not been (there is no #typescript-eslint among scope directories):
My node version is 16.3.
Update
Looks like #typescript-eslint/eslint-plugin has been added to node_modules below library with ESLint preset. I expected it will be added to directory below node_modules of the project, not below project/node_modules/#yamato-daiwa/style_guides/node_modules.
Do you really need eslint-plugin as a peerDependency in your project?
If so, inspect that you're trying to install the same version of eslint-plugin as the lib that is requiring it.
If not, remove it.
according to documentation: "When a dependency is listed in a package as a peerDependency, it is not automatically installed. Instead, the code that includes the package must include it as its dependency.
npm will warn you if you run npm install and it does not find this dependency."
https://flaviocopes.com/npm-peer-dependencies/
If all else fails, try running "npm ci" (clean install) rather than npm install.
I have a repository containing a package.json which contains scoped dependencies. I also have an .npmignore file intended to whitelist all files and subdirectories in dist/. The problem is all of the scoped dependencies are included when running npm install #private/a another repository. This includes both private npm packages and public packages such as #uirouter.
package.json:
{
"name": "#private/a",
"version": "1.0.0",
"description": "",
"main": "dist/index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"repository": {
"type": "git",
"url": "git+ssh://git#bitbucket.org/private/a.git"
},
"author": "",
"license": "ISC",
"homepage": "https://bitbucket.org/private/a#readme",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-angular-embed-templates": "^2.3.0",
"gulp-concat": "^2.6.1",
"gulp-jshint": "^2.0.4",
"gulp-rename": "^1.2.2",
"gulp-sass": "^3.0.0",
"gulp-uglify": "^2.0.0",
"jshint": "^2.9.4"
},
"dependencies": {
"#private/b": "^1.0.0",
"#private/c": "^1.0.0"
}
}
.npmignore
**
!dist/**
Despite these two files when I run npm install #private/a --save within another repository it is installing the dependency along with all it's scoped dependencies:
/node_modules/#private/a/dist/index.js
/node_modules/dist/css/styles.css
/node_modules/#private/a/node_modules/#private/b
/node_modules/#private/a/node_modules/#private/c
package.json
It should only be this:
/node_modules/#private/a/dist/index.js
/node_modules/dist/css/styles.css
package.json
How can I achieve this? I have tried different variations of the .npmignore but have not had any luck.
.npmignore is irrelevant to what you are trying to do. This file only decides which parts of your npm package code ends up in npm registry. So it is working as advertised.
Your problem must be in your npmconfig or because of using an older version of npm. The latest version installs stuff as so:
/node_modules/#private/a/dist/index.js
/node_modules/#private/b/...
/node_modules/#private/c/...
package.json
I have verified that this is happening with latest npm. But there used to be a time when npm installed dependencies into a nested structure. See this for example. So I suggest:
Making sure you have latest node and npm.
Making sure your npm config is not forcing legacy bundling. Run npm get legacy-bundling. Make sure this is false.
There are few cases where the nesting of dependencies happens legitimately even with the latest npm. See this. But I am guessing your problem is not due to this. You can test by simply doing npm install #private/a in an empty folder.
Node will install your package files along with all the dependencies declared under dependencies field.
How the dependencies tree is build, depends on which version of npm do you use.
If your package doesn't need those dependencies to run, it means they are just dev dependencies and you can safely list them under devDependencies field.
Dev dependencies are only installed when you run an npm install inside the plugin directory.
You need to lock your dependency. You might want to check out npm shrinkwrap.
I would like to use the grunt-contrib-jasmine NPM package. It has various dependencies. Part of the dependency graph looks like this:
─┬ grunt-contrib-jasmine#0.4.1
│ ├─┬ grunt-lib-phantomjs#0.2.0
│ │ ├─┬ phantomjs#1.8.2-2
Unfortunately, there's a bug in this version phantomjs which prevents it from installing correctly on Mac OS X. This is fixed in the latest version.
How can I get grunt-lib-phantomjs to use a newer version of phantomjs?
Some additional context:
grunt-contrib-jasmine explicitly requires version "~0.2.0" of grunt-lib-phantomjs, which explicitly requires version "~1.8.1" of phantomjs.
Adding phantomjs to my package's dependencies first has no effect; both versions are installed and grunt-contrib-jasmine still uses the older versions (see: When installing a package with NPM, can you tell it to use a different version of one of its dependencies?).
You can use npm shrinkwrap functionality, in order to override any dependency or sub-dependency.
I've just done this in a grunt project of ours. We needed a newer version of connect, since 2.7.3. was causing trouble for us. So I created a file named npm-shrinkwrap.json:
{
"dependencies": {
"grunt-contrib-connect": {
"version": "0.3.0",
"from": "grunt-contrib-connect#0.3.0",
"dependencies": {
"connect": {
"version": "2.8.1",
"from": "connect#~2.7.3"
}
}
}
}
}
npm should automatically pick it up while doing the install for the project.
(See: https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/)
As of npm cli v8.3.0 (2021-12-09) this can be solved using the overrides field of package.json. As described in StriplingWarrior's answer
For example, the project has typescript version 4.6.2 as direct development dependency and awesome-typescript-loader that uses old version 2.7 of typescript. Here is how you can tell npm to use version 4.6.2 of typescript for awesome-typescript-loader:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"typescript": "~4.6.2",
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "$typescript"
}
}
}
If you don't use typescript as direct development dependency, then you have to write 4.6.2 instead of $typescript in overrides section:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "~4.6.2"
}
}
}
For using the latest version of dependency:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "latest"
}
}
}
Same overrides can be used for both dependencies and devDependencies.
If you're using npm version >5 but <8.3.0: edit your package-lock.json: remove the library from "requires" section and add it under "dependencies".
For example, you want deglob package to use glob package version 3.2.11 instead of its current one. You open package-lock.json and see:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"glob": "7.1.2",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
}
},
Remove "glob": "7.1.2", from "requires", add "dependencies" with proper version:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
},
"dependencies": {
"glob": {
"version": "3.2.11"
}
}
},
Now remove your node_modules folder, run npm ci (or npm install for old version of node/npm) and it will add missing parts to the "dependencies" section.
As of NPM v8.3, the correct way to deal with this is via the overrides section of your package.json file.
If you need to make specific changes to dependencies of your
dependencies, for example replacing the version of a dependency with a
known security issue, replacing an existing dependency with a fork, or
making sure that the same version of a package is used everywhere,
then you may add an override.
Overrides provide a way to replace a package in your dependency tree
with another version, or another package entirely. These changes can
be scoped as specific or as vague as desired.
To make sure the package foo is always installed as version 1.0.0 no
matter what version your dependencies rely on:
{
"overrides": {
"foo": "1.0.0"
}
}
There are a variety of other, more nuanced configurations allowing you to only override a package when it's a dependency of a particular package hierarchy. For more details, check out https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
The only solution that worked for me (node 12.x, npm 6.x) was using npm-force-resolutions developed by #Rogerio Chaves.
First, install it by:
npm install npm-force-resolutions --save-dev
You can add --ignore-scripts if some broken transitive dependency scripts are blocking you from installing anything.
Then in package.json define what dependency should be overridden (you must set exact version number):
"resolutions": {
"your-dependency-name": "1.23.4"
}
and in "scripts" section add new preinstall entry:
"preinstall": "npm-force-resolutions",
Now, npm install will apply changes and force your-dependency-name to be at version 1.23.4 for all dependencies.
For those using yarn.
I tried using npm shrinkwrap until I discovered the yarn cli ignored my npm-shrinkwrap.json file.
Yarn has https://yarnpkg.com/lang/en/docs/selective-version-resolutions/ for this. Neat.
Check out this answer too: https://stackoverflow.com/a/41082766/3051080
Nested replacement with an entirely different package
Most of the strategies outlined in the other answers here work well if you are just interested in overriding the package's version number, but in our case, we needed to find a way to override a nested npm sub-dependency with a different package altogether. For details on why you would ever want to do this, please refer to the following question:
How to override a nested npm sub-dependency with a different package altogether (not just different package version number)?
Specify the tarball directly
For nested replacement of a package with an entirely different package using the npm-force-resolutions strategy that others have mentioned, you just need to provide a link to the tarball where you would normally specify the overriding version number.
As an example, for the case of replacing the vulnerable package, ansi-html, with the fixed fork of this package, ansi-html-community, your resolutions section of package.json should look like this:
"resolutions": {
"ansi-html": "https://registry.npmjs.org/ansi-html-community/-/ansi-html-community-0.0.8.tgz"
}
To find the link to the tarball, use the following command, modifying your registry as necessary:
npm view ansi-html-community dist.tarball --registry=https://registry.npmjs.org/
Also, note that for npm-force-resolutions to work when you run npm install, you will need a preinstall entry under the scripts section of package.json:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
#user11153 's answer worked for me locally, but when trying to do a clean install (aka deleting node_modules), I would get:
npm-force-resolutions: command not found
I had to update the preinstall script to be:
"preinstall": "npm i npm-force-resolutions && npm-force-resolutions"
Which ensures that npm-force-resolutions package is installed before attempting to run it.
That being said, if you're able to use yarn instead, I would do that and then use #Gus 's answer.
I had an issue where one of the nested dependency had an npm audit vulnerability, but I still wanted to maintain the parent dependency version. the npm shrinkwrap solution didn't work for me, so what I did to override the nested dependency version:
Remove the nested dependency under the 'requires' section in package-lock.json
Add the updated dependency under DevDependencies in package.json, so that modules that require it will still be able to access it.
npm i
I was about to go down the npm-force-resolutions route but it seems that simply including the dependency in my own package.json fixed the problem for me.
I believe this worked in my case because the original dependency allows for patch versions of the dependency in question that I wanted to update. Thus by manually including a newer version it still fulfilled the dependency of the original dependency and will use the one I've manually added.
Example
Problem
I need to update plyr to version 3.6.9 from 3.6.8
Mine
package.json
{
"dependencies": {
"react-plyr": "^3.2.0"
}
}
React Plyr
package.json
{
"dependencies": {
"plyr": "^3.6.8"
}
}
Notice for the plyr dependency it starts with ^ this means it can accept any minor patches. You can learn more about that here:
https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept
Updating Mine
This updates the plyr dependency from my package.json.
package.json
{
"dependencies": {
"plyr": "^3.6.9",
"react-plyr": "^3.2.0"
}
}
Based on the rest of the answers, I provide the same solution, but I display the package.json, as I struggled a little bit on where to place the override and how.
{
"name": "my-app",
"version": "snapshot",
"scripts": {
"ng": "ng",
"build-dev": "ng build --configuration development",
},
"private": true,
"dependencies": {
"#angular/animations": "~14.2.9",
"#angular/common": "~14.2.9"
...
},
"devDependencies": {
"#angular-devkit/build-angular": "^14.2.8",
....
},
"overrides": {
"loader-utils#>2.0.0 <3": "2.0.4",
"loader-utils#>3.0.0 <4": "3.2.1"
}
}
For November 2022 "loader-utils" security vulnerability, it was requested to
use the version 2.0.4, if you are in the 2.X
use the version 3.2.1, if you are in the 3.X
And to verify
add the package.json the override tag
delete the package-lock.json
run "npm install"
run "npm audit"
Run this first
npm i -D #types/eslint#8.4.3
it will solve the issue
I'm using npm v1.4.4 and node v0.10.25 on Mac OS X 10.9.2.
I've recently upgraded node and npm, and now npm install is no longer creating the .bin directory in node_modules.
I've deleted node_modules, tried npm install again, but the directory and binaries are never created.
Does anybody have any ideas as to why this is happening?
Here is my package.json:
{
"name": "redacted",
"author": {},
"description": "redacted",
"dependencies": {
},
"devDependencies": {
"karma": "*",
"karma-coverage": "0.1.2",
"karma-junit-reporter": "*",
"karma-coffee-preprocessor": "~0.1",
"grunt": "^0.4.2",
"grunt-contrib-requirejs": "^0.4.3",
"grunt-contrib-concat": "^0.3.0",
"grunt-contrib-sass": "^0.7.2",
"grunt-contrib-htmlmin": "^0.2.0",
"grunt-contrib-cssmin": "^0.7.0",
"grunt-contrib-coffee": "^0.10.1",
"grunt-contrib-uglify": "^0.3.3",
"grunt-contrib-jst": "^0.5.1",
"grunt-contrib-qunit": "^0.4.0",
"grunt-contrib-jshint": "^0.8.0",
"grunt-contrib-watch": "^0.5.3",
"grunt-contrib-jasmine": "^0.6.1",
"grunt-contrib-compress": "^0.6.1",
"grunt-contrib-handlebars": "^0.6.1",
"grunt-contrib-less": "^0.9.0",
"grunt-contrib": "^0.9.0"
}
}
I know this is an old post but I experienced the same issue recently. I had copied files from an existing project including package.json and package-lock.json. The package-lock.json was what prevented the node_module/.bin directory from being created.
The solution was to delete the node_modules directory and package-lock.json and run npm install again
The ./node_modules/.bin directory is where npm creates links to a node package's binary. From https://docs.npmjs.com/files/folders#executables
Executables
When in global mode, executables are linked into
{prefix}/bin on Unix, or directly into {prefix} on Windows.
When in local mode, executables are linked into ./node_modules/.bin so
that they can be made available to scripts run through npm. (For
example, so that a test runner will be in the path when you run npm
test.)
The package.json you pasted above do not have a bin section. Take a look at this example from npm's package.json
{
"version": "1.4.9",
"name": "npm",
"publishConfig": {
"proprietary-attribs": false
},
"description": "A package manager for node",
...
...
"main": "./lib/npm.js",
"bin": "./bin/npm-cli.js",
"dependencies": {
"abbrev": "~1.0.4",
"ansi": "~0.2.1",
...
...
Specifically the line "bin": "./bin/npm-cli.js" will tell npm to create a link at ./node_modules/.bin/npm to node_modules/npm/npm-cli.js
Seems that all your dependencies are dev dependencies.
Could you see if your NODE_ENV environment variable is set to production now? If yes you will need to change it back.
Also, any error happened during installation?
If all packages installed, only the .bin is gone.
you can just run npm rebuild
In my case I had webpack running in watch mode in another console window. I did not get any errors during npm install so it took me a moment to notice.
Ensure the dependencies are not in use, such as karma running tests or webpack running in watch mode
Delete the dependency folders, such as node_modules/karma, or the entire node_modules folder. NPM does not seem to create symlink files in .bin folder if dependency folder already exists.
Retry npm install
With NPM 6.7.0.
Not really an answer to your question, but because I had a similar situation: I run npm with the --no-bin-links option on my VM so my windows host doesn't complain. And then later I don't find the bin links folder... duh!
This could happen because of the broken npm. Try following command from the npm troubleshooting and it should just work fine.
curl -L https://www.npmjs.org/install.sh | sh