Initiative: v10.0.0

[darcyclarke]

Timeline:

• Roadmap Locked-in: July 2023
• Betas/Release Candidates: July - September 2023
• Generally Available: October 2023
• End of Life: October 2024

Note: the below items are subject to change right up until July 2023

v9

Release Target: July 2023

Tasks

Beta Give feedback

1. [epic] warn users when altering package.json during publish #672
   8 of 9
   epic +1
   

v10

Release Target: September 2023

See #487 (comment) for breaking changes list

v11 and beyond

These are still future looking breaking changes that we want to keep in consideration going forward

Breaking Changes:

Beta Give feedback

1. remove man pages
2. Remove install scripts support
3. Support for reading stdin across all commands (ie. https://github.com/npm/rfcs/blob/3d5b2130504139bdc8a3b599923aa07d2ff79c96/accepted/0000-dependency-selector-syntax.md#commands-could-read-from-stdin)
4. Support Package Distributions by default
5. Consider changing strict-ssl default based on environment variables fix: let fetch option respect NODE_TLS_REJECT_UNAUTHORIZED env as def… make-fetch-happen#257

Features (v10 or v11 or beyond):

Tasks

Beta Give feedback

1. New npm link experience
2. Add new "lifecycle events" API - differentiate between scripts & events - user/project & dependency defined usecases)
3. First-class import-maps Support
4. Warn/error on unecessary config items in publishConfig

Risks

• node 16 is Eol on Sep-2023
• we should ga npm 10 atlease a month of node 20

[ljharb]

Where can we discuss using isolated mode by default? That breaks valid use cases, and I don't think it would ever be a good default behavior.

[wraithgar]

Here is a more detailed writeup of the v10 changes. Tasklists don't allow annotations like this in sub-bullet-points so I'm putting it here.

v10 breaking changes

• Engines Settings
  • The new engines attribute for npm bill be [TBD] discussion issue
• Revisit "strip prerelease" logic from supported node version checker
  • We currently run process.version.replace(/-.*$/, '') before checking if the node version we are using is compatible with our engines entry. We should stop doing this and determine if we just drop that replace, or change our satisfies call to include prereleases. If the former it's technically a breaking change.
  • Not a breaking change
• add "obey user specifier" RFC | rfcs#547
• [FEATURE] Expand the list of default ignored files | npm-packlist#48
• Remove metrics-registry hard coded config
  • This is a custom getter we add to the config object itself, it is not flattened. npm itself does not use this but removing it is technically a breaking change.
• use @npmcli/agent
  • The existing http/s agent/proxy libs we use do not have very good timeout configurations and also diverge from the spec in odd ways. The new agent is intended to be identical to the existing way of doing things, but because of the scope of the change we are waiting on a semver major before cutting over.
• Remove unused tmp config
  • This config is already deprecated and unused within npm
• remove ci-name config
  • This config is already deprecated and will no longer be used in v10
• remove flat.hashAlgorithm from npm config (unused)
  • This is a hard coded attribute on the flatOptions passed from npm to its submodules, none of them use it anymore.
• remove implicit "if-present" logic from run-script in workspace mode
  • Currently when calling npm run-script on workspaces if any of the scripts are missing it is treated as a silently ignored error, making there an implicit "if-present" config in this mode. Users who want this behavior will need to include this config.
• remove rfc 8909 code from npa (remove strict mode environment check altogether, keep current behavior w/o strict flag)
  • Currently if users set an enviromnent variable NPM_PACKAGE_ARG_8909_STRICT to 1 npm will enter a strict mode when parsing package specs. We don't have any real plan with making that mode permanent so we are removing this functionality. Too many existing packages rely on our "fixing" behavior and it is not worth breaking so many people to force compliance. Anyone currently using this mode will need to find a third party way to strictly enforce the package specs in their package.json
• Don't retry 409 errors in libnpmpublish
  • Currently if npm gets a 409 from the registry during publish it attempts a single retry by re-fetching the manifest and attempting to apply a new patch on what's being published. This is not the safest approach, especially as the code used to patch is not the same code that is used to build the original manifest. It is much safer to simply have the user re-run the publish command.

[wraithgar]

user-agent switchover npm/make-fetch-happen#255

[wraithgar]

Most of the smaller v10 changes in the cli npm/cli#6641