Summary
@px402/next/dist/handler.js imports from "next/server" (no .js extension). Node's strict ESM resolver rejects this when importing the package outside a Next.js bundler context. Next.js consumers don't hit it because the Next bundler rewrites the specifier, but plain-Node smoke tests / tooling / non-Next runtimes fail.
Repro
From a scratch dir against the published 0.1.1:
```bash
mkdir /tmp/repro && cd /tmp/repro
npm init -y && pnpm add @px402/next@0.1.1
node -e 'import("@px402/next")'
```
Fails with:
```
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node_modules/next/server'
imported from .../node_modules/@px402/next/dist/handler.js
Did you mean to import "next/server.js"?
```
Cause
packages/next/src/handler.ts (or whichever module re-exports into dist/handler.js) uses:
```ts
import { NextResponse } from "next/server";
```
TypeScript emits this verbatim. Next.js's bundler resolves it. Node's strict ESM resolver does not — it requires an explicit .js or a matching exports map.
History
Latent since 0.1.0. The internal smoke / examples never tripped it because they run inside a Next app (where the bundler intercepts). Caught during the 0.1.1 install-from-npm verification done in a vanilla Node ESM script. Not a regression — 0.1.1 only touched README files.
Impact
- Real Next.js users: zero impact (bundler resolves it).
- Plain-Node consumers, smoke tests, tooling that introspects all packages via
import(): breaks.
Proposed fix
Either:
- Change the source to
import {...} from "next/server.js" (cleanest, works in both Next bundler and plain Node).
- Mark
next as an external peer dep with a wildcard exports map (more invasive).
- Ship a
package.json imports field rewriting next/server → next/server.js.
Option 1 is the smallest patch. Verify with a fresh pnpm add @px402/next@<next-version> + node -e 'import("@px402/next")' in a scratch dir before publishing.
Acceptance
- Vanilla Node ESM script can
import("@px402/next") without ERR_MODULE_NOT_FOUND.
- A Next.js app still builds + runs against
@px402/next (no bundler regression).
- Add a smoke step to release flow that does the scratch-dir install + import for every package.
Summary
@px402/next/dist/handler.jsimports from"next/server"(no.jsextension). Node's strict ESM resolver rejects this when importing the package outside a Next.js bundler context. Next.js consumers don't hit it because the Next bundler rewrites the specifier, but plain-Node smoke tests / tooling / non-Next runtimes fail.Repro
From a scratch dir against the published
0.1.1:```bash
mkdir /tmp/repro && cd /tmp/repro
npm init -y && pnpm add @px402/next@0.1.1
node -e 'import("@px402/next")'
```
Fails with:
```
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node_modules/next/server'
imported from .../node_modules/@px402/next/dist/handler.js
Did you mean to import "next/server.js"?
```
Cause
packages/next/src/handler.ts(or whichever module re-exports intodist/handler.js) uses:```ts
import { NextResponse } from "next/server";
```
TypeScript emits this verbatim. Next.js's bundler resolves it. Node's strict ESM resolver does not — it requires an explicit
.jsor a matchingexportsmap.History
Latent since 0.1.0. The internal smoke / examples never tripped it because they run inside a Next app (where the bundler intercepts). Caught during the 0.1.1 install-from-npm verification done in a vanilla Node ESM script. Not a regression — 0.1.1 only touched README files.
Impact
import(): breaks.Proposed fix
Either:
import {...} from "next/server.js"(cleanest, works in both Next bundler and plain Node).nextas an external peer dep with a wildcard exports map (more invasive).package.jsonimportsfield rewritingnext/server→next/server.js.Option 1 is the smallest patch. Verify with a fresh
pnpm add @px402/next@<next-version>+node -e 'import("@px402/next")'in a scratch dir before publishing.Acceptance
import("@px402/next")withoutERR_MODULE_NOT_FOUND.@px402/next(no bundler regression).