Why doesn't scope support versions in package-filter rules?

[szonker]

Context

The package-filter plugin currently supports three levels of rule granularity for allow/block rules:

• scope
• package
• package + versions

Here an example configuration from the plugin documentation:

filters:
  '@verdaccio/package-filter':
    minAgeDays: 7
    dateThreshold: '2025-01-01'
    block:
      - scope: '@malicious'
      - package: 'typosquat-pkg'
      - package: 'compromised-lib'
        versions: '>=3.0.0'
      - package: 'legacy-lib'
        versions: '>=2.0.0'
        strategy: replace
    allow:
      - scope: '@my-org'
      - package: 'compromised-lib'
        versions: '3.0.1'

We use minAgeDays combined with an allow-list to deliberately fast-track security fixes. This works well at the package + versions level, but for scopes that publish many related packages under the same version (e.g. @angular), fast-tracking a specific release currently means either adding a rule per package + version (tedious), or a scope-wide rule without a version constraint (too broad, bypasses minAgeDays entirely).

Question

Is there a technical or design reason scope doesn't support a versions constraint while package does? Is this a deliberate limitation, or just not implemented yet?

[mbtools]

@scope+version might work for a monorepo where all packages are published with the same version. But even then you can't be sure that there's another repo for the scope with independent versions. So I'm not how useful such filter would be. Or do you have something else in mind?

[szonker]

That's a fair concern, but I don't think scope + versions needs to assume all packages in the scope share one version. It could instead mean "apply this version constraint independently to each package under the scope" - sugar for repeating the package + versions rule for every package in that scope, without having to enumerate them.

That sidesteps the monorepo assumption: for lockstep scopes (like Angular, Babel, Storybook) it works like a single filter; for independently-versioned scopes, each package is just checked on its own, and packages outside the range simply don't match.

[mbtools]

I understand how you would like it to work but take your examples and scroll down the list and check the versions for these scopes:
https://npmx.dev/org/storybook (same for babel and angular)

The monorepo is on 10.5.10 and a @storybook + version filter would work well for most of the included packages. But there are also @storybook/icons at 2.1.0 (separate repo) or @storybook/theming at 8.6.14 (same monorepo but no v9 or v10 release track), for example, which would be caught by the filter.

Let's say you want to allow only latest @storybook packages from the monorepo because older versions are compromised:

 allow:
      - scope: '@storybook'
        versions: '>=10.5.10'

or

 block:
      - scope: '@storybook'
        versions: '<10.5.10'

Any project using @storybook/icons or @storybook/theming would fail.

Unless you have complete control over which packages are published for a scope or which packages are installed in a project (effectively your own scope), I don't see it being useful in practice.

[szonker]

Fair point, and the @storybook/icons/@storybook/theming example makes it concrete - a single range compared against independently-versioned packages in the same scope will misfire either way (false block or missed allow). That's a real problem with the idea, not just an edge case. I think you're right that this only works if the scope is the versioning unit, which isn't guaranteed. Thanks for walking through it.