Reconnexion/ng-eventually
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: T01.l est close - pnpm partout, la portee du pair durcie, pnpm link verifie

Browse Source 
Le critere d-acceptation a ete execute, pas raisonne : lien reel contre le
checkout, resolution confirmee par readlink, defaire par `pnpm remove`. Le
polyfill lui-meme n-est jamais duplique par le lien ; le SDK en dessous l-est
des que l-application importe `@ng-org/web` elle aussi - 2 copies mesurees.
This commit is contained in:
Sylvain Duchesne
2026-09-24 12:14:42 +02:00
parent 82d41b296f
commit ab5980c257
2 changed files with 142 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.tasks/todo/T01.l-pnpm-everywhere-and-two-loose-ranges.md
-48
View File
@@ -1,48 +0,0 @@
---
id: T01.l
title: pnpm everywhere, and two dependency ranges that are looser than they look
parent: T01
depends_on: [T01.j]
created: 2026-09-21
claimed_by: null
claimed_at: null
blocked: false
---
## Description
Four items. The first two are dependency hygiene found by T01.h; the last two finish the move to a single package manager, whose POINT is that `pnpm link` works for local development against a checked-out dependency.
### 1. `ng-e2e-helpers`' peer range admits a package nobody wants
`packages/ng-e2e-helpers/package.json` declares a peer range `>=0.1.2-alpha.13` on `@ng-org/*`. Those packages also publish a bare `0.1.2`, dating from 2025, which semver ranks ABOVE every `0.1.2-alpha.N` - so that range would happily resolve to a year-old release. Exact pins exclude it TODAY, which is precisely what makes it a trap: it is inert until someone loosens a pin or installs fresh against a different resolver.
Fix the range so it cannot admit the bare `0.1.2`. VERIFY the fix by checking what the range actually resolves to, not by reading it - a range that looks right and resolves wrong is the whole failure mode here. Check whether the same shape exists on any other declared range in either package while you are there.
### 2. `playwright` is behind
`1.61.1` -> `1.63.0`. Bump it, reinstall, and RUN the e2e suite - a Playwright bump is exactly the kind of change that is invisible to a typecheck and visible to a browser. Report the counts verbatim. If the broker is unreachable, report the suite as UNRUN; never substitute a typecheck for the measurement. `.project/concepts/e2e-harness/caveat_a-dropped-pipe-kills-a-run.md` describes a Chromium control-pipe failure this suite already lives with - read it before concluding that a new red run is caused by the bump.
### 3. Two places still describe `bun install`'s semantics
`packages/polyfill/e2e/orm-live-read.ts:159` and `.project/concepts/e2e-harness/knowledge_what-each-suite-judges.md:14` both explain that `@ng-org/orm` is an optional peer that "`bun install` does not fetch". That is no longer the repo's install path, and pnpm does not treat optional peers the same way. ESTABLISH what pnpm actually does here - install fresh and look - then correct both texts to say the true thing. If it turns out pnpm DOES fetch it, that changes what the ORM live-read runner needs to say about itself, so say so rather than editing the sentence to match a guess.
### 4. Make bun unnecessary for installing and typechecking
Root `package.json:13` and `packages/ng-e2e-helpers/package.json:23` run `bunx tsc`. Nothing installs with bun anywhere in this repo - VERIFIED, there is no `bun install` in any script and no CI exists - and `packageManager: pnpm@10.26.0` is declared. But `bunx` still requires a contributor to have bun on their machine to typecheck. Move those to pnpm's equivalent.
**Explicitly NOT in scope: `bun test`.** It is the test RUNNER, not an installer, and it does not block `pnpm link`. Changing it is a separate decision with its own cost, and nothing here needs it. If you find evidence that it DOES block something, report that rather than acting on it.
### The acceptance criterion, which is the reason for all of this
`pnpm link` must work for local development against a checked-out dependency. VERIFY IT - actually perform a link against a local checkout and confirm the consuming package resolves to it, then undo. Do not reason about whether it should work. And check the thing that would silently ruin it: that linking does not produce TWO copies of a state-carrying package in one tree. The polyfill holds a dozen module-level state holders, so two copies in one application means two registries and two identities - that hazard is named in its own published contract.
### Verification
**Hard gate:** `bun test` -> 0 fail; `bunx tsc --noEmit -p packages/polyfill/tsconfig.json` -> exit 0 (or its pnpm equivalent once item 4 lands); `bunx tsc --noEmit -p packages/polyfill/e2e/tsconfig.json` -> exit 0; the example's own typecheck -> exit 0; `python3 ~/.claude/skills/concept/lint.py` -> 0 ERROR; plus the e2e counts from item 2.
Anti-cheat: no `any`, no `@ts-ignore`, no deleted or skipped test, no weakened assertion, and no LOOSENING a range to make an install succeed - item 1 is about tightening, and a fix that widens something else to compensate is not a fix.
## Progress
## Result