I saw this somewhere, inside package.json:
"dependencies": {
...,
"npm": "^6.1.0",
...
}
Is there any point in this?
Will npm update itself as a result of this?
If yes, will it be able to do so if its current version is lower than 6?
This is not the normal practice for packages. This will not affect your global installation of npm.
If you wish to specify which version of npm your package requires to be installed, the engines field in the package.json is the proper place to put it. From the npm docs:
You can also use the “engines” field to specify which versions of npm are capable of properly installing your program. For example:
{ "engines" : { "npm" : "~1.0.20" } }
Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.
npm will not prevent installation of packages with a different version of npm listed in engines, but it will warn in the console that it's requesting a different version of npm than what you're using.
The only purpose of installing npm as a dependency would be if it's a package that somehow needs to use npm's API directly (like a node_modules/ analyzer, or something like that).
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).
We want to use AsyncAPI to document our RabbitMQ messaging. Therefore, we installed asyncapi/generator as a npm dependency.
If you have a look at the package.json you can see that it references npmi as a dependency which in turn is referencing to global-npm. If we want to run it, a globally installed node and npm is necessary.
Now if we run the generator ($ ag ./docs/asyncapi.yaml #asyncapi/html-template --output ./docs/asyncapi/ --force-write) on a machine which has no globally installed npm following error message appears:
/path/to/project/node_modules/global-npm/index.js:13
throw err
^
Error: Cannot find module 'npm'
at throwNotFoundError (/path/to/project/node_modules/global-npm/index.js:11:13)
at /path/to/project/node_modules/global-npm/index.js:39:5
...
As a workaround we declared npm itself as a dependency:
"dependencies": {
"#asyncapi/generator": "^1.1.4",
"#asyncapi/html-template": "^0.15.4",
"#asyncapi/markdown-template": "^0.11.1",
"npm": "^6.14.9",
...
I've never seen such a thing. Is this acceptable or do we need to install our npm on our machines separatly?
if you run ag you must have installed it with npm initially right? so npm is most probably on this machine already.
The error you have, I saw it on windows only, when you have the generator as dependency, and most likely you use nvm.
Solution was this, so manual bump of global-npm to have this fixed in npmi. This is a workaround,long term I think we need to get rid of npmi dependency from the generator I think
We only had this issue in our CI/CD pipeline working with maven-frontend-plugin which is installing node/npm. npm is located in node/node_modules. This is no location where AsyncAPI looks for npm. In order to fix this issue we link the npm-cli.js (which is npm) from
the maven-frontend-plugin to a well known place where AsyncApi looks up for npm node_modules/.bin.
- ln -sf "$(pwd)/node/node_modules/npm/bin/npm-cli.js" "$(pwd)/node_modules/.bin/npm"
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.
I have a project with a local file dependency in my package.json like this:
"dependencies": {
"dep_1": "file:../../dep_1"
}
}
When I do npm install it is installed into node_modules. But if I make changes to dep_1 how do I update the module version in node_modules?
I tried doing npm update but nothing happens.
If you are using a relatively new version of npm (I used version 2.14.2) you can bump the version number in package.json and npm update dep_1 should work. Otherwise how can npm know that something needs to be updated?
Note: This will only work if the version is higher than what has previously been installed. You will have to clean the cache to reset this behaviour.
However, you can forceably (and lazily) update local modules by simply running npm install again. e.g.
npm install dep_1
It should be fast since its on your local computer and you don't have to play around with version numbers.
For more detail see the discussion about this issue on the official npm repository page: https://github.com/npm/npm/issues/7426
I'm buidling two private npm packages that depends on each other.
Say that I have :
project
/my-commons
package.json :
{
name : "my-commons",
version : "0.0.1"
...
}
/my-server
package.json :
{
dependencies : {
"my-commons" : "0.0.1"
}
}
I can use 'npm link' to install the 'commons' package. So anyone willing to
start working on server has to do :
checkout project
cd my-server
npm link ../my-commons
npm install
And a symlink to ../my-commons is added in /my-server/node_modules, and everything's fine.
Is there however a way to tell npm that 'my-commons' package will always be in that folder out there, so that you could just do :
checkout project
cd my-server
npm install
Or am I missing something obvious here ?
Thanks
Maybe.
But first: If my-commons is needed by my-server then it is most likely a good idea to keep it in my-server/node_modules even if that is redundant. In most cases it's best keep a module's dependencies isolated from the rest of your application.
In that scenario, npm link can be used during development, when you're working on my-commons and want to use the changes in my-server without having to npm publish my-commons.
In production you will not want to use npm link, because dependent modules will lose control over which version of the linked module they end up with. If my-server depends on my-commons 0.1.0, but you npm linked your 1.0.1-pre-release version of the my-commons module all hell might break loose.
However, since version 1.2.10 (shipping with node 0.8.19) NPM supports peer dependencies.
Peer dependencies allow you to specify that my-server requires that my-commons be installed "besides" my-server. This does not enable you to require("my-commons") inside my-server but could be useful if my-server is a plugin for my-commons.
For more information: http://blog.nodejs.org/2013/02/07/peer-dependencies/
And finally, since you said that you are developing private packages: If installing the packages is what is causing trouble for you, because you can't publish your packages to the public NPM registry, have a look at alternative ways to specify dependencies (git-, http-URLs, TGZ files): https://docs.npmjs.com/files/package.json#dependencies