npm Blog (Archive)

The npm blog has been discontinued.

Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.

Updates to Community, Docs & more...

Happy Tuesday! Here on the Community & Open Source Team we’ve been working hard, in front of and behind the scenes, to provide real value and unlock developer potential. With that in mind, I’m happy to announce a number of updates/releases we’ve landed this morning & would like to detail.

Who We Are?

First off, you may have seen some new and old faces in the wild recently, so I thought I’d take a moment to reacquaint you with who our Community & Open Source Team is:

Open Source Product Development

As the stewards of the Open Source practice at npm we’ve begun a process to revamp how we plan, prioritize & communicate the development of tools & services supporting our community.

🧹 Clean Up

We began cleaning up our existing repositories back in August but the efforts will continue into Q4 to address licensing, docs, test coverage, archival of legacy work & more. With 285 Public, “active”, repositories, we’ve got our work ahead of us but are confident we can make contributing to any of our projects a seamless experience going forward.

⚙️ Standardization

Part of cleaning up our projects has been to standardize much our project config. We’ve taken the first steps to documenting our default labels and other config within a open-source-boilerplate-project and .github projects. The implementation of these settings is currently handled by Probot’s Settings app & GitHub’s native capabilities, respectively (both of which we’re learning to love).

🗣 Open RFC Meetings

In early September we began running a bi-weekly Open RFC call and have recently started to stream these calls on our YouTube Channel. We’ve opened a Poll to determine the best meeting days/times and hope you’ll give us your feedback on how we can continue to improve these discussions.

📅 Events Calendar

If you want to ensure you don’t miss one of the Open RFC calls, or are interested in the various meetups, conferences and events our team is attending, you can subscribe to our new Public Events Calendar.

✅ Status & Project Boards

Inspired by the work of Wes Todd on Express’ statusboard we’ve created a high-level project statusboard to keep track of the health of our various projects. This repository has doubled as our temporary, internal, issue tracker but will soon evolve into a critical tool for keeping an eye on the state of open source at npm.

As well, as of this morning, we’ve made public our GitHub Project board where you can see the status of the various initiatives we have in-progress day to day and week to week.

Image

ℹ️ Archiving npm.community

Last year we announced we were closing issues on npm/cli & pointing users to the npm community forums; While we’ve appreciated all of the support we saw with this change, the team strongly believes that we can better address feedback and interact with our users by being as close as possible to where our source code resides.

What this means?

Over the last year we’ve been humbled by the community support and want to give a huge shout out to some of our most active community members:

🎉 Supporting Open Source Maintainers

As of npm v6.13 we’ve added support for a brand new funding field in package.json along with a corresponding npm fund sub-command.

Post install you will now see output that describes the number of packages that have defined funding information. You can opt-out of this prompt by using the --no-fund flag if you so choose.

At the end of August, we made a promise to the community to invest time & effort to better support package maintainers. This work is just the first, small step toward creating a means/mechanism for a more sustainable open source development ecosystem.

A big shout-out goes to all the collaborators/contributors to this on-going work:

As noted back in August, we’d love to partner/collaborate with any interested parties that want to make a difference in this space. We’ll be looking to improve this funding experience and, overall, what we can offer the community in the months to come.

🎉 CLI Docs

As of npm v6.13 we’ve bundled a new look to the CLI docs. Running npm help <command> --viewer browser will give you an offline sneak peak at what is to come for our docs.npmjs.com site in the weeks ahead.

Image

ℹ️ npm v7 Status Update

Quite a lot of work has gone into npm v7 over the last several months, but much of it has been under the hood, refactoring components which will allow us to deliver some long-awaited features.

⏭ Faster, Better, Streamier

pacote, cacache, make-fetch-happen, ssri, and npm-registry-fetch, have all been ported to use the latest minipass streams instead of the hodge podge of core and community streaming libraries they were using before. Using a deterministic streaming library has allowed us to track down and eliminate entire classes of race conditions that arose from using a mix of Promises and async streams.

As part of this, we’ve also released minipass-fetch, which is a port of node-fetch to minipass streams.

pacote, npm’s package fetcher, has been completely rewritten from the ground up. In the process, we were able to unlock the ability to fetch the state of a package from a GitHub pull request (ie. your code reviews just got a whole lot easier 🎉).

Examples:

npm install github:username/reponame#pull/123
# or...
npx username/reponame#pull/123

cacache, npm’s content-addressable cache layer, has also gotten a major overhaul, tracking down some long-standing bugs and race conditions in the process.

ssri, cacache, npm-registry-fetch, and pacote all now have 100% test coverage, and we’re making progress on make-fetch-happen at this very moment. This work will make it easier to fix bugs and add new features with confidence in the future while the improved streaming performance will make installs that much faster.

🗂 Better package.json#files handling

Once upon a time, in the dark days before node-tar, npm’s implementation of .npmignore files was to use tar’s --exclude option. That confused people, who expected it to work like .gitignore, and so it was made that way, first with fstream-ignore.

Some time later, we decided that an include list would be better than an exclude list, and so the package.json "files" list was born. The initial implementation was to put a ! in front of all the entries in that list, and treat it like a sort of “reverse ignore” file.

That has caused a lot of problems in the intervening time. And, it’s unnecessarily slow. npm-packlist version 2 (which npm v7 will use) will treat the files list as a set of files to walk, rather than a set of reverse exclusion patterns. Unless you’re doing something very tricky with .npmignore files and package.json "files", you won’t notice a difference, and it’ll just remove a pile of weird edge cases that resulted in .DS_Store files showing up in packages.

⏱ Dropping Support for Node v6 & v8

Starting with npm v7, only Node.js versions 10 and up will be supported. Node.js v8 falls off the LTS maintenance window as of January 1st, 2020. Since npm v7 won’t be out of beta until after that window has closed, it only makes sense to move past these unmaintained releases.

This change also allows us to migrate fully to native Promises, and clear away some workarounds and hacks that were cluttering up the codebase.

🌲 The Tree Doctor

All the code in the npm CLI that deals with package trees is being refactored (and in many cases, entirely reimplemented) in a new module called arborist.

This will make it possible to easily add workspaces, properly handle peer dependencies, and behave as users expect with dependency trees created by both yarn and pnpm.

📦 Installing Peer Deps By Default

In one of our more controversial RFCs, @isaacs suggested that we start installing peer deps again. This would get rid of some error messages that persistently annoy users, especially newcomers to React and other ecosystems where peer dependencies are used heavily.

As Maël Nison and a few others have pointed out, this could be fairly disruptive, as many users have adapted to the peerDependencies “not installed by default” behavior.

npm’s current behavior, where it ignores peerDependencies entirely at tree building time, is a problem. Even if we back off from installing peer deps by default, we’ll still have to construct trees mindful of the conflicts that peer dependencies can create, and enable users to install peerDependencies with an opt-in command, so the implementation will need to be there regardless.

We expect to explore this more fully during the beta period, and either ratify npm/rfcs#43 or modify it based on what we learn.

📅 Beta Release Schedule

We hope to have arborist functionally complete in the next few weeks, with a preview of the full CLI release by the end of the year. After that, we’ll be bugging you all to try it out, with the expectation that we can promote npm v7 to latest after a few months of baking.

You’ll be the first to know when the beta launches and we hope you’ll help us vet all this hard work by trying it out and giving us your feedback as we continue to improve 🙂

Keep your eyes peeled for more updates and releases from our team in the weeks to come.