janpeter/scrum4me-shared
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

build(shared): declare type:module for Node/tsx runtimes (P0-B.2 prerequisite) #10

Merged
janpeter merged 1 commit from feat/shared-type-module into main 2026-06-07 13:46:04 +02:00
Conversation 0 Commits 1 Files changed 1 +1
janpeter commented 2026-06-07 13:40:35 +02:00
Owner
Copy link

What

Adds "type": "module" to @scrum4me/shared's package.json.

Why (P0-B.2)

@shared ships ESM TypeScript source (module: ESNext, .js-extensioned relative imports) but its package.json declared no module type. Bundler consumers — scrum4me-workers, scrum4me-web, and @shared's own vitest — were unaffected because they resolve TS through a bundler.

scrum4me-mcp (P0-B.2) becomes the first direct Node consumer: it re-exports the product-doc closure from @shared and runs via tsx. Without type: "module", Node/tsx treats @shared's .ts files as CommonJS, and a named import from an ESM module fails at runtime:

SyntaxError: The requested module '@shared/product-doc-folders.js'
does not provide an export named 'productDocFolderToApi'

Declaring the package ESM (which it already is) fixes named-export resolution. Confirmed: with type: "module", the full mcp product-doc closure loads at runtime via the production re-export chain (mcp/src/lib/* → @shared).

Safety

  • npm run verify green: dep-purity gate + tsc --noEmit + 101 vitest tests.
  • Relative imports already use .js extensions → Node-ESM compatible.
  • Contained blast radius: workers/web pin their own @shared submodule commit and are unaffected until they independently bump to include this commit.

🤖 Generated with Claude Code

## What Adds `"type": "module"` to `@scrum4me/shared`'s `package.json`. ## Why (P0-B.2) `@shared` ships ESM TypeScript source (`module: ESNext`, `.js`-extensioned relative imports) but its `package.json` declared no module type. Bundler consumers — scrum4me-workers, scrum4me-web, and `@shared`'s own vitest — were unaffected because they resolve TS through a bundler. scrum4me-mcp (P0-B.2) becomes the first **direct Node consumer**: it re-exports the product-doc closure from `@shared` and runs via `tsx`. Without `type: "module"`, Node/tsx treats `@shared`'s `.ts` files as CommonJS, and a named import from an ESM module fails at runtime: ``` SyntaxError: The requested module '@shared/product-doc-folders.js' does not provide an export named 'productDocFolderToApi' ``` Declaring the package ESM (which it already is) fixes named-export resolution. Confirmed: with `type: "module"`, the full mcp product-doc closure loads at runtime via the production re-export chain (`mcp/src/lib/* → @shared`). ## Safety - `npm run verify` green: dep-purity gate + `tsc --noEmit` + 101 vitest tests. - Relative imports already use `.js` extensions → Node-ESM compatible. - **Contained blast radius:** workers/web pin their own `@shared` submodule commit and are unaffected until they independently bump to include this commit. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
@shared ships ESM TS (module:ESNext, .js-extensioned relative imports) but lacked a package.json type. Bundler consumers (workers/web, vitest) were unaffected, but a direct Node runtime (mcp via tsx, P0-B.2) treats the .ts files as CommonJS and cannot see their named exports. Declaring type:module fixes the named-export resolution; verify stays green (tsc + 101 tests + dep-gate).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/scrum4me-shared!10
No description provided.