Summary

In October of 2020 the npm team launched the new public feedback process. A primary goal is to improve transparency and give our community a voice in determining the roadmap of npm. Starting in Q3 of 2020 the npm team will prioritize and ship 10 different features and bug fixes that were discussed and prioritized based on the feedback process.

Intended Outcome

• Improvements to the CLI, Registry, and Website
• The npm team builds trust in our new feedback process
• The npm team is able to show how we prioritize work in a transparent fashion

How will it work

The community will engage in our discussions forum to make requests for changes to any of the npm products.

The npm team will respond and participate in discussion to help identify solutions to the problem statements identified in the discussion. The npm team will also host bi-weekly triage meetings to discuss the discussions at length.

Items that we choose to explore will be added to the future column of the roadmap. Once the requested item has been properly scoped it will be prioritized based on available engineering resources.

Summary

Many developers store their repositories on GitHub and publish their packages to npm. At the moment, there is no connection between a developer's GitHub account and their npm account.

Intended Outcome

We'll explore the ability to authenticate to npmjs.com with your GitHub account, presumably by linking your two accounts.

Summary

Important data about a package such as the repo link + website link are not prominently featured on the website package page. Move this information to the top of the page could significantly improve discoverability

Intended Outcome

Developers visiting npmjs.com will be able to find important information quicker when visiting the landing page of a package.

How Will it Work

We will work with design to come up with a mock up and make changes to the templates for our website

Stretch Goal

There has been a request to add a GitHub icon to the npmjs.com website, if possible we should explore including this while we are doing this small design tweak

References
npm/feedback#50
npm/feedback#93

Summary

npm can mean many things: the cli, the registry, the website, and the team. There are various types of feedback that we can receive that can focus on any number or combination of meanings of “npm”. In order to ensure ongoing customer / ecosystem satisfaction we should have clear and reliable avenues to receive feedback and respond accordingly.

During the private alpha we will invite GitHub and Microsoft employees to give us feedback and dogfood the suggestions process.

Intended Outcome

• Get feedback from various GitHub and Microsoft employees
• Populate initial corpus of discussions and issues
• Identify any significant issues and fix them prior to beta preview.

How will it work?

GitHub Discussion will be utilized as a platform for receiving this feedback which will be organized on an official npm public roadmap. This process will allow us to show our existing priorities and transparency in which suggested features are selected to be worked on and why. This aligns with the overall GitHub strategy for feedback.

The npm team will aim to respond to all feedback within 7 days. All discussions should be eventually rolled up into a meta issue that will either describe the feature we will be working on or a transparent answer as to why we will not be exploring that specific feature.

Summary

Previously, when a person signs up for an account on npmjs.com they receive (at least) three emails: one welcoming them to npm, one requiring they verify their email address, and one that offers an upsell to paid npm plans and to send marketing content via email.

The welcome and email verification emails have been consolidated into a single email that serves both purposes.

The sales and marketing emails have been removed in full.

This means that users receive a single, actionable email at signup and no spam.

Summary

The dispute policy found at https://www.npmjs.com/policies/disputes has not been revisited post acquisition of npm. It would be prudent for us to review these policies and see what changes we can make that will remove ambiguity and help maintainers make informed decisions about how to handle abandoned packages.

Intended Outcome

Updated policies are fair, consistent, and enforceable.

How it will work

We should review existing policies, create a list of potential scenarios, adapt policies where they feel inadequate, and get updates vetted by appropriate GitHub teams.

Summary

Packages may have bundled TypeScript type information, and they contain .d.ts type declarations inside their package, and a types declaration in the package.json.

For packages with bundled type declarations, we will decorate the package on the website to indicate that it has TypeScript type declarations bundled.

Intended Outcome

• Users can see that packages have great TypeScript support because they have types available

@MylesBorins suggested that:

Lots of folks work with monorepos and it would be great to have more official tooling to support workflows

in #5

Summary

We encourage users to use two-factor authentication (2FA) when using the npm registry, which will help keep their accounts secure if a username and password is leaked. Two-factor authentication also applies to tokens that were generated for a user. This prevents users from being able to both have two-factor authentication enabled and use continuous integration (CI) workflows to publish packages.

We will add a new type of access token that users can create to use in CI workflows which will not require a TOTP code when publishing.

Intended Outcome

Users can use "automation tokens" to publish to the public registry from continuous integration workflows.

How will it work?

Users will be able to generate a new "automation token" on the npmjs.com website. This token will act as an authorization token for the user who generated it, but will not require two-factor authentication, regardless of the user's 2FA settings. Package maintainers can optionally allow automation tokens to publish packages so that they can be used as secrets in continuous integration workflows.

Existing access tokens will be unchanged, and will require two-factor authentication if a user has 2FA enabled.

The npm CLI will not immediately support creation of these tokens, it will continue to generate standard (2FA-enabled) tokens.

Summary

Our documentation site needs to include documentation for both the current release of the npm CLI (npm v6) as well as the next release (npm v7).

Intended Outcome

• Users can see the documentation for both releases.
• Users see the current npm v6 release documentation by default, but can view the next release documentation by selecting it.
• We will switch the default to npm v7 when we feel it has the appropriate adoption; at that time, users will still be able to select npm v6.

Summary

Currently automation tokens does not support creating new dist-tags, and as such are limited to publishing to existing tags.

Intended Outcome

• An Automation Token can be used to create a new dist-tag

Questions

Should an automation token be able to delete a dist-tag?

References

npm/feedback#108
semantic-release/npm#298 (comment)

Summary

The npm website currently only shows total download counts for a module. It would be extremely useful to show download metrics per version so developers can make informed decisions about their packages.

Intended Outcome

The landing page of a package will have a visualization of downloads with per version metrics. This could be in a table or graph. It could be per individual version or grouped by Semver-Major.

How will it work?

Our registry will collect this information and make it available via an API that the website will utilize to visualize on the package landing page.

References

This feature was originally requested in npm/feedback#60

Summary

Node.js ships with a number of builtin modules that a developer will be served when requiring or importing. If a module with the same name is installed from the registry it will generally not be served to developers, although there are some edge cases where this can happen accidentally or where it is desirable.

For this work item we will do an audit of the registry for all built-in modules and determine what steps should be taken based on each individual module.

Intended Outcome

• Developers do not have to worry about getting malicious code name squatting Node.js builtin modules
• Developers accidentally installing builtins will be clearly warned

How Will it Work

• We can obtain a list of builtins rather easily. One option is to consult the builtins module.
• For each builtin we will review what is currently published to the registry and categorize:
  • unmaintained: this module is not maintained and can be taken over (e.g. https
  • deprecated: this module has already been deprecated and no action is required (e.g. crypto
  • valid package: this package has valid use cases and no action should be taken (e.g. buffer

Summary

npm can mean many things: the cli, the registry, the website, and the team. There are various types of feedback that we can receive that can focus on any number or combination of meanings of “npm”. In order to ensure ongoing customer / ecosystem satisfaction we should have clear and reliable avenues to receive feedback and respond accordingly.

During the beta preview we will being onboarding external developers from the JavaScript community.

Intended Outcome

• The JavaScript community believes that npm and GitHub are listening
• The JavaScript community has faith in npm and GitHub as stewards of the registry
• A transparent and reliable process that gives insight into our decision making process
• Our products continue to improve and solve the problems of the JavaScript ecosystem

How will it work?

GitHub Discussion will be utilized as a platform for receiving this feedback which will be organized on an official npm public roadmap. This process will allow us to show our existing priorities and transparency in which suggested features are selected to be worked on and why. This aligns with the overall GitHub strategy for feedback.

The npm team will aim to respond to all feedback within 7 days. All discussions should be eventually rolled up into a meta issue that will either describe the feature we will be working on or a transparent answer as to why we will not be exploring that specific feature.

Summary

Previously, when you are logged in to npmjs.com and select "sign out", it appears that nothing happens. In fact, you would be signed out, but there is no visual indication of this. Instead, you will still have your avatar in the upper right hand of the site, the "sign out" option is still available, and generally, it looks like you are logged in. (Thankfully, you were not - following a link or performing an activity on the site will show that you are not signed in.)

This has been corrected, and it should be (hopefully) obvious that you are no longer signed in immediately upon selecting the "sign out" button.

Summary

npm can mean many things: the cli, the registry, the website, and the team. There are various types of feedback that we can receive that can focus on any number or combination of meanings of “npm”. In order to ensure ongoing customer / ecosystem satisfaction we should have clear and reliable avenues to receive feedback and respond accordingly.

During the beta preview we will being onboarding external developers from the JavaScript community.

Intended Outcome

• Get feedback from various JavaScript Community Members
• Gather additional Feedback
• Identify issues and fix them prior to public beta
• Adhere to our target SLA
• Develop Q2 2020 Roadmap

How will it work?

GitHub Discussion will be utilized as a platform for receiving this feedback which will be organized on an official npm public roadmap. This process will allow us to show our existing priorities and transparency in which suggested features are selected to be worked on and why. This aligns with the overall GitHub strategy for feedback.

The npm team will aim to respond to all feedback within 7 days. All discussions should be eventually rolled up into a meta issue that will either describe the feature we will be working on or a transparent answer as to why we will not be exploring that specific feature.

Summary

We initially launched support for workspaces in npm v7.0.0

While our initial implementation is a great start there is still a number of features that are needed to get workspaces in a place where they can be useful for day-to-day development of large projets.

Intended Outcome

• npm workspaces subcommand for managing workspaces
• Making various existing commands workspace aware

References

npm/rfcs#273
npm/rfcs#117

Summary

npm v7 is the next major release of the npm cli. It includes a number of improvements including:

• An improved algorithm for resolving peer-dependencies
• Workspaces
• A large refactor of internals

Intended Outcome

JavaScript Developers will be able to beta test npm v7.

How will it work?

JavaScript developers will be able to manually install the npm v7 beta with the command npm install --global npm@next-7

Summary

Packages may not have bundled TypeScript type information, but someone may have done the hard work of creating the type declarations and publishing them to Definitely Typed .

For packages with DefinitelyTyped type definitions, we will decorate the package on the website to indicate that it has TypeScript type declarations available in DefinitelyTyped, with a link to the package.

Intended Outcome

• Users get a link to the DefinitelyTyped package that provides type declarations

Summary

Users want to be able to create a package without special privileges - for example, in a CI/CD workflow - but do not want to allow that unprivileged identity to perform the final publish of the package without further intervention.

Instead, there will be a publication gate requiring some signoff from a human person before the package publication is finalized.

Intended Outcome

A user can set up a CI/CD workflow that creates a package, but the actual mechanism of its publication is still left up to a person.

How will it work?

This is a high level overview to show that there's work that we want to invest in at some point in the future. This does not constitute a final design or specification. Terms like "authorization mechanism", "upload" and "download" are intentionally vague so as to not suggest any type of implementation.

• A user will be able to create an authorization mechanism that does not have the ability to publish packages, but does have the ability to stage packages.

• This authorization mechanism can be used to upload a package. At this point, the package is not available or visible publicly on the public registry.

• A user will need to perform some manual intervention in order to make this package available publicly.

Again, this is a high-level overview. We'll start fleshing this out more in the future.

As per the README.md

Issues will be created for features and work items we are tracking on our roadmap. Issues are read-only and locked on creation. Our roadmap is heavily influenced by discussions with our community that take place in our public feedback repository.

Summary

In order to get broad adoption of npm v7 it is imperative that we ship npm v7 in Node.js 15.

Intended Outcome

JavaScript developers will be able to install Node.js 15 via the official installer or a tarball from nodejs.org and it will come bundled with npm v7

How will it work?

This is predicated on npm v7 reaching General Availability. Once we are confident in the stability of the new version of npm we will need to open an upstream PR and get approval from the Node.js project to update the version of npm they are shipping.

Summary

The npm website does not currently render READMEs with GitHub flavored Markdown. This can create an inconsistency between viewing the document on GitHub and viewing it on npmjs.com.

Intended Outcome

During publishing we would render markdown in a way that respects GitHub flavored Markdown. We may possibly want to re-render existing READMEs

How will it work?

This is a feature that should just work™️ when developers publish modules to the registry.

References

This feature was originally requested in npm/feedback#3

Summary

Automation tokens support only a subset of the registry endpoints for additional security. Unfortunately, they do not currently support the /whoami endpoint. They should support this.

Summary

npm v7 is the next major release of the npm cli. It includes a number of improvements including:

• An improved algorithm for resolving peer-dependencies
• Workspaces
• A large refactor of internals

Intended Outcome

JavaScript Developers will be able to use npm v7 in production. npm 7 will be performant, fully tested, and well documented.

How will it work?

npm v7 will work much in the same way that npm v6 works today. JavaScript developers will get it when installing Node.js or alternatively will be able to upgrade their local version using npm install --global npm

We currently operate a number of microservices and databases that make up the production infrastructure for the npm registry. We will make a number of investments in these systems to reduce the ongoing maintenance burden on the npm engineering team, and to ensure that the stability of the registry improves and we increase our availability.

Intended Outcome

• The availability of the npm registry increases
• Our engineering team does less hands-on maintenance and has fewer on-call incidents

How will it work?

We will upgrade a number of critical production systems and improve the monitoring and observability of our systems.

Summary

As a followup to #6, we will provide an option to limit the scope of automation tokens so that they can only publish specified packages.

Intended Outcome

Users can create an automation token that can publish only a single, specified package.

How will it work?

Much like an individual package can require two-factor authentication to be published, we will allow a package to allow only a limited set of automation tokens for its publication.

This allows you to create an individual automation token for an individual package. That way if an automation token is ever leaked, the potential damage is limited to a single package.

Questions

• Should this token be scoped to a single package or be able to scope to a group of packages?

Summary

Currently there is no ability to name generated tokens. Not being able to name tokens makes it harder to manage over time and audit existing tokens to ensure access is still necessary.

Intended Outcome

• Developers can name the tokens that they create on npmjs.com
• When viewing tokens developers should be able to see the names

Outstanding Question

• Should developers be able to rename tokens?

How Will it Work

TBD

Summary

We will open source docs.npmjs.com and allow community contributions.

Intended Outcome

• Users can clone the repository that contains the documentation and easily run a copy of the docs site
• Users can open issues that describe problems with the documentation
• Users can open pull requests that fix the documentation
• Pull requests will show a rendered version of the documentation