---
id: T01.n
title: The polyfill's peer ranges exclude exactly the versions it needs
parent: T01
depends_on: [T01.m]
created: 2026-09-24
claimed_by: null
claimed_at: null
blocked: false
---

## Description

Two loose ends from T01.l, the first of which is a published-surface defect waiting for the first publish.

### 1. Four peer ranges that admit nothing usable

`packages/polyfill/package.json` declares all four `@ng-org/*` peers as `"*"`. In semver, `*` matches NO pre-release version. MEASURED by T01.l against the registry: of the 16 published versions, that range admits ONLY the bare `0.1.2` (dated 2025) and EXCLUDES every `0.1.2-alpha.N` - which is precisely what this package is built against and needs.

It is inert today only because the polyfill itself is not published (a registry query for it returns E404), so no consumer has ever resolved these peers. It is certain to surface at the first publish, as an unsatisfiable or wrongly-satisfied peer for every application installing this package.

Fix the four ranges so they admit the alphas this package actually works with and exclude the stale bare `0.1.2`. T01.l's tightening of `ng-e2e-helpers` to `>=0.1.2-alpha.13 <0.1.2` is the shape that was measured to work - decide whether the same bound is right here, given the polyfill is built against orm alpha.21 rather than web alpha.14.

**VERIFY BY RESOLUTION, NOT BY READING.** This is the whole lesson of T01.l: the range it was sent to fix had a real defect, but the stated failure mode was wrong, and only a resolution test showed which part was true. Query the registry, compute what the range admits before and after, and paste both counts. A range that looks right and resolves wrong is the entire failure mode here.

**Check `peerDependenciesMeta` at the same time.** All four are declared optional; confirm that is still the intent for each, since T01.l MEASURED that a consumer receives none of them under pnpm while this checkout gets the ORM through a devDependency.

### 2. The example has no `typecheck` script

`examples/notebook` typechecks correctly when invoked directly, but carries no `typecheck` script, so nothing in the repo runs it and its green state depends on someone remembering the command. Add the script. Do not build tooling around it.

### Verification

**Hard gate:** `bun test` -> 0 fail (baseline `449 pass / 0 fail`, measured); `pnpm exec tsc --noEmit -p packages/polyfill/tsconfig.json` -> exit 0; `pnpm exec tsc --noEmit -p packages/polyfill/e2e/tsconfig.json` -> exit 0; the example's typecheck via its new script -> exit 0; `python3 ~/.claude/skills/concept/lint.py` -> 0 ERROR.

A fresh `rm -rf node_modules && CI=true pnpm install --no-frozen-lockfile` must end with ONE copy of each `@ng-org` package - verify what each resolves to rather than trusting a silent install. Two copies of a package holding module-level state means two registries and two identities, which is this package's own named hazard.

Anti-cheat: no widening a range to silence a warning, and no `any`, `@ts-ignore`, deleted or skipped test.

Every quantitative claim carries the number that supports it in the same sentence.

## Progress

## Result