# Description of Changes
Closes: #3895
- Added third tier expanding folder
- Merged most into intro + core concepts
- Collapsed modules + database into one
- Moved several documents to how-to to streamline the core concepts
- Added warning to RLS to use views
- refactored all links
- Moved How To and References into Developer Resources
- Fixed TypeScript View code
Sample: (Getting Started will start expanded due to being the initial
page)
<img width="293" height="746" alt="image"
src="https://github.com/user-attachments/assets/6abc3a0d-1ae2-4886-bda7-11f5565afecf"
/>
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
- [X] Updated the quickstarts.py and generate-cli tooling
---------
Signed-off-by: Jason Larabie <jason@clockworklabs.io>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
# Description of Changes
With the refactor docs I had left the original module folder and
mistakenly didn't remove it as requested as per Tyler's comment:
https://github.com/clockworklabs/SpacetimeDB/pull/3877#pullrequestreview-3585291570:
> Also please remove the "old files" before merging.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
Removal of documents there is no test to run
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Add back the instructions for regenerating CLI docs, which were removed
in https://github.com/clockworklabs/SpacetimeDB/pull/3343. I also made a
script for it.
This also fixes the CI checking this file, which was silently broken in
the same PR.
I have **not** verified that this works in Git Bash in Windows.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] CI passes
- [x] CI fails if I change the CLI reference
- [x] CLI reference looks visually reasonable on a local `pnpm dev`
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
The `.png` logo image has been replaced by a `.svg` and needed to be
updated.
# API and ABI breaking changes
Not applicable
# Expected complexity level and risk
0.000001
# Testing
Run `pnpm dev` and check that the logo is correctly displayed in the top
left corner
# Description of Changes
This makes it possible to insert new pages between existing pages
without renaming the existing pages.
I also added a section to docs/README.md with procedure for how to name
new pages, which I'll paste here:
### Adding new pages
All of our directory and file names are prefixed with a five-digit
number which determines how they're sorted.
We started with the hundreds place as the smallest significant digit, to
allow using the tens and ones places to add new pages between.
When adding a new page in between two existing pages, choose a number
which:
- Doesn't use any more significant figures than it needs to.
- Is approximately halfway between the previous and next page.
For example, if you want to add a new page between `00300-foo` and
`00400-bar`, name it `00350-baz`. To add a new page between `00350-baz`
and `00400-bar`, prefer `00370-quux` or `00380-quux`, rather than
`00375-quux`, to avoid populating the ones place.
To add a new page after all previous pages, use the smallest multiple of
100 larger than all other pages. For example, if the highest-numbered
existing page is `01350-abc`, create `01400-def`.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1 - @JulienLavocat said this wouldn't break anything.
# Testing
None.
---------
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
# Description of Changes
Closes: #3781
- Added and tested procedure docs for Unreal C++ & Unreal Blueprint
- Fixed a small issue with the blueprint accessors for the event status
- Fixed a bug in the C# procedure docs
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
I built a new local test framework to do another clean end to end test
of procedures with Unreal to properly test the Blueprint work as well.
- [x] Built the Rust server alongside a new Unreal client and tested
each procedure/callback in C++ and Blueprint
- [x] Reviewed the docs locally
# Description of Changes
- Update docs nav height to 56px
## Screenshots:
<img width="1256" height="55" alt="image"
src="https://github.com/user-attachments/assets/df070fb2-f3c8-4f17-ae58-6a6aa72c8033"
/>
<!-- 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. -->
# Description of Changes
This removes all usages of `pathname:///` and replaces them with
`https://spacetimedb.com/`. `pathname:///` was resolving to `/docs` in
some cases and was not verified by our link checker. Note that this
means these links will NOT work in staging.
This is a temporary fix. We should find a way to be able to link out to
the rest of the site without hardcoding the hostname in the future.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- I tested that the links work locally (but obviously they link to the
production site).
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
In the spirit of our planned move to concept-based documentation rather
than language-based documentation,
I've chosen to add a quick section to the overview, and then a new page
for documentation about procedures. I have not updated any tutorials or
reference pages.
# API and ABI breaking changes
N/a - docs
# Expected complexity level and risk
1 - docs
# Testing
None.
---------
Co-authored-by: Noa <coolreader18@gmail.com>
# Description of Changes
Somehow (apparently after #3494) we wound up with a bunch of duplicate
folders in our repo, both the old title-case names and the new
lower-case names. All of the remaining files in the title-case
directories have their last change in #3343, well before #3494, so I
don't believe we're losing any intermediate changes by deleting them.
I'm not sure how this happened, but it seems to be an easy fix.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
2 - some small possibility that I accidentally deleted an intentional
change that got borked by a merge conflict or something. I don't think I
did, tho, based on the age of the git blame on the files deleted here.
# Testing
None
# Description of Changes
This PR is the first in a series of PRs which are an effort the
reorganize the docs and make it easier for people to get started using
SpacetimeDB.
This PR:
1. Renames all folders to be `kebab-case`. This is because `docIds` are
set based on folder and file names, and there is no way to override that
within a file (all you can change with `id: my-id` is the last component
of the id. Because we want to be able to access docs in react components
we need stable predictable ids.
- This also necessitates setting up a few `_category_.json` files so
that the categories do not show up as kebab case in the sidebar.
2. Adds a few React components with images so it's clearer on how to get
started
3. Reorganizes the quickstarts to be at the top of the side bar and
simplifies the server and client into a single document named for the
language
4. Sets up redirections so the old links to the old documents now point
to the new documents
5. Copies the entirety of `typography.css` from the website into this
repo for the purpose of keeping them identical
6. Makes minor fixes and improvements to the contents of the docs
In a future PR, I intend to:
1. Add a tutorial section to the docs which will include two tutorials:
Blackholio and Chat
2. Turn the chat quickstart documents into the Chat tutorial and
consolidate it into a single file with different language switchers (if
this is feasible)
3. Create a new quickstart section, which has a quickstart guide for
each platform that we support so far, namely:
- Vanilla TypeScript
- Vanilla JavaScript
- Vanilla Rust
- Vanilla C#
- React
- Unity
- Unreal
4. Update the quickstart guides to do the following (in the future I
will add more platforms with this scheme):
- Use `spacetime dev --template <framework-template>` to create a new
project for the given framework
- Insert data into the database
- Add a new `reducer` to the template
- Add a new `table` to the template
- Add a new `view` to the template
- Call the reducer from the client
- Subscribe to the `view` from the template
5. Break up the current per language module reference files into files
about SpacetimeDB concepts with a `TabGroup` for each language, namely:
- Modules
- Tables
- Reducers
- Procedures
- Code generation
- DbConnection (and the SDK API)
- Auth
- etc.
The idea being that we should explain our platform by concept, not by
language. This will also allow us to reuse a lot of prose that is
repeated in the different language documents.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Tested the documents locally to ensure that they render properly
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
- Update docs nav items font weight to 600
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Screenshot:
<img width="1489" height="56" alt="image"
src="https://github.com/user-attachments/assets/175ef382-41a1-40ed-8a25-c38cc4e513f1"
/>
# 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: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This PR modifies the `--delete-data` flag on `spacetime publish` and
adds the `--delete-data` flag on `spacetime dev`.
In particular instead of `--delete-data` being a boolean, it is now a an
enum:
- `always` -> corresponds to the old value of `true`
- `never` -> corresponds to the old value of `false`
- `on-conflict` -> clears the database, but only if publishing would
have required a manual migration
This flag does NOT change any behavior about prompting users to confirm
if they want to delete the data. Users will still be prompted to confirm
UNLESS they pass the separate `--yes` flag.
`spacetime dev` gets the same `--delete-data` flag. The default value of
`never` is equivalent to the existing behavior. `spacetime dev`
continues to publish with `--yes` just as before. This behavior is
unchanged.
# API and ABI breaking changes
Adds the flags specified above. This is NOT a breaking change to the
CLI. Passing `--delete-data` is the equivalent of
`--delete-data=always`.
This IS technically a breaking change to the `pre_publish` route. As far
as I'm aware this is *only* used by our CLI however.
> IMPORTANT SIDE NOTE: I would argue that `--break-clients` should
really be renamed to `--yes-break-clients` because it actually behaves
like the `--yes` force flag, but only for a subset of the user prompts.
I have not made this change because it would be a breaking change, but
if the reviewers agree, I will make this change.
# Expected complexity level and risk
2, Very small change, but if we get it wrong users could accidentally
lose data. I would ask reviewers to think about ways that users might
accidentally pass `--delete-data --yes`.
# Testing
- [ ] I have not yet tested manually.
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# 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>
# Description of Changes
Includes Rust, C#, and TypeScript.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Just docs.
# Description of Changes
Following discussions about having our Inkeep's API key being public, I
added a comment to all the places where we use it saying that this is OK
and a link to the documentation.
As per Inkeep's documentation:
> When you embed your AI assistant in websites where the user is not
authenticated, like in your public docs, help center, or marketing site,
the web browser is considered a "public client". Since many of these
clients often don't have a backend, the most practical way to use the AI
assistant is for UI components to talk directly to the Inkeep service.
While it is up to your company's own policies and best practices, in
these scenarios, the Inkeep API key is generally ok to be included in
the source code of your web page that is exposed in the browser. This is
similar to how [Algolia's search
service](https://support.algolia.com/hc/en-us/articles/18966776061329-Can-the-search-API-key-be-public)
or [Sentry's error
logging](https://forum.sentry.io/t/how-does-sentry-prevent-spammers/8188)
works.
https://docs.inkeep.com/cloud/ui-components/public-api-keys#public-clients
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Ran the docs locally to ensure that the comment isn't visible on the
markdown pages
# Description of Changes
Inkeep's API key for the search bar is the staging one instead of
production, therefore requests made are failing due to an incorrect
referrer.
I've fixed this on `docs/release` quickly after we migrated the new docs
but haven't made a PR to add it to master, due to this the change was
lost on `docs/release` in the last docs release.
I just cherry-picked the commit that I had on my local branch
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
Cherry-pick of a commit that was already deployed
# Description of Changes
The GitHub edit links were disabled in the new docs, this reenables
them.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# 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 locally that this works.
# Description of Changes
This PR implements a new command for the CLI: `spacetime dev`. If run
from outside of a project directory, it will call `init` in interactive
mode to allow user to create a project. If run from a project directory,
it will ask for a module to conect to and it will:
* subscribe to logs
* observe files in the `spacetimedb` directory and automatically publish
to SpacetimeDB
One caveat is that instead of reusing the `logs` code I did some
repetition cause currently the logs code acquires a lock that lives
through await points. It is fixable, but due to limited time I decided
to go with a bit of code duplication. It shouldn't be very hard to fix
later, though.
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: = <cloutiertyler@gmail.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Fixes an issue in the new TypeScript module quickstart which would
cause users to encounter an error.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None
# Expected complexity level and risk
1
<!--
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] I did the quickstart from start to finish and it works now without
hitting any errors
Manual test output:
```
boppy@geralt MINGW64 ~/clockwork/SpacetimeDB/quickstart-chat (jdetter/fix-typescript-quickstart)
$ spacetime publish --project-path spacetimedb quickstart-chat
Build finished successfully.
Uploading to local => http://127.0.0.1:3000
Checking for breaking changes...
Publishing module...
JavaScript / TypeScript support is currently in BETA.
There may be bugs. Please file issues if you encounter any.
<https://github.com/clockworklabs/SpacetimeDB/issues/new>
Created new database with name: quickstart-chat, identity: c200a4abaa304575600961ee0a39210a536bcd9d52d14580ce56dd51627013f5
boppy@geralt MINGW64 ~/clockwork/SpacetimeDB/quickstart-chat (jdetter/fix-typescript-quickstart)
$ spacetime call quickstart-chat send_message "Hello, World!"
WARNING: This command is UNSTABLE and subject to breaking changes.
boppy@geralt MINGW64 ~/clockwork/SpacetimeDB/quickstart-chat (jdetter/fix-typescript-quickstart)
$ spacetime logs quickstart-chat
2025-10-30T15:50:23.882048Z INFO: Creating table `message`
2025-10-30T15:50:23.882191Z INFO: Creating table `user`
2025-10-30T15:50:23.882713Z INFO: Invoking `init` reducer
2025-10-30T15:50:23.883599Z INFO: Database initialized
2025-10-30T15:50:31.461395Z INFO: send_message spacetimedb_module:3640: User c20093cd8df79879ae6d2b058650ca5112d6bb11334b5003f443cc0776da3d15: Hello, World!
boppy@geralt MINGW64 ~/clockwork/SpacetimeDB/quickstart-chat (jdetter/fix-typescript-quickstart)
$ spacetime sql quickstart-chat "SELECT * FROM message"
WARNING: This command is UNSTABLE and subject to breaking changes.
sender | sent | text
--------------------------------------------------------------------+----------------------------------+-----------------
0xc20093cd8df79879ae6d2b058650ca5112d6bb11334b5003f443cc0776da3d15 | 2025-10-30T15:50:31.460991+00:00 | "Hello, World!"
```
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 <cloutiertyler@users.noreply.github.com>
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: = <cloutiertyler@gmail.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@aol.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
- Expanded on the Unreal tutorial to create the Blueprint version,
~~this uses :::server-cpp and :::server-blueprint which might not work
yet when deploying~~ with using Docusaurus Tabs.
- Updated the server side code to use signed integers as discussed for
both Rust + C# server modules.
# API and ABI breaking changes
None
# Expected complexity level and risk
1 - Documentation update, does update the server side
# Testing
- [x] Manually tested both Rust + C# modules
- [x] Ran through all images and steps
# Description of Changes
Closes#3502.
Adding section for more clarification (the remark in `Connection
Parameters` could be easy to miss)
# Expected complexity level and risk
1
# Testing
- [x] See the changes with the `pnpm dev`
---------
Signed-off-by: Mario Montoya <mamcx@elmalabarista.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
LLMS.md was deleted and not added before merging the docusaurus
migration
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
None
## Description of Changes
- Migrate the documentation site to **Docusaurus**.
- Add a **GitHub Action workflow** that runs `pnpm build` on pull
requests targeting `master`.
This command checks for broken links and images and ensures the site
builds correctly.
- Add a **GitHub Action workflow** to publish the docs automatically
when a merge occurs on the `docs/release` branch.
**Important**: The workflows haven't been tested yet due to the fact
that they need to be merged first before being able to run. It's a
fairly basic workflow I don't expect this to block anyone but anyways I
will make another PR with the complete changes when I can actually run
it.
---
## API and ABI Breaking Changes
No breaking changes for **SpacetimeDB** users.
Documentation contributors should experience minimal disruption —
content is still written in Markdown.
---
## Expected Complexity Level and Risk
**Complexity:** 3/5
**Reasons:**
1. Several adjustments were made to fit Docusaurus conventions:
- Replaced our custom `:::server-rust` blocks with [Docusaurus `<Tabs/>`
components](https://docusaurus.io/docs/markdown-features/tabs).
- Converted “Note” callouts using
[admonitions](https://docusaurus.io/docs/markdown-features/admonitions)
instead of Markdown blockquotes.
- Updated all images (including Unity tutorial ones, which were
previously commented out).
- Moved images from the DO bucket into the repository at
`docs/static/images`.
2. Customized Docusaurus CSS and one component to apply our theme and
color palette.
---
## Testing
Tested locally.
---
## Review Notes
This PR involves many file changes — a full code review is likely not
productive.
Instead, please focus on verifying that the **documentation content**
was migrated correctly:
- Review sections you’re familiar with to confirm accuracy.
- Ensure formatting, links, and images render as expected.
You can follow the updated **README** for instructions on running
Docusaurus locally.
---------
Signed-off-by: Julien Lavocat <JulienLavocat@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: = <cloutiertyler@gmail.com>
# Description of Changes
This PR adds a new TypeScript reference doc at
`/docs/modules/typescript`.
# API and ABI breaking changes
None
# Expected complexity level and risk
1, just docs
# Testing
- [ ] I have carefully reviewed the changes and believe that all code
represented here should compile.
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# 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>
# Description of Changes
Python is funny, if a file `token.py` is created and another script run
on the same dir, it will cause python to block:
```python
python3-3.13.7/lib/python3.13/tokenize.py", line 35, in <module>
from token import *
File "/Users/mamcx/token.py", line 3, in <module>
text = sys.stdin.read()
```
By coincidence the docs on `pg wire` use this name. Changed to one that
don't cause the trouble.
# Expected complexity level and risk
1
# Testing
- [x] Created another script and run it, see it blocks because this...
# Description of Changes
In the React Integration tutorial
- Replace the staging URL by the production one
- Add useAutoSignin to automatically redirect users to the login page
- Add post_logout_redirect_uri to redirect users back to the application
after login
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
Local test
# Description of Changes
Update:
This PR did all of the below but was split. Now it just does:
1. Exposes V8/JS modules via the `unstable` feature flag on the host. To
publish a JS module, `--js-path path/to/module.js`
This PR:
1. Exposes V8/JS modules via the `unstable` feature flag on the host. To
publish a JS module, `--js-path path/to/module.js` needs to be used.
2. Bumps V8 to 140.2.
3. Shares more logic with WASM and makes some minor refactorings to
energy/budget logic.
4. Moves logic from `WasmInstanceEnv` to `InstanceEnv` and friends.
5. Makes JS modules actually work in terms of `create_instance`,
`make_actor`,
6. Fleshes out `call_reducer` with timeouts and long-running logs added
as well.
7. Adds all the syscalls with associated documentation as well.
# API and ABI breaking changes
None
# Expected complexity level and risk
2? It's only available on unstable and mostly touches V8 stuff.
# Testing
Follow up PRs will add unit tests for parts.
We'll also need to add integration tests for whole modules.
# Description of Changes
Fix various issues on the React Integration page:
- Invalid links (Closes#3332)
- Fix broken syntax highlight
- Update the page title (React -> `React integration`)
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
Tested using a local version of the website
# Description of Changes
The instructions were misleading about which directory to generate into.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
None
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
PR contains:
* CLI changes for the `pre_publish` endpoint when publishing a module.
* The regular `--yes` flag will not bypasses the *break clients* warning
prompt — an extra confirmation is now required. For CI, a hidden flag
`--break-clients` is added.
* Added smoketest.
* Some trivial naming changes in `client-api-*` crates for consistency
reasons.
* `pre_publish` route to accept similar Body size limit as `publish`
route.
# API and ABI breaking changes
an additive API change, does not break anything.
# Expected complexity level and risk
2
# Testing
- Existing smoketests passing for backward compatibility.
- New smoketest for add columns
---------
Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Add documentation for SpacetimeAuth
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
Checked if everything was working using a local instance of the website
# Description of Changes
As the title says
# Expected complexity level and risk
1
# Testing
- [x] Manually create the projects shown as examples and run them
# 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>
# Description of Changes
This adds `react` as an optional peer dependency. If the TypeScript SDK
is imported into a library that uses React (of the appropriate version)
then they will have access to two new React hooks:
```ts
useSpacetimeDB<DbConnection>();
useTable<DbConnection, MyTable>('my_table');
```
This PR also updates the TypeScript `quickstart-chat` tutorial in the
docs to use the new React hooks. I will split that tutorial into
separate `React` and `TypeScript` tutorials in a future PR.
# API and ABI breaking changes
This is a purely additive change to the SDK
# Expected complexity level and risk
2 because it changes how the SDK is built a bit. Namely it makes the
`spacetimedb` library an external dependency.
# Testing
TODO: I am not through testing yet.
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: Julien Lavocat <JulienLavocat@users.noreply.github.com>
# Description of Changes
Closes#3219
This adds the Unreal SDK, the new Unreal test cases, updates the test
runner to handle Unreal, codegen updates for Unreal, and a QuickStart
Chat.
# API and ABI breaking changes
No breaking changes.
# Expected complexity level and risk
2 - This impacts the subcommand generate.rs to include unrealcpp and
crates/testing to expand for Unreal
# Testing
- [x] Run the new Unreal tests
- [x] Run any previous automation testing - with all the changes to
generate/testing I'm uncertain if there is an impact
- [x] Review the new CLI generate documentation changes
---------
Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# 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
# Description of Changes
Implements [subscribing to durable
commits](https://github.com/clockworklabs/SpacetimeDBPrivate/issues/1594).
The setting works on a per-connection level, and essentially just delays
sending transaction updates until the transaction is reported as durable
by the database.
For connectionless SQL operations, the setting works per-request. No SQL
syntax is provided by this patch to toggle the configuration.
After some deliberation, I opted to obtain the offset when a transaction
commits (as opposed to when it starts). This creates some mild
inconvenience, because we prevent the transaction from committing until
the corresponding subscription updates are enqueued.
The strategy is, however, more correct should we ever support weaker
isolation levels, and it is easier to document.
Follow-ups include:
- Provide SQL syntax (`SET synchronous_commit = ON` or something)
- C# and TypeScript SDKs
- Reference docs?
# API and ABI breaking changes
Not breaking, but adds a parameter to the subscribe and sql endpoints.
# Expected complexity level and risk
4
To the author's understanding, ordering of outbound messages is not
changed by this patch, even if there are messages that don't have a
transaction offset (such as error messages). I.e. while waiting for the
transaction offset of a message to become durable, no message enqueued
after that message will be delivered. This may not be desirable in some
cases.
The patch may contain concurrency bugs, e.g. awaiting futures that may
never resolve.
# Testing
- [x] Implemented a new test in the `module_subscription_actor` module
- [x] Added unit tests for the core logic in `ClientConnectionReceiver`
It would be desirable to also have integration-level tests, but I'm
currently unsure how to write those without being able to control if and
when the database reports an offset as durable.
---------
Signed-off-by: Kim Altintop <kim@eagain.io>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
# Description of Changes
Some minor cleanups in the flow for regenerating the CLI reference.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Existing CI passes
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# 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>
# Description of Changes
To address user issue
https://github.com/clockworklabs/SpacetimeDB/issues/2647 , the C#
implementation of quickstart-chat files and documentation have been
updated to pattern match the variable assignment of User.
This has the benefit of the variables never being perceived by the
analyzers as a nullable types.
# API and ABI breaking changes
Not API breaking
# Expected complexity level and risk
1
# Testing
- [X] Tested updated module code locally, following instructions from
the documentation.
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
Jason Larabie