Declare solid-js as a peerDependency

[Karolk99]

@moq/publish, @moq/watch, and @moq/ui-core import from solid-js and solid-js/web, but solid-js was only listed in devDependencies. Since common/package.ts strips devDependencies at release time, the published package.json files declared no solid-js at all, while their JS still contains bare import "solid-js" statements.

Consumers ended up with either an unresolved import or two Solid runtime instances loaded side-by-side. Because Solid's delegateEvents is a per-runtime singleton, UI components rendered by these packages registered click handlers on a different runtime than the one wired up to the host app, so buttons appeared inert.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fa85917b-56a0-4c17-a3f4-b6b334e2fa84

📥 Commits

Reviewing files that changed from the base of the PR and between 6adf3c3 and 2ec7e96.

📒 Files selected for processing (3)

• js/publish/package.json
• js/ui-core/package.json
• js/watch/package.json

---

Walkthrough

This PR adds peer dependency declarations for Solid packages across three packages in the monorepo. js/publish/package.json now declares solid-element and solid-js as peer dependencies. js/ui-core/package.json adds solid-js to its peer dependencies alongside the existing @moq/signals. js/watch/package.json adds a new peer dependencies block declaring both solid-element and solid-js. These changes explicitly surface the required Solid packages to consumers of each package.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: declaring solid-js as a peerDependency across three packages to fix a runtime dependency issue.
Description check	✅ Passed	The description is well-related to the changeset, explaining the problem (solid-js only in devDependencies leading to runtime issues) and the solution (adding peerDependencies declarations).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

✨ Simplify code

• Create PR with simplified code

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[kixelated]

Okay so I'm not sure if I want solid-js as a peerDependency, but 100% bundling a second SolidJS runtime is not great.

We currently build moq/watch with vite so it inlines solid; there should be no import "solid" in the final NPM package. Can you double check?

[Karolk99]

I didn't realise Solid was being inlined. Inlining means each package ships its own Solid runtime, so the components can't be rendered inside the consumer app's Solid tree, which is the problem affecting @moq/watch/ui, @moq/watch/ui, and @moq/ui-core because they export raw Solid components.

One option is to mark solid-js as external in the Vite config across all packages; another is to do it only for the UI-focused ones (@moq/watch, @moq/publish, @moq/ui-core) and leave the ./element web-component entries alone but then u still have to import solid-js on your own.

Worth noting: after building locally with solid-js externalised, dist/ui/index.js went from 48 KB → 26 KB — that delta is the size of the Solid runtime that was previously being carried inside each package.

What do you think @kixelated?

[kixelated]

I don't really want to make solid an explicit dependency just for the UI web component. It hurts dev UX.

TBH I kind of want to revert the switch to solidjs and go back to the minimal moq/signals DOM library, since it's already a dependency. Solid feels like overkill for a simple, stock video UI.

And yeah ui-core is not supposed to be consumed by external users.

[Karolk99]

Sounds good — happy to close. Just one thing for the record: on the supported Web Component path ( + in a Solid app, no direct /ui imports), the overlay buttons fire, but their visual state doesn't update (play icon stays on play after pausing). Reactive signals seem not to cross between the inlined Solid in @moq/watch/element and the one in @moq/watch/ui. Probably moot once you move off Solid, but at the moment it doesn't work properly.