How to enforce install to check for minimumReleaseAge always against public registry https://registry.npmjs.org

[psulek]

We use Azure Devops on-prem private registry , have it in .npmrc file specified. In devops registry and public registry https://registry.npmjs.org is defined as upstream registry.

In pnpm-workspace.yaml we got:

 minimumReleaseAge: 1440 # 1 day

Problem is when you first install via "pnpm install" a package is cached in devops registry as upstream. But pnpm checks are made against this devops registry (which we want because there are our company private packages) but that also means it gets wrong dates for public packages from registry https://registry.npmjs.org.

I dont know to it will do it where some packages are our own private and only lives in that devops custom registry and not in public npmjs and then public packages are cached. So from where to get "source of truth" for publish date in this case?

[psulek]

Found issue on M$ dev community about this.
And closed as design by M$ :-(

[MILLERMARRU]

The publish dates pnpm checks come from the packument returned by whichever registry resolved the package. There is no setting that points the minimumReleaseAge check at a different registry than the one used for resolution, so as long as public packages resolve through your Azure DevOps feed, pnpm sees the feed's dates. And as you found, DevOps reports the time a version was ingested into the feed, not the real publish time, and Microsoft closed that as by design. The result cuts both ways: freshly proxied packages look newer than they are (cooldown blocks longer than intended), while versions cached long ago look old (cooldown silently passes even if npmjs metadata would fail it).

The setup that actually fixes it is to stop proxying the public registry and scope the private feed instead:

; .npmrc
@yourcompany:registry=https://pkgs.dev.azure.com/yourorg/_packaging/yourfeed/npm/registry/
registry=https://registry.npmjs.org/

Public packages then resolve straight from npmjs with authoritative time metadata, so the cooldown works as intended, and your internal packages keep coming from DevOps. If internal packages trip the check because of the feed dates, you can list them in minimumReleaseAgeExclude.

If the proxy has to stay for compliance or offline reasons, then the honest answer is that the cooldown cannot be trusted through DevOps today, and a feature request for a configurable time source (or a fallback to npmjs for time data) would be worth opening on the pnpm repo.