Some useful npm commands
npm is a package manager for the JavaScript programming language. It is the default package manager for Node.js. Recently I completed a learning path Build JavaScript applications with Node.js and found some basic and useful npm commands which were very helpful to me, so I thought of sharing.
Here are some useful npm commands.
To create a package.json in interactive mode, you can use the npm init command.
npm init
To create a package.json in non interactive mode, use the npm init -y command.
npm init -y
To get full detailed list of all the commands, type npm –help.
npm —help
To install any package, you can use npm install command followed by package name.
npm install <package name>
To install a package for development only which wont be shipped with production build, try the npm install with save-dev parameter. It also adds an entry in devDependencies in package.json.
npm install <package name> —save-dev
To install a package for production, try with production parameter. It adds an entry in dependencies in package.json.
npm install <package name> —production
To install a package in global directory instead of project’s node_modules directory, use the g parameter.
npm install <package name> -g
To take care of fetching the dependency and carrying out the command, and clean up so it is not saved (or do not take up space) in node_modules folder, try the following command.
npx <name of package>
To list all the packages that your project is depending on, try the npm list command. It uses dependencies section from package.json. Use depth=0 for first level dependencies and depth=1 for 2nd level dependencies and so on.
npm list —depth=<depth>
To uninstall a package you use the uninstall command. It will remove the package from the manifest file and also from the node_modules directory.
npm uninstall <name of dependency>
To remove all dependencies in the node_modules directory that are not listed as dependencies in the manifest file, you can try the prune command.
npm prune
To list all the outdated packages, use the outdated command
npm outdated
To list vulnerabilities by different severity levels, high, and low for all the packages used in your project, use audit command
npm audit
To fix the vulnerabilities found by audit, try the audit command with fix.
npm audit fix
To fix the vulnerabilities found by audit forcefully, try the force parameter.
npm audit fix —force
To install the latest version, use @latest with npm install command.
npm install node-fetch@latest lodash@latest
The following instruction will update to the latest patch version. If you only want the patch version to update, you would specify like this
1.0.0. What this instruction says is equal or great to in the same range.
The following instruction will update only the minor version.
^1.1.1 or 1.x.1
The following instruction will update to the highest major version.
*1.1.1 or x.0.0
The package-lock.json guarantees exact installs.
The following command starts debugger that comes bundled with Node.js.
node inspect myscript.js
Wrap up
These were some basic and useful nom commands that can get you started with npm.
Unlocking security updates for transitive dependencies with npm
How Dependabot integrated with npm to address security vulnerabilities on transitive dependencies and increase the likelihood of success for JavaScript security updates by 40%.
Dependabot helps developers secure their software with automated security updates: when a security advisory is published that affects a project dependency, Dependabot will try to submit a pull request that updates the vulnerable dependency to a safe version if one is available. Of course, there’s no rule that says a security vulnerability will only affect direct dependencies—dependencies at any level of a project’s dependency graph could become vulnerable.
Until recently, Dependabot did not address vulnerabilities on transitive dependencies, that is, on the dependencies sitting one or more levels below a project’s direct dependencies. Developers would encounter an error message in the GitHub UI and they would have to manually update the chain of ancestor dependencies leading to the vulnerable dependency to bring it to a safe version.
Internally, this would show up as a failed background job due to an update-not-possible error—and we would see a lot of these errors.
Understanding the challenge
Dependabot offers two strategies for updating dependencies: scheduled version updates and security updates. With version updates, the explicit goal is to keep project dependencies updated to the latest available version, and Dependabot can be configured to widen or increase a version requirement so that it accommodates the latest version. With security updates, Dependabot tries to make the most conservative update that removes the vulnerability while respecting version requirements. In this post we’ll be looking at security updates.
As an example, let’s say we have a repository with security updates enabled that contains an npm project with a single dependency on react-scripts@^4.0.3 .
Not all package managers handle version requirements in the same way, so let’s quickly refresh. A version requirement like ^4.0.3 (a “caret range”) in npm permits updates to versions that don’t change the leftmost nonzero element in the MAJOR.MINOR.PATCH semver version number. The version requirement ^4.0.3 , then, can be understood as allowing versions greater than or equal to 4.0.3 and less than 5.0.0 .
On March 18, 2022, a high-severity security advisory was published for node-forge , a popular npm package that provides tools for writing cryptographic and network-heavy applications. The advisory impacts versions earlier than 1.3.0 , the patched version released the day before the advisory was published.
While we don’t have a direct dependency on node-forge , if we zoom in on our project’s dependency tree we can see that we do indirectly depend on a vulnerable version:
In order to resolve the vulnerability, we need to bring node-forge from 0.10.0 to 1.3.0 , but a sequence of conflicting ancestor dependencies prevents us from doing so:
- 4.0.3 is the latest version of react-scripts permitted by our project
- 3.11.1 is the only version of webpack-dev-server permitted by react-scripts@4.0.3
- 1.10.14 is the latest version of selfsigned permitted by webpack-dev-server@3.11.1
- 0.10.0 is the latest version of node-forge permitted by selfsigned@1.10.14
This is the point at which the security update would fail with an update-not-possible error. The challenge is in finding the version of selfsigned that permits node-forge@1.3.0 , the version of webpack-dev-server that permits that version of selfsigned , and so on up the chain of ancestor dependencies until we reach react-scripts .
How we chose npm
When we set out to reduce the rate of update-not-possible errors, the first thing we did was pull data from our data warehouse in order to identify the greatest opportunities for impact.
JavaScript is the most popular ecosystem that Dependabot supports, both by Dependabot enablement and by update volume. In fact, more than 80% of the security updates that Dependabot performs are for npm and Yarn projects. Given their popularity, improving security update outcomes for JavaScript projects promised the greatest potential for impact, so we focused our investigation there.
npm and Yarn both include an operation that audits a project’s dependencies for known security vulnerabilities, but currently only npm natively has the ability to additionally make the updates needed to resolve the vulnerabilities that it finds.
After a successful engineering spike to assess the feasibility of integrating with npm’s audit functionality, we set about productionizing the approach.
Tapping into npm audit
When you run the npm audit command, npm collects your project’s dependencies, makes a bulk request to the configured npm registry for all security advisories affecting them, and then prepares an audit report. The report lists each vulnerable dependency, the dependency that requires it, the advisories affecting it, and whether a fix is possible—in other words, almost everything Dependabot should need to resolve a vulnerable transitive dependency.
There were two ways in which we had to supplement npm audit to meet our requirements:
- The audit report doesn’t include the chain of dependencies linking a vulnerable transitive dependency, which a developer may not recognize, to a direct dependency, which a developer should recognize. The last step in a security update job is creating a pull request that removes the vulnerability and we wanted to include some context that lets developers know how changes relate to their project’s direct dependencies.
- Dependabot performs security updates for one vulnerable dependency at a time. (Updating one dependency at a time keeps diffs to a minimum and reduces the likelihood of introducing breaking changes.) npm audit and npm audit fix , however, operate on all project dependencies, which means Dependabot wouldn’t be able to tell which of the resulting updates were necessary for the dependency it’s concerned with.
Fortunately, there’s a JavaScript API for accessing the audit functionality underlying the npm audit and npm audit fix commands via Arborist, the component npm uses to manage dependency trees. Since Dependabot is a Ruby application, we wrote a helper script that uses the Arborist.audit() API and can be invoked in a subprocess from Ruby. The script takes as input a vulnerable dependency and a list of security advisories affecting it and returns as output the updates necessary to remove the vulnerabilities as reported by npm.
To meet our first requirement, the script uses the audit results from Arborist.audit() to perform a depth-first traversal of the project’s dependency tree, starting with direct dependencies. This top-down, recursive approach allows us to maintain the chain of dependencies linking the vulnerable dependency to its top-level ancestor(s) (which we’ll want to mention later when creating a pull request), and its worst-case time complexity is linear in the total number of dependencies.
To meet our second requirement of operating on one vulnerable dependency at a time, the script takes advantage of the fact that the Arborist constructor accepts a custom audit registry URL to be used when requesting bulk advisory data. We initialize a mock audit registry server using nock that returns only the list of advisories (in the expected format) for the dependency that was passed into the script and we tell the Arborist instance to use it.
We see both of these use cases—linking a vulnerable dependency to its top-level ancestor and conducting an audit for a single package or a particular set of vulnerabilities—as opportunities to extend Arborist and we’re working on integrating them upstream.
Back in the Ruby code, we parse and verify the audit results emitted by the helper script, accounting for scenarios such as a dependency being downgraded or removed in order to fix a vulnerability, and we incorporate the updates recommended by npm into the remainder of the security update job.
With a viable update path in hand, Dependabot is able to make the necessary updates to remove the vulnerability and submit a pull request that tells the developer about the transitive dependency and its top-level ancestor.
Caveats
When npm audit decides that a vulnerability can only be fixed by changing major versions, it requires use of the force option with npm audit fix . When the force option is used, npm will update to the latest version of a package, even if it means jumping several major versions. This breaks with Dependabot’s previous security update behavior. It also achieves our goal: to unlock conflicting dependencies in order to bring the vulnerable dependency to an unaffected version. Of course, you should still always review the changelog for breaking changes when jumping minor or major versions of a package.
Impact
We rolled out support for transitive security updates with npm in September 2022. Now, having a full quarter of data with the changes in place, we’re able to measure the impact: between Q1Y22 and Q4Y22 we saw a 42% reduction in update-not-possible errors for security updates on JavaScript projects. 🎉
If you have Dependabot security updates enabled on your npm projects, there’s nothing extra for you to do—you’re already benefiting from this improvement.
Looking ahead
I hope this post illustrates some of the considerations and trade-offs that are necessary when making improvements to an established system like Dependabot. We prefer to leverage the native functionality provided by package managers whenever possible, but as package managers come in all shapes and sizes, the approach may vary substantially from one ecosystem to the next.
We hope other package managers will introduce functionality similar to npm audit and npm audit fix that Dependabot can integrate with and we look forward to extending support for transitive security updates to those ecosystems as they do.
What is NPM audit?
This article is based on Node v16.15.1 and NPM 8.11.0.
NPM audit — build-in security. NPM (Node Package Manager) is the package manager for Node.js and allows JavaScript developers to share node modules. Read more about NPM in Intro to NPM.
�� The Pragmatic Programmer: journey to mastery. �� One of the best books in software development, sold over 200,000 times.
In version 6 npm introduced a new command that lets you run a security audit with npm audit and assess your package dependencies for security vulnerabilities.
Let’s explore how to use npm audit to evaluate the dependency tree recursively and safeguard the quality and integrity of our code.
What is NPM audit?
npm audit is a built-in security feature, that scans your project for security vulnerabilities. It provides an assessment report that contains details of the identified anomalies, potential fixes, and more.
It checks the current version of the installed packages in your project against known vulnerabilities reported on the public npm registry. If it discovers a security issue, it reports it. The report contains the level of severity of the identified vulnerability. The command will exit with a 0 exit code if no vulnerabilities were found.
The extent of severity is determined by the impact and exploitability of the issue. The level of severity and recommended actions are:
| Level of Severity | Recommended Actions |
|---|---|
| Critical | resolve straightaway |
| High | resolve as fast as possible |
| Moderate | resolve as time allows |
| Low | resolve at your discretion |
Benefits of npm audit
npm audit offers the following advantages:
- Big community of open source contributors, who endeavor to find and address vulnerabilities in npm packages.
- Identifies the security issues clearly and labels them in terms of the level of severity.
- If a fix has been published, it provides an out-of-the-box option for resolving the discovered anomalies.
How to run npm audit
Ensure you have npm v6 or higher installed, by typing in your shell:
If you have to upgrade run the following command to update to the latest version:
Whenever you install a package via npm, npm install , the npm audit command will automatically in the background and output the security report after successful installing the dependencies.
If you want to run it manually, just go to the src folder of your project and use the command:
The npm audit command requires a package-lock.json and, a package.json to be present.
The audit report will be printed in the console. If you want the report in JSON format, run:
You can also specify the audit result to contain a certain level of severity, for example only critical results
The full synopsis of npm audit is:
Take security serious and always check the report and take action as indicated.
How to fix security vulnerabilities
If vulnerabilities were found, you have two options:
- Apply the suggested fix automatically
- Take manual actions to fix them
1) Apply the suggested fix automatically. If you want npm to automatically fix the vulnerabilities, run npm audit fix . Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. There will be additional output in the console.
Configs: npm audit fix runs a full-fledged npm install under the hood, all configs that apply to the installer will also apply to npm install. Commands like npm audit fix —package-lock-only will work as expected.
If the update requires moving to a major version, then you’ll need to add the force flag:
2) Take manual actions: If there are no patches for the identified issues, the security audit report will give you more details on how to carry out manual investigations to address them.
You can take any of the following actions to resolve the vulnerabilities:
- Look for mitigating factors: In some limited cases, you may continue consuming the package even when the weakness is still existing. For instance, the security risk may only be present on certain operating systems.
- Update dependent packages: If a fix has been released, but the packages that depend on the vulnerable package have not been amended to reference the patched version, it may be necessary to undertake some manual interventions. You can start by locating the package, that should be updated by looking at the Path field on the security audit report. This will let you locate the vulnerable package, update the reference to the vulnerable package and, this may solve the security issue.
- Fix the vulnerability yourself: If a patch has not been released and nobody is working on it, fix it yourself and submit a pull request.
npm audit is a very useful feature that can enhance the security of your code, you can identify vulnerabilities and get actionable instructions on how to get rid of the risks.
Thanks for reading and if you have any questions, use the comment function or send me a message @mariokandut.
If you want to know more about Node, have a look at these Node Tutorials.
NPM Audit Fix Fixing NPM Dependencies Vulnerabilities
Meaning that this example would have another 61 vulnerabilities ranging from low to high with of course high being the most dangerous vulnerability. For more info on any of these vulnerabilities, there is also a link to the vulnerability on NPM inside the More Info section of the warning.
At first, it may seem confusing on how to properly fix these vulnerabilities. NPM actually provides a service built into NPM that is supposed to automatically fix these issues, npm audit fix , but I’ve found that this will rarely work, and will leave you with nearly just as many vulnerabilities as before. In fact, here’s an example of what happened after I ran npm audit fix .
NPM gives us the option to use the —force flag, npm audit fix —force , but even NPM will warn you about using this flag
So what are we supposed to do? If our package manager isn’t able to fix these vulnerabilities then surely we’re out of luck and must find a way to survive with these vulnerabilities hoping nobody decides to exploit them against our project.
The Fix
Manually upgrade the packages one at a time with the command suggested by NPM instead of running the npm audit fix —force command. For example npm install —save-dev jest@24.8.0 .
First of all, I want to say that this might be incredibly obvious to those that have run into this problem before. When I first saw these, it was a gigantic list of warnings and being the lazy developer that I am, I didn’t even bother to scroll through the issues.
If you just continue to scroll up inside your console to the very first issue you’ll actually run into a fix and yes, as you would expect, it’s as simple as updating the package that’s causing the issue.
Right before the vulnerability issue you’ll notice the text # Run npm install —save-dev jest@24.8.0 to resolve 62 vulnerabilities which is exactly what we’re looking for. You may also notice that the very next line says SEMVER WARNING: Recommended action is a potentially breaking change . Manually running this command instead of using the npm audit fix —force command lets us know exactly which packages we’re updating. This is valuable for the scenario where updating these packages actually causes a breaking change.
Summary
So in the end, manually upgrading the vulnerable packages and running npm audit fix —force is going to have the same results. The only difference is that manually upgrading our packages will allow us to upgrade a single package, test for a breaking change, then update the next package, instead of just upgrading all of the packages at once, find a breaking change, then having no idea which package decided to screw things up.