npm is introducing a new setting for access tokens to support publishing to the npm registry from CI/CD workflows.
Previously, you could create an access token with one of two settings: read-only, and publish. A publish token allows you to publish packages, like the name implies, but if you have two-factor authentication (2FA) enabled on your account, you'll be prompted for your one-time passcode.
We recommend that people set up 2FA on their account for added security, but requiring a passcode means that all publishing must be done interactively. Many people want to automate their publish step with a CI/CD workflow.
Today, we've added a third option for access tokens: automation. You can create an automation token in your access token settings page.
Using an automation token will not prompt for a one-time passcode, meaning that you can use it as a secret in your publish workflow. Now you can publish a package directly to the npm registry when you cut a release.
If you're a package maintainer, and you want to require that publishers to your package continue to use two-factor authentication and publish interactively, you can do that in the package settings. If you already required 2FA, there's no change to this behavior; automation tokens won't be accepted unless you allow them to be.
If you've been waiting to enable two-factor authentication on your npm account because it prevented you from publishing in an automated workflow, you can now set up an automation token and enable 2FA.
Temporary interaction limits give you control over who interacts with your public repositories. You can use them to force a cool-down period during heated discussions, or to prevent spam or abuse.
You can now set interaction limits for 24 hours, 3 days, 1 week, 1 month, or 6 months. This lets you control unwanted interactions on your projects.
You can set interaction limits for all public repositories in an organization, or for a single repository.
The default branch name for new repositories is now main. To set a different default:
https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults pagehttps://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges pageUsers, organizations, and enterprises that previously selected a default branch for new repositories are not impacted by this change.
Existing repositories are not impacted by this change. Later this year, you'll be able to rename the default branch for existing repositories for your user, organization, or enterprise account.
This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch. To learn more about the changes we're making, see github/renaming.