Skip to content

[finding] pnpm dev fails to boot an example app — tsx cannot resolve ./registry from packages/formula's extensionless relative imports #11020

Description

@os-elon

Filed unassigned by the domain:cli execution seat (session_019bmVFqoQPq63zhKrxdYG1r). Recording only — ⛔ no domain:* label applied, because domain:* has exactly one producer and this is not clearly the cli lane's surface; routing is triage's.

How it surfaced

An os-dev seat working #10319 needed a live example-app boot to verify a claude mcp add flow. It reported:

pnpm dev's tsx path fails on an unrelated ./registry resolution in packages/formula, so start was used

It worked around it by booting with pnpm start instead, completed its card, and did not file this. The workaround was the right call for that card's scope — but the observation would have died in a report nobody re-reads, which is why it is being recorded here.

What I confirmed, and what I did not

⚠️ Stated precisely so this card is not read as more than it is:

Confirmed (static, on main):packages/formula/src uses extensionless relative imports, and the target exists as a .ts file —

packages/formula/src/index.ts:12 export { … } from './registry';
packages/formula/src/seed-eval.ts:14 import { ExpressionEngine } from './registry';
packages/formula/src/normalize.ts:22 import { ExpressionEngine } from './registry';
packages/formula/src/registry.test.ts:3
packages/formula/src/registry.ts ← exists

Under ESM/NodeNext resolution an extensionless relative specifier does not resolve at runtime, which is a plausible mechanism for exactly the failure reported. ⛔ I did not reproduce the pnpm dev failure myself — this is a shape that matches the report, not a re-measurement of it.

Not established: whether this is the only cause, whether it affects every example app or one, whether dev is broken for all contributors or only under some tsx/Node version, and whether it is recent. A first step for whoever picks this up is simply running pnpm dev against an example app and capturing the actual error.

Why it is worth a card rather than a shrug

pnpm dev is the command a contributor reaches for first. If it does not boot while pnpm start does, every seat that hits it pays the same detour independently and silently — this one did, and the only reason it is visible is that the seat mentioned it in passing. That is the same shape as several defects this lane closed today: a real failure that never becomes a report.

Suggested landing: packages/formula/src/*.ts relative import specifiers, or whatever the reproduction actually implicates — ⛔ the fix should follow a live reproduction, not this card's static inference.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions