Turbopack build can't resolve `import 'harper'` (Next 16); README recommends an import that breaks the build

[dawsontoth]

Summary

On Next.js 16, a top-level import 'harper' in server code fails the plugin's on-startup build with:

Error: Turbopack build failed with 1 errors:
Module not found: Can't resolve 'harper'
> import 'harper';

withHarper() externalizes harper for the webpack path and adds it to serverExternalPackages, but adds nothing for Turbopack (src/withHarper.cts L31–43; the comment at L24–26 notes Turbopack support is "currently proving difficult"). Since v16 defaults to Turbopack (src/plugin.ts L196–197), the build throws, and the plugin logs the error and returns without serving (src/plugin.ts L254–264) — so the app boots but every route 404s. It's a silent failure that's especially confusing on remote/Studio deploys (the component "deploys" but serves nothing).

Interaction with #37

Forcing bundler: webpack gets past module resolution, but then hits #37: the same top-level import 'harper' opens the database during Next's build-time page-data collection → IO error: While lock file: .../database/data/LOCK: Resource temporarily unavailable. So a top-level import 'harper' breaks the build under both bundlers, for two different reasons (resolution under Turbopack, DB lock under webpack).

The docs recommend the import that breaks it

README step 5 (~L63–75) tells users to import 'harper' in server-side code. That guidance triggers this on v16. Notably, the plugin's own next-16 fixture doesn't import harper in Next code — it keeps Harper access in a jsResource (fixtures/next-16/greeting.js) and the Next pages use the injected tables global / process.env. Using the injected tables global directly (no top-level import) builds and serves fine on Turbopack, and it's what the _next-14-old fixture does in a Next module.

Minimal repro

1. A Next 16 app using @harperfast/nextjs (e.g. npx create-harper my-app --template nextjs).
2. Add import 'harper'; at the top of a server action/component (as the README shows).
3. harper run . → Turbopack build fails (Can't resolve 'harper') → all routes 404.
4. Remove the import and use the injected tables global instead → builds & serves fine.

Versions: @harperfast/nextjs 2.2.1, next 16.2.11, harper 5.1.22, Node 24.

Suggestions

1. Add Turbopack externalization for harper/harper-pro in withHarper() (e.g. turbopack.resolveAlias / external config) so import 'harper' resolves under the v16 default bundler — or, if that's blocked upstream, default the plugin build to webpack on v16 with a warning.
2. Update the README to recommend the injected tables global without a top-level import 'harper' (or document that any such import must be lazy/request-time to avoid Running a build at a runtime with a RocksDB database fails #37). The current guidance produces broken builds on v16.
3. Consider surfacing a failed startup build more loudly than a logged error + silent 404s (e.g. serve a 500 with the build error), so the failure mode is obvious on remote deploys.

Happy to open a PR for the docs change and/or test a Turbopack externalization approach if useful.