Reduce Dependabot version updates in your Python projects with the increase-if-necessary strategy

npm v9.0.0 released

October 24, 2022

The npm CLI team has been working hard over the past few months and are happy to announce the release of the next major version – v9.0.0

Installation

You can start using npm v9.0.0 today by running:

$ npm i -g npm@9

About this release

Our goal with this major release was to standardize appropriate defaults and clean up legacy configurations where possible. We believe the changes made lay the ground-work for future improvements to the default npm experience long-term. Notably, Docker users should find this release to to be beneficial as we simplifie file permissions (ref. #5703 & #5704).

Timeline to GA

Although we have published v9.0.0, we are not immediately setting this release to latest in the npm registry or considering this “Generally Available.” Our team has been coordinating with the Node.js Release WG on a phased approach to making v9 the next major version of the CLI available to the widest audience; this means ensuring v9 can be safely backported to as many Node.js LTS versions as possible. With that in mind, we’ve put together a phased roll-out plan outlined below:

Wednesday Oct. 19th
- npm@9.0.0 was released & set to the next-9 dist-tag (previously used for pre-releases)
- The CLI team will continue to cut minor & patch versions of v9.x, addressing any feedback or unexpected issues arising from the breaking changes (outlined below)
Wednesday Nov. 9th (General Availability)
- To ensure npm@9.x is considered "non-breaking" for Node.js LTS we will codify a set of exit criteria in collaboration with the Release WG
- npm@9.x will be set to the latest dist-tag (becoming the latest, maintained version of npm)
- A PR will be opened to land npm@9.x in nodejs/node's main branch (exposing experimental/nightly users to this latest version)
Wednesday Dec. 7th (~4 weeks after GA)
- A PR will be opened to backport npm@9.x in node@19
Wednesday Jan. 18th (~6 weeks after node@19 backport)
- A PR will be opened to backport npm@9.x in node@18

⚠️ Notable Breaking Changes

the compatible semver ranges of node have been updated to: ^14.17.0 || ^16.13.0 || >=18.0.0
npm will no longer attempt to modify ownership of files it creates
the presence of auth related settings that are not scoped to a specific registry found in a config file is no longer supported and will throw errors
login, adduser, and auth-type changes
- legacy auth types sso, saml & legacy have been consolidated into "legacy"
- auth-type defaults to "web"
- login and adduser are now separate commands that send different data to
  the registry.
npm pack now follows a strict order of operations when applying ignore rules. If a files array is present in the package.json, then rules in .gitignore and .npmignore files from the root will be ignored.
links generated from git urls will now use HEAD instead of master as the default ref
timing and loglevel changes
- timing has been removed as a value for --loglevel
- --timing will show timing information regardless of
  --loglevel, except when --silent
--timing file changes:
- When run with the --timing flag, npm now writes timing data to a
  file alongside the debug log data, respecting the logs-dir option and
  falling back to <CACHE>/_logs/ dir, instead of directly inside the
  cache directory.
- The timing file data is no longer newline delimited JSON, and instead
  each run will create a uniquely named <ID>-timing.json file, with the
  <ID> portion being the same as the debug log.
- Finally, the data inside the file now has three top level keys,
  metadata, timers, and unfinishedTimers instead of everything being
  a top level key.
npm now outputs some json errors on stdout. Previously npm would output all json formatted errors on stderr, making it difficult to parse as the stderr stream usually has logs already written to it.
deprecated boolean install flags in favor of --install-strategy
- deprecated --global-style, --global now sets --install-strategy=shallow
- deprecated --legacy-bundling, now sets --install-strategy=nested
npm config set will no longer accept deprecated or invalid config options
install-links config defaults to "true"
node-version config has been removed
npm-version config has been removed
npm access subcommands have been renamed
npm birthday has been removed
npm set-script has been removed
npm bin has been removed (use npx or npm exec to execute binaries)

Notable Features

a09e19d #5696 new npm config fix command (@nlf)
3445da0 npm timings are now written alongside debug log files (@lukekarrys)
6ee5b32 query: now displays queryContext in results (@nlf)
314311c #5550 separated login/adduser (@wraithgar)
de2d33f add --install-strategy=hoisted|nested|shallow (#5709) (@fritzy)

For more information about this release, check out the GitHub release notes.

See more See more

Secret scanning now stores encrypted secrets

October 24, 2022

GitHub now stores detected secrets using symmetric encryption. Storing the encrypted secret allows secret scanning to provide the best possible user experience.

Previously, we only stored the locations of the exposed secret and a hash of it. Each time we presented the secret in our user experience or API we therefore had to re-derive it from its location and hash. This meant that we could not always display a preview of a detected secret in the UI or API, preventing the user from ensuring proper revocation and remediation. Below are a few examples of when we could not previously show users the secret preview:

If a contributor leaked a secret and then rewrote their Git history
If the secret was found in a file larger than a certain size, for practical performance reasons
If the secret was detected in a file with certain text encoding that was incompatible for previewing in GitHub UI

Now, GitHub stores detected secrets separately from source code using symmetric encryption. By storing this information we can more reliably retrieve and display detected secrets with a consistent user experience even if they've been removed from version history. As a result, as a user, you'll no longer be left wondering what a previously detected secret was and whether its previous exposure represents a long-term threat.

With our users’ security always top of mind, we’re confident that the change to our secrets storage will allow our users to take the proper remediation and revocation steps they need to secure their software.

Learn more about secret scanning for GitHub Advanced Security