4 Commits

Author	SHA1	Message	Date
Noa	cc73953787	Typescript views (#3584) ... # Description of Changes Currently need changes from both #3548 and #3527, and the latter is merged into master but the former isn't rebased on top of it. so we stay silly for the moment I'd like to pull out my first commit into its own PR, but that's not really possible until #3548 rebases onto master. # Expected complexity level and risk 2 - pretty straightforward translation of the wasm/Rust view implementation to typescript. # Testing - [ ] <!-- maybe a test you want to do --> - [ ] <!-- maybe a test you want a reviewer to do, so they can check it off when they're satisfied. -->	2025-11-07 21:10:43 +00:00
Piotr Sarnacki	647be7e9c0	spacetime init rewrite (#3366) ... This is a draft of the new functionality for `spacetime init`. In order to run it with built-in templates you have to set the path to the config file: ``` export SPACETIMEDB_CLI_TEMPLATES_FILE=crates/cli/.init-templates.json ``` In the future it will fetch the list from GH. A few notes: * the previous functionality of `spacetime init` does not work at the moment * the code needs a bit more cleanup and tests before merging * there is a bit of a mix in how we generate empty server and client projects. For Rust we use the existing way of generating. For TypeScript we clone an empty project from the repo. I wanted to play with both ways of doing things, and I'm still not sure which is better. Generation in Rust means that the generated code will match the CLI version and not necessarily whatever is in Git. On the other hand, for the builtin templates we will be fetching the newest version from GH, which I guess might also not what we want, ie. we probably want only stable templates. More discussion is needed here * we use `spacetimedb` directory for the server files * I don't particularly like the inability to disable interactive mode easily. We discussed disabling it by default if all of the required arguments are passed, but I don't think it's feature proof. For example, if someone relies on a non-interactive mode, and we add a new required argument, instead of printing a message `missing --foo`, we will automatically launch interactive mode, which is harder to debug. That's why I think I'd prefer to implement `--non-interactive` argument * it's kind of hard to keep the legacy behaviour. If you don't pass any arguments, we go into interactive mode. In the legacy version, we would print required arguments. If someone passes `--lang` or `--project-path` explicitly, I guess we could run the legacy workflow, but not sure if it's worth it, as the command was marked as unstable anyway * the project path defaults to the project name, but I think we should probably replace change whitespaces to dashes, or at least ask for the project path with the project name being the default (or both) --------- Signed-off-by: Tyler Cloutier <[email protected]> Signed-off-by: John Detter <[email protected]> Co-authored-by: = <[email protected]> Co-authored-by: Tyler Cloutier <[email protected]> Co-authored-by: Tyler Cloutier <[email protected]> Co-authored-by: John Detter <[email protected]>	2025-10-30 04:26:08 +00:00
Tyler Cloutier	58d299ea42	Removed @clockworklabs/typescript-sdk in favor of spacetimedb (#3262) ... # Description of Changes This PR removes the `@clockworklabs/typescript-sdk` from the repository and retains only `spacetimedb` in the `crates/bindings-typescript` directory. Some files are migrated to `spacetimedb`. I have also updated the appropriate READMEs. In addition I have symlinked the old `sdks/typescript` directory to point to `crates/bindings-typescript`. # API and ABI breaking changes This is not technically a breaking change of any kind, although it does orphan and deprecate the [@clockworklabs/spacetimedb-sdk](https://www.npmjs.com/package/@clockworklabs/spacetimedb-sdk) npm package. This package will no longer work with SpacetimeDB. Users should now install and use the `spacetimedb` package. # Expected complexity level and risk 2, it's a straightforward change but affects many files. # Testing - [ ] I ran `pnpm test` in the `spacetimedb` package - [ ] I ran the quickstart app --------- Co-authored-by: Zeke Foppa <[email protected]>	2025-09-23 00:25:24 +00:00
Tyler Cloutier	c83f55f65e	Refactors TypeScript into a single spacetimedb package (#3248) ... # Description of Changes This PR moves most of the contents of `@clockworklabs/spacetimedb-sdk` into the `spacetimedb` module. The `spacetimedb` module now exports `sdk` and `server` as separate subpaths where `sdk` contains the code which was previously in `@clockworklabs/spacetimedb-sdk`. In particular it makes the following moves: - `/sdks/typescript/packages/sdk` -> `/sdks/typescript` - most of the contents of `/sdks/typescript/packages/sdk` -> `crates/bindings-typescript` - `/sdks/typescript/packages/test-app` -> `crates/bindings-typescript/test-app` The following packags was NOT moved: `/sdks/typescript/examples/quickstart-chat` ## Motivation In accordance with https://github.com/clockworklabs/SpacetimeDB/issues/3250, we would like to consolidate `@clockworklabs/spacetimedb-sdk` into a single `spacetimedb` package so that users can import the different things they need from a single package. ### Pros: - allow users to install a single package with subpaths `spacetimedb`, `spacetimedb/react`, `spacetimedb/sdk`, `spacetimedb/server`, etc. - Is much simpler for bundling, etc. - Is backwards compatible with `@clockworklabs/spacetimedb-sdk` which now becomes a thin wrapper - eventually allow us to break up the `spacetimedb` package into other packages if we want to split them up (e.g. `@spacetimedb/lib`, `@spacetimedb/sdk`, etc.) and we can solve the build complexity that introduces when we get to it - eventually allow us to move `bindings-csharp` out of the crates directory where it probably doesn't belong anyway - organizes all TypeScript packages into the packages directory where you'd normally expect them, with the possible exception of `/sdks/typescript` if we wanted to leave that separate ### Cons: - The `sdk` directory is now a bit of a ruse as to where the code actually lives since it's just a thin wrapper. If it eventually becomes its own independent package, we'll also have to break up spacetimedb into `@spacetimedb/lib` and `@spacetimedb/server` so that `@clockworklabs/spacetimedb-sdk` can depend on `@spacetimedb/lib` while being a dependency of `spacetimedb`. Ideally this change would have been made later, however, it became necessary for the following **heinously disastrous chain of forcing moves**: 1. Adding `react` support necessitated shipping react as an optional peer dependency under `@clockworklabs/spacetimedb-sdk/react` 2. This required adding a new build target/export/bundle 3. Previously `@clockworklabs/spacetimedb-sdk` was configured to have `noExternal` for `spacetimedb` meaning it would collect the library into the sdk bundle. I attempted to continue this for react support but... 4. Creating a new `react` bundle which also pulled in `spacetimedb` caused their to be nominal type conflicts between classes in the duplicate `spacetimedb` bundles. 5. Changing `spacetimedb` to be included as `external` caused compile errors because `@clockworklabs/spacetimedb-sdk` is configured in `tsconfig.json` to fail on unused variables and it was now including the source of `spacetimedb` which is not configured to error on unused variables and has "unused" private variables which are actually used by us secretly, but not exposed to the clients. > SIDE NOTE: The unused variables settings cannot be turned off on a line by line basis, so it has to be turned off entirely, but in order to maintain the linting checks we had I used `eslint` to enforce the rule so that we could disable it line by line. (This caused me to discover quite a lot of things that were broken that were caught by `eslint` being applied to the entire project. `eslint` was previously only applied to the `quickstart-chat` and the `crates/bindings-typescript` library) 6. Changing the build to be external, now requires `spacetimedb` to also be published to npm as its own module which `@clockworklabs/spacetimedb-sdk` now imports, which requires that we add `tsup` config to `spacetimedb` to publish a built version of the library. 7. The only way to avoid that is to move the `sdk` and `react` code from `@clockworklabs/spacetimedb-sdk` into the existing `spacetimedb` package to avoid the duplicate import problem on step 4 and change `@clockworklabs/spacetimedb-sdk` back to again use `noExternal` for its `spacetimedb` dependency. And here we are. I chose not to move `/crates/bindings-typescript` even though that's probably not a great place long term. It would be better to have it in `/packages/spacetimedb` or `/npm-packages/spacetimedb` or `/ts-packages/spacetimedb` or something, and move all our TypeScript packages in there. But that is a different matter. The net result however is that we have a new `spacetimedb` package which exports the different parts of the API under: - `spacetimedb` - `spacetimedb/server` - `spacetimedb/sdk` - `spacetimedb/react` while still not breaking the existing deploy process, nor any users/developers who are currently using `@clockworklabs/spacetimedb-sdk`. I think long term should we ever decide to split `spacetimedb` up into multiple packages or if we have additional unrelated packages, we should publish them to the `@spacetimedb` org which I reserved for us here: https://www.npmjs.com/org/spacetimedb > NOTE: `spacetimedb` is a package and `@spacetimedb` is an org. `spacetimedb/sdk` is not a separate package, it's a subpath export of the `spacetimedb` package, whereas `@spacetimedb/sdk` would be (and would need to be) it's own separate package. You can certainly have both `spacetimedb/sdk` and `@spacetimedb/sdk`. We could for example host the code for the sdk at `@spacetimedb/sdk` and just reexport it from `spacetimedb` under the `spacetimedb/sdk` subpath. # API and ABI breaking changes This should not change or modify the API or ABI in any way. If it does so accidentally it is a bug, although I carefully went through the exports. # Expected complexity level and risk 3 because it changes how the SDK is built a bit and rearranges a lot of paths. # Testing - [x] All of the CI passes - [x] I also ran quickstart-chat to confirm that it is not broken - [x] I also ran test-app	2025-09-19 19:33:45 +00:00