PROD-58888: support jarvis-emitter v3 (meaco 2.0.0) - #1
Merged
Conversation
Bump jarvis-emitter peer to ^3.0.2 and bump meaco to 1.1.0. Add a duck-type fallback in the JarvisEmitter detection branch in index.js so coroutines correctly await JarvisEmitter subclasses (e.g. NPPHandler) and tolerate cases where two jarvis-emitter copies coexist in the resolved module tree — `instanceof JarvisEmitter` returns false across duplicate copies because the class identities differ. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates meaco to support jarvis-emitter@3.x and improves coroutine yield detection so JarvisEmitter-like objects (including subclasses and scenarios with duplicate installed copies) are awaited correctly.
Changes:
- Bump
meacoversion to 1.1.0 and updatejarvis-emitterdependency range to ^3.0.2. - Extend the JarvisEmitter detection branch in
index.jswith a duck-typing fallback (done/callDone).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| package.json | Version bump + widen jarvis-emitter dependency range to v3. |
| index.js | Add duck-typed JarvisEmitter detection to handle subclasses / duplicate installs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
3 tasks
Address PR review:
- Guard the JarvisEmitter detection branch with
`typeof promise === "object" && promise.constructor` before reading
`.constructor.name`, so a null-prototype yield (e.g. Object.create(null))
falls through to callDone instead of throwing TypeError.
- Add three mocha specs covering the duck-type fallback that this PR
introduced:
1. Yielding an emitter-like object that fails both
`instanceof JarvisEmitter` and `constructor.name === "JarvisEmitter"` —
the gen2/NPPHandler scenario where two jarvis-emitter copies coexist.
2. Error path on the same emitter-like object — verifies the error
registerer is wired up correctly on duck-typed objects.
3. Null-prototype yield falls through cleanly to callDone instead of
crashing the coroutine runner.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per PR review, the packaging intent is that consumers provide the JarvisEmitter implementation — meaco both returns JarvisEmitter instances and checks `instanceof JarvisEmitter` against the consumer's copy. Listing it as a regular dependency invited nested duplicate copies (the root cause of PROD-58888 itself: meaco@1.0.4's "jarvis-emitter": "^2.0.4" forced a nested v2 alongside the framework's hoisted v3). Move to peerDependencies (npm 7+ enforces a single shared copy across the tree) and add to devDependencies so the mocha suite can install its own copy for local testing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Keep jarvis-emitter under dependencies — matches meaco@1.0.x packaging and is invisible to existing consumers (who all declare jarvis-emitter directly anyway). Peer-dep semantics would risk install-time warnings/regressions on older npm without adding meaningful protection, since the duck-type fallback added in this PR already handles the duplicate-class-identity case at runtime. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
nirhen
reviewed
May 17, 2026
nirhen
left a comment
There was a problem hiding this comment.
Semver concern on the version bump — see inline comment on package.json.
Per review (nirhen): bumping the range from ^2.0.4 to ^3.0.2 under a meaco minor bump (1.0.3 -> 1.1.0) silently forces every meaco@^1 consumer onto a transitive major upgrade. Per semver this would require meaco@2.0.0. The duck-type fallback added in this PR already handles both v2 and v3 emitter shapes at runtime (.done/.error/.catch/.callDone are unchanged across majors). Accepting both ranges lets npm dedupe to whatever the consumer's tree already has, avoiding the two-copies-in-tree scenario this PR was written to fix for one caller — and not reproducing it for every other consumer who happens to be on v2. Verified by running the mocha suite (9/9) against both jarvis-emitter@2.1.4 and @3.0.2. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per review (nirhen): widening the jarvis-emitter range under a minor bump silently forces a transitive major upgrade on every meaco@^1 consumer. The correct semver move is to release this as meaco@2.0.0 with jarvis-emitter pinned to ^3.0.2 (caret — future 3.x patches and minors are picked up automatically without further meaco bumps). In the mceSystems ecosystem this is also the more honest call: every internal consumer (mce/gen3, mce-2nd-gen/gen2, libijs, mce-aura-agent) is migrating to jarvis-emitter@3 in lockstep with this release. No consumer is staying on v2, so the OR-range was hedging against a population that doesn't exist here. The duck-type fallback and null-prototype guard added earlier in this PR remain — they protect against subclass detection (e.g. NPPHandler) and any future duplicate-copy scenario regardless of version pin. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
erezmce
approved these changes
May 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
1.0.3→2.0.0.dependencies."jarvis-emitter"^2.0.4→^3.0.2(caret — future 3.x picked up automatically).index.jsso coroutines correctly await JarvisEmitter subclasses (e.g. gen2'sNPPHandler) and tolerate cases where twojarvis-emittercopies coexist in the resolved tree (instanceoffails across duplicate class identities).Object.create(null)).Why a major bump
Bumping
jarvis-emitterfrom^2.0.4to^3.0.2is a transitive major upgrade. Per semver it can't ride a meaco minor — everymeaco@^1consumer would silently get a different jarvis-emitter major on their next install. So this PR releases asmeaco@2.0.0.In the mceSystems ecosystem this is also the honest framing: every internal consumer (mce/gen3, mce-2nd-gen/gen2, libijs, mce-aura-agent) is migrating to jarvis-emitter@3 in lockstep with this release.
Context — PROD-58888
The gen3 framework was upgraded to
jarvis-emitter@3.0.2while meaco@1.0.4 still pinned"jarvis-emitter": "^2.0.4". npm couldn't satisfy meaco's range from the hoisted v3 and nested a separate v2 copy undermeaco/node_modules/jarvis-emitter. TwoJarvisEmitterclass objects coexisted at runtime;instanceof JarvisEmitterreturnedfalsefor v3 instances created elsewhere (e.g. gen2'sNPPHandler extends JarvisEmitter) → meaco's detection atindex.js:37fell through → yieldedNPPHandlerreturned unresolved → device sessions closed ~1 s after connect.Two complementary fixes in this PR:
^3.0.2lets npm satisfy meaco's range from the framework's hoisted v3, so no nested duplicate is created.typeof promise.done === "function" && typeof promise.callDone === "function") keeps meaco robust if a future major mismatch slips through (e.g. a JarvisEmitter subclass with a differentconstructor.name). The null-prototype guard preventsTypeErroronObject.create(null)yields.Merge / release order
This PR is #1 of 5 across repos for PROD-58888:
meaco@2.0.0to npm^2.0.0jarvis-emitter+meaco(regenerate lockfiles at install time against published meaco@2.0.0)Test plan
npm test— 9/9 mocha specs pass (6 original + 3 new for duck-type detection and null-proto guard)npm installresolves a singlejarvis-emitter@3.0.2