Compare normalized purls to account for encoding quirks

[juxtin]

Fix allow-dependencies-licenses not matching scoped npm packages

Bug

When a user specifies a scoped npm package in allow-dependencies-licenses using percent-encoded PURLs (e.g. pkg:npm/%40lancedb%2Flancedb), the exclusion silently fails to match, and the package is still flagged for license violations.

Root cause: parsePURL splits on literal / characters after the type segment to separate namespace from name. When the / between namespace and name is percent-encoded as %2F, the split doesn't happen, and the entire @scope/name string ends up in the name field with namespace set to null.

The dependency graph API returns PURLs with a literal / (e.g. pkg:npm/%40lancedb/[email protected]), which parses to {namespace: "@lancedb", name: "lancedb"}. But the user-provided exclusion pkg:npm/%40lancedb%2Flancedb parses to {namespace: null, name: "@lancedb/lancedb"}. The previous field-by-field comparison (namespace === namespace && name === name) always fails because the fields don't align.

To reproduce: Add allow-dependencies-licenses: pkg:npm/%40lancedb%2Flancedb to a workflow. The scoped package will still be reported as a license violation.

Fix

Added a purlsMatch(a, b) function in purl.ts that normalizes the namespace/name pair into a single "namespace/name" string before comparing. This means all of these user-provided formats now work:

User input	Parsed	Matches API PURL?
pkg:npm/%40lancedb%2Flancedb	ns=null, name=@lancedb/lancedb	✅
pkg:npm/@lancedb/lancedb	ns=@lancedb, name=lancedb	✅
pkg:npm/%40lancedb/lancedb	ns=@lancedb, name=lancedb	✅

The license exclusion comparison in groupChanges (licenses.ts) now calls purlsMatch instead of doing a strict field-by-field check.

Tests

• purlsMatch matches identical PURLs (ignoring version)
• purlsMatch matches when the namespace separator / is percent-encoded as %2F
• purlsMatch matches scoped npm packages across all three encoding variants
• purlsMatch rejects packages with different names or different types
• purlsMatch works for unscoped packages (no namespace)
• Integration test: scoped npm change with %2F-encoded exclusion is correctly filtered from license violations

Risks

Low. The change is scoped to PURL comparison only and doesn't alter parsing behavior. The purlsMatch function is additive — existing correctly-formatted PURLs continue to match as before. The normalization is a straightforward string concatenation of fields that were already decoded by parsePURL.

[Copilot]

Pull request overview

This PR fixes a bug where scoped npm packages specified in allow-dependencies-licenses using percent-encoded PURLs (e.g., pkg:npm/%40lancedb%2Flancedb) were not properly matched against dependency graph results, causing license exclusions to fail silently. The root cause was that percent-encoding the namespace separator / as %2F prevents the PURL parser from splitting the namespace and name into separate fields, resulting in field-by-field comparisons that always fail.

Changes:

• Added a purlsMatch() function that normalizes namespace/name pairs into a single string before comparison, handling encoding variations
• Updated license exclusion logic to use purlsMatch() instead of direct field comparison
• Added comprehensive unit and integration tests covering multiple encoding scenarios

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/purl.ts	Added fullName() helper and purlsMatch() function to normalize and compare PURLs regardless of namespace separator encoding
src/licenses.ts	Updated license exclusion comparison to use purlsMatch() instead of field-by-field comparison
__tests__/purl.test.ts	Added comprehensive unit tests for purlsMatch() covering various encoding scenarios and edge cases
__tests__/licenses.test.ts	Added integration test verifying scoped npm packages with %2F-encoded separators are correctly excluded
dist/index.js	Compiled output reflecting source changes (two instances of the bundled code)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ljones140]

Looks great. Encoded characters are tricky.