fix the turbopack and jest bundling of proteinpaint code

[siosonel]

Description

This PR re-enables the dynamic rebundlng of proteinpaint client dist code when using the portal-proto/src/features/proteinpaint/dev.sh script, which was previously broken after recent version bumps to the nextjs dependency. ProteinPaint code outside of the gff directory can now be dynamically bundled by turbopack and jest.

@craigrbarnes Please verify that your npm run dev is not affected by these changes, I assume you don't have a local proteinpaint repo setup.

Checklist

• Added proper unit tests
• Left proper TODO messages for any remaining tasks
• Scanned for web accessibility with aXe, and mitigated or documented
  flagged issues

Screenshots/Screen Recordings (if Appropriate)

[Copilot]

Pull request overview

Re-enables local development against a sibling proteinpaint/client repo by adding a Turbopack config fragment that aliases @sjcrh/proteinpaint-client to a local build and widens Turbopack’s root so files outside the Next.js project can be bundled.

Changes:

• Added ppTurbopackDev helper to generate a Turbopack config fragment when PP_CLIENT_DIST is set.
• Updated dev.sh to drive the new workflow (no npm link / manual cp -r dist into node_modules).
• Wired the helper into packages/portal-proto/next.config.js under turbopack.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
packages/portal-proto/src/features/proteinpaint/ppTurbopackDev.js	Adds Turbopack fragment to alias proteinpaint client to a local dist build and widen Turbopack root.
packages/portal-proto/src/features/proteinpaint/dev.sh	Updates local dev script to set PP_CLIENT_DIST and remove the old npm-link/copy workflow.
packages/portal-proto/next.config.js	Applies the optional proteinpaint Turbopack overrides during dev when PP_CLIENT_DIST is set.

Suppressed comments (2)

packages/portal-proto/src/features/proteinpaint/dev.sh:27

• The comments describe PP_CLIENT_DIST as pointing to a "dist" directory, but the script sets it to the client repo root (../proteinpaint/client). This mismatch makes it easy to set the variable incorrectly and end up with a confusing dist/dist/app.js resolution in the Turbopack config.

	# 2. PP_CLIENT_DIST (below) tells Turbopack to bundle the local client dist
	#    directly (see next.config.js `turbopack.resolveAlias`), so no npm link or
	#    manual `cp -r dist ...` into node_modules is needed. A browser refresh after
	#    a client rebuild is usually enough to pick up changes.

packages/portal-proto/src/features/proteinpaint/ppTurbopackDev.js:46

• turbopack.root is set to the common ancestor of the project and the client. When the two directories only share the filesystem root (e.g. /), this widens Turbopack's root to the entire drive, which can significantly increase file-watching scope and slow down dev builds. Consider failing fast with a clear error when the computed ancestor is the filesystem root, so developers know to place the repos under a closer common parent.

  return {
    root: commonAncestor(projectDir, clientDir),
    resolveAlias: { "@sjcrh/proteinpaint-client": rel },
  };

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[craigrbarnes]

The changes to NextJS might not be necessary: Can you test this both in dev and build by adding the --webpack flag to the dev and build commands? This will force Next.js to use webpack, which should not require these changes