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
Background
PR is here: #3262
As of SpacetimeDB v1.4 (this PR), the
@clockworklabs/spacetimedb-sdkhas been dependent on the internalspacetimedbpackage 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-sdkis configured to bundlespacetimedbinto itself so it doesn't requirespacetimedbto 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/reactThe 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/reactare dependent on
spacetimedbthe types in the two bundles don't match when you try to use these packages together. This means that we would need to stop shippingspacetimedbbundled into@clockworklabs/spacetimedb-sdkand@clockworklabs/spacetimedb-sdk/react.On reflection however, @JulienLavocat and @cloutiertyler feel that we should probably just be using the
spacetimedbpackage name as a simpler way of having users usespacetimedband thus what we should really do is have:spacetimedbspacetimedb/libspacetimedb/sdkspacetimedb/reactAnd so forth. This would also give us an opportunity to drop the provenance and complex/different deploy process of
@clockworklabs/spacetimedb-sdk