Summary

Fixes packaged/global termdraw rendering with incorrect colors by pinning OpenTUI runtime dependencies to exact versions.

The app CLI bundles OpenTUI JS into dist/cli.js, but the bundled code still dynamically loads the platform native OpenTUI package at runtime. With ^0.1.97 ranges, npm can install a newer @opentui/core / native optional dependency version than the one the CLI bundle was built against. In my case, the globally installed CLI still worked interactively, but the UI rendered only red on a black background.

This also updates the app CLI source import to use the workspace package entrypoint, @termdraw/opentui, instead of reaching into ../../opentui/src.

Reproduction

From the original package state:

cd packages/app
npm pack --ignore-scripts
npm install -g "$(ls -t *.tgz | head -1)"
termdraw

Observed: the UI opens and remains interactive, but colors render incorrectly as red on black.

After this change:

cd ~/Code/termdraw-fork
bun run build
cd packages/app
npm pack --ignore-scripts
npm install -g "$(ls -t *.tgz | head -1)"
termdraw

Observed: the UI renders with the expected full color palette.

Why

This appears to match an OpenTUI optional dependency/version mismatch issue described here:

anomalyco/opentui#29 (comment)

That comment notes that loose optional dependency versions could cause the wrong native package version to be downloaded, and that explicit versions fix it.

Since @termdraw/app publishes a bundled CLI but relies on OpenTUI’s installed native package at runtime, exact OpenTUI pins keep the JS bundle and native package aligned for npm consumers.

Screenshots

BEFORE:

AFTER:

Validation

bun run typecheck
bun run build

Manually verified by packing and globally installing the app tarball before and after the dependency pin change.

Also fixed a workspace relative link because it bugged me to see. Probably unrelated. 😅

Used codex to help diagnose. I'm on a plane rn. ✈️