For example, when you do npm init and install express, you end up with a node_modules folder with 20 other folders in it.
I never ran into this issue... but isn't it something that may be a concern?
First, it's important to do our homework before installing a package.
Read the package's page on npmjs.com and look at who published the package, the number of versions and the number of weekly downloads. If these numbers are very low, I would pass or definitely inspect the source code.
Another thing to do is to pay attention when you type the package name, when you install. Typo squatting is possible and there are published packages which have names close to popular packages.
In terms of how secure is NPM (the registry), they do periodic penetration testing and outgoing code reviews. Also, they report vulnerabilities to package authors and handle vulnerabilities reports from other users. But, it's a continuous fight against spammers, malware, etc.
Commands you can run:
npm outdated (for locals) and npm outdated -g --depth=0 (for globals)
This will check which packages are outdated and it will list "Current Wanted Latest" versions for each outdated package.
npm audit
This will produce a report of security vulnerabilities with the affected package name, vulnerability severity and description, etc.
Also, npm audit automatically runs when you install a package with npm install.
npm audit fix
This automatically install compatible updates to vulnerable dependencies.
More:
(https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities)
(https://www.youtube.com/watch?v=H48KuESn2sk)
When writing Node.js applications, ending up with hundreds or even thousands of dependencies can easily happen.
For example, if you depend on Express, you depend on 27 other modules directly, and of course on those dependencies' as well, so manually checking all of them is not an option!
The only option is to automate the update / security audit of your dependencies. For that there are free and paid options:
npm outdated
Trace by RisingStack
NSP
GreenKeeper
Snyk
Yea, it is def something to keep in mind. That being said, most of the time, you will be dealing with pretty popular libraries/packages that are safe to assume they are secure. However, if you DO need to download one that isn't super popular, just take a look at the source code.
Edit: A concern for security becomes more off an issue when you install packages globally. NEVER install a package globally that you have any doubts about.
Of course, there may be malicious code in it. It's just like installing a software, you do not install random modules. Just make sure the packages you install are trustworthy.
Related
I hope you are doing well!
I got asked about why should I use -f to force npm install packages to install. In the documentation it states that
force npm to fetch remote resources even if a local copy exists on disk.
But does this mean that it redownloads global packages for the local project or what does it solve exactly?
Another thing happens is when I use npm install, I see a lot of warnings in the console that
WARNING: X package is deprecated
But when I run npm outdated I see that all packages are all fairly up to date (all match the recommended version to download), so I assume this might be a dependency for a certain package. But does it affect our work negatively? Why does this happen?
For the packages I download, I generally look for packages that have in the 6 digits Weekly Downloads from npm so I don't think we are using unfamiliar packages.
I am asking these questions because they have been asked to me but I don't have a straight answer to them.
Thank You!
I don't understand how npm install -f works
Let's say I published few years back a npm package package_a.
Now I actually "namespaced" all my packages under #myfancyname/package_a.
Is there a way to transform package_a install process so that
npm install -g package_a
actually just run
npm install -g #myfancyname/package_a
(of course this should work also for npm install package_a -> npm install #myfancyname/package_a)
This might be bad practice, so please advice in this case as well.
TL;DR: It's likely that the best solution is to use npm deprecate on your old package to provide people with a message directing them to the new package name.
This issue in the npm issue tracker suggests contacting support#npmjs.com. The issue is quite old, though, and also only seems to suggest contacting support for a large number of packages. Although the issue may be out of date, if there's a better way to do things, I'm sure the support team would redirect you there.
That said, while that npm issue title asks about a redirect (implying, to me at least, automatic redirect like what you want), the answers seem to be more about "redirecting" by informing users. Chances are, that's the recommended way, for better or worse. So you can use npm deprecate on your old package to provide people with a message directing them to the new package name.
I am working on a react project and I am using various npm packages. Now there were 1002 vulnerable packages when I started fixing/updating my old packages. And at last this only 20 vulnerable packages were remained which were also very low priority.
But now again after 3 months the vulnerability has increase to 925 vulnerable packages. So my question is, when I am using packages.lock.json for installing a specific package version only. Then how the vulnerabilities increased. I mean is there any mechanism which npm follow before telling "this package is vulnerable." I want to know how npm check if this package is vulnerable or not. Even when it was fine before and I am using same package version with same node version as well.
npm as a package manager runs audit of the installed/installing dependencies to check for the vulnerabilities posted/reported on that particular NPM package you installed/installing. It list them out to notify/warn you about the problem you might encounter, using such packages.
It will be an API call from npm to the registry. Read further: docs.npmjs.com/cli/audit#description
One can manually audit its dependencies as well. using the following command:
npm audit
Make sure you are running this command in the same directory where your package-lock.json exists.
If you are using yarn as a package manager, you can run:
yarn audit
Here is a great explanation on npm vulnerability.
https://snyk.io/blog/understanding-filesystem-takeover-vulnerabilities-in-npm-javascript-package-manager/
NPM vulnerability check mainly depends on the version and last publish date of each packages.
On Windows NPM has issues due to its deep nesting of dependencies. In order to fix this a friend suggested the following command
npm install <dep> -g --no-bin-link
The man pages say about this command
The --no-bin-links argument will prevent npm from creating symlinks for any binaries the package might contain."
Could anyone explain, in plain language, what the impact this flag has on allowing dependencies to be installed that would usually causing deep path issues?
Could anyone explain, in plain language, what the impact this flag has on allowing dependencies to be installed that would usually causing deep path issues?
Sure. Many packages published on npm can be used both as a command-line tool and programmatically. For example the jslint package publishes both a command-line tool for linting files and an API that can be required, so you can write code that uses jslint
The deep path issues usually become visible when creating the files that go into the bin directory, for command-line use. The deep paths usually do not affect packages used programmatically with require.
So for "regular" dependencies of a package, it is usually harmless to omit the bin links, because those dependencies are consumed with require.
For "dev" dependencies or packages installed globally, it is usually necessary to keep the bin links, because those packages are more likely to be used as command-line tools.
Incidentally you should update to the latest npm if you haven't yet -- latest is 2.1.16 at this writing, and a guide for updating npm on windows is here: https://github.com/npm/npm/wiki/Troubleshooting#upgrading-on-windows
Recently I start committing my application node_modules folder into VCS to speed up deployments and fix dependencies.
I noticed that many npm packages contain a bunch of stuff unnecessary to me like tests and various builds that I'll never use and I wrinkle every time when I put it in my repo.
So, what should one put into npm package?
The tests and other items are usually a good item to include in your devDependencies.
You can install packages without them by using npm install --production or setting the configuration flag to production using npm config set production
I would recommend looking at this page and reading the information in the different types of dependencies to get an understanding of what each does.
That being said the bare minimum to include is just what it takes for your module to run but that varies based on the module you're creating. Although a README.md is almost essential if you're sharing your package publicly so users can git a quick overview of your package on npm and github.