feat(solid): [WIP] Add wrapper implementation for SolidJS as @superdoc-dev/solid

[msviderok]

Summary

Adds SolidJS wrapper package @superdoc-dev/solid.

This PR introduces a Solid-native SuperDocEditor component which is practically identical to @superdoc-dev/react with the only differences being the framework-specific lifecycle/state management parts.

What Changed

• Added packages/solid as a new workspace package
• Implemented SuperDocEditor for SolidJS
• Copied and adjusted all the .md and config files to match packages/react
• Added Solid-specific TypeScript types derived from the core superdoc constructor config
• Copied and modified SuperDocEditor.test.tsx from `packages/react to keep the tests intact in terms of logic/behaviour/visual aspects
• Added semantic-release config and scripts/publish-solid.cjs for publishing @superdoc-dev/solid
• Updated workspace/catalog dependencies and lockfile with the Solid-related packages

What differs from packages/react

• Miscellaneous files:
  • "find-and-replace"-ed React to Solid
  • changed examples in .md files to adhere to Solid practices
• src/utils:
  • the only utility needed is shallowJsonEqual due to fine-grained reactivity of Solid negating the need for the rest of React-specific ones
  • test file is unnecessary as the original one didn't cover shallowJsonEqual

Testing

• Added packages/solid/src/SuperDocEditor.test.tsx
• Solid package can be tested with:

pnpm --filter @superdoc-dev/solid test

Next changes

• add "Getting Started" example for SolidJS

⚠️ For some reason, `SuperDocEditor.test.tsx` testsuite passes _**but**_ with a post-error. Currently, I'm in progress resolving this issue, related to: [discord conversation](https://discord.com/channels/1299087524056010902/1472961164886671624/1504451997494149241)

TypeError: Cannot read properties of undefined (reading 'state')
 ❯ createCommentForTrackChanges ../superdoc/dist/superdoc.es.js:3455:30
    3453|    }
    3454|   });
    3455|   const { tr } = editor.view.state;
       |                              ^
    3456|   tr.setMeta(CommentsPluginKey, { type: "force" });
    3457|   editor.view.dispatch(tr);
 ❯ bootstrapImportedTrackedChangeComments ../superdoc/dist/superdoc.es.js:3333:3
 ❯ Timeout._onTimeout ../superdoc/dist/superdoc.es.js:3383:4
 ❯ listOnTimeout node:internal/timers:605:17
 ❯ processTimers node:internal/timers:541:7

Test Files  1 passed (1)
      Tests  20 passed | 3 skipped (23)
     Errors  12 errors

Seems to only be happening locally, all good with CI.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b2cdf130e9

ℹ️ 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".

[chatgpt-codex-connector]

Remove documentMode from rebuild dependencies

Including restProps.documentMode in the main createEffect dependency list causes a full destroy/recreate cycle every time mode changes, even though this component already has a separate effect that imperatively calls setDocumentMode. In practice, toggling between viewing/editing will reinitialize SuperDoc (showing loading again and tearing down the current instance), which can drop transient editor state and defeats the intended efficient mode switch behavior.

Useful? React with 👍 / 👎.

[msviderok]

Fixed

[caio-pizzol]

hey @msviderok, thank you for putting this together. The constructor-based type extraction is a good direction, and I appreciate that you carried over the SD-2635 prop-stability coverage from the React wrapper instead of treating this as just a thin copy.

After discussing the package scope, we're keeping first-party framework support focused on React and Vue, where we have the maintenance bandwidth and the demand signal. The maintenance burden of a new framework wrapper is real, and we don't see that signal for Solid yet, so we're not going to merge @superdoc-dev/solid into the monorepo.

That said, this would be very welcome as a community-maintained wrapper under a non-SuperDoc namespace, for example superdoc-solid or @msviderok/superdoc-solid. Once it's stable, we can also link it from the README/docs ecosystem section as a community integration.

Closing this out as out-of-scope for the monorepo, not as a quality bar - the work is good, the scope is the call.

[caio-pizzol]

Technical notes from our pass, in case you want to publish this as a community wrapper:

• document prop changes currently don't rebuild the SuperDoc instance.
• documentMode currently calls setDocumentMode() and then rebuilds, which loses instance state.
• pnpm --filter @superdoc-dev/solid run test needs @testing-library/jest-dom in devDependencies; setupFiles: [] does not opt out of vite-plugin-solid's injection.
• Consider tightening the superdoc dependency range so future 2.x releases do not install silently.
• Cleanup nits: React naming leftovers, shallowJsonEqual naming, and the dynamic import workaround if it is not load-bearing.