Repository navigation
refactor(engine): move the engine's node-free half into engine-core - #72
Conversation
The calls into the reactor, the lexer and the replay loop import nothing from Node, so a browser can host the same engine.wasm with a WASI shim of its own; src/engine.ts keeps loading it with node:wasi.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
There was a problem hiding this comment.
ℹ️ No critical issues. One gap in the build guard is worth a look.
Reviewed changes
This review covers the one commit that splits the engine host into a Node-free core and the Node loader.
src/engine-core.ts:EngineCore(call,lex, theanalyzereplay loop),fulfil,AnswerCacheand the request and answer types moved here unchanged. Its only imports are./connection.tsand./engine-type.ts(types only), and neither pulls in Node.src/engine.ts: re-exports everything from the core.Enginenowextends EngineCoreand keeps onlystatic load, which usesnode:wasi. Every caller's import 8000 still resolves, andEngine.loadstill returns anEngine.AGENTS.md: the file table now namessrc/engine-core.tsas the engine host's Node-free half.
ℹ️ The dist/reylo guard does not cover the new module
scripts/build.ts:63 fails the build when a run-time module pulls build-time code into dist/reylo. Today that check fires through src/engine.js. The analysis host now lives mostly in src/engine-core.js, and the regex does not list that file. If a run-time module imported ./engine-core.ts, the replay loop and AnswerCache would ship in reylo and the build would not complain. Nothing does that today, so this is about keeping the guard as strict as it was before the split.
Technical details
# Build guard misses `src/engine-core.js`
## Affected sites
- scripts/build.ts:63 — the regex `^src\/(tooling|analyze|engine|loader|commands|mapper-server)\.js$` does not match `src/engine-core.js`
## Required outcome
- A run-time import of `src/engine-core.ts` that drags it into `dist/reylo` fails `nub run build`, as an import of `src/engine.ts` does now. The other option is to decide that the core may ship in `reylo`, for example for a future browser entry, and say so in the comment above the guard.
## Open questions for the human
- Is the browser host meant to ship from `reylo` itself, or from an engine package or the docs site? That decides whether `engine-core` belongs in the guard.claude-opus-5-5 | 𝕏
|
Pullfrog's build-guard note: fixed in 2534e67. The |
There was a problem hiding this comment.
✅ No new issues found. The build guard gap from the last review is closed.
Reviewed changes
This review covers the one commit pushed since the last Pullfrog review.
scripts/build.ts: thedist/reyloguard regex now listsengine-core. A run-time module that imports./engine-core.tsnow failsnub run build, just as an import of./engine.tsalready did. Onlysrc/engine.tsimports the core today, so the build still passes.
claude-opus-5-5 | 𝕏

The calls into the engine's WASI reactor, the lexer, the replay loop that hands each round's needs to an
EngineIo, and the answer cache import nothing from Node. They move tosrc/engine-core.tsasEngineCore, with the request and answer types, so a browser can host the sameengine.wasmwith a WASI shim of its own.src/engine.tsre-exports them and keepsEngine.load, which loads the artifact withnode:wasi; every caller is unchanged.Verified:
nub run typecheck,nub run testagainst throwaway Postgres 18 and MySQL 8.4 (223 pass, none skipped), andnub run build.