mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-09 00:59:46 -04:00
bot/docs-commitlog-reference
18 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 bradleyshep
|
e9ecfa9775 |
Keynote fixes/refinements (#4418)
# Description of Changes Integrate the `keynote-2` benchmark template into the pnpm workspace so it uses the local SpacetimeDB TypeScript SDK instead of a pinned npm version. - Add `templates/keynote-2` to `pnpm-workspace.yaml` and switch its `spacetimedb` dependency to `workspace:*` - Regenerate module bindings for SDK 2.0.1 - Update `DEVELOP.md`: bump Node.js prerequisite to ≥ 22.x (required by the SDK's use of `Promise.withResolvers`), update CLI commands to use `cargo run -p spacetimedb-cli --` for local development - Fix `build` script: use `tsc` only (keynote-2 is a Node.js CLI app, not a web app — `vite build` fails without an `index.html`) - Fix demo results display: treat 0 TPS as a failure (`✗ FAILED`) instead of showing it as a valid result and producing a nonsensical "Infinityx FASTER" comparison - Enable `LOG_ERRORS` by default in the demo so reducer failures are immediately visible instead of silently producing 0 TPS - Minor cleanup: fix unused variable warning in `init_sqlite_seed_in_docker.ts` # API and ABI breaking changes None. # Expected complexity level and risk 1 — Scoped entirely to the `keynote-2` template and its workspace integration. No changes to the SDK, server, or any other template. # Testing - [ ] Run `pnpm install && pnpm --filter spacetimedb build` from repo root - [ ] Run `pnpm run demo -- --systems spacetimedb --seconds 3` from `templates/keynote-2` against a local SpacetimeDB server and confirm non-zero TPS - [ ] Verify that a system producing 0 TPS shows `✗ FAILED` and is excluded from the comparison chart - [ ] Verify that reducer errors are printed to console during benchmark failures --------- Co-authored-by: clockwork-labs-bot <bot@clockworklabs.com> |
||
|
clockwork-tien
|
029e7c1e40 |
fix: Additional fixes for templates (#4372)
# Description of Changes
- Add back `{ public: true }` to tables, update `module_bindings`
accordingly
- Add missing templates to `pnpm-workspace.yaml`
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [ ] <!-- 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. -->
---------
Co-authored-by: bradleyshep <148254416+bradleyshep@users.noreply.github.com>
|
||
|
Julien Lavocat
|
83851fe9df |
Add Angular integration (#4139)
# Description of Changes - Add Angular integration - Add Angular quickstart chat template # API and ABI breaking changes None. # Expected complexity level and risk 2 # Testing Ran the template --------- Co-authored-by: Tien Pham <tien@clockworklabs.io> Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com> |
||
|
clockwork-tien
|
99edb2954c |
feat: Quickstart and client for TanStack Start (#4107)
# Description of Changes - Quickstart template `tanstack-ts` and client for TanStack Start - Add Vue Quickstart Docs <!-- Please describe your change, mention any related tickets, and so on here. --> # Screenshots - `tanstack-ts` template <img width="1461" height="898" alt="image" src="https://github.com/user-attachments/assets/6b7e5473-33c4-4f76-92a7-18607c74422c" /> - TanStack Start Quickstart Docs <img width="1459" height="896" alt="image" src="https://github.com/user-attachments/assets/b7557498-ff5a-4ce5-9c85-68db943e1b9a" /> # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [x] Tested the templates locally (e.g. able to add people), works well for me |
||
|
clockwork-tien
|
132112b435 |
feat: Quickstart and client for Nuxt (#4176)
# Description of Changes The PR implements the following updates: - Create `nuxt-ts` template - Add Nuxt Quickstart Docs <!-- Please describe your change, mention any related tickets, and so on here. --> # Screenshots - `nuxt-ts` template <img width="1446" height="894" alt="image" src="https://github.com/user-attachments/assets/743a946a-3570-4c0b-823a-c919be722d0a" /> - Nuxt Quickstart Docs <img width="1460" height="898" alt="image" src="https://github.com/user-attachments/assets/a7014d04-6dc1-4e1d-ac39-051c9ef7c09e" /> # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [ ] <!-- 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. --> --------- Co-authored-by: = <cloutiertyler@gmail.com> |
||
|
clockwork-tien
|
aca374a781 |
feat: Quickstart and client for Plain JS Script Tags (#4161)
# Description of Changes The PR implements the following updates: - Create a quickstart guide and client support for using SpacetimeDB directly in browser with script tags - A template to easily work with/test the implementation and get started with script tags The bundle is served via `https://unpkg.com/spacetimedb@latest/dist/browser.bundle.js`, which only works after the package is published to npm, therefore to test locally we can use the `browser-ts` template and local bundle: 1. Build local bundle ``` cd crates/bindings-typescript pnpm install pnpm build ``` 2. Use local bundle built in template`index.html` (swap the URL from `unpkg`) ```diff - <script src="https://unpkg.com/spacetimedb@latest/dist/browser.bundle.js"></script> + <script src="../../crates/bindings-typescript/dist/browser.bundle.js"></script> ``` 3. Open `browser-ts/index.html` directly in browser along with `spacetime start` + publish the module `spacetime publish --project-path spacetimedb browser-ts` # Screenshots <img width="1106" height="707" alt="image" src="https://github.com/user-attachments/assets/715bea26-f54b-42be-97f9-79dcd57d153f" /> <img width="1490" height="855" alt="image" src="https://github.com/user-attachments/assets/2b1aeaf9-22ba-4ae6-bc63-771805b8c2b9" /> <!-- Please describe your change, mention any related tickets, and so on here. --> # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [ ] <!-- 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. --> --------- Co-authored-by: = <cloutiertyler@gmail.com> |
||
|
clockwork-tien
|
806447d718 |
feat: create Svelte framework integration (#4063)
# Description of Changes The PR implements the following updates: - Create Svelte framework sdk/integration - Add Svelte Quickstart Docs - Create `svelte-ts` template <!-- Please describe your change, mention any related tickets, and so on here. --> # Screenshots - `svelte-ts` template <img width="1511" height="863" alt="Screenshot1" src="https://github.com/user-attachments/assets/f266dc63-228c-4bff-96f6-b780ce53167f" /> - Svelte Quickstart Docs <img width="1451" height="893" alt="Screenshot2" src="https://github.com/user-attachments/assets/3456a60b-60d7-4232-94fc-152a020f675b" /> # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [ ] <!-- 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. --> --------- Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> |
||
|
clockwork-tien
|
f7a22018d0 |
feat: create Vue framework sdk (#4037)
# Description of Changes The PR implements the following updates: - Create Vue framework sdk - Add Vue Quickstart Docs - Create `vue-ts` template # Screenshots - `vue-ts` template <img width="1512" height="862" alt="Screenshot" src="https://github.com/user-attachments/assets/15c8209b-ec7f-4f4a-a5b4-5174ddd068be" /> - Vue Quickstart Docs <img width="1392" height="854" alt="image" src="https://github.com/user-attachments/assets/57650232-81fa-43d3-be5a-135aa1799f05" /> <!-- Please describe your change, mention any related tickets, and so on here. --> # API and ABI breaking changes <!-- If this is an API or ABI breaking change, please apply the corresponding GitHub label. --> # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [ ] <!-- 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. --> --------- Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com> |
||
|
Piotr Sarnacki
|
cd1ec90d16 |
Templates naming standarization (#4042)
# Description of Changes This PR renames the templates to always use shorthand for the language, specify a framework (or console) if necessary, and shorten the naming in general # Expected complexity level and risk 1 # Testing I've tested generating templates manually --------- Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com> |
||
|
Piotr Sarnacki
|
3c8836b1a3 |
Templates rework (#3879)
# Description of Changes We would like to move all of the templates to a central directory # API and ABI breaking changes None # Expected complexity level and risk 2 # Testing --------- Co-authored-by: spacetimedb-bot <spacetimedb-bot@users.noreply.github.com> |
||
|
Noa
|
cb3ac50bdf |
[TS] Http procedure API (#3731)
# Description of Changes Provides a fetch-alike API on `ctx.http`. I guess it could just be `ctx.fetch()` instead of `ctx.http.fetch()`, but I'm not sure if that's a good idea. # Expected complexity level and risk 2 # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [x] Need to verify that this actually works - [ ] <!-- maybe a test you want a reviewer to do, so they can check it off when they're satisfied. --> |
||
|
Tyler Cloutier
|
ce543854e9 |
Unifies server module library and client SDK for TypeScript (and fixes several bugs) (#3559)
# Description of Changes This PR is a very large change to the workings of the TypeScript SDK and as such requires a higher bar of testing than other PRs. However, it does several important things: 1. Unifies the API of the server and client so they not only have the same API, but they actually implement it with the same TypeScript types. This fixes several inconsistencies between them and fixes several small bugs as well. 2. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3365 3. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3431 4. Closes https://github.com/clockworklabs/SpacetimeDB/issues/3435 5. Subsumes the work done in https://github.com/clockworklabs/SpacetimeDB/pull/3447 6. Derives all type information on the client from a single `RemoteModule` type which vastly cleans up the correctness of type checking on the client and helped me to find several small bugs It accomplishes this by changing code generation of TypeScript on the client to code generation approximately what a developer would manually write in their module. The ultimate goal would be to allow the developer to use the types and functions that they define on in their module directly on the client without needing to do any code generation at all, provided they are using TypeScript on the server and client. https://github.com/clockworklabs/SpacetimeDB/issues/3365 is resolved by `.build()`ing the `DbConnection` inside a React `useEffect` rather than doing it directly in line with the render of the provider. In order to do that we needed to not expose the `DbConnection` directly to developers by returning a different type from `useSpacetimeDB`. `useSpacetimeDB` now returns a `ConnectionState` object which is stored as React state and updates when any of the fields change. This change also resolves https://github.com/clockworklabs/SpacetimeDB/issues/3431. https://github.com/clockworklabs/SpacetimeDB/issues/3435 was the issue that initially lead me down the rabbit hole of unifying the server and the client because it was nearly impossible to track down all the various type functions and how they connect to the values that we code generate on the server. After several hours of attempting this, I decided to clean up the types a bit to be more uniform. Implementing the unification between the client and the server also necessitated fully implemented parts of the API that were fully implemented on the server, but were broken or missing on the client. # API and ABI breaking changes [Unification] -> Means that this is breaking behavior for the client SDK, but that the new behavior is identical to the server's existing behavior ## Breaking changes: - Table accessor names and index accessor names are converted to camelCase on the `ctx`, so `ctx.db.foo_bar` is now `ctx.db.fooBar` - [Unification] On the client `my_table.iter()` returns `IterableIterator` instead of an `Array` - [Unification] `module_bindings` now export `TypeBuilder`s for all types instead of a `type MyType` and object `MyType`, so instead of using `MyType` as a type directly, you need to infer the type `MyType` -> `Infer<typeof MyType>`. - [Unification] We no longer generate and export `MyTypeVariants` for sum types (these are now accessed by `Infer<typeof MyType.variants.myVariant>`) - [Unification] `MyType.getTypeScriptAlgebraicType()` has been replaced with `MyType.algebraicType` - `useSpacetimeDB()` no longer takes type parameters - `useTable()` now takes a `TableDef` parameter and type params are inferred - `useTable()` now just returns an `Array` directly instead of a object with `{ rows }` - [Unification] `ctx.reducers.createPlayer(argA, argB)` -> `ctx.reducers.createPlayer({ argA, argB })` - [Unification] `ctx.reducers.onCreatePlayer(ctx, argA, argB)` -> `ctx.reducers.onCreatePlayer(ctx, { argA, argB })` - [Unification] `ctx.reducers.removeOnCreatePlayer(ctx, argA, argB)` -> `ctx.reducers.removeOnCreatePlayer(ctx, { argA, argB })` - [Unification] `myTable.count(): number` -> `myTable.count(): bigint` ## Additive changes: - `Infer<>` now also does `InferTypeOfRow<>` if applicable - Added a `useReducer()` React hook - `module_bindings` now exports a `tables` object with references to all the `TableDef`s - `module_bindings` now exports a `reducers` object with references to all the `ReducerDef`s - Added a new `MyType.create('MyVariant', ...)` function in addition to the `MyType.MyVariant(...)` constructors (this is private) ## Notable things that did not change: - `MyType.serialize(writer: BinaryWriter, value: Infer<typeof MyType>)` and `MyType.deserialize(reader: BinaryReader): Infer<typeof MyType>` are still supported exactly as before. - The `MyType.MyVariant(...)` constructor function on sum types is still present, but implemented with the private `MyType.create('MyVariant', ...)`. We could choose to move away from this API later if we didn't like the variants polluting the namespace # Expected complexity level and risk 4 - This is a deep reaching an complex change for the SDK. For the server, it is much less deep reaching since it reuses much of the same machinery, although it does require thorough testing there as some of the code was modified. This change is fully localized to TypeScript and does not touch the host (or other languages) at all, and therefore only impacts a beta aspect of SpacetimeDB. # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [ ] Added regression test for https://github.com/clockworklabs/SpacetimeDB/issues/3435 - [x] Manually tested `test-app` and `test-react-router-app` - [ ] Add test cases for camelCase-ing --------- Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
Mazdak Farrokhzad
|
50d58a2858 |
Add modules/benchmarks-ts (#3408)
# Description of Changes Adds `modules/benchmarks-ts`. # API and ABI breaking changes None # Expected complexity level and risk 2? # Testing This is a test. --------- Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org> Co-authored-by: Noa <coolreader18@gmail.com> |
||
|
Noa
|
bb43213245 |
Typescript module API (#3327)
# Description of Changes Currently based on #3361 Implements most of the TS module API (not yet a function for type aliases). # Expected complexity level and risk <!-- How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change. This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code. If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways. --> # Testing <!-- Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected! --> - [x] Extremely basic module stuff works - [ ] <!-- maybe a test you want a reviewer to do, so they can check it off when they're satisfied. --> --------- Signed-off-by: Noa <coolreader18@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com> Co-authored-by: = <cloutiertyler@gmail.com> Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com> Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
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 <bfops@users.noreply.github.com> |
||
|
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 |
||
|
Tyler Cloutier
|
413c8cbf3c |
Unifies TypeScript packages and command names (#3195)
# Description of Changes This PR: - standardizes the prettier config across all TypeScript projects - adds a root level package.json - standardizes all `pnpm` commands to be the same - updates documentation accordingly - adds some additional typescript testing for serialization and deserialization **IMPORTANT!** Once this PR merges we will need to change the `compile-and-test` required check to `build-and-test` # API and ABI breaking changes No breaking changes. # Expected complexity level and risk 2 - It in principle doesn't change any code, but could affect deploy processes. # Testing - [x] Just the automated testing that we had previously - [x] I added additional automated tests --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |
||
|
Tyler Cloutier
|
5901fb5063 |
Separate out TypeScript module library from the SDK (#3182)
# Description of Changes Please note, much of the code changed in this PR is generated code. This change updates the TypeScript SDK to use a new `spacetimedb` TypeScript library which lives under the `/crates/bindings-typescript` folder alongside `/crates/bindings-csharp`. Just like with the C# bindings library, the types for `AlgebraicType` and `RawModuleDef` are now code generated with a script in `/crates/codegen/examples`. Pulling this out into a library allows us to use the same types and serialization code on both the server and the client for TypeScript modules. In the process of making this change I also found and fixed several issues with the TypeScript code generation. Namely an issue with recursive types and an issue with the `never` type. I also removed any use of `namespace`s since those are a TypeScript only feature, and we want to have JavaScript + types so that we can use the generated code with ESBuild without TSC. I have also improved the npm/pnpm scripts to be able to generate TypeScript code for us automatically by running `pnpm generate` for any place that we have to generate typescript code. Namely: - Quickstart module bindings - AlgebraicType/ModuleDef for TypeScript module library - Client API messages for the TypeScript API - TestApp module bindings # API and ABI breaking changes IMPORTANT! This is an API breaking change for clients, as such it should be a major version change. However, I am going to see if I can shim in the old API as best as possible to make it compatible. Notably, we were previously exporting APIs that end users do not need, and I don't think it would ever occur to them to use, namely the whole `AlgebraicValue` API and also the `AlgebraicType` API. In principle, no one should have a need for these, although it was technically possible for them to use it. Indeed, we could potentially even just remove AlgebraicType completely from the API by directly code generating the serialization code. Listed below are all of the **BREAKING** changes to the API and their effect: - `AlgebraicType` is now a structural union literal type instead of a class (nominal type), this is a consequence of generating the type with our code gen. Users did not have a reason to use `AlgebraicType` directly. - The `AlgebraicValue` type has been removed entirely. This was previously a class that was exported from the SDK, but very unlikely to be used by users. - The `ProductValue` type has been removed. - The `ReducerArgsAdapter` and `ValueAdapter` types, which were used with AlgebraicValues have been removed. - Generated code has changed incompatibly so users will have to regenerate code when upgrading to this version. Technically a breaking change, but pretty easy to fix. Listed below are the non-breaking API changes: - I am now exporting generated product types as the default export in addition to how I was exporting them before - For generated sum type `T`, I am now exporting a `TVariants` namespace which has the types of all the variants for `T`. This was previously exposed on the namespace `T`, but was inaccessible in modules other than the one it was defined in because I also export a type `T` in addition to namespace `T` and in the type position `T` was being interpreted as a type rather than a namespace. It's unclear why TypeScript resolved it as the `T` namespace within the module in which is was defined previously. Anyway, since the old types were apparently unobservable to users, I've replaced them with the types in `TVariants`. (Open to other names for this namespace). - I fixed a bug where never types (sum types with no variants) were not correctly generated. # Expected complexity level and risk 3. The most complex thing about the PR are the potential impacts to the API. I am reasonably certain, but not 100% certain that I have accounted for everything above. # Testing - [x] I ran `pnpm test` which runs all the tests in the repo including an integration test which tests the connection to SpacetimeDB. I also fixed broken tests. --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> |