[Exploration] Configure per feature with packages

[michael]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
svedit	Ready	Preview, Comment	Jul 6, 2026 6:32pm

[michael]

I’m a bit torn here. On one hand, it’s nice to group related functionality together, and to keep things like node_layouts right next to the component registry.
But at the same time, the whole thing becomes harder to understand and more magical. Packages are often not truly independent. For example, in the page package you can no longer simply list the allowed node_types; instead, you’d need some dynamic hook that resolves them depending on which packages are registered.
So the “body nodes” would have to register themselves as such in their own package, and the page package would collect them. But then the ordering has to be right too: independent packages first, and the page package last.
That’s why, back in Substance, we had this “configurator” with its own API, which recorded things in one place so they could be read back elsewhere.
But somehow that doesn’t feel quite right to me.

@johannesmutter what do you think, do you like the direction described here?

[johannesmutter]

Let me first describe my devx pain here:

I'm using svedit now in 9 parallel running active projects, all very different on their surface, but also very similar in certain mechanics, e.g. all have a text node for heading, paragraph, with the same architecture, or a media block (with pipeline) or Slash Menus.

In the most recent projects I have perfected the editing ergonomics for e.g. the TextBlock. But bringing them back to the repos that starter earlier is an effort ... haven't tried though to just ask an agent to do this work for me ... but if these components were from the start authored in a more isolated way, swapping them out would be much easier and code / UX wouldn't drift as much as it does now.

Installing shadcn components is quite close to an ideal experience: everything nicely packaged.

So in principle I like the package structure from the PR, and that it stays flat:

There is no plugin runtime or registry — a package is just an object, and after composition the result is indistinguishable from a hand-written flat config. The flat style (as used in src/test/create_test_session.js) remains fully supported.

It also reminds of the Block Protocol. Their value proposition was: "Add new blocks to your app with zero marginal implementation cost". The implementation cost is gone now. But the systems thinker in me still things this is right path.

A human will prefer cleanly separate modules.
An LLM model doesn't care, or might actually prefer all in one place, due to less tool calling and folder browsing.

So this might boil down to the question: who will be the primary author of Node schemas and components?

[michael]

Thanks for the comments!

Need to reflect more on this, just leaving this here as an experiment for later inspiration for now. It's a controversial topic. I see a lot of projects (especially libraries) moving towards less modularization and config interpretation. e.g. Wordgard (ProseMirror successor).

The real use case for packages is on the app level, when you want defined extension points. Only the app knows which extension points to offer. E.g. Svedit doesn't know about a toolbar, but the app might let you configure tools that show up depending if a package is imported or not.

So I feel like I might soon try that same thing, but in the Editable app. I feel like I can come up with a configurator pattern for Editable specifically, but not with a generic one that Svedit exposes. I guess Svedit better stays low-level, and hackable to the core.

I think sharing functionality across projects like that one TextBlock package is a legit goal but usually backfires, as each app needs something else a little bit and has different assumptions. At least it's super hard to get universal "core commons" that are consumed by multiple projects. Marijn also commented on HN that he has a lot of same code in CodeMirror and Wordgard, but keeps it separate as that's less hassle than trying to make them generic 100% and maintain them in a shared place.