@pascal-app/editor beta.5 pulls node:module into external browser builds through Manifold print export

[smokie40]

What happened?

Hi Pascal team,

we are integrating @pascal-app/editor into an external Next.js application and found a browser packaging issue in beta.5.

The public @pascal-app/editor root pulls the Manifold print-export path into the browser dependency graph even when print export is not used.

As a result, an optimized Next/Webpack build fails when it reaches node:module through manifold-3d.

The relevant import chain is:

node:module
→ manifold-3d
→ print-shell-compiler-manifold-core
→ print-shell-compiler-manifold.worker
→ print-shell-compiler-manifold-worker
→ export-manager.tsx
→ @pascal-app/editor root
→ external Next.js application

The build error is:

Module build failed: UnhandledSchemeError:
Reading from "node:module" is not handled by plugins.

The editor APIs and runtime functionality we use otherwise work correctly. The failure is specifically at the optimized browser production-build boundary.

Steps to reproduce

1. Consume the public @pascal-app/editor root from an external Next.js application.
2. Use the current beta.5 source.
3. Import the editor through its public package entrypoint.
4. Run an optimized Next/Webpack production build.
5. The browser bundle traverses the print-export dependency path and eventually reaches node:module through manifold-3d.
6. The build fails with UnhandledSchemeError.

We most recently rechecked exact upstream source SHA:

cfe1306

The issue is still present there.

Expected behavior

The public browser editor entrypoint should be consumable by an external browser application without pulling Node-only dependencies into the browser bundle.

Either of these approaches would solve our integration issue:

1. Isolate/lazy-load the print/Manifold implementation so it is not part of the editor browser dependency graph unless print export is actually used.

or

2. Expose a supported browser-safe editor/embed package subpath for host applications that need the editor composition APIs but not print export.

For example, a public entrypoint conceptually similar to:

@pascal-app/editor/embed

containing the browser-safe editor surface would also work for us.

Browser & OS

N/A — the failure happens during the optimized Next.js/Webpack production build, before browser runtime.

Screenshots or screen recordings

No response

Additional context

This does not appear to be a general editor/runtime incompatibility.

Our integration checks for the editor API, runtime/client geometry, dimensions, workspace adapter, and ordinary Web tests pass. The blocker is specifically the production browser bundle.

We are currently keeping our production integration pinned to the previous browser-safe Pascal source rather than adding a Webpack node:module shim or importing private @pascal-app/editor/src/... paths.

We would prefer to stay on the supported public Pascal API.

If useful, we would be happy to validate a candidate fix against our external Next.js integration.

Thanks!