Operix Node — looking for a JS/TS maintainer (and thinking of you, @MiguelDomingues 🦎)

[julienmerconsulting]

Hey @MiguelDomingues 👋 — I've just listed oculix-vscode in the OculiX README and proposed moving it into the org over on your repo (separate issue). Here's a parallel conversation that may or may not interest you — same low-pressure spirit.

Operix already has a Node.js seat at the table

Operix is the umbrella for non-JVM language bindings around OculiX core. The repo already has four parallel folders — dotnet/, nodejs/, python/, jvm-bridge/ — each with its own CDC (cahier des charges, the spec doc) at the root: CDC-Operix-DotNet.md, CDC-Operix-NodeJS.md, CDC-Operix-Python.md.

The Python one is the most mature today (published as oculix on PyPI since June). The C# one is being sketched. The Node.js one is the one where the structure is drafted but no maintainer has taken the wheel yet.

What's already in nodejs/

• TypeScript source structure scaffolded (src/, tests/, package.json, tsconfig.json, README)
• Gateway lifecycle management drafted (spawning a child JVM as a JSON-RPC server via stdin/stdout, avoiding repeated JVM launches and the JNI complexity)
• API surface designed to mirror the Python one: Screen.click / type / wait / exists / capture, App.open / focus / close, Pattern similarity matching, VNCScreen, ADBScreen, PaddleOCR wrapper classes — all async/await
• Seven hybrid usage examples drafted (Jest, Playwright + OculiX hybrid, VNC remote testing)
• A risk-mitigation table already written

What's left

• Implement the Java RPC server (~150 lines) inside jvm-bridge/
• Wire the Maven build for the bridge JAR
• CI/CD across Win/Mac/Linux
• npm publication + docs polish

The roadmap in the CDC estimates 1.5 weeks of focused work to ship npm install oculix to the JS/TS ecosystem (Playwright tests + Jest + Mocha workflows + Node-based CLIs).

Why I'm thinking of you specifically

Your VS Code extension already solves what is essentially 80% of the same mental model — consuming OculiX as a JAR runtime from a TypeScript world. You've already worked out JAR resolution, IPC patterns from Node, multi-monitor capture, DPI awareness, cv2.matchTemplate from JS. That's exactly the muscle that makes the Operix Node leg viable. The remaining 20% is mostly making the RPC server clean enough to be shared across languages.

What I'm asking, concretely

Nothing committal. Two open questions:

1. Does this interest you at all as a parallel track alongside oculix-vscode, or do you feel your extension is already where your JS/TS energy should go? Both answers are fine — your VS Code extension alone is a major contribution and I'm not trying to redirect that energy.
2. If yes: I've given you read access to the Operix repo so you can poke around the structure and the CDC at your own pace. No pressure to commit anything until you've looked and feel the architecture fits how you'd want to build it. If you tell me "I want to drive this", I bump your access to write/admin on nodejs/ and we coordinate from there — same model as the oculix-vscode proposal: you stay the decision-maker on the Node track, I don't override.

The CDC is at https://github.com/oculix-org/Operix/blob/main/CDC-Operix-NodeJS.md and the existing scaffold at https://github.com/oculix-org/Operix/tree/main/nodejs — give it a glance whenever you have a free hour, then ping me back here with whatever your gut says.

And if the answer is "not for me right now", totally fine. The Node leg will wait for the right contributor — better the right one later than the wrong one now.

🦎 — Julien

[MiguelDomingues]

Unfortunately, at the moment I'm not able to provide the necessary time for this.