feat: Bijou CSS Engine and Background Worker Runtime#39
Conversation
- Implement BCSS Engine with zero-dependency CSS parser - Implement BCSS Resolver supporting Specificity (ID > Class > Type) and Media Queries - Implement TokenGraph bridge in CSS via `var()` syntax for semantic color mapping - Integrate BCSS into the Rendering Pipeline via `bcssMiddleware` - Implement `runInWorker` to run TEA apps in Node.js background threads, keeping main thread responsive - Standardize `BijouNodeOptions` across core components (id, class, ctx) - Update `badge` to resolve global BCSS overrides
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c1c7e79b97
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return new Promise<void>((resolve, reject) => { | ||
| // Spawn the worker | ||
| const worker = new Worker(resolvePath(options.entry), { | ||
| workerData: { isBijouWorker: true, options }, |
There was a problem hiding this comment.
Avoid cloning non-serializable run options into workerData
runInWorker forwards the entire options object through workerData, but RunWorkerOptions inherits fields like ctx and middlewares that can contain functions and other non-cloneable values; when callers pass either of those, new Worker(...) throws a DataCloneError and the worker app never starts. This makes documented runtime options unusable in worker mode unless users manually avoid those fields.
Useful? React with 👍 / 👎.
| (ctx as any).resolveBCSS = (identity: any) => { | ||
| return resolveStyles(identity, sheet, { | ||
| width: ctx.runtime.columns, | ||
| height: ctx.runtime.rows, | ||
| }, ctx.tokenGraph, mode); | ||
| }; |
There was a problem hiding this comment.
Reset injected BCSS resolver after each run
This writes a stylesheet-specific resolver directly onto the shared ctx object, but nothing restores the original resolveBCSS when the app exits. If the same context is reused for a later run() call without options.css (for example via the global default context), components will still resolve styles from the previous stylesheet, causing cross-run style leakage.
Useful? React with 👍 / 👎.
# Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the commit.
- Upgrade canvas() to support high-resolution Braille (2x4) and Quad (2x2) plotting - Support rich cell output (char, color, bg) from fragment shaders - Implement normalized UV mapping (0.0 to 1.0) for resolution-independent shaders - Add uniforms registry for passing external state into the shader pipeline - Fix infinite loop bug in quad resolution renderer - Update canvas tests to verify high-res modes and UV normalization
Phase A of the RE-017 execution plan. Migrates remaining components to the theme cache fast path (fgRGB/bgRGB), adds three new bench scenarios that cover realistic workloads, and captures the Phase A baseline for measuring Part II. Component migration (task #38): - notification.ts: CellTextStyle extended with fgRGB/bgRGB; tokenToCellStyle now threads them through. - overlay.ts: CellStyle type extended; styleFromToken and backgroundStyleFromToken updated. - transition-shaders.ts: tokenCell helper updated. - app-frame-render.ts: active header tab override path updated. - Skipped css/text-style.ts (local StyledTextToken has no pre-parsed RGB; hot path already caches via parseHex once); box-v3.ts fallback (already has setRGB fast path); theme/graph.ts (not a rendering hot path). New bench scenarios (tasks #39, #40, #41): - diff-sparse: ~10% dirty cells per frame, realistic interactive updates. P50 349 µs at baseline. - diff-static: identical surfaces, zero changes. Reference target for II-1 render-dirty bitmap optimization. P50 227 µs — should drop to near-zero post-II-1. - dogfood-realistic: multi-region composition (header+sidebar+ body+footer). Cross-component regression gate for Part II. P50 469 µs. Phase A baseline (task #43): bench/baselines/HEAD-f966c72-phase-a.json. 30 samples each, all CoVs under 5% except paint-rgb-fixed (7.4% due to its 145 µs floor where OS jitter dominates). Numbers are trustworthy. Obsolete tasks moved to docs/graveyard/: - I-3 (custom baseline format) — bench v2 already ships one. - I-0d (render pipeline instrumentation) — I-0e confirmed the hex-parse hypothesis without needing general instrumentation. Full findings and Part II targets documented in docs/perf/RE-017-byte-pipeline.md. 2,807 tests pass. Typecheck clean across all workspace packages. Part II targets unlocked by this baseline: - diff-static: 227 µs -> ~0 µs (II-1 render-dirty bitmap skip) - diff-gradient: 2.08 ms -> <1.5 ms (II-4 byte pipeline) - dogfood-realistic: 469 µs -> <350 µs (combined II-1 + II-4) - diff-sparse: 349 µs -> <200 µs (II-1 + II-4)
Summary
This PR builds on the V3 Core Engine foundation, introducing a CSS-based styling system and multi-threaded application support.
Key Changes
var()syntax.idandclassproperties across all core components.