ink: <Text dimColor> renders as [object Object]

[proggeramlug]

Follow-up discovered while landing ink #348 end-to-end (PR #5038).

Repro

import React from 'react';
import { render, Box, Text } from 'ink';
function App() {
  return (
    <Box flexDirection="column">
      <Text dimColor>A dimColor plain ascii</Text>
      <Text>B plain text</Text>
      <Text color="cyan">C colored ascii</Text>
    </Box>
  );
}
const { unmount } = render(<App />);
setTimeout(() => unmount(), 100);

Actual

[object Object]
B plain text
C colored ascii

The dimColor line renders as [object Object] instead of its text. color="cyan" (a chalk color) renders fine, so the issue is specific to ink's handling of the boolean style modifiers (dimColor, and likely bold/italic/underline/inverse/strikethrough).

Notes

• ink's <Text> maps dimColor to a chalk modifier (chalk.dim) vs color to chalk[color]. The boolean-modifier path produces an object where the string-color path produces a string — points at how the chalk modifier function/proxy is being applied or coerced when compiled natively.
• Layout/borders are unaffected — purely a text-styling coercion issue.
• Separate from the yoga/taffy + JSON-import + Context.Provider work in feat: native yoga-layout via taffy + JSON module imports — ink #348 end-to-end #5038; everything else in ink renders correctly.

Part of #348.

[proggeramlug]

Broader root cause than just dimColor — the whole chalk styling path is inert in compiled binaries. Diagnosed with a direct chalk import:

chalk.level       = 0
supportsColor     = undefined      // supports-color detection returns nothing
process.stdout.isTTY = undefined   // should be true (tty) / false (pipe)
process.env.FORCE_COLOR (with FORCE_COLOR=3) = "3"   // env IS readable...
chalk.level (with FORCE_COLOR=3)  = 0                // ...but chalk's level ignores it
typeof chalk.green("x") = object,  bytes: ""         // builder returns empty object at level 0

Consequences in ink:

• <Text color=...> → text renders but uncolored (zero ESC bytes emitted, even with FORCE_COLOR).
• <Text bold> / <Text dimColor> → leaks chalk's passthrough builder source (...strings) => strings.join(' ') (or [object Object]) into the output.

Likely sub-issues to fix:

1. process.stdout.isTTY is undefined — should reflect the real fd.
2. supports-color returns undefined — its detection (env + isTTY) isn't resolving; chalk's level is computed once at import and never sees FORCE_COLOR.
3. chalk.green('x') returns an empty object at level 0 instead of the passthrough string.

Net: ink layout (flexbox/taffy, borders, padding, margins, nesting, list maps) works fully; ink text styling (color/bold/dim/italic) does not yet. Retitling scope to the chalk color-level path.

[proggeramlug]

Root-caused — two coupled bugs

Dug into why chalk emits zero color in compiled binaries. It's two bugs, and they're coupled.

Bug 1 (fixed): Node package-imports (#-subpath) don't resolve

chalk does import supportsColor from '#supports-color', resolved via its package.json imports map. Perry didn't resolve #-prefixed specifiers at all:

Warning: Could not resolve import '#supports-color' from index.js

→ supportsColor undefined → chalk forces level = 0 → no color, ever.

Fix (branch fix-ink-color-5039, commit e1ec91aea): resolve #-imports through the owning package's imports map, preferring the node condition over default/browser (Perry is a native, Node-like target, so it must get the real supports-color, not the always-off browser stub). With this, chalk.level detects correctly — 3 under FORCE_COLOR=3 or a TTY, 0 when piped (matching Node).

Bug 2 (the blocker): inherited accessor getters on a closure receiver get the wrong this

Fixing Bug 1 alone regresses ink into a crash: once supports-color loads, chalk activates its lazy builder-cache getters, and ink throws:

TypeError: Cannot redefine property: cyan

chalk's pattern (paraphrased):

for (const name of styleNames) {
  Object.defineProperties(Ctor.prototype, { [name]: { get() {
    const builder = makeBuilder();
    Object.defineProperty(this, name, { value: builder }); // self-shadow on the instance
    return builder;
  }}});
}
const chalk = (...s) => s.join(' ');
Object.setPrototypeOf(chalk, Ctor.prototype);

Minimal repro (s8):

function Ctor() {}
Object.defineProperties(Ctor.prototype, {
  green: { get() {                       // NOTE: no `configurable: true` (chalk's shape)
    const b = (...s: any[]) => 'S:' + s.join('');
    Object.defineProperty(this, 'green', { value: b });
    return b;
  }}
});
const c: any = (...s: any[]) => s.join(' ');
Object.setPrototypeOf(c, Ctor.prototype);
c.green('A');   // → TypeError: Cannot redefine property: green

Root cause: the inherited getter is invoked with an inconsistent this — sometimes the receiver c, sometimes the prototype (the accessor's owner). When it's the prototype, the getter's Object.defineProperty(this, 'green', {value}) tries to redefine the prototype's own non-configurable accessor → throws. (A marker test confirms both c and Ctor.prototype receive the getter's this writes.)

Narrowing that pins it:

• Plain-object receiver + inherited accessor + self-shadow → works (s4).
• Object.defineProperty singular, configurable: true → works (masks it; redefining the configurable proto accessor is allowed).
• Object.defineProperties on a function prototype, no configurable (chalk's exact shape), closure receiver → fails.
• External defineProperty(c, 'green', {value}) (not from inside the getter) → works (s9); only the re-entrant in-getter case fails.

So the bug is specific to inherited accessor this-binding on function/closure receivers in the property-get / method-call dispatch path — same class of deep object-model issue as #5024.

Status / next step

• Bug 1 fix is ready on fix-ink-color-5039 but must not land alone (regresses ink). It needs to pair with the Bug 2 this-binding fix.
• Bug 2 is the core blocker. With both, ink renders in full color.

Repros s4–s10 available; happy to attach.