The npm Blog
Month
npm offers a way for security researchers, package users, package maintainers, and community members to report security vulnerabilities via the “Report a Vulnerability” button on npm Package pages. This provides the community a way to participate in coordinated disclosure with the package maintainer instead of opening a public issue, which could put users at risk.
These reports go directly to the npm Security team for triage instead of to the package maintainers. This is our way of helping the community spend less time on low-quality security reports.
In order for us to make sure reported vulnerabilities are handled rapidly and effectively, we need you, our community, to provide us with actionable, detailed information. Here’s some basic do’s and don’ts for your security report:
Also note: Vulnerabilities in the npm Registry, website, or other core services and tooling should be reported to [email protected].
I would like to report a command injection vulnerability in the “foobarbaz” package, version 1.0.0.
Follow the below steps to reproduce this vulnerability.
Environment:
Node.js v10.9.0 on Linux
1. npm i [email protected]
2. Create the following proof-of-concept:
The code below illustrates the issue. Executing this code in a directory that contains the file existingfile.zip (a valid zip file that exists on disk, does not necessarily have to be attacker controlled) will also execute the supplied touch xyz command creating a file, but this could be any command the user executing the code has permission to run.
‘‘‘
var foo = require('foobarbaz');
var unzip = foo.unzip;
// Gather user input from some source. In this case we simulate it with a string
var userinput = './existingfile.zip; touch xyz"';
// This line calls the vulnerable method with our user input.
unzip(userinput, './unzipped', function(){});
‘‘‘
We’re grateful for our community’s continual efforts to identify and report vulnerabilities and we look forward to your future submissions. We will continue to improve our tools and resources so that npm remains the source of trusted JavaScript.
Q. Hi! Can you state your name, what you do, and/or what your company does?
Hi there! My name is Adam Reis, and I am the co-founder and CTO of Hello Club.
We’ve created Hello Club to help reduce the workload and time spent on admin tasks for the volunteers and committee members who often run clubs.
It has been designed to be easy to use and fun to work with, and allows clubs to keep track of members, bookings, events, and finances effortlessly. It integrates with popular tools like Mailchimp and Xero and also has an integrated access control system for clubs that need it.
Best of all, it’s free for small clubs, so if you know anyone involved in a (sport) club, feel free to point them in our direction!
How’s your day going?
It’s been great so far, thanks! Super busy, but that’s a good thing :).
Tell me the story of npm at your company. What specific problem did you have that npm solved?
We needed a good way to package and distribute reusable components for our Javascript modules, and were looking for a tool that could help orchestrate our build processes, test scripts, and database migration scripts.
npm offered all of that along with a great eco system of already-existing packages that we use for both our front-end, back-end, and IoT devices.
To people who are unsure what they could use npm for — how would you explain the use case?
I would say that npm allows you to bundle and distribute your code, so that you can reuse it in multiple different projects. What’s great is that you can use it for both public (open source) code, as well as proprietary code and modules.
It also allows you to lock in specific versions of modules you want to use — you don’t have to worry about breaking your application when packages are updated or that all your developers are using the exact same version.
In addition, npm can help you organize your scripts and build tools and commands, making it easy to manage the build, test, and maintenance processes of your software or application.
How’s the day to day experience of using npm?
It’s been great! We’ve use it just about every single day for the past 4–5 years, and find that in general it’s been stable and effective, with minimal downtime of the service.
Would you recommend that another org or company use npm and why?
I definitely would. I think npm is the best package manager out there at the moment and would highly recommend it to anyone developing anything with JavaScript.
Any cool npm stuff your company has done publicly that you’d like to promote?
To support the basic functionality we needed for our application, we’ve developed an ecosystem of packages called Meanie that work together to provide a framework for anyone developing with the MEAN stack (MongoDB, Express, Angular, Node).
Most of these modules are available as open source under the @meanie namespace and are updated regularly, so feel free to check them out and use them in your own projects.
Today the Node.js and JS Foundations announced an intent to merge.
tl;dr – This is a good thing. I’m psyched.
The JavaScript community is a big and diverse group of people, doing lots of stuff. Most companies in the world use JavaScript, and at npm, we have a unique view into the shape and scope of this ecosystem.
The overwhelming majority of JavaScript users are people making websites, using modern frameworks, and tooling built in Node.js. They are trying to get a job done, and they want streamlined tools that make them more able to do their jobs. Many of them are not what we might have thought of as “Node Devs” a few years ago (though many are). Their websites run on every back-end platform, including but not limited to Node.js, and they all have to ship a website to browsers, which means JavaScript. Node.js is the dominant platform for building the tools for doing this, and npm is the place where platforms, modules, and tooling are distributed and shared.
A split between “back-end” and “front-end” JavaScript makes less and less sense in light of the way that this community has grown over the last 9 years since Node.js was released. (Wow, has it really been that long? Time flies.) A fast-growing community means that most of the people writing websites, using Node.js-powered tooling and pulling libraries and frameworks from npm, have only been doing it for less than 2 years. The split may have felt normal to those of us involved in 2009, but it seems unnatural and awkward to most working in the field today. It’s just JavaScript. It runs on servers, and on the command line, and in browsers, and you use npm and a bunch of other tools it provides. Is “babel” a front-end tool or a back-end tool? Why are there two groups, when it’s mostly the same people?
Node.js getting more integrated with the broader JS community means that the project can more effectively advocate for server-side use cases, and can get better feedback from those who are depending on Node.js to power the tools they use to ship websites.
As one of the companies at the center of JavaScript development, we at npm are thrilled to see the two major JavaScript foundations joining forces to provide a forum for the entire Open Source JavaScript community. Consistency of governance, processes, and policies can make it easier for devs in disparate JavaScript projects to collaborate and coordinate, removing an unnecessary barrier to innovation. Both foundations now have an established history of iterating on their processes. I hope that this new shift provides a chance to retrospect on what worked, what didn’t work, and what can be improved by working together.
On a personal note, I got involved with Node.js in the first place because I wanted to live in a world where front-end, back-end, tooling, and infrastructure coding did not require constantly shifting my brain around to a whole new language. I couldn’t have predicted how npm would become so relevant to the world of web development, and it’s more than I would have thought to hope for. There’s a lot of open questions about what exactly a merged foundation will look like, but I’m very happy to see things move in this direction.
Q1. Hi! Can you state your name, what you do, and/or what your company does?
I’m Amer Wilson, CRM Consultant at Rolustech, a certified SugarCRM and Salesforce Partner firm. We do CRM customization, implementation, and integrations and have been in the CRM industry for 10 years.
Q2. How’s your day going?
Great!
Q3.Tell me the story of npm at your company. What specific problem did you have that npm solved?
Our company builds software and does CRM customization for our clients. We have used npm in multiple projects. Some of the use cases are below where we used or will use npm:
1. We provide SugarCRM solutions for our Clients. There are many packages available for SugarCRM that we use in our different projects, all installed and managed with the help of npm. We don’t want to commit these dependencies and libraries in our version control system and want to share the same copy of these with everyone in our development team. We simply define these dependencies in the package.json file and other developers just run “npm install” to get all of these installed in their project.
2. We build custom CRM Portals in Ember.js. We install the dependencies in our Ember projects with npm. We use Ember.js command line utility named “ember-cli” and we use npm to install it. We use npm commands to test and build Ember projects.
3. We are developing a CRUD Application in MEAN stack. All the dependencies in Angular are installed by npm. Also, Express is installed in the node server by npm. The tests are performed by npm and the build is created by npm.
4. In one of our projects, we have to show real-time notifications to the CRM users. The solution involves the building of a WebSocket server and we are going to use Node.js and express.js for it. Again we will have to use npm to install all dependencies.
Q4. To people who are unsure what they could use npm for — how would you explain the use case?
npm will help Javascript developers to share their code with other developers or at other places and manage dependency conflicts intelligently.
For example, imagine there is a project in which you make use of different dependencies e.g bootstrap, jasmine, karma, tslint. There are different developers working on the project. You don’t want to commit all of those libraries and JavaScript files in your repository because these files are not going to be changed and everyone needs to have the same version of these files. These can be installed directly by npm. What you need to do is create a package.json file and define all these dependencies in that file and commit it in your repo. Now other developers working on the project will simply run “npm install” command and npm will take care of the rest. All the dependencies will be downloaded and installed in their project. This is a very convenient way to share the code between different people.
Moreover, developers can create and publish their own Node modules of reusable code so that other developers can use it by installing them with the help of npm.
Q5. How’s the day to day experience of using npm?
We keep on using it in different projects as described above. Any new dependency needs to be added to project, we just add it in package.json file and rest npm takes care of.
Q6. Would you recommend that another org or company use npm and why?
We absolutely recommend it for getting the multiple benefits described above.
Q7. Any cool npm stuff your company has done publicly that you’d like to promote?
Not really.
This post was written by Benjamin Coe, Product Manager at npm, Inc. and lead maintainer of yargs and Istanbul for the Node.js Collection. It covers work that has gone into introducing native code coverage support to Node.js.
TLDR: You can now expose coverage output through Node.js by setting the environment variable NODE_V8_COVERAGE to the directory you would like coverage data output in. The tool c8 can be used to output pretty reports based on this coverage information.
A Bit of History: How Test Coverage Has Historically Worked
In JavaScript code, coverage has traditionally been facilitated by a clever hack: tools like Istanbul and Blanket parse JavaScript code inserting counters that (ideally) don’t change the original behavior of the application, for instance:
function foo (a) {
if (a) {
// do something with 'a'.
} else {
// do something else.
}
}gets rewritten as:
function foo(a) {
cov_2mofekog2n.f[0]++;
cov_2mofekog2n.s[0]++;
if (a) {
// do something with 'a'.
cov_2mofekog2n.b[0][0]++;
} else {
// do something else.
cov_2mofekog2n.b[0][1]++;
}
}cov_2mofekog2n.f[0]++ indicates that the function foo was executed, cov_2mofekog2n.s[0]++ indicates that a statement within this function was called, and cov_2mofekog2n.b[0][0]++ and cov_2mofekog2n.b[0][1]++indicate that branches were executed. Based on these counts, reports can be generated.
This transpilation approach works, but has shortcomings:
I found myself wishing there was a better way to collect code coverage…
Code Coverage in V8
I was chatting with Bradley Farias in August of 2017 about ESM module support in Node.js as ESM modules presented a problem for Istanbul. The problem? Bradley’s rewrite of Node.js’ loader to support ESM modules no longer supported hooking require statements, this made it difficult for Istanbul to detect that an ESM module had been loaded and instrument it. I made a strong case for adding this functionality back, Bradley had another suggestion:
What if we leverage V8’s new built in coverage functionality?
Using coverage built directly into the V8 engine could address many of the shortcomings facing the transpilation-based approach to code coverage. The benefits being:
I proceeded to investigate using Node.js’ inspector module for collecting coverage directly from V8; there were some hiccups:
if statements, while statements, switch statements).|| expressions, &&expressions.These challenges aside, using V8’s coverage via the inspector felt promising. I was left wanting to help see things over the finish line.
Moving Towards a Proof of Concept
I reached out to Jakob Gruber on the V8 team regarding the bugs I was seeing integrating V8 coverage with Node.js. The folks at Google were also excited to see coverage support in Node.js and pitched in to start addressing bugs almost immediately.
After a discussion with several V8 maintainers, we determined that there was in fact a mechanism for enabling block level coverage:
--inspect-brk flag, such that the inspector terminated execution immediately.Runtime.runIfWaitingForDebugger needed to be run to kick off program execution.Runtime.executionContextDestroyed needed to be listened for, at which point coverage could be output.I tested the approach outlined above and it worked!
I next asked Jakob if I could pitch in and start implementing some of the missing coverage functionality in V8. With the patient help of several folks on the V8 team, I was able to implement support for || and && expressions. This was my first time writing C++ in years and was a ton of fun for me.
At this point we had detailed V8 coverage information being output, but no easy way to output human readable reports. Two npm modules were written to facilitate this:
c8 node foo.js.Leveraging these new libraries, we were finally able to see coverage reports!
This was a exciting milestone, but I still wasn’t satisfied. Here’s why:
process.exit(0) was called, there was no way to dump a coverage report.Node-Core Implementation
I had an epiphany, what if Node.js could be placed into a mode that always dumped coverage?
process.exit(0) and process.killevents.In conversation with Anna Henningsen, it turned out that the Node.js inspector implementation lent itself to my idea:
Excited, I sat down and implemented V8 test coverage as a feature of Node.js itself. Here’s what it looks like:
>=10.10.0 you can now set the environment variable NODE_V8_COVERAGE to a directory, this will result in V8 coverage reports being output in this location.NODE_V8_COVERAGE environment variable, consumes the V8 coverage data, and outputs pretty reports.Next Steps
You can start using the Node.js built in coverage reporting today:
10.10.0.c8 node foo.js.This feature is brand new, and I’d love for JavaScript communities to help see things over the finish line.
You can help by:
What if installs were so fast they could happen in the background, just by using Node? What if every file in your dependencies could be guaranteed to be bit-by-bit identical to what’s on the registry? What if working on a new project was as simple as clone and run? What if your build tools got out of your way?
Introducing tink, a proof of concept implementation of an install-less installer.
tink acts as a replacement for Node.js itself, working from your existing package-lock.json. Try it out on a project without a node_modules and you’ll find that you can still require any of your dependencies even though you never ran an install. The first run will take a few seconds while it downloads and extracts the package tarballs, but subsequent runs are nearly instantaneous even though it’s still verifying that everything in your package-lock.json is on your system.
The first thing you’ll notice is that none of those modules are put into your node_modules folder — in fact, the only thing you’ll find there is a .package-map.json file. This contains hashes of all of the files in every package you have installed. These are verified before they’re loaded, so you can have confidence that you’re getting what you asked for (if a verification fails then the file is fetched from its original source, all transparently).
We’re not throwing the baby out with the bathwater though. You can still install things in your node_modules folder and those versions will be used in preference to the cached version. This opens a path to live-editing of dependencies (sometimes a necessary debugging technique) and support for things like postinstall scripts that mutate the package distribution.
tink is an opportunity to change how we relate to our Node.js projects and the npm Registry. Should using require or import on a module not in your package.json just add it to your package.json? Should extremely popular features like babel-compatible esm, typescript, or jsx be available by default? These are the questions we’ve been asking ourselves and we’d love to hear what you would want from a next generation experience. Come by npm.community and let us know!
A new version of the npm CLI has been released!
Check out the changelog on npm.community
Q. Hi! Can you state your name, what you do, and/or what your company does?
A. My name is Joe Hanley, and I am a full-stack software engineer at Capital One. We’re a bank, a credit card company, and a financial services provider, but we like to think of ourselves as a data and technology company at heart. I work in our San Francisco office on an internal tool that we use to track our interactions with other companies.
How’s your day going?
My day is going great so far! I just got into the office an hour ago and started working on a bug we discovered yesterday. I’m pretty excited to finish that up and get the fix into production, since afterwards I’ll get to work on some super cool pilot work for Amazon Neptune.
Tell me the story of npm at your company. What specific problem did you have that npm solved?
npm is in use all over Capital One! A quick search of our private Github shows over 9000 package.json files at the root level of a repo. My current team uses npm as our package manager for every component our project — our Angular front end, our orchestration layer, our Node.js backend, our NativeScript mobile app, and all of our Lambda microservices. We love npm for a few reasons.
First, using package-lock lets us ensure that all of our team members are working off the same version of each package, so we don’t run into unexpected compatibility issues.
Second, since we use npm on all of our projects, it is super easy for new team members to get each of components running locally. Once they’ve gotten one component set up and working, the rest are simple to run. Third (and maybe most importantly), npm works well with our enterprise environment. It works with our corporate proxy and we can easily switch it between our private registry and the public one as needed.
To people who are unsure what they could use npm for — how would you explain the use case?
npm is great for any JavaScript based project where you want to use external packages in your code. We use it for all sorts of front end web projects, Node.js APIs, and cross-compiling mobile apps. It also great if you want to let other developers use your code in their own projects.
How’s the day to day experience of using npm?
My day to day experience with npm is very positive. I very rarely have issues with it, even when switching versions using nvm. One part of the experience that I really like is how easy it is to find new packages. Often, I’ll start Googling for a solution to a problem that’s facing me, and the first result will be a npm registry page for a package that does exactly what I need!
Would you recommend that another org or company use npm and why?
Absolutely. npm does exactly what you need a package manager to, and it does it without much friction. Additionally, it is widely known among web developers, so many new hires will already be super comfortable with it. Finally, it is flexible enough to accommodate most security requirements — as a bank, Capital One has super stringent security needs, and we are able to fit npm into our ecosystem easily.
Any cool npm stuff your company has done publicly that you’d like to promote?
Capital One has started open sourcing a bunch of the tools that we’ve developed while running a modern, technology focused banking and credit card company, and a ton of them are built using npm. Check them out here.
A new npm cli version has been released!
Check out the changelog on npm.community
As you’ve probably noticed, npm has been on a roll delivering security features. We have three new features on the website that we’d like to share: the report a vulnerability button, security advisories, and a feature that prevents the use of compromised passwords.
Report a vulnerability
The rapidly growing number of packages in the npm Registry requires us to have a vigilant community who can report anything suspicious. If you feel like you’ve found a security flaw or a malicious module in the Registry, it’s easy to let us know:
On each package page there is now a “Report a Vulnerability” button. Press it and fill out the required information and we’ll decide whether to take action.
Please note: there is no need to send us the output of npm audit as we already know about those vulnerabilities. Take a look at the About security audits documentation to learn about the output of npm audit.
Improved Security Advisories
Security advisories are what power npm audit. They give you a brief overview of the vulnerabilities in a package, how we recommend you respond, and some handy reference links to find out more.
Transitioning the Node Security Platform required us to move the security advisories to npmjs.com so we took that opportunity to improve their look and feel. We also added a detailed timeline for future advisories so you can learn what changed and when during an advisory’s lifecycle.
You can find a sorted list of advisories on the advisories page.
Blocking password reuse of compromised credentials
It’s fairly common for users to reuse passwords between accounts, but it’s an extremely risky practice that should be avoided. If a shared password is used on another account that is caught in a data breach, attackers can use this public data to guess their way into the user’s npm account and other accounts.
When you sign up for npm or change your password, your chosen password’s hash will be compared against an enormous list of 571 million password hashes graciously provided by Troy Hunt and the Have I Been Pwned project.
If a match is found, you will be presented with an error and will not be allowed to use the password.
Don’t worry! We aren’t sending your password to a third party service. We keep it local to our infrastructure and we don’t transfer or store it in clear text.
Other ways you can protect your account
A great companion to a strong password is 2-Factor Authentication. If you haven’t yet enabled it for your account, we encourage you to take a few seconds to do this. Once enabled, make sure to keep track of your recovery codes in a safe place like a password manager.
We hope you enjoy the new security features we’re continuing to release. If you have any feedback join the discussion at npm.community.
A new version of npm has been released!
Read more about it on npm.community!
6e9f04b0b npm/cli#8 Search for authentication token defined by environment variables by preventing the translation layer from env variable to npm option from breaking :_authToken. (@mkhl)84bfd23e7 npm/cli#35 Stop filtering out non-IPv4 addresses from local-addrs, making npm actually use IPv6 addresses when it must. (@valentin2105)792c8c709 npm/cli#31 configurable audit level for non-zero exit npm audit currently exits with exit code 1 if any vulnerabilities are found of any level. Add a flag of --audit-level to npm audit to allow it to pass if only vulnerabilities below a certain level are found. Example: npm audit --audit-level=high will exit with 0 if only low or moderate level vulns are detected. (@lennym)d81146181 npm/cli#32 Don’t check for updates to npm when we are updating npm itself. (@olore)A very special dependency update event! Since the release of [email protected], an awkward version conflict that was preventing request from begin flattened was resolved. This means two things:
npm audit now shows no vulnerabilities for npm itself!Thanks, @rvagg!
866d776c2 [email protected] (@simov)f861c2b57 [email protected] (@rvagg)32e6947c6 npm/cli#39 [email protected]: REVERT REVERT, newer versions of this library are broken and print ansi codes even when disabled. (@iarna)beb96b92c [email protected] (@zkat)348fc91ad [email protected]: Fixes errors with empty or string-only license fields. (@Gudahtt)e57d34575 [email protected] (@shesek)46f1c6ad4 [email protected] (@isaacs)50df1bf69 [email protected] (@iarna)
(@Erveon) (@huochunpeng)af98e76ed npm/cli#34 Remove npm publish from list of commands not affected by --dry-run. (@joebowbeer)e2b0f0921 npm/cli#36 Tweak formatting in repository field examples. (@noahbenham)e2346e770 npm/cli#14 Used process.env examples to make accessing certain npm run-scripts environment variables more clear. (@mwarger)This is basically the same as the prerelease, but two dependencies have been bumped due to bugs that had been around for a while.
Following the eslint incident on July 12, 2018, the community reached out to us with a few follow-up questions. This post will answer those questions as well as provide some additional technical insight into the eslint-scope malware that we haven’t seen discussed elsewhere:
Both npm and RunKit performed a search for code similar to what was used during the eslint incident. Their analysis is posted here.
We have not found any other malicious packages with an identical payload to that of the eslint-scope malware, but we found variants. We identified 2 other packages (one on 7/13 and one on 7/16) that attempted to replicate the behavior of the eslint-scope payload. The npm security team unpublished them immediately upon discovery. Because these packages were not tied to a popular package, they received no downloads beyond downstream mirrors.
The two packages mentioned above were discovered by our internal tooling which looks for malicious packages and suspicious behavior. We will continue to improve upon these tools as well as our response processes to reduce the time that malicious code lives in the npm Registry.
Where it makes sense, we’ll work to extend these tools to our users to empower them to make better decisions around what packages they should use and provide context around how they were published.
Package maintainers have a lot of responsibility to the community they serve. A package maintainer should:
Additionally, maintainers should pay attention to the emails that we send out when publications happen and contact support should something seem out of place.
For users that are concerned about install scripts, you can block install scripts from running with the --ignore-scripts flag.
Example: npm install --ignore-scripts
If you wish to never run scripts at install time, you can instead run the following command. However, be aware that some modules require install scripts to install properly:
npm config set ignore-scripts true
One thing to note is that if we took away install scripts, which is a popular suggestion after these types of incidents, attackers would move their payloads inside the package code, which you would likely execute as soon as you were done installing.
During our technical analysis of the eslint-scope payload we found a critical assumption in the attacker’s code that limited its effectiveness against some users.
At first glance, the attacker’s payload was designed to grab tokens from the end of the line that looked like //registry.npmjs.org/:_authToken= in the users .npmrc file, put them in a referrer header, and send them off to a remote server.
Here is the relevant snippet from the attacker’s payload:
content = fs.readFileSync(npmrc, { encoding: "utf8" });
content = content.replace("//registry.npmjs.org/:_authToken=", "").trim();
The assumption here is that the .npmrc file contains only 1 line. If any other configurations were present in this file then the referrer header would contain new line characters (which are invalid) and the request would fail, providing the attacker with no data.
Thank you to the community for sending in questions and for working with the npm Security team to keep the registry secure.
ad0dd226f npm/cli#26 npm version now supports a --preid option to specify the preid for prereleases. For example, npm version premajor --preid rc will tag a version like 2.0.0-rc.0. (@dwilches)c1dad1e99 npm/cli#6 Make npm audit fix message provide better instructions for vulnerabilities that require manual review. (@bradsk88)15c1130fe Fix missing colon next to tarball url in new npm view output. (@zkat)21cf0ab68 npm/cli#24 Use the defaut OTP explanation everywhere except when the context is “OTP-aware” (like when setting double-authentication). This improves the overall CLI messaging when prompting for an OTP code. (@jdeniau)a9ac8712d npm/cli#21 Use the extracted stringify-package package. (@dpogue)9db15408c npm/cli#27 wrappy was previously added to dependencies in order to flatten it, but we no longer do legacy-style for npm itself, so it has been removed from package.json. (@rickschubert)3242baf08 npm/cli#13 Update more dead links in README.md. (@u32i64)06580877b npm/cli#19 Update links in docs’ index.html to refer to new bug/PR URLs. (@watilde)ca03013c2 npm/cli#15 Fix some typos in file-specifiers docs. (@Mstrodl)4f39f79bc npm/cli#16 Fix some typos in file-specifiers and package-lock docs. (@watilde)35e51f79d npm/cli#18 Update build status badge url in README. (@watilde)a67db5607 npm/cli#17 Replace TROUBLESHOOTING.md with posts in npm.community. (@watilde)e115f9de6 npm/cli#7 Use https URLs in documentation when appropriate. Happy Not Secure Day! (@XhmikosR)In case you missed it, we moved!. We look forward to seeing future PRs landing in npm/cli in the future, and we’ll be chatting with you all in npm.community. Go check it out!
This final release of [email protected] includes a couple of features that weren’t quite ready on time but that we’d still like to include. Enjoy!
244b18380 #20554 add support for –parseable output (@luislobo)7984206e2 #12697 Add new sign-git-commit config to control whether the git commit itself gets signed, or just the tag (which is the default). (@tribou)4c32413a5 #19418 Do not use SET to fetch the env in git-bash or Cygwin. (@gucong3000)d9b2712a6 [email protected]: Downgraded to allow better deduplication. This does introduce a bunch of hoek-related audit reports, but they don’t affect npm itself so we consider it safe. We’ll upgrade request again once node-gyp unpins it. (@simov)2ac48f863 [email protected] (@MylesBorins)8dc6d7640 [email protected]: cli-table2 is unmaintained and required lodash. With this dependency bump, we’ve removed lodash from our tree, which cut back tarball size by another 300kb. (@Turbo87)90c759fee [email protected] (@zkat)4231a0a1e Add cli-table3 to bundleDeps. (@iarna)322d9c2f1 Make standard happy. (@iarna)I’m happy to announce that you can now beta-test two-factor authentication protection for individual packages in the npm Registry. This setting requires that every publication of a protected package be authorized by a one-time password. This requirement is enforced even if maintainers of that package haven’t required two-factor auth for publication themselves—they’ll still be prompted for a code for this package. If a maintainer hasn’t enabled two-factor auth at all, they’ll be unable to publish the package until they do.
You can test this feature using the npm canary client, npmc. We recommend you invoke the canary using npx: `npx npmc`. You can also install the canary build of npm directly by running npm install -g npmc@latest.
Toggle the settings with these commands:
npx npmc access 2fa-required <package>
npx npmc access 2fa-not-required <package>
Or cd to your package directory then run npmc access 2fa-required. If you have two-factor auth enabled for package publication already, you’ll be asked to provide a one-time password. You will be prompted for a one-time password for all changes to that package from then on. This includes maintainer changes.
Here’s an example of enabling it for a package, then attempting to publish without an OTP:
This setting isn’t visible in our web site yet, and support for toggling this setting isn’t in the default npm client yet. The default npm client behaves correctly when it encounters the setting, however, and will prompt for a one-time password when one is needed.
We will be encouraging maintainers of all popular packages to enable this to protect themselves and their users.
Early in the morning of July 12, an individual gained access to an npm publisher’s account and used this access to publish an unauthorized update of a popular package. The update included malicious code that would have attempted to access the accounts of additional npm users by obtaining these accounts’ access tokens.
We determined that access tokens for approximately 4,500 accounts could have been obtained before we acted to close this vulnerability. However, we have not found evidence that any tokens were actually obtained or used to access any npmjs.com account during this window.
As a precautionary measure, npm has revoked every access token that had been created prior to 2:30 pm UTC (7:30 am California time) today. This measure requires every registered npm user to re-authenticate to npmjs.com and generate new access tokens, but it ensures that there is no way for this morning’s vulnerability to persist or spread. We are additionally conducting a full forensic analysis to confirm that no other accounts were accessed or used to publish unauthorized code.
This morning’s incident did not happen because of an npmjs.com breach, but because of a breach elsewhere that exposed a publisher’s npm credentials. To mitigate this risk, we encourage every npmjs.com user to enable two-factor authentication, with which this morning’s incident would have been impossible.
We’re excited to announce that npm has joined ECMA International and is participating in TC39, the working group of ECMA International that defines the standard for the JavaScript programming language. (The standard is, strictly speaking, called ECMAScript, although everyone refers to it as JavaScript.)
Why are we joining TC39?
The members of TC39 have control over what JavaScript comes to be by discussing, debating, and reaching consensus on how the language should change.
npm directly touches nearly 11 million JavaScript users every day. As a part of TC39, we will use our knowledge of this community to advocate for improvements to the language spec that benefit all JS developers.
npm started in an obscure corner of the JavaScript universe, Node.js, which is why many people continue to expand npm to “Node Package Manager.”
Almost six years later, Node.js is no longer an obscure corner of the JavaScript universe, and npm is used by a whole lot of people who don’t think of themselves as Node developers, but JavaScript developers. The npm Registry now distributes more front-end code than server-side JavaScript and is used to distribute every popular web development framework.
When we look at the wider context in which npm is used, we believe that every JavaScript developer in the world would like to write even more JavaScript using npm. Participating in ECMA and TC39 lets us shape the language and work to reduce developer friction at a broader level.
How does this affect the JavaScript community?
JavaScript’s design has a huge effect on the future of software development. In the last two decades, people have learned programming by opening up the console in their web browsers and typing JavaScript into it. Over the last eight years, the browser has become a first class application development environment and application delivery tool. All kinds of sophisticated things are happening behind the scenes to show you streaming video, give you drag-and-droppable interfaces, and enable you to collaborate with teammates across the office and across the globe.
These innovations exist because JavaScript has improved significantly and browser implementers have gotten serious about implementing the TC39 standard. As a result, the web is in the middle of a renaissance.
Our mission is enabling JavaScript developers by removing friction. We can take that mission seriously by getting involved in the committee that structures the way JavaScript is written, working with the people who wrote the specification, and understanding their intentions. By joining TC39, we can do a better job of helping implement JavaScript and build better tooling to help developers build the coming decades’ amazing things.
I am pleased to announce that npm is transitioning its public issue trackers from GitHub to a Discourse site at npm.community. This will allow us to give the community a single place to report bugs that impact npm, regardless if they’re on the website, in the command line tool or in the registry itself.
You can sign up today. Go to https://npm.community and login with your GitHub account or create a npm.community account.
By changing from bug tracking software to forum software specifically designed for supporting software support we hope to better empower users to help other users, and to recognize their effort in doing so. This will also make it easier for teams within npm to work with the community to identify and resolve the issues that they’re encountering.
Discourse also gives is insight into what problems users are having the most often that GitHub issues do not. We will be producing regular reports on what we’re seeing and how that’s impacting our plans and priorities.
The existing repositories, including the one from the npm CLI will be archived. All existing issues will still be searchable, but further discussion will not be possible. If you want to discuss a previously existing issue, please copy it over to a new post on npm.community in the appropriate section.
npm/npm is being archived. Further issues, comments and PRs will no longer be possible.
npm/cli repo.npm/registry is being archived. Further issues will no longer be possible.
npm/www is being archived. Further issues will no longer be possible.
npm/docs is being made private and reorganized.
npm/docs holds all the documentation on https://docs.npmjs.com except the “Using npm”, “CLI commands” and “Configuring npm” sections. Those sections will live in npm/cli.You can join npm.community today! We plan to archive the repositories on the 12th or 13th of July, 2018. There will be another post here at that time.
Earlier this year, we announced npm, Inc.’s acquisition of ^Lift Security and the Node Security Platform and promised to provide updates as our teams combined to protect the world’s largest JavaScript developer community. Today, we have some news about how the acquisition affects you.
With vulnerability scanning that was built into your workflow, and by maintaining JavaScript’s definitive listing of known package vulnerabilities, the Node Security Platform has kept thousands of developers safe from insecure code.
Since joining npm, we’ve worked to bring these protections to the larger developer community.
npm now automatically reviews every install request against the NSP vulnerability database and warns you if you try to use unsafe code. Additionally, beginning with npm@6, a new command, npm audit, recursively analyzes your dependency trees to identify specifically what’s insecure, recommend a replacement, or fix it automatically with npm audit fix.
These tools are faster and more directly integrated into the way you write JavaScript. They also form the backbone of powerful new security tools we have in store for the months ahead. Given this, it’s time to phase out the original Node Security Platform.
The Node Security Platform service will stop working on September 28, 2018.
We encourage you to update to npm@6 — just type npm i -g npm@latest — to take advantage of powerful, automatic protection built right into your workflow, along with a host of other enhancements and features. If you have been a subscriber to NSP’s pre-publication advisories, your account will cancel automatically (these advisories are now available to customers of any of npm’s paid services).
We’re proud of the ways we work to keep you safe and excited for what’s still in store. As always, don’t hesitate to reach out with your feedback or questions.
ce0793358 #20750 You can now disable the update notifier entirely by using --no-update-notifier or setting it in your config with npm config set update-notifier false. (@travi)d2ad776f6 #20879 When npm run-script <script> fails due to a typo or missing script, npm will now do a “did you mean?…” for scripts that do exist. (@watilde)8f033d72d #20948 Fix the regular expression matching in xcode_emulation in node-gyp to also handle version numbers with multiple-digit major versions which would otherwise break under use of XCode 10. (@Trott)c8ba7573a Stop trying to hoist/dedupe bundles dependencies. (@iarna)cd698f068 #20762 Add synopsis to brief help for npm audit and suppress trailing newline. (@wyardley)6808ee3bd #20881 Exclude /.github directory from npm tarball. (@styfle)177cbb476 #21105 Add suggestion to use a temporary cache instead of npm cache clear --force. (@karanjthakkar)7ba3fca00 #20855 Direct people to npm.community instead of the GitHub issue tracker on error. (@zkat)88efbf6b0 #20859 Fix typo in registry docs. (@strugee)61bf827ae #20947 Fixed a small grammar error in the README. (@bitsol)f5230c90a #21018 Small typo fix in CONTRIBUTING.md. (@reggi)833efe4b2 #20986 Document current structure/expectations around package tarballs. (@Maximaximum)9fc0dc4f5 #21019 Clarify behavior of npm link ../path shorthand. (@davidgilbertson)3924c72d0 #21064 Add missing “if” (@roblourens)We did some reshuffling and moving around of npm’s own dependencies. This significantly reduces the total bundle size of the npm pack, from 8MB to 4.8MB for the distributed tarball! We also moved around what we actually commit to the repo as far as devDeps go.
0483f5c5d Flatten and dedupe our dependencies! (@iarna)ef9fa1ceb Remove unused direct dependency ansi-regex. (@iarna)0d14b0bc5 Reshuffle ansi-regex for better deduping. (@iarna)68a101859 Reshuffle strip-ansi for better deduping. (@iarna)0d5251f97 Reshuffle is-fullwidth-code-point for better deduping. (@iarna)2d0886632 Add fake-registry, npm-registry-mock replacement. (@iarna)8cff8eea7 [email protected] (@zkat)bfc4f873b [email protected] (@zkat)532096163 [email protected] (@zkat)4a512771b [email protected] (@iarna)b7cc48dee [email protected] (@iarna)bae657c28 [email protected] (@iarna)3d46e5c4e [email protected] (@iarna)d0a905daf [email protected] (@iarna)4fc1f815f [email protected] (@iarna)f72202944 [email protected] (@iarna)bdce96eb3 [email protected] (@iarna)fe4240e85 [email protected] (@zkat)We’re continuing our analysis of the results of last winter’s JavaScript Ecosystem Survey, a survey of over 16,000 developers conducted by npm in collaboration with the Node.JS Foundation and the JS Foundation. Our second topic is How JavaScript is used across industries — and, more specifically, how different industries use certain JavaScript tools, frameworks, and practices. To read more about the methodology behind this survey, click here.
We asked about what industry our respondents worked in. 45% of users answered “tech”, revealing an underlying ambiguity in our question. For instance, if you work at Google, do you work at a tech company or an advertising company? What about at Microsoft, which many consider a tech company, but also has advertising and even hardware manufacturing arms? Next time, we’ll ask for more detailed information about industry concentrations.
“We asked about what industry our respondents worked in. The most common answer was “tech” at 45%”
Despite this, we still gathered some good data about how use of JavaScript varies by industry. The top industries were:
There were meaningful differences across industries in how and why people use JavaScript. There were also some clear commonalities, not all of which we’re going to mention. But from a statistician’s point of view, the questions where all the industries answered very similarly are useful because it indicates the differences in other questions are “real” and not just random variation.
With 16,000 responses, even the single-digit groups per industry constituted enough data to make meaningful conclusions. We discarded answers from industries with less than 2% responses (i.e. less than 300 individual responses).
First, we asked about common tools: bundlers, linters, testing frameworks, transpilers, CSS preprocessors, and more.
Manufacturing across the board uses less of everything — only 51% of manufacturing respondents say they use a testing framework, compared to 75% in finance.
The explanation for this may lie in the answer to another question; “Where does the JavaScript you write run?” 15% of manufacturing developers say their code runs on embedded devices which is twice as much as any other industry. Embedded platforms often have intrinsic transpilers for JS, so you do not need to use your own and have no need for browser-specific optimizations that most of these tools provide.
“Manufacturing across the board uses less of everything — only 51% of manufacturing respondents say they use a testing framework, compared to 75% in finance.”
Put another way: hardware isn’t a browser. This view of manufacturing respondents is backed up by another question, in which 31% of manufacturing respondents say their code is put to use in IoT (Internet of Things). No other industry gets above double digits for that answer. This makes manufacturing an interesting set of answers across the board, as we’ll see.
Finance, on the other hand, uses everything the most. They are the most likely to use a bundler, second-most likely to use a linter (after healthcare), most likely to test, second-most likely to use a web framework (after retail), most likely to use a transpiler, and second-most likely to use a CSS preprocessor (after advertising). Finance just does all the things.
We’ve examined the popularity of JavaScript frameworks in the past. Our survey data provides another view into these preferences, and the results are enlightening.
Angular was a fairly popular choice across all industries, but strongest in finance. Developers in entertainment were the least likely to use Angular, their strongest preference being for React (65%).
React was the most popular framework in the survey overall, though with strong variations by industry. As mentioned, 65% of developers in entertainment chose it, but that fell to 46% in government and 38% in manufacturing. Manufacturing’s strongest choice for a framework was jQuery (52%), suggesting the industry is a late adopter. Government also had jQuery as its top pick at 52%.
Around 20% of developers in most industries reported using Vue, though it was notably more popular in advertising, with 34% of developers reporting it there.
“We also asked developers how they made decisions about choosing frameworks. Big majorities (60-90%) in every industry reported things like support, features, and stability being important, with little variation.”
Ember did not get a lot of mention from our respondents, with an average of 4% of developers reporting that they used it. Also in this range were Preact (5%), Hapi (5%), Next.js (5%), and Meteor (5%).
A surprisingly popular choice was Electron, which is obviously not a web framework at all but we included in our options. More than 20% of developers in every industry reported using Electron for some projects.
We also asked developers how they made decisions about choosing frameworks. Big majorities (60-90%) in every industry reported things like support, features, and stability being important, with little variation. Security was the lowest ranked concern for frameworks, averaging only 25%, though finance was most concerned at 30%. We’ll go more into attitudes to security later in this post.
Obviously everybody in the survey uses JavaScript, but lots of respondents use another primary language as their back-end choice and there were noticeable variations by category.
Python was the choice of the unemployed. This sounds unflattering, but thanks to a poorly-phrased question on our part, the “unemployed” category includes people in full time education. Their questions (such as what level of schooling the respondent had completed) lend weight to the idea that the unemployed category was full of people who are still in school, so we believe Python is popular in education.
Java was the choice of the finance industry by quite a margin—41% versus 27% for the second most popular language in finance, .NET.
PHP was the choice of the advertising industry, again by a huge margin — 49% to 26% for Python, the second most popular. Why advertising companies choose PHP is unclear to us, but PHP is popular with advertising agencies putting together micro-sites. Furthermore, a question about company size showed that over 50% of advertising respondents worked at small companies (less than 50 people), so this category is probably dominated by small shops putting together these sorts of sites.
Our poorly-chosen “.NET” category (not really a language) was no industry’s first choice. Its strongest showing was in the manufacturing category at 33%, a very close second to Python at 34%. However, because we didn’t pick out C# and F# separately, it’s possible these results are skewed by people who use those languages, but don’t use .NET.
Ruby is a relatively unpopular option across all our respondents, chosen by less than 13% in all cases. Its weakest showing was in manufacturing, where only 3% chose it, and its strongest in education, where 13% did.
C and C++ were unsurprisingly most popular in the hardware-dominated manufacturing industry, at 9% and 18% of respondents respectively. C++ was more popular than C across the board. The retail industry is the least fond of C++, with only 4% of respondents reporting using it.
We also polled on Go, Swift, and Rust. Go was about 10% usage across the board, Swift was 3-5%, and Rust about 3% except in manufacturing, where it hit 7%.
In general, people are pretty clear why they choose JavaScript: the huge ecosystem of libraries. An academic study of the same topic in 2013, An Empirical Analysis of Programming Language Choices (Meyerovich and Rabkin, 2013) exhaustively researched what makes developers choose programming languages and it reached the same conclusion. It’s not controversial to conclude that the modules in the npm registry are a major reason people choose JavaScript. However, people cited a number of other reasons and there were notable variations by industry.
Respondents who say they work in government were the least likely to report that they chose JavaScript for productivity gains, with only 51% saying so versus 60% in the finance industry, where this belief is strongest. Instead, government was most likely to believe that using JavaScript gave them performance gains: 31% of government respondents cite this, while in most other industries only 20-21% said this.
The advertising industry is the one most likely to say that developer satisfaction is a reason they choose to use JavaScript, with 50% of respondents saying so. This is notable since the advertising industry has a lot of PHP developers, and as we’ll see in a future analysis based on programming language choices, high satisfaction with JavaScript is a characteristic shared by most PHP developers.
“Across every industry, solid majorities (more than 90% in every case) expected to use JavaScript more or about the same amount as they had previously in the next 12 months.”
Cost savings as a reason for choosing JavaScript were most cited by respondents who work in finance (41%). This seems pretty logical, as finance is an industry that presumably can be relied upon to think of the costs of things.
The entertainment industry was the most likely to cite the size of the developer pool (41%) while the retail industry was most likely to say the ease of on-boarding new developers (40%) was their reason for choosing JavaScript. While JavaScript has a big pool of developers and we think on-boarding developers in JavaScript is pretty easy, it’s unclear why these industries in particular would note those advantages.
Finally, some people don’t get to choose what programming language they work in. This number was highest in government, at 21%.
Across every industry, solid majorities (more than 90% in every case) expected to use JavaScript more or about the same amount as they had previously in the next 12 months.
npm is making a big push to improve the security of the modules in the registry in 2018, so we asked our users about their attitudes toward security. You can see our previous post for a deeper analysis of attitudes to security, but there are some interesting variations by industry.
Firstly, everyone is concerned about the security of the code they write (87-90%) and of the open source code they use (73-79%). Developers who work in tech were the most likely to be concerned, but there wasn’t a lot of variation.
Majorities in every industry reported that they were dissatisfied with current methods of evaluating the security of code (51-60%). Advertising and entertainment were the most likely to say they were dissatisfied with available methods.
“Firstly, everyone is concerned about the security of the code they write (87-90%) and of the open source code they use (73-79%). Developers who work in tech were the most likely to be concerned, but there wasn’t a lot of variation.”
A whopping 90% of people working in education (non-students) were likely to be concerned about the quality of the code they wrote themselves. This was an interesting result as they were also the industry most likely to say they were doing nothing at all to assess security (33%):
The industry most likely to be actively doing something about security is the finance industry. They were the group most likely to participate in code reviews (81%), most likely to have external audits of their code (30%), and the most likely to be using automated scans of their code (52%). The tech industry was a close second to finance in all of these answers.
We explored the ways developers use and store private code.
Everybody reports having private code and GitHub is an extremely popular place to store it — 93% of the advertising industry report using it, with most industries in the high 80’s. Manufacturing was an outlier here, with only 75% of developers saying they used GitHub. We thought this was a strange result, but it was consistent; when asked how they discovered packages, developers in manufacturing were also the least likely to report using GitHub (14% versus 20% for other groups).
Developers also store private npm packages. Across all industries, about a third of developers said they had created private npm packages. However, their reasons for doing so varied.
“However, by far the most popular reason for everyone using private packages was the most obvious: the packages contain private IP. Majorities from 65% in education to 91% in manufacturing reported this as a reason for creating private npm packages.”
Developers sometimes use private modules to hold test projects which aren’t ready for release. This practice varies widely across industries, with 23% of developers in education saying they do this but only 8% in retail.
More common was keeping code private for release as open source later. Education was likely to do this, with 27% saying so, and government employees following close behind at 25%. Healthcare developers, who reported less engagement with open source, were the least likely to report this as a reason, at 9%.
A big reason for everyone to keep private packages was re-use by their co-workers — including majorities from 53% in finance and 67% in retail.
However, by far the biggest reason for everyone using private packages was the most obvious: the packages contain private IP. Majorities from 65% in education to 91% in manufacturing reported this as a reason for creating private npm packages.
Finally, we explored attitudes toward testing across the industries.
In keeping with its answers in every other category, finance was the most likely to report that they use a testing framework (88%). Government and manufacturing developers on the other hand were the least likely to use a testing framework, with only 68% of developers in both industries saying so.
Across every industry, the most popular testing framework choice was Mocha (50%), followed by Jasmine (33%) and Jest (19%). Unlike web framework choices, there was less variation between the popularity of testing frameworks across industries.
There were some fascinating differences across the industries. The advertising and entertainment industries often found themselves paired together in terms of practices. Finance was cautious and security-focused. Government and manufacturing were mostly on the opposite end of that scale, with lower reported use of best practices and modern tooling. Whether you’re in these industries or building products for developers in these industries, we hope these results help you get a better sense of the broader universe of JavaScript developers.
Thanks to everyone who took the survey. We’ll be providing more analysis in the near future, so stay tuned!
This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.
Q: Hi! Can you state your name, what you do, and/or what your company does?
A: Hey there! My name is Feross Aboukhadijeh. I’m an entrepreneur and programmer who spends a lot of time writing open source code. A few examples of projects I started are WebTorrent and Standard, which are open source. You can learn more about my newest projects by checking out my blog or GitHub profile.
How’s your day going?
Pretty great! I’m happy that it’s finally the weekend. I’m doing some reading, open source maintenance, and tonight I’m hosting a party with my awesome housemates.
Tell me the story of npm at your company. What specific problem did you have that npm solved?
I first encountered npm while starting my first company, PeerCDN, in 2013. PeerCDN was a peer-to-peer content delivery network (CDN) which aimed to make the web faster, and help reduce website bandwidth costs. npm allowed us to build something useful super quickly. We installed `express`, `ws`, wrote some custom WebRTC magic and we had prototype off the ground in a few weeks. (We were eventually acquired by Yahoo).
The vast majority of the software I’ve written has been open source. I have over 100 packages on npm! I am able to create lots of value in the world when I don’t restrict how people can use my work. Publishing things under an open source license lets anyone use my code however they like, which is super powerful.
To people who are unsure what they could use npm for — how would you explain the use case?
If you want to use any modern JavaScript library, you’re going to get it from npm. Period.
How’s the day to day experience of using npm?
npm install; npm test
These two magic commands are the not-so-secret incantations that bring any npm package to life. As an npm user, you’ll type these commands dozens of times every day.
Would you recommend that another org or company use npm and why?
Definitely! npm is the best way to publish JavaScript code. It’s super fast, it’s optimized for a friendly developer experience (no dependency hell!), and it has all the packages that you need to make your vision come to life. If there’s a package that’s missing, you can be the one who writes it and publishes it to npm.
Any cool npm stuff your company has done publicly that you’d like to promote?
I’d just like to shout out open source maintainers. They do all the thankless work that makes this whole thing possible. Their tireless effort makes our awesome apps, websites, and projects possible! Many authors devote countless hours to open source. I think we all have a duty to help out authors and make the software we rely on healthier by giving back.
I built a tool called thanks that helps you financially support the open source maintainers you depend on in your project. Just run `npx thanks` in your project to see which of your dependencies are seeking donations. Share the love!
Follow me on Twitter at @feross.
npm loves everyone!
Just like last year, npm team’s Pride shirts available to all, with help from our friends at &yet and Teespring. Select your favorite design from the pictures below and click through for types and sizes — or collect them all! — and 100% of proceeds will benefit The Trevor Project.
Heads up! The timer on each Teespring page resets every three days when an order goes out — these shirts will be available indefinitely.
Are we missing a design? Reach out and let us know!
npm cli users should make sure that they have git version 2.17.1 or later installed to protect against a recent code execution vulnerability involving git submodules.
On May 29th, a new version of git (2.17.1) was published which addressed a flaw in how git submodules are handled. The flaw allowed for code execution on a user’s system when a recursive git clone of a specially created repository was performed.
The npm cli supports git dependencies; to enable this it delegates the act of cloning these dependencies to the git command. Because of this delegation, if the system has a vulnerable version of git installed the npm cli, it could be tricked into installing a git dependency of a malicious repo that could execute code on the user’s system.
To check what version of git you have installed you can run git --version
$ git --version
git version 2.17.1
Updating git is a different process for different systems. Users should use whatever method they initially installed git with in order to update it.
Windows users can read more here: Announcing the May 2018 Git Security Vulnerability
This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.
Q: Hi! Can you state your name, what you do, and/or what your company does?
A: I’m Mark Voorberg, one of the co-founders at BinaryOps Software. We build custom business software using the latest tools and technologies.
How’s your day going?
So far, so good! The sun is shining, the birds are chirping, and I’m in my happy place working through some code for a customer.
Tell me the story of npm at your company. What specific problem did you have that npm solved?
We started using npm back as far as 2013 to install published packages in our first application prototype built with Node. Fast-forward a few years and we released a simple Grunt plugin on npm. After that we’ve decided to create an npm Organization and release a much larger project that includes multiple packages.
To people who are unsure what they could use npm for — how would you explain the use case?
npm is a great way to find and install reusable NodeJS packages or to publish your own. Packages can be public or private which means it’s not just for open source projects, but internal ones as well.
How’s the day to day experience of using npm?
npm has become part of our regular workflow, whether it’s searching for functionality that we don’t need to invent, looking up a package that we’ve used before, or simply publishing updates to one of our own packages.
Would you recommend that another org or company use npm and why?
In my mind, npm is the de-facto standard for package management on Node. Hosting packages anywhere else is an unnecessary risk that you can do without.
Any cool npm stuff your company has done publicly that you’d like to promote?
At the end of 2017, we published a project called TransomJS. It’s a collection of packages that allow us to create full-featured REST APIs with metadata. For example, there’s a Transom package that translates JSON metadata into Mongoose models. It creates the corresponding endpoints for common CRUD interactions and then some. Everything from audit fields, data type validations, mapped relationships, and querying are handled by the Transom-Mongoose package. Similar packages exist for Authentication, Websockets, SMTP messages, content templating etc. It’s a cool project and lets us move quickly, only having to write the parts of an app that make it unique, anything that can be abstracted away can be put into its own Transom module.
We’ve added language to our privacy policy about our participation in the EU-US and Swiss-US Privacy Shield programs. As always, you can read the diff on GitHub.
Look at that! A feature bump! npm@6 was super-exciting not just because it used a bigger number than ever before, but also because it included a super shiny new command: npm audit. Well, we’ve kept working on it since then and have some really nice improvements for it. You can expect more of them, and the occasional fix, in the next few releases as more users start playing with it and we get more feedback about what y'all would like to see from something like this.
I, for one, have started running it (and the new subcommand…) in all my projects, and it’s one of those things that I don’t know how I ever functioned without it! This will make a world of difference to so many people as far as making the npm ecosystem a higher-quality, safer commons for all of us.
This is also a good time to remind y'all that we have a new RFCs repository, along with a new process for them. This repo is open to anyone’s RFCs, and has already received some great ideas about where we can take the CLI (and, to a certain extent, the registry). It’s a great place to get feedback, and completely replaces feature requests in the main repo, so we won’t be accepting feature requests there at all anymore. Check it out if you have something you’d like to suggest, or if you want to keep track of what the future might look like!
npm audit fixThis is the biggie with this release! npm audit fix does exactly what it says on the tin. It takes all the actionable reports from your npm audit and runs the installs automatically for you, so you don’t have to try to do all that mechanical work yourself!
Note that by default, npm audit fix will stick to semver-compatible changes, so you should be able to safely run it on most projects and carry on with your day without having to track down what breaking changes were included. If you want your (toplevel) dependencies to accept semver-major bumps as well, you can use npm audit fix --force and it’ll toss those in, as well. Since it’s running the npm installer under the hood, it also supports --production and --only=dev flags, as well as things like --dry-run, --json, and --package-lock-only, if you want more control over what it does.
Give it a whirl and tell us what you think! See npm help audit for full docs!
audit FEATURES1854b1c7f #20568 Add support for npm audit --json to print the report in JSON format. (@finnp)85b86169d #20570 Include number of audited packages in npm install summary output. (@zkat)957cbe275 [email protected]: Overhaul audit install and detail output format. The new format is terser and fits more closely into the visual style of the CLI, while still providing you with the important bits of information you need. They also include a bit more detail on the footer about what actions you can take! (@zkat)npm init <pkg>!Another exciting change that came with npm@6 was the new npm init command that allows for community-authored generators. That means you can, for example, do npm init react-app and it’ll one-off download, install, and run create-react-app for you, without requiring or keeping around any global installs. That is, it basically just calls out to npx.
The first version of this command only really supported registry dependencies, but now, @jdalton went ahead and extended this feature so you can use hosted git dependencies, and their shorthands.
So go ahead and do npm init facebook/create-react-app and it’ll grab the package from the github repo now! Or you can use it with a private github repository to maintain your organizational scaffolding tools or whatnot. ✨
a41c0393c #20538 Make the new npm view work when the license field is an object instead of a string. (@zkat)eb7522073 #20582 Add support for environments (like Docker) where the expected binary for opening external URLs is not available. (@bcoe)212266529 #20536 Fix a spurious colon in the new update notifier message and add support for the npm canary. (@zkat)5ee1384d0 #20597 Infer a version range when a package.json has a dist-tag instead of a version range in one of its dependency specs. Previously, this would cause dependencies to be flagged as invalid. (@zkat)4fa68ae41 #20585 Make sure scoped bundled deps are shown in the new publish preview, too. (@zkat)1f3ee6b7e [email protected]: Stop dropping size from metadata on npm cache verify. (@jfmartinez)91ef93691 #20513 Fix nested command aliases. (@mmermerkaya)18b2b3cf7 [email protected]: Make sure different versions of the Path env var on Windows all get node_modules/.bin prepended when running lifecycle scripts. (@laggingreflex)a91d87072 #20550 Update required node versions in README. (@legodude17)bf3cfa7b8 Pull in changelogs from the last npm@5 release. (@iarna)b2f14b14c #20629 Make tone in publishConfig docs more neutral. (@jeremyckahn)If you access /-/_view endpoints in the npm Registry, you have probably noticed that their availability has been low recently. We are temporarily suspending these endpoints and responding to them with 404s instead of the 504s you’ve been seeing. Our intent is to replace the service behind these endpoints with something more scalable. Unfortunately we have no estimates about when these endpoints will be available again.
The full list of deprecated endpoints is:
/-/_view/byKeyword/-/_view/browseUpdated/-/_view/browseAll/-/_view/dependedUpon/-/_view/browseAuthors/-/_view/browseStarPackageIf you need regular, reliable access to this data, we strongly suggest that you mirror the public registry data by replicating the CouchDB at replicate.npmjs.com. The CouchDB JavaScript application that provides these views is available in the npm/npm-registry-couchapp repo. Follow the instructions in that repo and replicate from replicate.npmjs.com to get the full data set.
Last month, we announced npm@6, which includes a powerful new tool to protect the safety of your code, npm audit. Together with new automatic alerts when a user installs code with a known security risk, audit is a dramatic step to ensure the quality and integrity of the code you use, and protect the world’s largest community of open source software developers.
Read on to learn more about audit and how we’re working to help you develop with confidence.
npm audit?npm audit is a new command that performs a moment-in-time security review of your project’s dependency tree. Audit reports contain information about security vulnerabilities in your dependencies and can help you fix a vulnerability by providing simple-to-run npm commands and recommendations for further troubleshooting.
You can start using npm audit right now by updating to the latest version of npm. Just type npm install npm -g.
Here is an example of running npm audit against your-fantastic-app:
cd your-fantastic-app
npm audit
The results should look like this:
We’ve also built in a summary security report into npm install if vulnerabilities are found during installation:
Or when no vulnerabilities are found:
You can learn more about how to run a security audit on the npm documentation site
npm audit is available in [email protected] and npm@6. Prior versions of npm will receive vulnerability messages similar to the following:
npm-notice: [SECURITY] marked has 3 high, and 2 moderate vulnerabilities. Go here for more details: [https://nodesecurity.io/advisories?search=marked&version=0.3.0](https://nodesecurity.io/advisories?search=marked&version=0.3.0) - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
We’re not aware of any third-party registry clients that currently support displaying the npm-notify header, so users of these tools will not receive vulnerability messages. For maximum protection against unsafe code, all users should use npm@6.
In the short term, these new alerts and npm audit will raise developers’ awareness of known security vulnerabilities within their applications.They also provide actionable guidance to eliminate the identified risks.
In the longer term, prominent vulnerability warnings and actionable security alerts will raise the floor for everyone. When a developer of a popular package notices they have been bringing in a vulnerable dependency and switches to using a fixed version, instead, every package that depends upon this popular package will now grow safer, too. Everyone stands to benefit from this network effect.
Security is a process, not a project—it’s never done. We will continue to work to improve the security of the npm Registry and the code you write, and we’re excited by what’s in the works in coming weeks and months.
Already, we’ve announced that package signing is on its way. This will allow users of npm packages to verify the integrity of the package regardless of the tools they use to retrieve it or the registry from which they download it.
After this, expect a summer full of products that empower security-focused teams and enterprises by augmenting the tools we’ve announced today. Watch this space.
Update: We’ve added
npm audit fix which combines all the actionable, semver-compatible reports from your audit and runs them for you. You can read more about it in the v6.1.0 release notes.
b267bbbb9 npm/lockfile#29 [email protected]: Switches to signal-exit to detect abnormal exits and remove locks. (@Redsandro)If a published modules had legacy npm-shrinkwrap.json we were saving ordinary registry dependencies (name@version) to your package-lock.json as https:// URLs instead of versions.
89102c0d9 When saving the lock-file compute how the dependency is being required instead of using _resolved in the package.json. This fixes the bug that was converting registry dependencies into https:// dependencies. (@iarna)676f1239a When encountering a https:// URL in our lockfiles that point at our default registry, extract the version and use them as registry dependencies. This lets us heal package-lock.json files produced by 6.0.0 (@iarna)You can’t use it quite yet, but we do have a few last moment patches to npm audit to make it even better when it is turned on!
b2e4f48f5 Make sure we hide stream errors on background audit submissions. Previously some classes of error could end up being displayed (harmlessly) during installs. (@iarna)1fe0c7fea Include session and scope in requests (as we do in other requests to the registry). (@iarna)d04656461 Exit with non-zero status when vulnerabilities are found. So you can have npm audit as a test or prepublish step! (@iarna)fcdbcbacc Verify lockfile integrity before running. You’d get an error either way, but this way it’s faster and can give you more concrete instructions on how to fix it. (@iarna)2ac8edd42 Refuse to run in global mode. Audits require a lockfile and globals don’t have one. Yet. (@iarna)b7fca1084 #20407 Update the lock-file spec doc to mention that we now generate the from field for git-type dependencies. (@watilde)7a6555e61 #20408 Describe what the colors in outdated mean. (@teameh)We’ve rewritten our privacy policy from scratch to make it easier to read, cover new features, and meet the requirements of the EU’s General Data Protection Regulation. The new policy also announces a new contact point, [email protected], for privacy-related questions and help.
Early May 2nd, the npm security team received and responded to reports of a package that masqueraded as a cookie parsing library but contained a malicious backdoor. The result of the investigation concluded with three packages and three versions of a fourth package being unpublished from the npm Registry.
No packages published to the npm Registry used the malicious modules in a way that would have allowed the backdoor to be triggered. Applications not published to the registry that directly required the malicious modules might have been vulnerable, but are out of the scope of our analysis.
Initial information from the community reported that the package getcookies contained a potential backdoor, that express-cookies and http-fetch-cookies depended upon getcookies, and that a popular package, mailparser, depended upon http-fetch-cookies.
Upon receiving the report, npm’s security team started triage. The goal of triage was determining whether the reported package did in fact contain malicious code, and, if so, how this impacted the community.
We won’t disclose the entire backdoor here, but we’ll give a few highlights that we noted as it was reviewed.
The backdoor worked by parsing the user-supplied HTTP request.headers, looking for specifically formatted data that provides three different commands to the backdoor.
JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, p, v) => {})
We can see here that the headers are stringified and the result searched for values in the format of: gCOMMANDhDATAi
The control flow codes available were:
vm.runInThisContext, providing module.exports, require, req, res, and next as arguments.These control codes allowed for an attacker to input arbitrary code into a running server and execute it.
Beyond the backdoor code, other aspects of these modules and the account also stood out:
mailparser
└── http-fetch-cookies
└── express-cookies
└──getcookies
Dependency relationship of the reported modules
Despite being deprecated, mailparser still receives about 64,000 weekly downloads. We searched for how users of this module might be impacted. We determined the published versions of mailparser that depended on http-fetch-cookies did not use the module in any way, eliminating any risk the backdoor posed. We speculate that mailparser’s requiring http-fetch-cookies was to execute an attack in the future or to inflate download counts of express-cookies to add to its legitimacy.
Ultimately, mailparser users weren’t impacted. Only users that directly required and used the express-cookies or getcookies packages would be impacted.
dustin87 user and unpublished getcookies, express-cookies, and http-fetch-cookies;mailparser that depended on the http-fetch-cookies module;All times in Pacific Daylight Time (UTC–7)
05:23—Initial community report
05:41—Security team started triage
07:01—Unpublished getcookies, express-cookies, http-fetch-cookies
07:02—Revoked tokens for mailparser maintainer
07:26—Unpublished mailparser versions 2.2.3, 2.2.2, and 2.2.1
In coordination with today’s announcement of Node.js v10, we’re excited to announce npm@6. This major update to npm includes powerful new security features for every developer who works with open source code. Read on to understand why this matters.
In this winter’s ecosystem survey, we learned that 97% of worldwide JavaScript developers rely on open source code in our projects. This is borne out by the metrics we’ve observed in the npm Registry, which served 5 billion package downloads last week: it’s indisputable that the model of finding, sharing, and reusing others’ modular code is the new normal in software development.
When we asked for your attitudes towards whether the code you use is secure, we learned two eye-opening facts. First: 77% of developers expressed concern with whether the open source code they use is secure. More interestingly, 87% expressed concern about the safety of their own code. Put another way, more developers trust the security of the open source code they use than trust themselves.
In that same survey, we learned that more than half of you are dissatisfied with the current methods available to assess whether code is safe.
We believe the explanation is simple: complexity is the enemy of best practices. If a security process requires pausing development for manual reviews, paying for an external audit, or introducing a third-party tool into your workflow, you’re less likely to follow it.
Earlier this month, we were excited to announce our acquisition of the Node Security Platform, the definitive source of known JavaScript package vulnerabilities. With npm@6, we’re proud to announce the first fruits of our collaboration.
Soon, every user of the npm Registry will begin receiving automatic warnings if you try to use code with a known security issue. npm will automatically review install requests against the NSP database and return a warning if the code contains a vulnerability.
In addition, a new command in npm@6, `npm audit`, will soon allow you to recursively analyze your dependency trees to identify specifically what’s insecure — so you can swap in a new version or find a safer alternate dependency.
These features are already available to users of npm’s beta registry, and in coming weeks they will automatically roll out to every member of the community. Both of these features are available free of charge to every npm user, with no purchase or registration required. (Customers of our paid services will receive additional pre-publication vulnerability disclosures, formerly the NSP’s premium tier.)
We’re giving away these resources to maximize community benefit. Every developer needs to know that the code they use is safe. By alerting the entire community to security vulnerabilities within a tool you already use, we can make JavaScript development safer for everyone.
If you haven’t already, you should check out our recap of what we’ve added to npm in the last year, the notes for today’s release, and our roadmap of the year ahead. There’s a lot to celebrate. This includes:
You can update to npm@6 by typing `npm i -g npm@latest`. And, as always, you can get in touch with your feedback, questions, and ideas. Just hit us up on Twitter or drop us a line.
We’re excited by today’s announcement, and hopeful that you are, too. It’s never been faster or safer to build amazing things.
First published just under a year ago, npm@5 has probably seen the fastest rate in major changes of any prior npm version. Even if you’ve been following us closely, you probably still haven’t been able to keep up with everything that’s been going on with npm@5.
With [email protected] getting tagged as latest this week, we thought it would be a good idea to summarize all the changes that have happened since [email protected] was first tagged — and what you can expect to get in one upgrade when you first install [email protected]!
This one’s first because it’s the most noticeable change for anyone doing the initial switch. npm is now between 4x and 17x faster than npm@4, especially in CI settings. This means developers can iterate on their changes faster, share their changes faster, and spend less time waiting between pushing a new build and continuing deployment. These sorts of speed differences are not just about making existing things fast, either—they’re about opening doors to entire new opportunities and allowing our users to scale projects beyond what they could do before.
We’ll continue to improve performance—both the CLI and registry teams are dedicated to getting you all that code as fast as your hardware allows it.
package-lock.json and automatic conflict resolutionAlong with the speed change, you might have noticed a new file in your git repositories. package-lock.json is a so-called “lock file” that saves information about your node_modules/ tree since you last edited your dependencies. Even though it’s a generated file, it’s meant to be committed into git and has a number of benefits, including increased reproducibility across teams, reduced network overhead when installing, and making it easier to debug issues with dependencies.
Because this was such a significant change to the way npm works, initial iterations of package-lock.json were a bit of a bumpy ride, with unexpected changes and platform differences. As of npm@6, your lock file will be stable not just between you and your coworkers on similar platforms, but across operating systems! You can even use npm install --package-lock-only to generate one of these without installing into node_modules/.
Some folks faced issues when using package-lock.json that led to inscrutable git conflicts. As of [email protected] (and, by extension, npm@6), npm will now automatically resolve package-lock conflicts when you run npm install during a conflicted state. To make this experience even smoother, we’ve released npm-merge-driver, which lets you do all the rebasing and merging and other git backflips. You can get started with the merge driver by doing $ npx npm-merge-driver install -g one time. After that, all your future merge and rebase conflicts in any git repo will be resolved in the background.
Those of you who used package-lock.json throughout the npm@5 release line will see a big git diff next time you do an npm install with npm@6: the requires field is changing its format slightly, and we’re adding a new from field to locked git dependences (if you use those) but you should not see this happen again if you and your team are all on npm@6 or later.
npx
What’s that npx thing we mentioned? Why, it’s the npm package runner! [email protected] introduced a new workflow tool included with npm itself. npx solves a lot of specific problems, but its overall purpose is making the experience of working with npm-based CLI tools easy, smooth, and seamless!
npx can actually do a lot of different things,
but the biggest benefits are:
You can run project-local binaries with it. That means you don’t need to install things like grunt-cli, gulp, bower, and tsc globally—you can install them as devDependencies and use npx to run the local versions without hassle (for example, $ npm i -D standard && npx standard).
You can do one-off, temporary installs of command line utilities that you run rarely, such as generators: $ npx create-react-app.
You can easily try different versions of these tools with a single install if you need to compare them: $ npx standard@8 && npx standard@10.
You can even install the shell auto-fallback to not even have to write $ npx ... in many cases.
npx has already made a huge difference in the daily workflow of many of our users. Have you tried it yet?
npm ci
Thanks to the new package-lock.json feature, we were able to add a cool new command in [email protected]: npm ci! This added a second installer to the npm CLI that takes advantage of projects with package-lock.json files in order to rapidly extract to node_modules/. It skips a lot of the interactivity and human-oriented checks that npm install does, and even makes it so that any inconsistencies trigger errors, rather than having the npm install command fix them for you. npm ci, as the name implies, is meant primarily for use in Continuous Integration/Continuous Deployment situations where you want fast installs that give you early warnings about potential errors. npm ci is about 2–3x faster than a regular npm install.
Finally, as with npm it, there’s now an npm cit for doing an npm ci install + npm test in a single command.
Last October, npm introduced two-factor authentication for a number of account-related actions, including publishing and dist-tag management. Roughly 9 billion weekly downloads—about 43% of downloads—now involve packages that were published by 2fa-protected accounts. That’s amazing news for the overall security of the ecosystem.
As part of that release, we also included the ability to create “read-only” tokens, filter tokens by CIDR, and manually manage your active tokens through the CLI and the website.
npm@5 introduced a completely new system cache for package downloads, replacing the older, buggier, and slower implementation. It was built on top of a standalone library, cacache, and was designed to work closely with the new package-lock.json format by enabling content-addressable storage of package data. This allows it to do much faster lookups of tarball data. It also allows npm to verify your package data on every single install, so you can always trust that what comes out of the registry or the cache is exactly the data you expect it to be.
This process also upgraded our shasum infrastructure to support Subresource Integrity, with new tarballs being published with sha512, instead of the now-insecure sha1 algorithm. This method also makes it much easier to upgrade our infrastructure once faster and better cryptographic hashing algorithms become available in Node.js.
Finally, the new cache architecture enabled a much-awaited npm feature: seamless offline installation! If you don’t have network access or can’t reach the registry for some reason, npm will automatically install from your cache without the need for any extra flags or preparation. Just keep a warm cache and go ahead and do your work on a plane or while you’re disconnected from the network to preserve bandwidth. If you’re on a functional but slow connection, you can even use the new --prefer-offline flag to opt into stale data in exchange for minimal network hits.
npm ci and lock files aren’t the only exciting feature for devops folks! As part of npm@5, Isaac completely rewrote node-tar, which is a huge part of the recent performance boost. It also gave us the ability to pack tarballs with pinned file timestamps.
npm can now generate and publish tarballs built at different times on different platforms with identical shasums, enabling reproducible builds!
Keep in mind that you still need to make sure your build run-scripts generate reproducible build artifacts for this to work!
npm publish and npm pack improvements
npm now prints a summary of tarball details whenever you package up an npm project. This summary includes information about the files that you’re including, along with their file sizes (which can help make sure you’re publishing only what you intend), the name and version of the package, and the shasum and integrity for the generated tarball.
In addition, both npm publish and npm pack now support --dry-run and --json flags. With these, you can test that you’re getting what you expect before you actually publish your project. If you’re trying to get reproducible builds working, you can use --dry-run to check that your scripts are generating your published files consistently.
Because npm publish and npm pack both accept any package specifier, you can even use them to test other people’s packages to make sure, for example, that the tarball published to npm actually matches the tagged git version: $ npm pack --dry-run github:zkat/figgy-pudding && npm pack --dry-run figgy-pudding.
You can even hook into the new prepack, pack, and postpack lifecycle scripts along with the new prepare lifecycle to automate this detection as desired.
npm has also greatly improved its interaction with git dependencies, adding two major features to git deps:
First, git-based packages with prepare scripts defined will have their devDependencies installed and the prepare script executed before the package tarball for the dependency is packaged and installed. This means that if you want to work off a fork but you want a build step for your library, you can still have that build process! You don’t need to check in built/minified .js directly into git anymore—npm will generate them for you.
Second, npm added semver-range support for git dependencies. Just like you can do $ npm install pkg@^1.2, you can now do npm install github:usr/pkg#semver:^1.2. Semver support will work off branch and tag names, so as long as you keep those up, you’ll be able to use semver with them.
These features should help smooth out the experience for users that are heavily reliant on git dependencies.
npm hooks have been available for a couple of years, but the only way to manage them was through a separate CLI. As of npm@6, you can manage hooks directly with npm itself.
This feature allows you to add webhooks to npm packages, scopes, or users, and have the npm registry post to an external endpoint when related events happen. Hooks can be a great way to integrate npm into your release flow or to get better analytics. Check them out!
file: dependency symlinkingPreviously, directory dependencies (that is, what would install if you did $ npm install ../some-pkg), would go through a two-step process: first, they would be packaged into a tarball, as if for publishing, and then that tarball would be installed as a dependency. However, updating that dependency’s code in the future required that you do a full install of it again. That caused some friction for users wanting to work based off local packages or who were working on monorepos.
Now, those dependencies are installed as symlinks, so any changes you make to them will be immediately visible to your package without needing to do a whole new install.
npm@6 also includes a number of smaller aesthetic and usability improvements we’ve been incrementally landing in npm:
npm install saves by default
npm install now savess dependency changes by default. You no longer need to remember to add --save before your dependencies get written to package.json (and package-lock.json). This applies to other commands as well, like npm update and npm uninstall.
New npm view output format
Previously, you’d get several screenfuls of colorful JSON output any time you did $ npm view. Now you get this:
You can still access the JSON version by using --json or you can access specific packument fields with $ npm view [...], but the default view is now much easier to view and understand and it includes what we think is the most essential information about the package.
Short install summary
Running npm install in npm@4 would get you a massive amount of tree output. This output made sense when projects were smaller, but it eventually became unreadable for users and took a long time to calculate and print out.
Now, this is all you get when you run npm install on a big project:
We also added the by N contributors section to increase awareness of everyone putting effort into improving the npm ecosystem. You can find out how to give back by running $ npx thanks.
npm update respects latest
The npm update command was a weird creature before: unlike npm install, it would ignore the latest tag and instead install the highest semver-matching version available for that package. Sometimes, these higher versions were intended as prerelease versions and could cause unintentional installs of unstable software.
As of npm@6, $ npm update foo and $ npm install foo will have similar semantics on this front, with the exception that update will limit its install to a version matching the currently-saved semver range for that package.
install and update skip deprecated versions.
Along those lines, if you try and install a package and it has deprecated some of its versions, npm@6 will try to avoid installing the deprecated ones and find other matching versions if possible. Deprecated versions will only be installed if there’s no other way to fulfill the requested version.
Module: example
Versions:
1.0.0
1.1.0
1.1.2
1.1.3 (deprecated)
So, given this example, npm install example@^1 will now install [email protected], whereas before, it would have installed [email protected].
There’s a lot of very exciting changes coming in 2018! For more info about what we have planned, take a look at this post.
We’re working hard this year to continue minimizing friction for JavaScript developers and make the experience of using npm as smooth, seamless, and secure as we can. npm is the largest package ecosystem in the world and continues to grow at an incredible pace—we’re glad to have the opportunity to make that possible and bring JavaScript and web development into the future it deserves!
Watch this space: follow @npmjs on Twitter for release updates and subscribe to our newsletter!
This week npm@6 is going to be promoted to latest and so now is an excellent time to look forward. If you dig into it you’ll find that it doesn’t have much in the way of breaking changes. Later this year we’ll be releasing npm@7. First there are a few new features, these will initially ship as npm@6 minor releases:
npm install will be updated to be an alias for npm ci when they would produce the same result, that is, that your package-lock is compatible with your package.json and you’re starting with no node_modules.The breaking changes in npm@7 should not be disruptive but are important:
npm login and npm adduser will finally be split apart. Up till now they’ve been the same command, which is why npm login prompted for an email address.npm init will be getting an overhaul, both with allowing easy third-party init templates and with some new one’s from us, to help you configure your CI and git environments.sudo and how it handles permissions as root to make it less surprising. Look for a new RFC soon!npm link rewrite as described in its associated RFC.preinstall, install and postinstall scripts when running for a dependency will have their output captured and it will only be displayed if there’s an error. They will run with stdin closed. This means that install lifecycle scripts in projects installed as dependencies will not be able to be interactive. For all other lifecycle scripts, output will be captured and routed to the log and also outputted to stdout.After npm@7, in the late summer and fall of 2018, our plans are somewhat more tentative, but we have a few things we’d like to get out to you all:
npx has been a huge success, but it can mean that you’re running untrusted code from the registry. We have a number of thoughts about how to improve its security, from looking for known vulnerabilities to catching typo-squatting.shrinkpack into npm directly. This would allow for entirely offline deploys even without a cache. It will also let you deploy with git dependencies without having git installed on your production machines.npm install and npm ci. If one fails due to certain classes of error then we should try the other.npm init auto?)As we work our way through the year we will likely be rewriting a number of other components in npm, either as we need them or as the community provides them.
npm outdated could use with a rewrite as it has the hackiest of shims to make it work at all. It was originally designed to run off of read-installed output which is what npm@1 and npm@2 used to read node_modules. A version that was designed to run off of modern npm data structures would be much easier to understand.npm ls would benefit a great deal from being updated to work off of modern data structures.npm-registry-client (and in turn request) from the npm code base. With the advent of npm-registry-fetch (which is based off make-fetch-happen and in turn node-fetch) we can finally complete this.For more…
Watch this blog, follow @npmjs on Twitter and subscribe to our newsletter!
If you want to follow development as it happens the best place to go is #js-npm on the package.commmunity discord.
Hey y'all! Here’s another npm@6 release – with node@10 around the corner, this might well be the last prerelease before we tag 6.0.0! There’s two major features included with this release, along with a few miscellaneous fixes and changes.
npm init SCAFFOLDINGThanks to the wonderful efforts of @jdalton of lodash fame, npm init can now be used to invoke custom scaffolding tools!
You can now do things like npm init react-app or npm init esm to scaffold an npm package by running create-react-app and create-esm, respectively. This also adds an npm create alias, to correspond to Yarn’s yarn create feature, which
inspired this.
008a83642 ed81d1426 833046e45 #20303 Add an npm init feature that calls out to npx when invoked with positional arguments. (@jdalton)This version of npm adds a new command, npm audit, which will run a security audit of your project’s dependency tree and notify you about any actions you may need to take.
The registry-side services required for this command to work will be available on the main npm registry in the coming weeks. Until then, you won’t get much out of trying to use this on the CLI.
As part of this change, the npm CLI now sends scrubbed and cryptographically anonymized metadata about your dependency tree to your configured registry, to allow notifying you about the existence of critical security flaws. For details about how the CLI protects your privacy when it shares this metadata, see npm help audit, or read the docs for npm audit online. You can disable this altogether by doing npm config set audit false, but will no longer benefit from the service.
f4bc648ea #20389 [email protected] (@iarna)594d16987 #20389 [email protected] (@iarna)8c77dde74 1d8ac2492 552ff6d64 09c734803 #20389 Add new npm audit command. (@iarna)be393a290 #20389 Temporarily suppress git metadata till there’s an opt-in. (@iarna)8e713344f #20389 Document the new command. (@iarna)package-lock.json FORMAT CHANGES?!820f74ae2 #20384 Add from field back into package-lock for git dependencies. This will give npm the information it needs to figure out whether git deps are valid, specially when running with legacy install metadata or in --package-lock-only mode when there’s no node_modules. This should help remove a significant amount of git-related churn on the lock-file. (@zkat)9d5d0a18a #20358 npm install-test (aka npm it) will no longer generate package-lock.json when running with --no-package-lock or package-lock=false. (@raymondfeng)e4ed976e2 2facb35fb 9c1eb945b #20390 Fix a scenario where a git dependency had a comittish associated with it that was not a complete commitid. npm would never consider that entry in the package.json as matching the entry in the package-lock.json and this resulted in inappropriate pruning or reinstallation of git dependencies. This has been addressed in two ways, first, the addition of the from field as described in #20384 means we can exactly match the package.json. Second, when that’s missing (when working with older package-lock.json files), we assume that the match is ok. (If it’s not, we’ll fix it up when a real installation is done.) (@iarna)a1c77d614 #20331 Fix broken link to ‘private-modules’ page. The redirect went away when the new npm website went up, but the new URL is better anyway. (@vipranarayan14)ad7a5962d #20279 Document the --if-present option for npm run-script. (@aleclarson)a9e722118#20256
Add support for managing npm webhooks. This brings over functionality
previously provided by the wombat CLI.
(@zkat)8a1a64203#20126
Add npm cit command that’s equivalent of npm ci && npm t that’s equivalent of npm it.
(@SimenB)fe867aaf149d18b4d8ff6b31f7778eab3cda
The requires field in your lock-file will be upgraded to use ranges from
versions on your first use of npm.
(@iarna)cf4d7b4de#20257
Add shasum and integrity to the new npm view output.
(@zkat)685764308
Fix a bug where OTPs passed in via the commandline would have leading
zeros deleted resulted in authentication failures.
(@iarna)8f3faa3236800f76ffec90c06c7825b5d2c64785f13fbbd16485f5
Restore the ability to bundle dependencies that are uninstallable from the
registry. This also eliminates needless registry lookups for bundled
dependencies.
Fixed a bug where attempting to install a dependency that is bundled inside another module without reinstalling that module would result in ENOENT errors. (@iarna)
429498a8c#20029
Allow packages with non-registry specifiers to follow the fast path that
the we use with the lock-file for registry specifiers. This will improve install time
especially when operating only on the package-lock (--package-lock-only).
(@zkat)
Fix the a bug where npm i --only=prod could remove development
dependencies from lock-file.
(@iarna)
834b46ff4#20122
Improve the update-notifier messaging (borrowing ideas from pnpm) and
eliminate false positives.
(@zkat)f9de7ef3a#20154
Let version succeed when package-lock.json is gitignored.
(@nwoltman)f8ec52073#20212
Ensure that we only create an etc directory if we are actually going to write files to it.
(@buddydvd)ab489b753#20140
Note in documentation that package-lock.json version gets touched by npm version.
(@srl295)857c2138d#20032
Fix bug where unauthenticated errors would get reported as both 404s and
401s, i.e. npm ERR! 404 Registry returned 401. In these cases the error
message will now be much more informative.
(@iarna)d2d290bca#20082
Allow optional @ prefix on scope with npm team commands for parity with other commands.
(@bcoe)b5babf0a9#19580
Improve messaging when two-factor authentication is required while publishing.
(@jdeniau)471ee1c5b0da38b7b4
Fix a bug where optional status of a dependency was not being saved to
the package-lock on the initial install.
(@iarna)b3f98d8ba9dea95e31
Ensure that --no-optional does not remove optional dependencies from the lock-file.
(@iarna)73dc97455zkat/cipm#46[email protected]:
Detect binding.gyp for default install lifecycle. Let’s npm ci work on projects that
have their own C code.
(@caleblloyd)77c3f7a00[email protected]dce733e37zkat/json-parse-better-errors#1[email protected]
(@Hoishin)c52765ff3[email protected]
(@mcollina)e160adf9f[email protected]
(@sindersorhus)9a9d7809e[email protected]
(@joshbruce)f2fbd8577#20256[email protected]
(@zkat)44972d53d#20256[email protected]
(@zkat)cfe562c58#20276[email protected]3c0bbcb8ezkat/npx#172[email protected]
(@jdalton)0573d91e5zkat/cacache#128[email protected]
(@zkat)396afa99f[email protected]
(@zkat)e7f869c36[email protected]
(@zkat)77dac72df[email protected]
(@zkat)0b802f2a0[email protected]
(@iarna)4781b64bc[email protected]
(@zkat)7bdbaeea6[email protected]
(@zkat)5f2bf4222[email protected]
(@zkat)32ec2f54b#20257
Add shasum and integrity to the new npm view output.
(@zkat)a22153be2#20126
Add npm cit command that’s equivalent of npm ci && npm t that’s equivalent of npm it.
(@SimenB)089aeaf44
Fix a bug where OTPs passed in via the commandline would have leading
zeros deleted resulted in authentication failures.
(@iarna)6eaa860ea
Eliminate direct use of new Buffer in npm. While the use of it in npm was safe, there
are two other reasons for this change:
new Buffer in unsafe ways, if they try
really hard.(@iarna)
85900a294
Starting with 5.8.0 the requires section of the lock-file saved version ranges instead of
specific versions. Due to a bug, further actions on the same lock-file would result in the
range being switched back to a version. This corrects that, keeping ranges when they appear.
(@iarna)
0dffa9c2a609d6f6e108f81aa94f8b76e0766d609822d59d080a22
Restore the ability to bundle dependencies that are uninstallable from the
registry. This also eliminates needless registry lookups for bundled
dependencies.
Fixed a bug where attempting to install a dependency that is bundled inside another module without reinstalling that module would result in ENOENT errors. (@iarna)
db846c2d5#20029
Allow packages with non-registry specifiers to follow the fast path that
the we use with the lock-file for registry specifiers. This will improve install time
especially when operating only on the package-lock (--package-lock-only).
(@zkat)
Fixes a bug where npm i --only=prod could remove development
dependencies from lock-file.
(@iarna)
3e12d2407#20122
Improve the update-notifier messaging (borrowing ideas from pnpm) and
eliminate false positives.
(@zkat)f18be9b39#20154
Let version succeed when package-lock.json is gitignored.
(@nwoltman)ced29253d#20212
Ensure that we only create an etc directory if we are actually going to write files to it.
(@buddydvd)8e21b19a8#20140
Note in documentation that package-lock.json version gets touched by npm version.
(@srl295)5d17c87d8#20032
Fix bug where unauthenticated errors would get reported as both 404s and
401s, i.e. npm ERR! 404 Registry returned 401. In these cases the error
message will now be much more informative.
(@iarna)05ff6c9b1#20082
Allow optional @ prefix on scope with npm team commands for parity with other commands.
(@bcoe)6bef53891#19580
Improve messaging when two-factor authentication is required while publishing.
(@jdeniau)155dab2bd
Fix a bug where optional status of a dependency was not being saved to
the package-lock on the initial install.
(@iarna)8d6a4cafca0937e9af
Ensure that --no-optional does not remove optional dependencies from the lock-file.
(@iarna)8baa37551zkat/cipm#46[email protected]:
Detect binding.gyp for default install lifecycle. Let’s npm ci work on projects that
have their own C code.
(@caleblloyd)323f74242zkat/json-parse-better-errors#1[email protected]
(@Hoishin)d0cf1f11e[email protected]
(@mcollina)9e9fdba5e[email protected]
(@sindersorhus)57fa33870[email protected]
(@joshbruce)d2b20d34b#20276[email protected]2b5700679zkat/npx#172[email protected]
(@jdalton)If you’ve recently examined packuments in the Registry, you might have noticed a new npm-signature field in the dist section. It might look to you like a PGP signature, and that in fact is what it is! This field holds the npm registry’s PGP signature of the integrity field.
Read on to find out why we’re signing publications, what exactly we’re signing, and how you can use this signature data.
Every package has a package metadata document. This is a JSON document that describes the package and what versions have been published, and what their dependencies are. We refer to this as a packument—a portmanteau of ‘package’ and 'document’.
A package-version is a specific version of a package, along with its metadata and code tarball. You can uniquely name a package-version with its package-name + version. For example, [email protected] is a package-version.
Every package-version published to the registry has a dist structure in the package’s metadata document. Here’s the dist structure for version 1.4.3 of light-cycle:
{
"integrity": "sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ==",
"shasum": "c305f0113d81d880f846d84f80c7f3237f197bab",
"tarball": "https://registry.npmjs.org/light-cycle/-/light-cycle-1.4.3.tgz",
"fileCount": 11,
"unpackedSize": 25612,
"npm-signature": "..."
}
This structure tells npm clients where to fetch the tarball to install the package-version, and, further, how to verify that the tarball fetched is the same as the one the npm registry intended to serve. The shasum is a SHA-1 sum of the file. We’ve supplemented this to the side with an integrity field, based on the subresource integrity specification, to allow us to migrate to different hashing algorithms. For this publication, the client had sha512 available and used it to hash the contents.
The npm CLI checks tarball integrity when a package-version arrives in your local cache, which is a content-hash addressed cache.
The shasums above are invaluable for determining that your npm client received the data it was supposed to receive over the network without corruption. They do not, however, protect against man-in-the-middle attacks.
If an attacker has interposed a proxy between you and the registry, they can tamper with both the package JSON document that advertises the shasum and the tarball itself. This attacker could create a tarball with unexpected content, generate an integrity field for it, then construct a packument advertising this poisoned tarball. An npm client would trust the packument and therefore also trust the tarball.
We offer you a way to detect this kind of tampering by signing package integrity fields along with some data that uniquely identifies the package-version.
Note that verifying this signature only establishes that a middleman has not tampered with the contents or integrity field for that package-version. It does not establish that the npm registry itself hasn’t meddled with package contents at publication time! You still have to trust us. (We intend to offer a solution to that problem in the future.)
The npm registry uses OpenPGP to sign packages. PGP, aka Pretty Good Privacy is an encryption standard that offers ways to authenticate and verify messages. The EFF has a good introduction to public-key cryptography and PGP, which I recommend if you would like a general introduction to the topic.
We’re generating signatures using openpgpjs , a pure JavaScript implementation of OpenPGP.
Our public key is at the end of this post.
We’ve also chosen to use Keybase to publicize our PGP key and give you confidence that the npm registry you install from is the same registry that’s signing packages. Our account on Keybase is npmregistry.
Keybase offers two advantages over the core OpenPGP experience that move us to recommend it to you. First, the Keybase application and CLI provide an excellent user experience for PGP, which can be intimidating for newcomers. Second, Keybase manages and displays social proofs that the entity that controls a specific pgp key also controls accounts on social media and other places. These proofs help you determine whether you can trust an account.
We’ve established proofs on Keybase that we control @npmjs on Twitter, the domain npmjs.com, and the domain npmjs.org. Verifying these proofs won’t tell you who owns those domains, but it does establish that the same entity controls them and the pgp key advertised on Keybase.
You can also observe that npm’s executive and technical team are among the people who’ve chosen to follow npmregistry on Keybase. For example, I (ceej) am following npmregistry, as are Isaac Z. Schlueter (isaacs) and Adam Baldwin (adam_baldwin).
If you install Keybase and create an account, you can follow npmregistry yourself and keep a local copy of the registry’s public key. The verification examples that follow assume you have done so.
The registry signs the following data for each new package-version published:
<package>@<version>:<integrity>
This string uniquely identifies a package-version in the registry and associates it with a specific package integrity field.
On package publication, we first validate that the data we received matches what the client thinks it published by checking shasums and the integrity field. Next, we construct the package-version + integrity string. We then generate a detached signature for that string—that is, a signature that isn’t part of a full message structure. The detached signature is stored in the npm-signature field in dist.
Here’s an example. When [email protected] was published, the npm registry created a pgp signature for this exact string:
[email protected]:sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ==
The presence of a signature is not enough for you to feel confident that you got the package the npm registry saw. You must verify the signature as having been made by a specific key for a specific message. This process is a little fiddly to do by hand, but I’ll step you through how, so you can do it without relying on third parties or the npm cli if you need to. This example assumes you’ve installed Keybase, but you can also use The GNU Privacy Guard.
Suppose I want to check the signature on version 1.4.3 of light-cycle. First, I fetch the signature for the version I’m interested in and save it in a file:
$ http GET https://registry.npmjs.org/light-cycle | json "versions['1.4.3'].dist.npm-signature" > sig-to-check
Next, I get the integrity field for that version:
$ http GET https://registry.npmjs.org/light-cycle | json "versions['1.4.3'].dist.integrity"
sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ==
You can verify that this integrity field matches the tarball you have by calculating the hash yourself. npm uses the ssri module to calculate integrity fields, and it verifies that the hashes match when it adds a tarball to your local cache.
Now that I have an integrity string for my package, I construct the string that ties the two together: package@version:integrity. This is the message I pass to keybase to verify:
$ keybase pgp verify --signed-by npmregistry -d sig-to-check -m '[email protected]:sha512-sFcuivsDZ99fY0TbvuRC6CDXB8r/ylafjJAMnbSF0y4EMM1/1DtQo40G2WKz1rBbyiz4SLAc3Wa6yZyC4XSGOQ=='
▶ INFO Identifying npmregistry
✔ <tracked> public key fingerprint: 0963 1802 8A2B 58C8 4929 D8E1 3D4D 5B12 0276 566A
You last followed npmregistry on 2018-04-10 21:21:57 PDT
✔ <tracked> admin of DNS zone npmjs.com: found TXT entry keybase-site-verification=iK3pjpRBkv-CIJ4PHtWL4TTcFXMpPiwPynatKl3oWO4
✔ <tracked> "npmjs" on twitter: https://twitter.com/npmjs/status/981288548845240320 [cached 2018-04-12 13:18:31 PDT; but got a retryable error (API network error: Get https://twitter.com/npmjs/status/981288548845240320: net/http: request canceled (Client.Timeout exceeded while awaiting headers) (code=170)) this time around]
✔ <tracked> admin of DNS zone npmjs.org: found TXT entry keybase-site-verification=Ls8jN55i6KesjiX91Ck79bUZ17eA-iohmw2jJFM16xc
Signature verified. Signed by npmregistry 7 minutes ago (2018-04-13 15:00:37 -0700 PDT).
PGP Fingerprint: 096318028a2b58c84929d8e13d4d5b120276566a.
It’s obviously inconvenient to verify by hand, and we plan to offer you easier ways to check version signatures soon. Note that it’s expensive to verify signatures fully with Keybase, since proofs are rechecked and this requires network activity. This is not intended to be an action you take many thousands of times per second. It would be appropriate action to take when you choose to verify a deploy artifact, however, or when a package is stored in your cache in the first place.
You’ll notice that the signatures are only available on newly-published package-versions. We’ll backfill signatures for all packages published earlier than our signing launch, but we’ll do this slowly, so as not to destroy everyone’s registry caches all at once.
We also intend to follow up with verification built into the official npm CLI, so you can check more conveniently.
Finally, we’d like to take the next step and allow package authors to sign integrity fields as part of publication, so you can have a way to verify that the npm registry itself hasn’t meddled with package contents. (I believe we’re a trustworthy steward of your JavaScript code, but I’d like to be able to prove that to you.)
Our public key follows. You can also fetch it from Keybase:
http GET https://keybase.io/npmregistry/pgp_keys.asc-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Keybase Go 1.0.47 (darwin)
Comment: https://keybase.io/download
xsFNBFrD+I4BEAClMVISYE30bHfb9hr6odnBu+GLP5TktnkNqx9sfdRH6JkiDNUv
9QwChC4IerLtNRAsXymq+mGe+kgUweYvQhNi5DkiEWfMHMSSUCArmNl+UMLkMDaW
Wtl8RWFxgDNsqtuWXy/Q/13b36RcaKXJ1bSQbOWW5EuFlm0La7P5Lc/QIk7bdKDR
IMNzQUAO4xNABp78fd5jXGa//D/FscpuBJ7u0b0SLiL+DoiEu4uXriKo3GOh4u3z
7Slfsw7Q7tCnE7PoCQspZG8WkfgLWxwoL6DhFVKOydFSXCNB+FXQCbrXuh/1njoN
Nusa/alYEk3WP9C+gFEtU+yR0rLSp84Qt7l+9peMG34711HZ6oPPNBtHephuq8ob
Kx8wkkWd4XIFAfHoy3FtriWNWY0WgTOn99Di2QZAcHhn40m0Vo4ZajwssOPch//U
KUlws66VSg2YGWmUL5k+o/S34a6QRAq0dQ1JMpcq4cpzHQFF7BI9xcjfmyIGmuu5
8zze6r8nOp/G/agX4ZP/4VprSPpMkFlrb/JXMB6G+4RHMJzabBlVtKvmkdtF+zf0
90xJXYXo2KkmDBlEMkcdFBn+de7EZKsZut85E923PX+sAIJuOeIWiuzUU0lYY9Cz
Xi3GghntBhI9yIIeINvDFV+DDfHd9pN1abEZ2vFqMrKM6rjd8kvfoCBSoQARAQAB
zSFucG0gcmVnaXN0cnkgPHNlY3VyaXR5QG5wbWpzLmNvbT7CwXgEEwEIACwFAlrD
+I4JED1NWxICdlZqAhsDBQkeEzgAAhkBBAsHCQMFFQgKAgMEFgABAgAAOXcQAEz/
7lxpMfto1FZ40xvkoAMaU4PndaDTqZNd+11yRHovjrMTvgsgFJq7mkvnJNsvmlvq
+pJJxHM4wW298poUsVwpUZVgvH56aocnS/8LZ9nFOO2AbYrWNYh9aADraBrdFL7l
+XEVz6PgXMB4GWR6A2uypQGtm+eyyeFPvUIz+GX8KkQeu/o1J8yDZUJvxKUARfgG
ADxzBb/MX0oWREGS7SJrvHnlCL+447PfR8x7aXXA0Yk2/CVsyGck7apO4p8y7LcJ
2TSN6bONiOxgY1SQjZsV2RadawcbVmC+goGnYU28F0jkkfnc8x522ducfTD8x8Yd
zXE7E/4lv1Nfu1Ybiye9aV0biK7XU2PmmKWWJYrLHZ5CqYiw/IDhPAM3aPaxFQ9l
6ee5628PGIWGq9FCdvaMsHRnG62yAXHtFrSQjcJzqi/+k4LDfDXp9s10MvJtY34l
UQ0hEYlLVKmgXRNTh9JBd7QtC754NlgF6HQxxoAiuJ+TlVxw5DQHEeSCVNWQ+WAB
K9zZvOnisbgo2JHqJk5OcVV6A9ii2oGWHOFwV0HXpbHem0GojqW5y3juWRRBfGxh
gMld3PaqL3ZOiQDyVKbdkIgaxQC8g0h+vq9VCzcd7IWy8zS96BkCZlijMGBT6+nT
UViyzasIGSFHP2MxspTgzs7MdhHVUASMMSsULaUVzRxucG0gcmVnaXN0cnkgPG9w
c0BucG1qcy5jb20+wsF1BBMBCAApBQJaw/iOCRA9TVsSAnZWagIbAwUJHhM4AAQL
BwkDBRUICgIDBBYAAQIAAHqzEACi58hDjJO83DvoUt3o/o2OINQVedAjrA4HU/JK
hzwq93ENdkaXTEv8c/SliMdjpA6qcyZn8R/HfrC2KX9RShqJj7vq9gy0uILdfAov
VjoZ/fY4oZL4Pu3ix9zWL3QGXyOIq9SiylSqwEyTUCE72mGCEK4nSNBv3r4Lpbir
eGmc2ak7PJsYURRFRwfZ7z4Aun3anY6s6pZnVJ9l/T08f+obZdiMhMlOOevYonT1
qABO+Fz+YfKarM/ya4mQcEKeafi/epNHiicaqzJC9xNd07NTSI8jzkVIS5KBbDGR
kN5Vc5VQqWZpHJngMD3uQn0ZqSoSpyGMTYNf8N00SCPkt9r2aM78G4Gsanq+rfwZ
ZsrViCHFCYqy3kUXxaiFI3zp2BjacbukncN2r3+IBIWgwKVUvQCk3ubTwbQML/nr
HnQD9q+vRUeYbMjG0OcE9G25J5AuXQI5gCN5q1hRGodtZ/23ZHyfbspelgpkTm40
+VxzgmN8DSAR4hxOCFj4+zYRPwFK5//u6HmDGB5dBf0eiwBT9PiWZ2pqiInvNPYc
hJqoS4afY35OMoEQvmcwLruX5Ds6qzNlP2yDkGxLde6Q5Fi4iqxAcOsJNgyNKwzN
+MBjUn2JnOb8kwgLONEWvUa6dIJktBGxdv5t1CyKNJZdPJMd9c/enYfaVk27rezg
pOAvrc7BTQRaw/iOARAAn4CznU636lxDzTsDe6DJQRQiGGrHExD0y1DgGH0xinVJ
jMxrSMZfDuTaURp2/EmKEM0gedA7N8fBm+XloNYlj22rTF9WoHJ88HyrfkGMZUE1
bNWn4zvL7gu4UMl51lrOqJys+ftE/DganaK4XEpL+ZsxfwfQn729/+Fer4qEhrdu
RSTI9q0TG5xJekjy714bledoni91USgFUbN+2CwC8O2eLJCx1ieCU3KWWMDwX48J
jlvklIjwF3h+YV7zUafEC3310p/CYcynWZAMDKXVsRTBcY4Gkm8+iF1npwII8epB
ILa5OPCym6vBMZyx8IyWGiYlqOjQXhIXf84wOjXO+82G+ve7eNUd6RE1FrNAEruD
fwtQ1KZE05zLN7TyN2REXdt5Q88AK1oLLmIL3zNyZcN5o0R061tkYStHlFSP8gLf
SbU/kTHRF1bqR8v+1dT/3FEo0GAUUqkIcgkYCEcLZ1wQyZ7HteH02aIrncUusQHJ
OVN+w9oI/zLuKN34RHQp94nVu46sj1vcQv2K3jfQzWrVY533ITqFqe4OH0/8KQHl
s9+sZMIcYZmkA3Vb+M2cu2hl8lN5hgUBoPAPnCBloG5OfeYM7PnNtvINRoUDuazm
3stK1xDX4ZSjFp3inrsXB3U5Yj9sLZaz39usa4YS5LpehAsGTR1vTO5kb1NlR8MA
EQEAAcLBdQQYAQgAKQUCWsP4jgkQPU1bEgJ2VmoCGwwFCR4TOAAECwcJAwUVCAoC
AwQWAAECAABk8RAAansHqbGUvT12DS3Z2e8O91sBGDzpMLRllBZIHDQFazNWUJl4
c4lFPBkMxuSMb0lV67RFmRYh4gmxRysdWp00xM0CO+AjWcfx83pCcwsErh+9BjQv
JCF1TymDS5YOspYeOi1Vv5KWXyC6OCFj+cbwLwiO/l7K8TjQ22prdrJuWw+3bP5b
X9oG6/mDow+FFMSf6ju02JhiRt63oIBYoFPoGmK6W+gF4/3Knu8dYynS/EBAqFVR
DcyQIB73W67yE7DoaP8BecPsiCvXGLes7JFauBiH2uOmdi828g+LgF8rl+DSKM2f
pOtDGB1hos7Jgd54d0TXP050NvKyqoAIxee3kl7cQuaSwTa2AkWLwfzUsF4NBRI+
D51xQZwOSEKGHHJ9DGSHaqqzyHIBVPzdrIYJ5nFnnGOVSokT2Jm9R0kdzTt6ym5C
8HCVkxbLBSZl+Dv7ZY+Wxkk/5uFecOZ72SoYzwjup/yiT/O0WTVwbALrgyZMGN4N
PbfsU8pKk4tk0vJWTv33/qhONX0/drp3va+C9h1cNyeuJGd7GeD6UacwvCdIlklW
C6fekfVCNOxZFjoCr4HCv20QbC2gdG20XULhBVf0OlMr2KqZW2rpyR3gqCjo1K57
5x7slApOCUi6+BQnNnnY8YZlUqWGA52GilpQnnB4gM+9xuIpxhL7QfCKHr4=
=39YB
-----END PGP PUBLIC KEY BLOCK-----
Today, we’re excited to announce that npm, Inc. has acquired the team and assets of ^Lift Security, including their work on the Node Security Platform. Adam Baldwin and his team have joined npm to work full time on keeping the npm Registry and npm applications safe, and to develop new products to help developers and their companies securely develop JavaScript.
^Lift Security has been working with npm longer than npm, Inc. has been a company. They review npm’s own code to ensure it’s safe before we take it live, and conduct periodic security audits, including penetration tests of our services. Most prominently, their Node Security Platform has become a definitive catalogue of JavaScript vulnerabilities for developers and security vendors.
npm is where the Node Security Platform belongs. All NSP users are npm users, and the security of open source code is core to npm’s mission. By combining our resources, we can deliver a continuous approach to security at scale, empowering millions of developers to build more secure code.
As one team, we’ll continue keeping the Registry safe, and develop new ways to help individuals and companies understand and trust the JavaScript code that they write and share.
Today’s announcement is the first in a series of strategic security initiatives we’ll be announcing in coming weeks. In conjunction with the next version of npm, shipping with Node.js version 10, we’ll introduce a series of new security features available to every npm user, directly integrated into the npmjs.com registry and the npm command line tool. Soon, we’ll also introduce a series of security products specifically tailored to the unique requirements of corporate developers and enterprises.
Security is the responsibility of every part of an organization. It needs to be intermixed with engineering, operations, and application development. npm is at the center of these workflows, so we are uniquely positioned to help you secure your code.
We know that the safety of the code you use is important to you, whether you’re a beginner or a seasoned expert. Together, we’ll ensure that the world’s largest community of software developers is also its safest.
Over the coming months, we’ll be diving more deeply into the results of this winter’s JavaScript Ecosystem Survey, a survey of over 16,000 developers conducted by npm in collaboration with the Node.JS Foundation and the JS Foundation. Our first topic is Security — and, more specifically, how developers perceive the safety of the code they write and the open source code they use. To read more about the methodology behind this survey, click here.
Taking security seriously is a habit that professional software developers acquire as they grow more experienced. Developers trust the security of open source code more than they trust the code they write themselves to be secure, but the tools for ensuring the safety and quality of code leave much to be desired.
These are some of the conclusions of a survey of over 16,000 developers run by npm in collaboration with the Node.js Foundation and the JS Foundation. We asked a lot of questions (thank you to everyone who answered all 54!) and got an enormous amount of amazing insight out of this data.
Are we satisfied with our security?
97% of respondents use open source code, so one of our first questions was: Are you concerned with whether the open source code you use is secure? Obviously we knew some people were, but it turns out 77% of respondents are concerned. The remaining 23% are presumably very trusting types.
Obviously, merely being concerned with whether it’s secure doesn’t mean you think open source code isn’t secure; it just means you want to know. So we also asked people whether they were satisfied with the methods available to them to evaluate the safety and quality of their open source code. The results were not great news:
Overall, 52% of respondents aren’t satisfied with the tools they’ve got to evaluate open source code’s security and quality. Interestingly, this number is lower but not zero among the people who say they aren’t concerned about the security of their open source code. Since the “unconcerned about security” group is 23% of all respondents, that means that 7% of the JavaScript community think the tools for evaluating open-source security aren’t good enough, but they’re still not concerned about security. We’ve labelled them internally as the DGAF group, which I’m assured means “optimistic”.
More than half of JavaScript developers think that the tools they’ve got for evaluating the security and quality of open source code aren’t good enough. That’s alarming! But we found something interesting when we asked them the same pair of questions, but this time about their own code, then compared the two sets of answers.
87% of respondents said they were concerned with the security of the code they wrote themselves, compared to only 77% saying the same about open source. A healthy majority are concerned about security in both cases, but this discrepancy suggests that JavaScript developers trust open source code to be secure more than they trust themselves to write secure code. If that’s what you believe, then that’s a strong driver to adopt open source code in the first place.
We also asked developers about the methods they had to evaluate the security of code. In both cases, majorities were not satisfied with the security options available to them, but again, the concern was greater about their own code than open source code. Developers seem to believe that open source code, while not perfect, is more likely to be secure than code they wrote, and that the tools for making sure it’s secure are better.
Attitudes to security change with experience
Another interesting effect we noticed in asking JavaScript developers about security is that developers seem to become more concerned about security the more experienced and sophisticated they become.
The first sign of this was when we split our users up by how long they’d been using JavaScript, in groups ranging from less than one year (6% of respondents) to more than ten years (19%). The result was a remarkably steady progression:
81% of respondents with 10+ years of experience said they were concerned about the security of the open source code they use, compared to only 72% of the newest group.
Given that the longer you use JavaScript, the more concerned about the security of it you become, it’s worth asking whether that pushes people away from the language over time. But there’s no evidence of this. We asked developers whether, over the next 12 months, they intended to use JavaScript more, less, or about the same amount. 95% of respondents said more or about the same, and that percentage didn’t change at all across groups divided by experience.
What seems to be driving an increase in consciousness of security is just a general increase in thoroughness and professionalism as a developer gains experience. We asked developers a range of questions about tools and practices, and there was a clear pattern when we again divided them into groups by experience:
Comparing the most experienced group to the last experienced group again, the most experienced group was:
In all the questions, the percentages grew as we moved from groups with less to more experience. These things appear to be best practices, adopted by strong majorities in most cases.
In particular, the last 3 practices all have to do with security. Combining the answers, we were able to measure how many people use some form of security analysis on their open source code (the answers for their own code followed a similar pattern). A strong majority did in both the least-experienced and most-experienced groups, but in the most experienced group it was a whopping 85%.
Conclusions
All this data drives some pretty clear conclusions:
npm has been putting more resources into improving security recently. In October we introduced two-factor authentication for npm accounts. In March, more than 8 billion package downloads — 43% of all package downloads that month — were of packages belonging to accounts protected by two-factor authentication. That’s a huge step forward in ensuring the code in the registry is safe and secure, but there is a lot more to do. Stay tuned.
Last week, the npmjs.com website received the most ambitious update in its history. We said “cheerio” to the old hapi-and jQuery-based website, and “hello” to a state-of-the-art web application based on Spife and React.
We decided to replace the old npmjs.com website in late 2016 when it had grown harder and harder to develop and release new features.
We had found ourselves outgrowing jQuery’s abilities for creating rich interfaces. We love the minimal investment and fuss jQuery demands. It was added to npmjs.com early on and has long stood the test of time. However, once we started experimenting with React, it was immediately clear that we wanted to work with it more.
We think React has much in common with jQuery:
We had commenced work on our old website around the time that hapi helped power Walmart through Black Friday in 2014. This had been an eye-catching achievement. Black Friday is the most challenging time of the year for an e-commerce website, and Walmart’s experiences were a strong endorsement of the new framework.
Over time, however, the npmjs.com site became technically isolated from the rest of the company. In its latter days, the site became our only codebase based on hapi. Experience and knowledge of working on the website gradually became concentrated in one or two developers, which placed increased pressure and responsibility on fewer people. The bus factor was too great.
We felt that a blank-slate reboot using a different platform was too good to resist. It was time for change.
With the spur of developer isolation, our first action was to hire more front-end developers. Alex Early and I were brought aboard to share our experience making websites with React. This provided two immediate improvements.
The first benefit was a much-needed backup for our website’s developers. Working on your own can be a dispiriting experience, and a stressful one. Sharing the pressure as a team gives the affected people a welcome respite.
The second advantage was that we now had a vocal group of developers to cheerlead for web standards, user experience, accessibility, and design. After all, npm has grown beyond being Node’s package manager. In a recent survey, we discovered that 80% of our users now use npm for front-end software development, just one portent of how the nature of software development is changing.
New tools such as Yarn and webpack have launched with features targeted at developers building web applications. Slack is using a web application with a rich developer API to help developers collaborate.
Work began on the new site in the spring of 2017. We knew that we wanted to use React, but the rest of the technology puzzle was unclear.
The first thing we wanted to change was to replace hapi as our platform choice. We needed a common thread linking the website with the rest of the npm Registry and to break down barriers that isolated developers to just one project. That common thread is called Spife.
Spife is a batteries-included HTTP framework. It’s similar to hapi and Express in that it’s a framework for serving HTTP requests, but it comes built in with all the features we needed for building the back-end of the new website. We created Spife in 2015 as an alternative to bolting together Restify and Knex each time we built a new service. It’s been quietly powering the Registry for three years!
Using Spife allowed us to use our own router for configuring services, our own logging standards to plug into our monitoring systems, and our own ORM layer to work with our existing databases. In effect, we created a framework tailored exactly for our own needs.
The foundation of the website is now built from the same building blocks as the rest of the npm Registry. This meant we could call on all the developers in the npm services team to help us plug the website in to the rest of the registry. Also, by finding more applications for Spife and the newly released npm@5, our website developers were able to find and report bugs, which made npm a little bit more reliable for everyone!
(We’ll be publishing an in-depth article on Spife in the near future. Stay tuned!)
There’s no denying it: modern front-end development is hard. Really hard. To address this complexity, we created a design system of React components with which to assemble our user interfaces. Components are styled using CSS Modules and Tachyons, and encapsulate their inner workings. Placing strong wrappers around each component means these can be used interchangeably, and we can customize our pages like flat pack furniture.
By assembling forms from larger components, we can ensure that all of our forms have web-standards built in. All of the form components in our design system have labels linked to the form fields so that their names are read out to users using screen readers.
Using components makes web standards easier to use, while providing a soft boundary that makes it safe for developers to learn about such implementation details later on. Components also gently guide developers into appropriately using native browser elements like buttons and links, so that the site can be used by keyboards and assistive technologies.
We also have two components, <Form> and <Link>, for progressively enhancing native browser behavior. These build in the native browser form and hyperlink elements so that the site is resilient when JavaScript is not available. When it is available, the <Form> and <Link> components use JavaScript to send JSON data between the front-end and back-end, instead of fully-rendered HTML pages. This allows us to use fewer AWS hosts to run the website while pages are loaded and ready to use up to a second quicker than before.
Here are some unscientific benchmarks:
The new npmjs.com site is available today—give it a whirl! There’s also a lot more we’re planning to do with it. A rich React user interface allows us to create better user interfaces and a more friendly user experience.
For the first time, we’ve been able to add a wizard-style control panel for setting up two-factor authentication on your npm account. The control panel walks users through each step of the process, offering a friendly alternative to setting it up using npm’s command-line tool. It’s a tiny glimpse of the quality of features we’ll be developing in the future.
We’ve also overhauled the design of the package page by giving in-depth features such as the list of a package’s versions their own tab. Download activity from the last seven days is also neatly summarised in the downloads chart.
We’re thrilled with the end result. The npm website uses cutting-edge technology, maintains accessibility for assistive technologies, is fully responsive on desktop and mobile devices, and paves the path for a first-class user experience in the future.
We really hope you love it too. Please do reach out to us with your feedback, or if you need any help—and stay tuned, as we roll out more new features faster than ever before.
This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.
Q. Hi! Can you state your name, what you do, and/or what your company does?
A. Hi, my name is James Kim. I am the JavaScript Engineer at SendBird, the chat solution for enterprise mobile and web services, apps, and games. I own and manage the SendBird JavaScript SDK and create our sample Javascript projects with it.
How’s your day going?
My day is going excellent! At the moment, we are hard at work adding new features and making improvements to our current product.
Recently, we’ve added a new feature, the “public group channel.” It allows users to browse and join channels that interest them and become members of them. It’s a mash-up between a private group chat and an open channel — the large scale of an open channel with the moderation, permissions, and members feature of a smaller group chat.
We’re also working to support TypeScript. Since JavaScript doesn’t have an explicit type, some developers using SendBird’s JavaScript SDK may pass the wrong type. But if they use TypeScript, they can validate type at the coding stage. This is a particularly excellent way to reduce mistakes and a good way for developers and cut down on debugging time.
Tell me the story of npm at your company. What specific problem did you have that npm solved?
Sendbird.com and Dashboard are typically our first interactions with many customers and they are critical to our success. Our website, Dashboard, and all of the webpages we offer need to use various libraries and npm allows us to easily manage those libraries. npm is a necessary and important tool to manage our libraries and save time.
npm helps us to educate our global customers about how to comfortably use our JavaScript SDK. And as we upload our JavaScript SDK to npm, engineers from around the world can access our product. npm serves as one nexus connecting SendBird to our customers.
To people who are unsure what they could use npm for - how would you explain the use case?
As you build your service, you will need to use a variety of libraries. With npm, you need not download all of the libraries and include them in a specific project folder. You can do everything from one place, whether you’re downloading libraries to managing versions. So you shouldn’t hesitate to use npm.
For these reasons, I am sure that npm is the best way to provide you and your company with an awesome library that can be easily and comfortably accessible for anyone in the world.
How’s the day to day experience of using npm?
On a day-to-day basis there’s sometimes stress around the dirty work of releasing a new version of our product. But with npm, there isn’t any extra work when you release a new version and, honestly, that’s one of its tremendous advantages. npm is the simplest way to deliver the latest version of our library with our newest features to a wide variety of customers around the world.
Would you recommend that another org or company use npm and why?
Yes, of course! If you use JavaScript in any capacity to build a website or you are using React native to create a mobile version of your site, then you’ll run into some difficulties if you’re not using npm.
Let’s say you’re using some service other than npm and you’re looking for each library on your own. Your valiant, though ill-fated, effort will (sorry to say) be a huge waste of your time. With npm alone, you can manage all of your versions and set up libraries with ease. If you deal in anything related to JavaScript, I strongly encourage you to use npm.
Any cool npm stuff your company has done publicly that you’d like to promote?
Anything cool? Of course! SendBird’s JavaScript SDK, which we released on npm, is pretty darn cool and it’s one of our company’s core products. By using our JavaScript SDK, you can add chat or messaging to any web or mobile application you would like. Thousands of customers have used our JavaScript SDK to add chat to their mobile and web application.
As far as I know, we’re the only chat and messaging SDK that supports React native. Many of those web and mobile customers used npm to download our JavaScript SDK and build great conversational products.
We continue to improve and add new features, so be on the lookout for SendBird. If you need to add chat or messaging to your service and haven’t used SendBird’s JavaScript SDK yet, I would recommend testing SendBird out through npm.
Coming to you this week are a fancy new package view, pack/publish previews and a handful of bug fixes! Let’s get right in!
There’s a new npm view in town. You might it as npm info or npm show. The new output gives you a nicely summarized view that for most packages fits on one screen. If you ask it for --json you’ll still get the same results, so your scripts should still work fine.
143cdbf13 #19910 Add humanized default view. (@zkat)ca84be91c #19910 [email protected] (@zkat)9a5807c4f #19910 [email protected] (@zkat)23b4a4fac #19910 [email protected]The npm pack and npm publish commands print out a summary of the files included in the package. They also both now take the --dry-run flag, so you can double check your .npmignore settings before doing a publish.
116e9d827 #19908 Add package previews to pack and publish. Also add –dry-run and –json flags. (@zkat)If you resolve a package-lock.json merge conflict with npm install we now suggest you setup a merge driver to handle these automatically for you. If you’re reading this and you’d like to set it up now, run:
npx npm-merge-driver install -g
a05e27b71 Going forward, record requested ranges not versions in the package-lock. (@iarna)f721eec59 Add 10 to Node.js supported version list. It’s not out yet, but soon my pretties… (@iarna)40aabb94e [email protected]: Fix bugs on docker and with some prepare scripts and npm ci. Fix a bug where script hooks wouldn’t be called with npm ci. Fix a bug where npm ci and --prefix weren’t compatible. (@isaacseymour) (@umarov) (@mikeshirov) (@billjanitsch)a85372e67 [email protected]: Switch to safe-buffer and Buffer.from. (@isaacs) (@ChALkeR)588eabd23 [email protected]07f27ee89 [email protected]01e4e29bc [email protected]344ba8819 [email protected]dc6df1bc4 [email protected]97a976696 [email protected]9b629d0c6 [email protected]Hey again, everyone! While last release was focused largely around PRs from the CLI team, this release is mostly pulling in community PRs in npm itself and its dependencies! We’ve got a good chunk of wonderful contributions for y'all, and even new features and performance improvements! 🎉
We’re hoping to continue our biweekly (as in every-other-week biweekly) release schedule from now on, so you should be seeing more steady npm releases from here on out. And that’s good, ‘cause we’ve got a ton of new stuff on our roadmap for this year. Keep an eye out for exciting news. 👀
2f513fe1c #19904 Make a best-attempt at preserving line ending style when saving package.json/package-lock.json/npm-shrinkwrap.json. This goes hand-in-hand with a previous patch to preserve detected indentation style. (@tuananh)d3cfd41a2 [email protected] (@zkat)
file:-based resolved URIs in package-lock.json.ecfbb16dc #19929 Add support for the NO_COLOR standard. This gives a cross-application, consistent way of disabling ANSI color code output. Note that npm already supported this through --no-color or npm_config_color='false' configurations, so this is just another way to do it. (@chneukirchen)fc8761daf #19629 Give more detailed, contextual information when npm fails to parse package-lock.json and npm-shrinkwrap.json, instead of saying JSON parse error and leaving you out in the cold. (@JoshuaKGoldberg)1d368e1e6 #19157 Add --no-proxy config option. Previously, you needed to use the NO_PROXY environment variable to use this feature – now it’s an actual npm option. (@Saturate)f0e998daa #18426 Do environment variable replacement in config files even for config keys or fragments of keys. (@misak113)9847c82a8 #18384 Better error messaging and suggestions when users get EPERM/EACCES errors. (@chrisjpatty)b9d0c0c01 #19448 Holiday celebrations now include all JavaScripters, not just Node developers. (@isaacs)I hope y'all have been having fun with npm ci so far! Since this is the first release since that went out, we’ve had a few fixes and improvements now that folks have actually gotten their hands on it! Benchmarks have been super promising so far, and I’ve gotten messages from a lot of you saying you’ve sped up your CI work by 2-5x in some cases! Have a good example? Tell us on Twitter!
npm ci is, right now, the fastest installer you can use in CI situations, so go check it out if you haven’t already! We’ll continue doing performance improvements on it, and a lot of those will help make npm install fast as well. 🏎😎
This libcipm release includes a number of improvements:
read-package-json and separate JSON update phase from man/bin linking phase. npm ci should be noticeably faster.--only and --also options._from to directory deps (aka file:packages/my-dep).58d2aa58d #20027 Use a specific mtime when packing tarballs instead of the beginning of epoch time. This should allow npm pack to generate tarballs with identical hashes for identical contents, while fixing issues with some zip implementations that do not support pre-1980 timestamps. (@isaacs)4f319de1d Don’t fall back to couch adduser if we didn’t try couch login. (@iarna)c8230c9bb #19608 Fix issue where using the npm-bundled npx on Windows was invoking npx prefix (and downloading that package). (@laggingreflex)d70c01970 #18953 Avoid using code that depends on node@>=4 in the unsupported check, so npm can report the issue normally instead of syntax-crashing. (@deployable)4477ca2d9 [email protected]: Fixes issue preventing correct rendering of backticked strings. man pages should be rendering correctly now instead of having empty spaces wherever backticks were used. (@joshbruce)71076ebda #19950 Add a note to install –production. (@kyranet)3a33400b8 #19957 nudge around some details in ci docs (@zkat)06038246a #19893 Add a common open reason to the issue template. (@MrStonedOne)7376dd8af #19870 Fix typo in npm-config.md (@joebowbeer)5390ed4fa #19858 Fix documented default value for config save option. It was still documented as false, even though [email protected] set it to true by default. (@nalinbhardwaj)dc36d850a #19552 Rework npm update docs now that --save is on by default. (@selbekk)5ec5dffc8 #19726 Clarify that name and version fields are optional if your package is not supposed to be installable as a dependency. (@ngarnier)046500994 #19676 Fix documented cache location on Windows. (@VladRassokhin)ffa84cd0f #19475 Added example for homepage field from package.json. (@cg-cnu)de72d9a18 #19307 Document the requires field in npm help package-lock.json. (@jcrben)35c4abded #18976 Typo fix in coding style documentation. (@rinfan)0616fd22a #19216 Add edit section to description in npm-team.md. (@WispProxy)c2bbaaa58 #19194 Tiny style fix in npm.md. (@WispProxy)dcdfdcbb0 #19192 Document --development flag in npm-ls.md. (@WispProxy)d7ff07135 #18514 Make it so javascript -> JavaScript. This is important. (@masonpawsey)7a8705113 #18407 Clarify the mechanics of the file field in package.json a bit. (@bmacnaughton)b2a1cf084 #18382 Document the browser field in package.json. (@mxstbr)b8a48a959 #19907 Consolidate code for stringifying package.json and package locks. Also adds tests have been added to test that package[-lock].json files are written to disk with their original line endings. (@nwoltman)b4f707d9f #19879 Remove unused devDependency nock from .gitignore. (@watilde)8150dd5f7 #16540 Stop doing an uninstall when using make clean. (@metux)ab237a2a5 [email protected] (@zkat)f6d668941 [email protected] (@zkat)882bfbdfa [email protected] (@zkat)6ae38055b [email protected]: Support git packed refs --all mode. (@zkat)89db703ae [email protected] (@mcollina)634dfa5f4 [email protected] (@rvagg)92ad34439 [email protected] (@zkat)75279c488 [email protected] (@isaacs)228aba276 [email protected] (@iarna)006e9d272 [email protected] (@zkat)9985561e6 [email protected] (@bcomnes)1dc6b3b52 [email protected] (@isaacs)Starting today, all npm users can take advantage of a new install command called npm ci. The command offers massive improvements to both the performance and reliability of builds for continuous integration / continuous deployment processes, providing a consistent and fast experience for developers using CI/CD in their workflow.
npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.
Previously, developers who wanted to ensure that node_modules/ and package.json stayed in sync would have to archive their node_modules folder. npm ci replaces this process with a single command.
npm ci is fast—in some cases, twice as fast as using npm i, representing a significant performance improvement for all developers using continuous integration.
This added speed and reliability reduces wasted time and promotes best practices. If it’s faster and easier to run tests, developers run them more often and catch errors sooner.
npm ci promises the most benefit to large teams. Giving developers the ability to “sign off” on a package lock promotes more efficient collaboration across large teams, and the ability to install exactly what is in a lockfile has the potential to save tens if not hundreds of developer hours a month, freeing teams up to spend more time building and shipping amazing things.
npm ci also provides additional ways to improve the reliability of your application builds. As an additional installation command, npm ci can be used as a fallback installer in case npm i fails, and vice versa. This hugely reduces the likelihood of a failed installation.
npm ci is available immediately by updating to the latest build of npm: run npm install -g npm @latest. For more details on the release, check out the Changelog
We want to know how this works for you, too. Have questions? Results? Interested in sharing what you & your team have built? Drop us a line.
This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.
Q: Hi! Can you state your name, what you do, and what your company does?
A: Hello, my name is Vladimir de Turckheim and I’m the lead Node.js developer at Sqreen.
I’m a Node.js contributor and member of the Node.js security working group.
At Sqreen we develop the first security platform made for developers: a library that spots and prevents attacks in your app.
How’s your day going?
My day is going great. I’m super excited because the Node.js Security Working Group I contributed to is finally up and doing. The security group manages vulnerabilities in the Node.js ecosystem. We already had a lot of vulnerability reports!
Tell me the story of npm at your company. What specific problem did you have that npm solved?
npm is the best way to have packages delivered to JavaScript developers around the world. It is fast, reliable, and widely used, which means there is no adoption friction here. Our customers all rely on npm and delivering our Sqreen library outside of npm was not an option.
Does your company do open source? How do you negotiate what you keep private and public?
Our vision is to break the standard of cybersecurity today. Security is an obscure world that historically has always been a fan of closed source.
We want to change that. Even if our core technology isn’t (not yet) open sourced, the code of our agent is open and everyone can have a look at it. Go ahead have a look and don’t hesitate to report improvements :P
We are also often releasing smaller open source projects and have a dedicated week every two months to work on something that excites us (and that is Open Sourced).
Sqreen is also supporting my involvement in the Node Security Working Group.
To people who are unsure what they could use npm for - how would you explain the use case?
Developers are used to finding all packages they need in one place. Would you imagine being asked by your manager to add a dependency to your code from a tarball or in some other non-npm ways? npm is the best way to distribute a package in the Node.js ecosystem in a user-friendly way!
How’s it going? How’s the day to day experience of using npm?
As a package maintainer, it’s pretty smooth. I have a CI job publishing my package from my Github repository, reaching my clients is only a push and a click away.
How would you see the product improved or expanded in the future?
I would love for npm to be able to give me better statistics about who installs my modules. Also, as an npm user, I sometimes wish the search could allow me to discover new awesome packages every day.
Would you recommend that another org or company use npm and why?
If you want to do business with people building Node.js applications, npm is the only acceptable solution, if you don’t use it, you will have a hard time having your product adopted and used.