Many projects using pnpm configure minimumReleaseAge to maintain dependency stability. This setting is an excellent defense mechanism that protects your project from unexpected bugs that may lurk in freshly released packages.

In our project, we had set up pnpm-workspace.yaml as follows, only allowing updates to packages that have been released for at least 24 hours (1440 minutes), ensuring stability:

minimumReleaseAge: 1440

However, recently this setting became an obstacle during an urgent security response. This article introduces how we resolved this challenge using minimumReleaseAgeExclude.

• minimumReleaseAgeExclude | Settings (pnpm-workspace.yaml) | pnpm

The Challenge Faced During an Emergency: minimumReleaseAge as a Barrier

One day, a high-severity vulnerability was discovered in a major library we were using in our project (React, for example), requiring an immediate security update. Although a new version containing the security patch had already been released, running pnpm update wouldn’t install the patch version that hadn’t yet been released for 24 hours due to the minimumReleaseAge setting.

We considered temporarily commenting out minimumReleaseAge in pnpm-workspace.yaml or changing the value to 0. However, this approach carried the risk of human error in forgetting to restore the setting afterward, and there was also the possibility that other packages might get updated to their latest versions during the process.

The Savior: minimumReleaseAgeExclude

This is where pnpm’s minimumReleaseAgeExclude setting came to the rescue. This setting allows you to exclude specific packages from the minimumReleaseAge restriction.

We solved the problem by specifying the packages that needed security updates in minimumReleaseAgeExclude.

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
  - react
  - react-dom
  - '@types/react'
  - '@types/react-dom'

With this configuration change, react, react-dom, and their related type definition packages were no longer subject to the minimumReleaseAge restriction, allowing us to immediately install the latest patch versions right after release. Meanwhile, other packages continued to have the 24-hour waiting period applied, enabling us to respond quickly and precisely where needed without compromising the overall stability of the project.

Example: fix: upgrade React and react-email to resolve CVE-2025-55182 · Pull Request #2357 · giselles-ai/giselle · GitHub

After the Response: Resetting minimumReleaseAgeExclude for Normal Operations

Once the security update was successfully completed, we restored the minimumReleaseAgeExclude setting. It’s a good practice to reset the configuration to empty and leave a comment for your future self and other team members.

minimumReleaseAge: 1440
# Use minimumReleaseAgeExclude temporarily for emergency security vulnerability fixes
minimumReleaseAgeExclude: []

By making it clear that this is a temporary measure, the configuration file becomes more readable and maintainable.

Example: Remove temporary minimumReleaseAgeExclude entries · Pull Request #2371 · giselles-ai/giselle · GitHub

Conclusion

pnpm’s minimumReleaseAge is a highly effective setting for stable project operation, but flexible responses are necessary in situations that demand speed, such as emergency security responses.

By utilizing minimumReleaseAgeExclude, you can quickly update only specific packages without compromising your usual operational policy of maintaining stability. Please keep this in mind as a powerful tool for achieving both stable operation and emergency response.

That’s all from the Gemba on using pnpm’s minimumReleaseAge and minimumReleaseAgeExclude for security updates.