Can I add another block from another registry as dependency?

[mmailaender]

I have the registry @auth/svelte and one of the files is importing
$lib/primitives/ui/avatar
which is not part of this registry. So I would like to define it as dependency to another block in another registry where the primitives are stored, so they get automatically fetched.

Is that somehow possible?
Something like

"blocks": [
  {
    "name": "UserProfile",
    "blockDependencies": ["@primitives/svelte@avatar"]
  }
]

[ieedan]

Currently no, I've thought about whether or not this is a good idea. Because depending on an external registry like this can easily cause your code to break if the the code changes in the original registry. It's easier to just have the code in your project and then there is no chance of it breaking unexpectedly

[mmailaender]

The problem that you describe sounds to me the same like what we have with classic npm dependencies.

The registry provider needs to ensure in both cases that his blocks are compatible with the referenced npm package/jsrepo registry version. So if he bumps the referenced registry/package he also needs to test if his shipped blocks are still working.

I see this a big benefit as I can tell the user "if you install or update this block I ensure you that the dependent registry block/package also works in the specified version". If I can't specify it, it could easily happen that the user installs a dependent block/package in a version that is incompatible/untested (+ the delightful convenience to run only one command and everything gets set-up).

Or am I overseeing something how jsrepo works?

[ieedan]

Requiring dependent registries to be versioned through jsrepo would absolutely be necessary. One issue we'd have to get over is how to actually validate that the code in the users project is not modified in any way from the source registry at the specified version. We would possibly have to do something weird like overwriting the existing block with the version the user specified.

The idea would be that it should be almost impossible to break a users code with jsrepo, it should build and distribute code in a way that there is no doubt that when it gets to the end user it will work as expected which just isn't a guarantee something like shadcn can give atm.

[mmailaender]

Yeah, I think I get what you mean. Let me try to put it into my own words:

Problem example

• Registry GREEN publishes version A which depends on BLUE v1.
• Registry GREEN publishes version B which depends on BLUE v2.

Now imagine the user installs GREEN-A (with BLUE-1) but later customizes BLUE-1 into a BLUE-1-CUSTOM version.
If they now upgrade to GREEN-B, they also need to move from BLUE-1 → BLUE-2. But since they diverged into BLUE-1-CUSTOM, they need a migration path to get from BLUE-1-CUSTOM → BLUE-2.

Comparison to npm

When starting fresh, npm and jsrepo behave similarly:

• Both install blocks/packages along with their dependencies (npm into node_modules, jsrepo into userland).
• Both use immutable versions, ensuring an idempotent install result.

But during upgrades the behavior diverges:

• npm: Packages are immutable after installation, so the upgrade path is deterministic and idempotent.
• jsrepo: Blocks are mutable after installation, which allows user customizations—but this makes migrations necessary if the user has modified the shipped code (see Problem example).

Thoughts

As you also already stated, allowing users to alter shipped code is powerful but inherently risky. It means upgrades may require migrations, and I don’t think that problem can be completely eliminated—it’s part of the model.

That said, I believe we can reduce the migration burden significantly if jsrepo could detect when the user modified the code. For example, an “intelligent upgrade mechanism” that understands the relation between BLUE-1, BLUE-1-CUSTOM, and BLUE-2, and helps merge/migrate without losing user changes. Like I mentioned here: #585

Summary

• Add an intelligent update mechanism to support merging/migrating customized blocks.
• Add blockDependencies so registries can explicitly declare dependencies between blocks.

[ieedan]

Yeah this would have the same issues as block versioning where you'd need a way to track versions of the block in a lock file or some other way