How do I sort out npm vulnerabilities dependent on another package.
For example I am getting the below error where the package undici is dependent on the prismix package.
Thinks I have tried:
Running npm audit fix
Prismix is already updated to the latest version
Moderate undici before v5.8.0 vulnerable to CRLF injection in request headers
Package undici
Patched in >=5.8.0
Dependency of prismix
Path prismix > #prisma/sdk > #prisma/engine-core > undici
More info https://github.com/advisories/GHSA-3cvr-822r-rqcc
The authors of prismix may not have updated their dependencies yet.
You might need to wait for their dependencies to be updated, or you could try installing the version 5.8.0 of undici nonetheless and cross your finger that they are compatible.
To specify a version:
npm install undici#5.8.0
What am I supposed to do with these warnings, given the libs in question belong to 3rd party libs?
> npm audit
=== npm audit security report ===
Manual Review
Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance
Low Denial of Service
Package node-fetch
Patched in >=2.6.1 <3.0.0-beta.1|| >= 3.0.0-beta.9
Dependency of aspnet-prerendering
Path aspnet-prerendering > domain-task > isomorphic-fetch >
node-fetch
More info https://npmjs.com/advisories/1556
Moderate Regular Expression Denial of Service
Package postcss
Patched in >=8.2.10
Dependency of #angular-devkit/build-angular [dev]
Path #angular-devkit/build-angular > resolve-url-loader > postcss
More info https://npmjs.com/advisories/1693
found 2 vulnerabilities (1 low, 1 moderate) in 1514 scanned packages
2 vulnerabilities require manual review. See the full report for details.
I'm not impacted by this. I was just striving for zero warnings on all fronts.
I can't/don't want to fiddle with a dependency's dependency! Do I just need to upgrade my dependency?
Technically, there is no silver bullet to solve the vulnerabilities report from npm audit. Here is the "Rule of Thumb" I am following:
Usually, I always do npm audit fix after npm audit. Note that: this one will not solve all reports.
Update my dependencies to the latest stable. Be careful about the compatibility. (Hope you understand the SEMVER). The cost you spend to keep your system up to date and stable is always cheaper than the cost you need to spend to handle vulnerable issues.
Reduce the number of your dependencies. Note everything you need to use the library. You can build yourself a simpler version.
Learn to separate dependencies and dev dependencies. If the issue is reported for a dev tool, you can skip it. As I said above, there is no silver bullet so give yourself relaxation instead of fixing all of them. Just fix the necessary ones.
Finally, follow this: https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities
You can make your dependencies to use other (current / secure) version of their dependencies.
Let's say you have a warning about postcss package, which I solved a moment ago so I can describe the process and you can proceed analogically.
After npm audit I got a warning like:
Moderate Regular Expression Denial of Service
Package postcss
Patched in >=8.2.10
Dependency of laravel-mix [dev]
Path laravel-mix > cssnano > cssnano-preset-default >
postcss-svgo > postcss
More info https://npmjs.com/advisories/1693
Notice! You have to be aware that when you'll make your package to use a newer version of its dependency it can break things, but it's worth trying.
So you see that the laravel-mix package uses old version of the postcss and that the issue is fixed in version >=8.2.10 of postcss so you want to install a newer version of the postcss package which you can achieve by:
npm install postcss --save-dev
Then you need to add a new section to your package.json file instructing npm that you want dependencies to use your specific version of the library. It goes in my case like this:
{
"resolutions": {
"postcss": "^8.2.15",
}
}
Then you have to add a new script to force npm usage of this new "resolutions" section like this:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
Notice! You have to run this script every time before running your regular npm install. It goes like this:
npm run preinstall
npm install
More info can be found in the npm docs.
You might just need to edit your package.json, update the version for the offending package to the latest stable version (in this case https://www.npmjs.com/package/node-fetch), and then run "npm install" from the terminal.
recently I've been getting this error message on github
Upgrade minimist to version 0.2.1
high severity
Vulnerable versions: < 0.2.1
Patched version: 0.2.1
minimist before 1.2.2 could be tricked into adding or modifying properties of Object.prototype using a "constructor" or "proto" payload.
Im not too sure why I'm getting this error. I never installed the minimist package before. I just created my project from create-react-app.
Is this something I should be worried about? If it is, how do i fix it?
thank you
If you run:
npm ls minimist
you will see which of your installed packages has a dependency on minimist. Most likely they will be dev packages that only run while building your project. Unless you will be deploying these packages, the security warning is not something you should worry about.
Here is more information about this warning for Angular apps. It most likely holds for React apps also: Upgrade minimist to >=1.2.3
You probably have a dependency that is using it. You should check your package-lock.json and see which one it is.
What are the differences between Yarn and NPM?
At the time of writing this question I can only find some articles on the Internet showing what's the Yarn equvalent of an NPM command like this.
Do they have the same functionalities (I know Yarn does local caching and looks like you only need to download a package once) but other than this is there any benefits for moving from NPM to Yarn?
UPDATE: March 2018 (bit late...)
Since version 5, npm
generates a 'lockfile' called package-lock.json that fixes your entire dependency tree much the same way the yarn (or any other) locking mechanism does,
A tool has been made
--save is now implied for npm i
Better network and cache usage
npm 5.7.0 further introduced the npm ci command to install dependencies more quickly in a continuous integration environment by only installing packages found in the package-lock.json (reporting an error if the package-lock.json and package.json are not synchronized).
Personally, I still use npm.
Original
I am loathe to quote directly from docs, but they do a great job of explaining why, concisely enough that I don't see how to further summarize the ideas.
Largely:
You always know you're getting the same thing on every development
machine
It paralellizes operations that npm does not, and
It makes more efficient use of the network.
It may make more efficient use of other system resources (such as RAM) as well.
What are people's production experiences with it? Who knows, it's an infant to the general public.
TL;DR from Yehuda Katz:
From the get-go, the Yarn lockfile guarantees that repeatedly running
yarn on the same repository results in the same packages.
Second, Yarn attempts to have good performance, with a cold cache, but
especially with a warm cache.
Finally, Yarn makes security a core value.
Nice blog post
“NPM vs Yarn Cheat Sheet” by Gant Laborde
Slightly longer version from the project:
Fast: Yarn caches every package it downloads so it never needs to
again. It also parallelizes operations to maximize resource
utilization so install times are faster than ever.
Reliable: Using a detailed, but concise, lockfile format, and a
deterministic algorithm for installs, Yarn is able to guarantee that
an install that worked on one system will work exactly the same way on
any other system.
Secure: Yarn uses checksums to verify the integrity of every installed
package before its code is executed.
And from the README.md:
Offline Mode: If you've installed a package before, you can install it again without any internet connection.
Deterministic: The same dependencies will be installed the same exact way across every machine regardless of install order.
Network Performance: Yarn efficiently queues up requests and avoids request waterfalls in order to maximize network utilization.
Multiple Registries: Install any package from either npm or Bower and keep your package workflow the same.
Network Resilience: A single request failing won't cause an install to fail. Requests are retried upon failure.
Flat Mode: Resolve mismatching versions of dependencies to a single version to avoid creating duplicates.
More emojis. 🐈
What is PNPM?
pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a single place on the disk and a hard link will put it into the node_modules where it should be installed.
As a result, you save gigabytes of space on your disk and you have a lot faster installations! If you'd like more details about the unique node_modules structure that pnpm creates and why it works fine with the Node.js ecosystem, read this small article: Why should we use pnpm?
How to install PNPM?
npm install -g pnpm
How to install npm package using PNPM?
pnpm install -g typescript // or your desired package
Benefits of PNPM over Yarn and NPM
Here is progress-bar showing installation time taken by NPM, YARN and PNPM (shorter-bar is better)
Click for Complete check Benchmark
for more details, visit https://www.npmjs.com/package/pnpm
Trying to give a better overview for beginners.
npm has been historically (2010) the most popular package manager for JavaScript. If you want to use it for managing the dependencies of your project, you can type the following command:
npm init
This will generate a package.json file. It contains all the dependencies of the project.
Then
npm install
would create a directory node_modules and download the dependencies (that you added to the package.json file) inside it.
It will also create a package-lock.json file. This file is used to describe the tree of dependecies that was generated. It allows developpers to install exectly the same dependencies. For example, you could imagine a developper upgrading a dependency to v2 and then v3 while another one directly upgrading to v3.
npm installs dependencies in a non-deterministically way meaning the two developper could have a different node_modules directory resulting into different behaviours. **npm has suffered from bad reputation as for example
in February 2018: an issue was discovered in version 5.7.0 in which running sudo npm on Linux systems would change the ownership of system files, permanently breaking the operating system.
To resolve those problems and others, Facebook introduced a new package manager (2016): Yarn a faster, more securely, and more reliably package manager for JavaScript.
You can add Yarn to a project by typing:
yarn init
This will create a package.json file. Then, install the dependencies with:
yarn install
A folder node_modules will be generated. Yarn will also generate a file called yarn.lock. This file serve the same purpose as the package-lock.json but is instead constructed using a deterministic and reliable algorithm thus leading to consistant builds.
If you started a project with npm, you can actually migrate to Yarn easily. yarn will consume the same package.json. See Migrating from npm for more details.
However, npm has been improved with each new releases and some projects still uses npm over yarn.
The answer by #msanford covers almost everything, however, I'm missing the security (OWASP's Known Vulnerabilities) part.
Yarn
You can check them using yarn audit, however, you cannot fix them. This is still an open issue on a GitHub (https://github.com/yarnpkg/yarn/issues/7075).
npm
You can use npm audit fix, so some of them you can fix by yourself.
Both of them, i.e. npm audit & yarn audit have their own Continuous Integration tools. These are respectively https://github.com/IBM/audit-ci (used, works great!) and https://yarnpkg.com/package/audit-ci (haven't used).
npm:
The package manager for JavaScript. npm is the command-line
interface to the npm ecosystem. It is battle-tested, surprisingly
flexible, and used by hundreds of thousands of JavaScript developers
every day.
NPM generates a correct lock file whereas a Yarn lock file could be
corrupt in some cases and has to be fixed with yarn-tools
Yarn:
A new package manager for JavaScript. Yarn caches every package it
downloads so it never needs to again. It also parallelizes
operations to maximize resource utilization so install times are
faster than ever.
Yarn doesn't support login with a password (while NPM does)
When you install a package using Yarn (using yarn add packagename), it places the package on your disk. During the next install, this package will be used instead of sending an HTTP request to get the tarball from the registry.
Yarn comes with a handy license checker, which can become really powerful in case you have to check the licenses of all the modules you depend on.
If you are working on proprietary software, it does not really matter which one you use. With npm, you can use npm-shrinkwrap.js, while you can use yarn.lock with Yarn.
For more information please read the following blog
https://blog.risingstack.com/yarn-vs-npm-node-js-package-managers/
Yarn
Advantages::
Supports features like parallel installation and
Zero-Install results in better performance
More secure
Large active user community
Disadvantages::
Doesn’t work with older versions of Node.js (lower than version 5)
Problems with installing native modules
NPM
Advantages::
Ease of use, especially for developers working with older
versions.
Optimized local package installation to save hard drive space.
Disadvantages::
Security vulnerabilities are still there
Conclusion:
Is Yarn better than NPM?
In terms of speed and performance Yarn is better than NPM because it performs the parallel installation. Yarn is still more secure than NPM. However, Yarn uses more disk space than NPM.
My Node version : v0.12.2
My npm version: 2.7.4
I ran the following command: npm install gulp -g
Should I care ? I get these warnings:
C:\Users\Maddy\Desktop\PublicServer\skill_tests>npm install gulp -g
npm WARN deprecated graceful-fs#3.0.8: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs#^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated minimatch#2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch#0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated lodash#1.0.2: lodash#<3.0.0 is no longer maintained. Upgrade to lodash#^4.0.0.
npm WARN deprecated graceful-fs#1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs#^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
Those error warnings are not a major issue. I get the same warnings when I install gulp. I have been using it for a while. It has to do with the libraries that support gulp. Gulp has dependencies and those dependencies are "packaged" together to create gulp. For example lodash is a javascript library that has a lot of array utilities. But lodash is maintained by the person who developed it
If you look in the node_modules folder you can see all the dependencies that make up gulp. I just pointed out lodash because you can find the link here and review it yourself. Gulp is not one javascript library it's a compilation of several projects that make up one tool.
Since npm has no kind of a rating system -- or anything remotely similar, there are a lot of "old" packages out there that refer to other "old" packages.
And, for the most part, that is fine.
For the most part being the key phrase.
Once in a rare while there may be a breaking change to node which causes one of these old packages to fail and you can get a cascading error upwards. However, it doesn't seem to happen too often -- I've only run into it once.
The bottom line is: Unless you are able to maintain the packages, there isn't really anything you can do about it.
All of these are warnings, which means you should be fine. If you encounter an error run:
npm list
which will give you a list of dependencies and packages. Generally speaking, these have to be updated by the author. So you if it's mission critical give them a ping on their repos or find alternatives that are maintained.