Deno 2.6 minimum dependency age flag silently drops month and year durations

Deno 2.6 ships with a guard against freshly published npm packages, but that guard quietly switches itself off for some inputs. According to hands-on testing published on dev.to by alexgeorgiev17, the --min-dep-age flag does nothing when given an ISO-8601 duration containing months, years or a time component: Deno installs the true latest version, exits with code 0 and prints no warning. A team that phrases its policy as "six months" or "two years" gets zero protection and no signal that anything is wrong.

How the feature is meant to work

The flag, available on deno add and deno install, refuses any dependency version younger than a threshold. The reasoning is that a malicious npm release is typically yanked or reported within hours or days, so only installing packages that have survived a waiting period dodges most of that attack class. The CLI help, quoted in the dev.to write-up, says the value can be a plain number of minutes, an ISO-8601 duration such as P2D, or an RFC3339 absolute cutoff date or timestamp, and marks the flag as unstable.

Day-based filtering behaves

The author tested on Deno 2.9.6, described as the current stable release carrying the feature, running a single deno add for 20 widely used packages once unrestricted and once with a 30-day minimum. Twelve packages resolved to older versions; the other eight had latest releases that were already more than 30 days old. The sharpest case was vitest, where the 30-day bar pinned version 4.1.10 — a full major release behind the actual latest, 5.0.1 — with no error, warning or hint that a newer major existed. Overhead was negligible: 10.2 seconds for the unrestricted 20-package batch versus 10.6 seconds with the filter, on a fresh container with a cold cache.

Months and years disable the check

The help text only shows day-based examples, but ISO-8601 also defines month and year components, and the flag description does not exclude them. In the tests, days and weeks (P30D, P4W), plain minutes and absolute dates all filtered correctly. The moment a duration contained a month or year component — P1M, P2Y, P100Y, and even zero-valued forms like P0Y1M0D — the whole restriction was dropped and Deno installed the real latest version, as though the flag had never been passed. Adding a time component, P1DT0H, broke the same way. Every one of these runs exited 0, wrote nothing to stderr and showed nothing about a skipped or rejected candidate even at --log-level=debug.

The practical consequence: a policy written into deno. as minimumDependencyAge set to P6M delivers no protection at all, and the only way to notice is comparing resolved versions against the registry by hand.

Two additional gotchas

• Config naming: the CLI flag is --min-dep-age, but the deno. key is the fully spelled minimumDependencyAge. Writing minDepAge, mirroring the flag, is silently ignored. The Deno blog announcement uses the long form, so the documentation itself is accurate; the trap is assuming symmetry between flag and key.
• Lockfiles: the age check runs at resolution time, when a version is chosen or the lock is updated, not on every install. The author locked a zod release roughly three days old, deleted node_modules, and ran deno install with a 30-day minimum; the fresh version reinstalled without complaint. Setting the flag in a CI install step achieves nothing if the lockfile was committed by someone without the policy.

The parts that behaved

Deno 2.6 also replaced deno install --allow-scripts with deno approve-scripts for npm lifecycle hooks. In the test, installing simple-git-hooks blocked its postinstall script by default with a warning, an explicit named approval ran it, and the decision was recorded as an allowScripts entry in deno. — matching the documentation exactly. The other headline feature, deno audit, which checks the dependency graph against npm's advisory database, could not reach the registry endpoint in the author's setup and returned a request error.

Why it matters

A security control that fails open and fails silently is worse than one that errors out, because it manufactures false confidence. The minimum-age idea itself is sound and cheap — the filtering is a metadata comparison that costs a fraction of a second — but until month and year durations are either supported or rejected loudly, teams should express policies in days or weeks (P30D, P26W) or as absolute cutoff dates, verify they are using the minimumDependencyAge key, and remember that the rule binds when a version is selected, not when it is installed. As it stands, a policy naturally phrased in months or years is read as permission to install anything.