Files
Shubham Mishra e2f8a60759 Case conversion (#4263)
# Description of Changes

Update the Default casing policy to `snake_case` for `RawModuleDefV10`.

Messy PR contains changes at different places, so that CI can pass:

Here are the main changes as follows:
- `bindings-macro` & `bindings` crate: `name` macro in Indexes for
canonical name and supply it to `RawModuleDefV10` via `ExplicitNames`.
- `bindings-typescript`: 
- Changes has been reviewed through this PR -
https://github.com/clockworklabs/SpacetimeDB/pull/4308.
   
- `binding-csharp`: a single line change to pass `sourceName` of index
instead of null.
- `codegen`:
  
- Changes has been merged from branch -
https://github.com/clockworklabs/SpacetimeDB/pull/4337.
  
- Except a fix in rust codegen to use canonical name in Query buillder
instead of accessor.
  
- `lib/db/raw_def`: Extends `RawDefModuleV10` structure to support case
conversion.
  
- `schema` crate:
- `validate/v9` - Nothing itself should change or changes in v9
validation logic but the file contains a `CoreValidator` which is shared
with `validate/v10`. No test have t be updated to `validate/v9` which
ensures we aren't regressing it.
- `validate/v10`: This is the main meat, look at the new tests added in
bottom to understand what it does.
     
   -  Rest of the files are either test updates or module bindings. 
     
    ## Testing:
1. Extensive unit tests have been added to verify generated `ModuleDef`
is correct.
2. I have done some e2e testing to verify rust codegen with rust and
typescript modules.
3. I would have like to do more testing for other codegens , I am
continue doing .

I have removed `sql.py` smoketest, as that seems to be already migated
in new framework and was headache to update.

## Expected complexity level and risk
4, It could have side-effect which aren't easily visible.


 
 
 
 
 
 -  -  -

---------

Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <bot@clockworklabs.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
Co-authored-by: Noa <coolreader18@gmail.com>
Co-authored-by: = <cloutiertyler@gmail.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@clockworklabs.io>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
2026-02-20 10:44:29 +00:00
..
2026-02-20 10:44:29 +00:00
2025-10-24 14:36:38 +00:00
2025-10-24 14:36:38 +00:00
2026-01-21 20:41:38 -05:00
2025-10-24 14:36:38 +00:00
2025-10-24 14:36:38 +00:00
2026-01-21 01:09:29 +00:00

SpacetimeDB Documentation

This repository contains the markdown files which are used to display documentation on our website. This documentation is built using Docusaurus.

Making Edits

To make changes to our docs, you can open a pull request in this repository. You can typically edit the files directly using the GitHub web interface, but you can also clone our repository and make your edits locally.

Instructions

  1. Fork our repository
  2. Clone your fork:
git clone ssh://git@github.com/<username>/SpacetimeDB
cd SpacetimeDB/docs
  1. Make your edits to the docs that you want to make + test them locally (See Testing Locally)
  2. Commit your changes:
git add .
git commit -m "A specific description of the changes I made and why"
  1. Push your changes to your fork as a branch
git checkout -b a-branch-name-that-describes-my-change
git push -u origin a-branch-name-that-describes-my-change
  1. Go to our GitHub and open a PR that references your branch in your fork on your GitHub

CLI Reference Section

To regenerate the CLI reference section, run pnpm generate-cli-docs.

Docusaurus Documentation

For more information on how to use Docusaurus, see the Docusaurus documentation.

Testing Locally

Installation

  1. Make sure you have Node.js installed (version 22 or higher is recommended).
  2. Clone the repository and navigate to the docs directory.
  3. Install the dependencies: pnpm install
  4. Run the development server: pnpm dev, which will start a local server and open a browser window. All changes you make to the markdown files will be reflected live in the browser.

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.

Best practices

  • Use relative links for linking between documentation pages, as this will ensure that links work correctly with versioning and localization.

License

This documentation repository is licensed under Apache 2.0. See LICENSE.txt for more details