I need to know if the following behavior is normal.
When I npm install, each package from my package.json and the dependencies, don't get installed nested anymore, but each dependency is installed in the node_modules directory. That makes my node_modules directory blown and look like this:
This happened since I updated npm and node.
Now I run:
npm -v 3.3.6
node -v 4.2.1
python 2.7
windows 7
wamp
My package.json file looks like this:
{
"private": true,
"devDependencies": {
"gulp": "^3.8.8"
},
"dependencies": {
"laravel-elixir": "^3.0.0",
"bootstrap-sass": "^3.0.0"
}
}
It's the standard laravel package.json file.
Is there a way to have nested directories again, because I don't like such a blown article with over 100 sub directories.
Update: As Erik Pukinskis mentioned in the comments:
As of npm 3.5, support for --legacy-bundling has been dropped.
Yes, there is a way to have nested directories again by changing npm's (version 3 as of this writing) default behaviour:
Delete the currently present node_modules folder.
Tell npm to install with legacy bundling for this one install:
npm install --legacy-bundling
A "permanent" alternative:
Set your npm config to always use legacy bundling...
npm set legacy-bundling=true
.. and run as usual:
npm install
Note: fetching dependencies with legacy bundling will take a lot more time because many several different versions of the same dependencies will be installed.
Disclaimer: As a non-Windows user I have no need for flat dependencies and want to find self-declared dependencies with ease in favour of automatic deduping. Since installing npm dependencies without legacy bundling already takes an incredible amount of time I'm usually willing to spend those extra minutes install time. It gets back down to 5 directories from previously 700+ (...) in a Laravel Elixir setup with bootstrap (non-sass), font-awesome and jquery added.
That's the new behavior of npm 3 as per this npm blog.
Related
I am getting 6 vulnerabilities after running npm audit report:
I tried a solution and overridden the vulnerable versions of a particular package with their latest versions in package.json file like this:
"overrides": {
"nth-check": "2.1.1",
"#svgr/webpack": "6.5.1",
"#svgr/plugin-svgo": "6.5.1",
"svgo": "3.0.1",
"css-select": "5.1.0"
}
Then I updated the npm packages with npm update. But it did not change the result.
Tried another solution by making a resolution object in package.json and specified specific versions of a particular package, and ran it using npx i npm-force-resolutions but it gives this error:
npm ERR! could not determine executable to run.
But I am still unable to fix the npm vulnerabilities. Please help!
You should delete both node_modules and package-lock.json before launching npm install again; this will require more time to install all dependencies, but this will override all the version that are currently installed (it will bring also minor updates in dependencies).
Also, for this vulnerability, you only need to override nth-check. You can see the changes by executing npm list nth-check with and without the override (remember to delete both node_modules and package-lock.json).
I am learning about the differences between package.json and package-lock.json
I been experimenting on a package with only one dependency called chance
I first installed it via npm i chance#1.0.0 and the package.json has "chance": "^1.0.0" and package-lock.json has "version": "1.0.0".
Because I wanted to see the effect that the lock file has on the version, I went ahead and deleted package-lock.json and node_modules, I ran npm install, the version of chance stays the same in package.json, which is "chance": "^1.0.0". In the newly created lock file, the version of chance became "chance": {"version": "1.1.8",, so it updated itself.
I then deleted package-lock.json and node_modules again and ran npm update, the results seemed to be the same with the previous experiment – in package.json I have "^1.0.0" in package.json and "1.1.8" in package-lock.json
My questions are:
in either case, with "^1.0.0" in package.json and "1.1.8" in package-lock.json, which version of the dependency am I actually using in my project, I guess it is 1.1.8 right? so by merely looking at the versions in package.json is not enough to determine the exact version of the dependencies used in a project?
When does running npm install change the lock file? I know that if we delete the lock file, it will generate a new one with the newest versions in the allowable ranges from package.json. But are there any cases where npm install would change the lock file even if I didn't delete the lock file?
So, the answer is a bit complex. Essentially there are 2 things at play: The version of the package you want/need, and the version of the package that is installed.
When you are building a project, you probably don't care what specific version of a given dependency is. Most of the time you want the latest one, or the latest patch near a specific major version. The package.json is supposed to document what you, the developer, believe is required for your project to work. So, if you put in the package json "chance": "1.0.0", it would mean that only version 1.0.0 exactly is acceptable, and any other version is unacceptable. If you put "chance": "^1.0.0", it means any version compatible with 1.0.0 is acceptable. So 1.2 or 1.3 might also be fine, but 1.4 might introduce a change that breaks compatibility.
Once you decide what packages you want, by writing the package json, you run npm install. npm install can't always install exactly the versions you want. For example, imagine you want to install two packages: React v1.13 and momentJS v2.8. So you add these to your package json like this:
(Note: these version numbers and dependancies are not based on real React or Moment version numbers)
"momentJS" : "2.8",
"react" : "1.13"
then you run npm install. And you get an error: Package dependencies cannot be resolved. (or something like that). The problem is that React version 1.13 requires momentJS 2.9, but your package json specifies that you want version 2.8 exactly. You can't have both, so npm isn't able to resolve the conflict. A fix would be:
"momentJS" : "^2.8",
"react" : "1.13"
Now you are saying that you need a version of moment compatible with 2.8, and you are okay with npm adjusting that to satisfy other packages. Run npm install again and npm might install version 2.9, which satisfies both your requirement of "compatible with 1.8" and React, which wants 2.9. Now, the web app I'm currently working on has over 1,000 dependancies total, so npm absolutely needs to be able to adjust version numbers in order to get all of those packages to play nice.
Now there is often more than one way to solve a dependancy graph--more than one way to adjust all the version numbers to make every package happy. Your package lock file records what the current solution is and what actual packages are installed.
All the options for specifying package verions are here
Hope that helps!
Also: the second part of your question was "will npm change the lock file without me deleting it?" And the answer is: basically everytime you run npm install, npm changes the lock file. What npm does try to do is change the lock file as little as possible with each new install and keep most packages the same
Using Visual Studio code as IDE but lately when I run the command - npm install from the app folder of the solution it installs around 374 items under "node_modules" instead of just installing the packages from the package.json file.
Can someone please provide some pointers for this behavior?
My versions:
node -v
v6.9.1
npm -v
3.10.8
Go to your node_modules folder and find one of the folders matching the libraries from your package.json file. Inside you will find another package.json which describes this library. It is most likely it will also have at least a couple of entries in dependencies section.
When you run npm install npm builds so-called 'dependency tree'. It starts with your top-level package.json and checks what dependencies needs to be installed, then (using its registry) it checks what are the dependencies of these dependencies and then their dependencies and so on...
It is prudent (but often neglected) to check what are the dependencies of the libraries you decide to use. Some of them might have licenses incompatible with yours. Some of them might need a ton of code to perform a simple thing. Many will use deprecated versions, which will spam your npm install log with warnings and might actually cause some conflicts with your other dependencies.
I really dont know why the NPM has started downloading about 40+ modules on Npm install but my package.json only contains following dependencies.
"devDependencies": {
"typescript": "^1.6.2",
"vscode": "0.10.x"
},
"dependencies": {
"fs": "^0.0.2"
}
Following are the list it started. Besides these modules there are about double of this number downloaded and added below but i didnt show here.
Is there any way to reset. I have tried to remove the modules folder and install again it started adding again.
Yesterday when i run i only get these dependencies only on other PC.
HeadCode is correct. npm3 installs some dependencies in a flat way.
From the docs:
While npm2 installs all dependencies in a nested way, npm3 tries to mitigate the deep trees and redundancy that such nesting causes. npm3 attempts this by installing some secondary dependencies (dependencies of dependencies) in a flat way, in the same directory as the primary dependency that requires it.
So, if you are using npm v2.x on one machine, and npm v3.x on another, you can get very different folder structures under your node_modules folder.
I have an application which has the usual set of dependencies on third party modules (e.g. 'express') specified in the package.json file under dependencies. E.g.
"express" : "3.1.1"
I would like to structure my own code modularly and have a set of local (meaning on the file system I am currently in) modules be installed by the package.json. I know that I can install a local module by running:
npm install path/to/mymodule
However, I don't know how to make this happen via the package.json dependencies structure. Using the --save option in this command is simply putting "mymodule": "0.0.0" into my package.json (doesn't reference the filepath location). If i then remove the installed version from node_modules, and try to re-install from the package.json, it fails (because it looks for "mymodule" in the central registry, and doesn't look locally).
I'm sure the is a way of telling the "dependencies": {} structure that I want it to be installed from a file system path, but don't know how.
Anyone else had this problem?
Thanks.
npm install now supports this
npm install --save ../path/to/mymodule
For this to work mymodule must be configured as a module with its own package.json. See Creating NodeJS modules.
As of npm 2.0, local dependencies are supported natively. See danilopopeye's answer to a similar question. I've copied his response here as this question ranks very high in web search results.
This feature was implemented in the version 2.0.0 of npm. For example:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
Any of the following paths are also valid:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
syncing updates
Since npm install <folder> adds the package in the directory as a symlink in the current project any changes to the local package are automatically synced.
See: Local dependency in package.json
It looks like the answer is npm link: https://docs.npmjs.com/cli/link
I couldn't find a neat way in the end so I went for create a directory called local_modules and then added this bashscript to the package.json in scripts->preinstall
#!/bin/sh
for i in $(find ./local_modules -type d -maxdepth 1) ; do
packageJson="${i}/package.json"
if [ -f "${packageJson}" ]; then
echo "installing ${i}..."
npm install "${i}"
fi
done
After struggling much with the npm link command (suggested solution for developing local modules without publishing them to a registry or maintaining a separate copy in the node_modules folder), I built a small npm module to help with this issue.
The fix requires two easy steps.
First:
npm install lib-manager --save-dev
Second, add this to your package.json:
{
"name": "yourModuleName",
// ...
"scripts": {
"postinstall": "./node_modules/.bin/local-link"
}
}
More details at https://www.npmjs.com/package/lib-manager. Hope it helps someone.
You can just add to your package.json file in your project
"package-name" : "path/to/package"
and then run npm i in your project
At work we have a common library that is used by a few different projects all in a single repository. Originally we used the published (private) version (npm install --save rp-utils) but that lead to a lot of needless version updates as we developed. The library lives in a sister directory to the applications and we are able to use a relative path instead of a version. Instead of "rp-utils": "^1.3.34" in package.json it now is:
{
"dependencies": { ...
"rp-utils": "../rp-utils",
...
the rp-utils directory contains a publishable npm package
use install-local
I had issues with conflicting react installations from the local dependency.
I solved the error by using install-local npm package. This package does not create symlinks, which solved my issue.
Steps:
run npm i -g install-local
run npx install-local --save <local-path> inside the target repository to install the local dependency
Further reading: https://www.npmjs.com/package/install-local
The error I received, when trying to install the local package with npm install --save <local-directory>:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
You might have mismatching versions of React and the renderer (such as React DOM)
You might be breaking the Rules of Hooks
You might have more than one copy of React in the same app
If it's acceptible to simply publish your modules preinstalled in node_modules alongside your other files, you can do it like this:
// ./node_modules/foo/package.json
{
"name":"foo",
"version":"0.0.1",
"main":"index.js"
}
// ./package.json
...
"dependencies": {
"foo":"0.0.1",
"bar":"*"
}
// ./app.js
var foo = require('foo');
You may also want to store your module on git and tell your parent package.json to install the dependency from git: https://npmjs.org/doc/json.html#Git-URLs-as-Dependencies