-
Notifications
You must be signed in to change notification settings - Fork 599
Description
Background
PR is here: #3262
As of SpacetimeDB v1.4 (this PR), the @clockworklabs/spacetimedb-sdk
has been dependent on the internal spacetimedb
package which is at /crates/bindings-typescript
. I believe (not strongly) that our existing deploy process will continue to work however because I believe @clockworklabs/spacetimedb-sdk
is configured to bundle spacetimedb
into itself so it doesn't require spacetimedb
to be published to npm separately.
However, with the addition of React hooks we would like to begin shipping different features as separate packages, e.g.:
@clockworklabs/spacetimedb-sdk
@clockworklabs/spacetimedb-sdk/react
The way that package scoping works is that these are just two different packages. However because of the fact that TypeScript classes are nominally typed, since both
@clockworklabs/spacetimedb-sdk
@clockworklabs/spacetimedb-sdk/react
are dependent on spacetimedb
the types in the two bundles don't match when you try to use these packages together. This means that we would need to stop shipping spacetimedb
bundled into @clockworklabs/spacetimedb-sdk
and @clockworklabs/spacetimedb-sdk/react
.
On reflection however, @JulienLavocat and @cloutiertyler feel that we should probably just be using the spacetimedb
package name as a simpler way of having users use spacetimedb
and thus what we should really do is have:
spacetimedb
spacetimedb/lib
spacetimedb/sdk
spacetimedb/react
And so forth. This would also give us an opportunity to drop the provenance and complex/different deploy process of @clockworklabs/spacetimedb-sdk