1. Home
  2. Categories
  3. Support
  4. NPM Incorrect Handling of min-release-age

Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

NPM Incorrect Handling of min-release-age

  • A

    Hi,

    There appears to be some disparity between the npm min-release-age and the ProGet Recently published rule on the feed.

    Setup

    ProGet 2025.25 (Build 11)

    .npmrc:

    registry=https://my-proget-server/npm/npm-public/
min-release-age=7

    ProGet Use Connector Publish Date enabled.
    35af2849-f0b3-421b-8b64-bb2ffdfaaaeb-image.png

    ProGet npm feed has Recently published (7 days).
    e14efc66-c8fb-4588-ae79-86bfc3127199-image.png

    Install

    Run npm install for the latest applicable version of @hono/node-server

    > npm i @hono/node-server@latest
npm error code E400
npm error 400 Bad Request - GET https://my-proget-server/npm/npm-public/%40hono/node-server/-/node-server-1.19.14.tgz - Package is Recently Published

    In Proget @hono/node-server-1.19.14 has a publish date of the 2026-04-13 02:20:00:
    c4272b8d-ff08-4166-be0e-db40c9cf7b81-image.png

    I ran the npm install on 2026-04-20 15:12 BST, minus 7 days is 2026-04-13 15:12 BST. That's greater than the ProGet npm package date of 2026-04-13 02:20:00.

    If I change my npm config to have min-release-age=8, then the install works fine. Is this some issue with timezones?

    Thanks!

    0
  • atripp
    inedo-engineer

    Hi @ashleycanham ,

    The min-release-age setting in npm and ProGet's "Recently published" are unrelated. One controls how the client (npm) behaves, the other controls how the server (ProGet) behaves.

    I'm not an expert on min-release-age on the client (npm) side, but I believe it changes the way the dependency resolution algorithm works. In turn, that means npm will request different packages from the server. That's why changing that value will yield different server results.

    On the server (ProGet) side, ProGet effectively blocks package downloads by looking at the publish date (which you can see on the history page, and even set/change on the Set Package Status Page) against the current server date time. This is obviously indicated by "Download Blocked" in your screenshot, but more precisely it has to do with "package compliance".

    There's a lot involved with that, but if you Reanalyze the Package, you can get detailed logs of what's making the package Noncompliant. Specifically, in those logs, you should see something like this:

    Policy "{policy.Name}" considers recently published ({recentlyPublishedDays} days) {rule}
Publish date of {package.Published.Value.Date:d} is considered recently published.

    That date will be UTC-based (the UI typically displays local time, i.e. BST), but you'll get an idea of how it works.

    Anyway, that's where I would start. Considering timezones, rounding, or partial days, you may find it simply easiest to set min-release-age=8 so that npm isn't requesting a package that's 6.99999 days old, or something weird like that.

    One last thing worth mentioning, we are no longer recommending blocking noncomplaint packages in most cases. Instead, using pgutil builds scan can be used to "Break builds" and give a much clearer output, so that developers don't have to chase down npm error logs.

    Thanks,
    Alana

    0
  • A

    Hi @atripp,

    I understand that min-release-age and the Recently Published rule refer to two different products, but that version of the package at that time should have been compliant in ProGet, but it wasn't. NPM correctly resolved the right version of the package.

    This is obviously quite hard to re-test with the Reanalyze logs because you need a package that's just over the Recently published rule. I don't see a way in the ProGet UI of updating the published date so that I can test it?

    We want to block packages from being installed on developer machines in addition to CI pipelines without additional tooling requirements.

    Thanks,
    Ashley

    0 atripp 1 Reply
  • atripp
    inedo-engineer

    Hi @Ashley ,

    To set override the publish date, first Pull the package to ProGet so that it's no longer a cached package. Once you do that, you will see a "Set Package Status" option (you may need to refresh page). On that modal dialog, select "Override Metadata..." and enter the date.

    3f6d8fe1-e54f-495e-be09-f9d55ed1dc4e-image.png

    That's what we do to test these rules; note you can delete the package and re-download it to cache it again.

    Let me know if you spot anything off, it seemed to work for me, but I might be looking at the wrong things.

    Thanks,
    Alana

    0
  • A

    Hi @atripp,

    Perfect thanks! I was able to recreate the behaviour with the metadata override and Reanalyze Package feature.

    Server date now: 2026-04-21 14:52BST (13:52 UTC)
    Package published date: 2026-04-14T13:00:00
    Reanalyze package outcome: Non-compliant

    There appears to be an issue uploading images at the moment, but heres the log:

    Package "pkg:npm/%40hono/node-server@1.19.14" will analyzed with local data
Attempting to update local package with remote metadata...
Cached metadata from search on 21/04/2026 13:01:56
Detecting licenses for "pkg:npm/%40hono/node-server@1.19.14"...
Found 1 licenses: MIT
Detecting vulnerabilities for "@hono/node-server" version "1.19.14"...
Found 0 vulnerabilities.
Searching policies associated with feed "xxxxxxxxxx"...
Found 1 policy to use for analysis.
Beginning license rule analysis...
Default rules: undectableLicense=Warn, unspecifiedLicense=Compliant
Checking MIT against rules...
No matching license rules; applying unspecifiedLicense rule (Compliant)
License rule analysis complete.
Policy "Global" considers aged packages (3 years) Warn
Policy "Global" considers recently published (7 days) Noncompliant
Publish date of 14/04/2026 is considered recently published.
No policies define a latest patch, so latest patch will not be checked.
Analysis resulted in a Noncompliant result.

    and the failing npm install:

    npm i -g @hono/node-server@1.19.14 --cache ./c
npm error code E400
npm error 400 Bad Request - GET https://xxxxx/npm/npm-public/%40hono/node-server/-/node-server-1.19.14.tgz - Package is Recently Published
npm error A complete log of this run can be found in: xxxxx
    0 atripp 1 Reply
  • atripp
    inedo-engineer

    Thanks @Ashley, that's exactly what I was thinking.

    I haven't tried reproducing this yet, but I've got all the steps to now! And at that point, I'll have a debugger and all the code in front of me, so it should be an easy fix. It's probably related to UTC/local time, I don't think we've ever tested it "by the hour" like that :)

    Anyway stay tuned we'll get it fixed pretty soon.

    0 atripp 1 Reply
  • atripp
    inedo-engineer

    Hi @Ashley ,

    Good news -- this will be fixed via PG-3265 in the upcoming maintenance release (next Friday).

    In case you're curious, the bug was that we were comparing packagePublished.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date, which includes the time-portion on the left side, but not the right-side (so 12:00A).

    Just changing to packagePublished.Date.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date does the trick, and it works for both Aged and Recently Published.

    cheers,
    Alana

    0
  • A

    Hi @atripp,

    Thanks for investigating and implementing a fix so quickly! It was always going to be something to do with a developers worst nightmare, time & timezones 🙂

    I'll update to the maintenance release after it's out and let you know our findings.

    0
Log in to reply
 
Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation