compilePackages: class extending React.PureComponent doesn't inherit `isReactComponent` on its prototype (2-level chain) → react-reconciler treats error boundaries as function components → children dropped (blocks ink)

[proggeramlug]

Summary

A class that extends React's PureComponent (i.e. two prototype levels up from React.Component) does not inherit the isReactComponent marker on its .prototype. react-reconciler's shouldConstruct(type) reads type.prototype.isReactComponent to decide ClassComponent (fiber tag 1) vs FunctionComponent (tag 0); when it reads undefined, the class is misclassified as a function component, its render() is never invoked as a class, and its children are dropped — the component renders nothing.

This is the wall after the Context.Provider classification fix (commit 81cfc6981, the labeled-break-from-nested-switch fix): ink's <ErrorBoundary> (class ErrorBoundary extends PureComponent) wraps the app's children, so the whole ink tree renders empty.

Minimal repro

import React from 'react';
const C: any = React.Component;
const PC: any = React.PureComponent;

console.log(typeof C.prototype.isReactComponent);          // Perry: "undefined"  (anomaly — see below)
console.log(typeof PC.prototype.isReactComponent);         // Perry: "undefined"

class X extends C  { render() { return null; } }
class Y extends PC { render() { return null; } }
console.log(typeof X.prototype.isReactComponent);          // Perry: "object"     ✓ (1 level: X → Component)
console.log(typeof Y.prototype.isReactComponent);          // Perry: "undefined"  ✗ (2 levels: Y → PureComponent → Component)

console.log(Object.getPrototypeOf(Y.prototype) === PC.prototype); // true
console.log(Object.getPrototypeOf(PC.prototype) === C.prototype); // true

Node prints object for all four isReactComponent reads.

The anomaly

React.Component.prototype.isReactComponent reads undefined directly, yet class X extends React.Component does observe it (object) via the chain. So the value is reachable one level up but:

• a direct read on Component.prototype misses it, and
• a two-level chain walk (Y → PureComponent → Component) misses it,

while a one-level walk (X → Component) finds it. The prototype links are all correct (getPrototypeOf checks pass). This points at a property-storage / prototype-chain-GET inconsistency specific to react's compiled component prototypes (PureComponent.prototype = Object.create(Component.prototype) shape), not generic inheritance — a plain user-land class Sub extends Base with Base.prototype.marker set does inherit correctly through two levels.

How it surfaced (ink, #348)

ink's App wraps children in <ErrorBoundary> (extends PureComponent). react-reconciler's shouldConstruct(ErrorBoundary) → ErrorBoundary.prototype.isReactComponent → undefined → shouldConstruct returns false → createFiberFromTypeAndProps leaves fiberTag = 0 (FunctionComponent) → ErrorBoundary is invoked as a function, its class render() never runs, this.props.children is never returned → the entire app subtree is dropped. Verified: return children from App renders; <ErrorBoundary>{children}</ErrorBoundary> renders nothing.

Impact

• Every class component that extends PureComponent (and likely any ≥2-level React component subclass) — error boundaries, many older libraries. They silently render as no-op function components.
• ink end-to-end (Compile ink (React-based TUI framework) end-to-end via perry.compilePackages #348): the wall after Context.Provider; ink lays out + renders natively otherwise (native taffy yoga + provider fix both working — text/boxes/colors render through bare/function/Fragment/Provider wrappers).

Related

• Compile ink (React-based TUI framework) end-to-end via perry.compilePackages #348 (ink end-to-end)
• 81cfc6981 (Context.Provider labeled-break-from-nested-switch fix — the previous wall)
• compilePackages: module.exports = class loses the class method table — static AND prototype methods read undefined (breaks stack-utils → ink) #4933 / fix(cjs_wrap): flat-emit module.exports = <Class> that closes over a top-level binding (#4933) #4947 (compiled-package class method-table loss — adjacent class/prototype family)

[proggeramlug]

Precise root cause (supersedes the prototype-chain theory above)

It's not prototype-chain inheritance — it's own-property enumeration of a function-constructor's .prototype. Expando properties written to F.prototype (for function F(){}) are stored such that direct GET works but the object's own-property key set does not include them, so Object.keys / getOwnPropertyNames / for-in / in / hasOwnProperty / Object.assign all miss them.

Minimal repro (no React)

function F(this: any) {}
(F.prototype as any).mark = { tag: 1 };

Object.keys(F.prototype);                                  // Perry: []            (Node: ["mark"])
Object.getOwnPropertyNames(F.prototype);                   // Perry: ["constructor"] (Node: ["constructor","mark"])
'mark' in F.prototype;                                     // Perry: false         (Node: true)
Object.prototype.hasOwnProperty.call(F.prototype, 'mark'); // Perry: false         (Node: true)

const t: any = {};
Object.assign(t, F.prototype);
Object.keys(t);                                            // Perry: []            (Node: ["mark"])

// control — a plain object source copies fine:
const src: any = { a: 1 }; src.b = 2;
const t2: any = {}; Object.assign(t2, src);
Object.keys(t2);                                           // Perry: ["a","b"]  ✓

So writing an expando to a function's .prototype doesn't register it in that object's own-key metadata (a plain object literal works fine). Direct F.prototype.mark GET returns the value, so the storage exists — it's just invisible to enumeration/Object.assign.

Why this breaks React class components

React 19 sets up PureComponent by copying Component.prototype onto PureComponent.prototype via Object.assign:

function Component(...) {}
Component.prototype.isReactComponent = {};          // expando on a function's prototype
...
PureComponent.prototype = new ComponentDummy();      // ComponentDummy.prototype = Component.prototype
Object.assign(PureComponent.prototype, Component.prototype);   // <-- meant to copy isReactComponent

Because Object.assign can't see Component.prototype's expando isReactComponent, PureComponent.prototype.isReactComponent ends up undefined. react-reconciler's shouldConstruct (type.prototype.isReactComponent) then returns false for any class X extends PureComponent, so it's classified as a FunctionComponent — its class render() never runs and its children are dropped. ink's <ErrorBoundary extends PureComponent> wraps the whole app → blank render.

Suggested fix area

When a property is written to a function's .prototype object, register it in that object's own-property key set (the same metadata Object.keys/getOwnPropertyNames/for-in/hasOwnProperty/Object.assign consult), exactly as for a plain object. The value is already being stored (direct GET works); only the own-key tracking is missing for function-prototype objects.

[proggeramlug]

Disambiguation — it's specifically the auto-created default function prototype object:

function F(){}
const p = F.prototype;
p === F.prototype;        // true (stable identity)
p.mark = {x:1};
Object.keys(p);           // []        ← write to the auto-created prototype isn't key-tracked
'mark' in p;              // false

function G(){}
G.prototype = { gmark:1 };  // REPLACE with a plain object literal
Object.keys(G.prototype);   // ['gmark']  ← a normal object tracks keys fine

So the auto-vivified F.prototype object stores expando values (direct GET works) but doesn't register them in its own-key metadata; a normal object literal assigned as the prototype works. Fix target: make the auto-created function-prototype object a normal own-key-tracking object (or register the key on write). This is the last blocker for ink #348 — with it fixed, ink renders its full <App> (7 context providers + ErrorBoundary) natively.