[ProGet] Recently Published Rule

tim.vanryzin_8423

Hi.

We'd like to implement the recently published rule. Before we do we are not sure of how the developer experience will be. Will it be obvious that they are not getting the latest package even though I just ran an update to get latest? For example when they go to the online repo it says the latest is 1.12.15 but when upgraded they get 1.12.10.

Any thoughts on this are appreciated.

stevedennis

Hi @tim-vanryzin_8423 ,

Great question on developer experience! We're very curious to learn that ourselves, so please let us know as you implement it.

First and foremost, if you haven't already, check out the Recently Published & Aged Packages rules blog article to see how this works and our current advice. FYI - we are likely going to change the best practices guidance in 2026 to discourage download blocking.

From an API/technical standpoint, it's simply not possible to "hide" the fact that 1.12.15 is the latest version. So, if you have a connector, ProGet will report the latest version as reported by the connector.

But even it were technically possible, there's no simply great developer experience here. Keep in mind that most never look at the ProGet ui -- they configure things once, and forgeet about it.

So really, it's just a question of when you want the developer to find out they can't use Xyz-1.12.15. Here are the general options:

Manual Curation (no connectors) - it's always going to be on nuget.org / npmjs.org, so even if you manually curate every page in ProGet, they'll know it exists and will be confused why it's not on ProGet; they may not even know who to ask
Download blocking - you could simply block downloads of newest packages, but that's just going to look like random "400 errors" to developers and they will become frustrated
Build Auditing - run pgutil builds audit on your build server, and you can see if the packages are noncompliant; this is where we are shifting our advice, as a failed build at that stage will be so much more obvious than a 400 buried in a package restore step

Ultimately this requires training developers to use lock files and not always get latest. That's why we are shifting to pgutil builds audit -- it's almost self-training. When their builds fail, they will see the reason clearly and should be able to adjust their code/configuration to not use a non-compliant version.

-- Dean

tim.vanryzin_8423

Thank you. Super helpfull!

jstrassburg_8563

I'd like to ask a follow up / clarifying question -

In general, developers install new packages without specifying a version constraint, e.g. - npm i underscore

which would return the latest compatible version given the other packages that may already be installed. Those packages and versions are then frozen for deployment.

Does the statement "From an API/technical standpoint, it's simply not possible to "hide" the fact that X is latest" mean that if the resolved version that npm i underscore chose was released in the blocking period, the npm command would 400?

stevedennis

Hi @jstrassburg_8563,

if the resolved version that npm i underscore chose was released in the blocking period, the npm command would 400?

If you have "Block Noncompliant Packages" enabled (which we generally don't recommend) and you have a rule that new packages are complaint, then the npm command would most certainly give some kind error.

You will probably see a 400 code, but I don't think it will display the message that's sent by ProGet (i.e. "package blocked due to...")? The real issue comes with a large dependency tree, and it'll be hard to know what exactly the issue is.

As such, we recommend running pgutil builds scan/audit in your CI/CD pipelines instead of blocking. This will produce a much easier to understand report, and even allow you to bypass issues reported on a case-by-case basis.

Thanks,
Steve