Skip to content

chore(release): 0.4.0 — publish the no-dash label rule - #11

Merged
ralyodio merged 1 commit into
mainfrom
chore/release-no-dash-labels
Aug 3, 2026
Merged

chore(release): 0.4.0 — publish the no-dash label rule#11
ralyodio merged 1 commit into
mainfrom
chore/release-no-dash-labels

Conversation

@ralyodio

@ralyodio ralyodio commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

The problem

lib/index.mjs has refused a dash in a label since the look-alike squatting decision — .crypto against .cryp-to, in a namespace that is one level deep, first come first served, with no dispute process to appeal into. The version was never bumped, so that fix never shipped. npm still serves the dash-permitting regex from before it:

published 0.3.0   const LABEL = /^[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?$/   ← dashes allowed
main              const LABEL = /^[a-z0-9]{1,63}$/                          ← the actual rule

This isn't cosmetic. The registry enforces the no-dash rule, so a client using this package accepts lazy-loaded locally and then has it refused by the server it's a client of. Being that rule is the package's entire job.

What's in here

Only the version number. No code changemain was already right.

0.4.0 rather than a patch: refusing input that used to be accepted is breaking for anyone who took the old answer at face value.

Verified against the consumer that noticed

moshcode vendors these rules as apps/pwa/src/lib/moshpit-name.mjs and has a drift test comparing the two. Installed both ways:

  • against published 0.2.x/0.3.03 subtests fail (every hostname parses the same way, labels normalise the same way)
  • against this branch — all 8 pass

Those 3 have been failing in moshcode for a while; this is what fixes them. After publish, moshcode's apps/pwa devDependency needs moving off ^0.2.0 (which cannot resolve 0.4.0 on a 0.x range) — I'll follow up with that.

Local suite: 35/35 pass.

🤖 Generated with Claude Code

The rule changed here and never shipped. `lib/index.mjs` has refused a dash
in a label since the look-alike squatting decision (`.crypto` against
`.cryp-to`, in a namespace one level deep with no dispute process), and the
version was never bumped — so npm still serves the dash-permitting regex
from before it.

The gap is not cosmetic. The registry enforces the no-dash rule, so a
client using this package accepts `lazy-loaded` locally and then has it
refused by the server it is a client of. The package's whole job is to be
that rule.

0.4.0 rather than a patch: refusing input that used to be accepted is
breaking for anyone who took the old answer at face value.

Verified against the consumer that noticed: moshcode's
apps/pwa/test/moshpit-name-drift.test.mjs fails 3 subtests against the
published copy and passes all 8 against this one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.

@ralyodio
ralyodio merged commit 7a4f176 into main Aug 3, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant