# Description of Changes
This reverts the version bump, since it seems to be causing test
flakiness somehow.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [ ] CI passes
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
Uses the xoroshiro128+ implementation from the `pure-rand` package.
# Expected complexity level and risk
1 - this API is "userspace" only.
# 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] Verified that the pcg32 implementation is correct and matches the
rust version it's based off of
- [ ] Add a test using `ctx.random()`
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Version upgrade to `v1.12.0`.
# 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 - this is just a version upgrade
<!--
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! -->
The testsuite failures are fixed by
https://github.com/clockworklabs/SpacetimeDB/pull/4120
- [x] License has been properly updated including version number and
date
- [x] CI passes
---------
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# 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>
# 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>
# Description of Changes
Use relative import `'../src'` in serde.test.ts to match all other test
files.
This is a consistency fix. The `'spacetimedb'` import works in CI (build
runs first, enabling package self-reference), but all other tests use
`'../src'`.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Description of Changes
Dpends on and includes: #4011
Will remove commits whenever that merges 👍
This impacts the `useTable()` functions `where`clause.
We add a new possibility for the `Value` type which is the new `Uuid`
type.
Also my formatter is bugging again :( whenever i `pnpm format` it does
things differently than the guidelines? Would be cool for that reason if
someone can run format for me maybe bfops like the last time :>
# API and ABI breaking changes
None
# Expected complexity level and risk
1. Only lifts the filter for the where clause a bit to further support
`Uuid` alongside bool, string, and number.
# Testing
- [x] Getting syntax highlithing for the new availbale row
- [x] Getting row back from subscription when supplying a uuid
- [x] Fix edge case with string
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This moves the query builder code out of the `server` package and into
`lib` so it can be shared by the client and server.
I put the query builder in the `index.ts` of module bindings as a
`query` object that can be imported. The typescript `test-app` has an
example of using it with the subscription builder.
This is branched off of
`https://github.com/clockworklabs/SpacetimeDB/pull/3980`.
# API and ABI breaking changes
This extends the client subscription builder API to allow `string |
RowTypedQuery<any, any>`, so existing client code should be fine.
# Expected complexity level and risk
1.5. This is low risk.
# Testing
I manually tested that the test app still works locally.
This also has a few minor changes to fix build errors for the
`test-app`.
# Description of Changes
Updates the typescript-test CI job to build some packages that weren't
being built before.
This also updates the root-level `pnpm generate/format/lint/build`
commands to also apply to templates.
# Expected complexity level and risk
1
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Implements the `Nameable` interface for the generated uuid client
bindings.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. Only additive changes pretty much copy pasted from the other types
where it was already implemented.
# Testing
- [x] Before it didnt work in my project now it works
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
- Made spacetime dev <database> a positional argument and deprecated
--database
- Fixed double connection in React SDK
- Added a more descriptive error message to unresolved table name.
# API and ABI breaking changes
Deprecates `--database`. Still works, but it prints with a warning.
# Expected complexity level and risk
2
# Testing
- [x] I have tested that the double render fix works in React
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
One of the TypeScript UUID tests took several seconds to run, and would
sometimes time out in CI. This PR decreases the number of iterations so
that it runs comfortably.
We do not think that this will materially impact the correctness of the
test.
# API and ABI breaking changes
None. Test only.
# Expected complexity level and risk
1
# Testing
- [x] The test now runs in ~500ms on my machine, instead of ~4s
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This PR does several small things:
1. It removes the explicit `h1` tags on every page, and either uses the
side bar title directly, or puts it in the frontmatter
2. It merges what are currently called quickstarts into a single Chat
App Tutorial
3. It creates new quickstarts which just use `spacetime dev --template`
to get you up and running quickly
4. It adds a "The Zen of SpacetimeDB" page much like the Zen of Python
which goes over the 5 key principles of SpacetimeDB
5. It reorders all Tabs groups so that the ordering is `TypeScript`,
`C#`, `Rust`, `Unreal`, `C++`, `Blueprints` (order of decreasing
popularity).
6. It improves the sidebar navigation by having categories act as
overview pages, and also fixes the breadcrumbs
7. It fixes various small typos and issues
8. Closes#3610 and adds cursor rules files generally
9. It fixes general styling on the docs page by bring it inline with the
UI design:
Old:
<img width="1678" height="958" alt="image"
src="https://github.com/user-attachments/assets/f36efee6-b81a-4463-a179-da68b3a7152e"
/>
New:
<img width="1678" height="957" alt="image"
src="https://github.com/user-attachments/assets/f430f77d-0663-47f2-9727-45cbfe10e4c7"
/>
https://github.com/user-attachments/assets/adc5a78a-ada8-45b5-8078-a45cb81477a3
# API and ABI breaking changes
This PR does NOT change any old links. It does add new pages though.
# Expected complexity level and risk
3 - it's a large change. I manually tested the TypeScript Chat App
Tutorial but I have not gone through the Rust and C# quickstarts.
However, we have testing on the quickstarts and this is text only so can
be carefully reviewed.
# 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] Ran through each step of the Chat App TypeScript tutorial to
ensure it is working
- [x] Ran and tested the styles and the functionality of the side bar
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: spacetimedb-bot <spacetimedb-bot@users.noreply.github.com>
Co-authored-by: clockworklabs-bot <clockworklabs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# 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>
# Description of Changes
Fixes https://github.com/clockworklabs/SpacetimeDB/issues/3240.
Non-unique indices are now backed by a type `SameKeyEntry` which holds
the `RowPointer`s for the same key.
When these `RowPointer`s exceed 4KiB (512 entries), the data structure
switches from using an array list to a hash set.
# API and ABI breaking changes
None
# Expected complexity level and risk
2?
# Testing
Covered by existing tests, though more test will come in future PRs.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Version upgrade to `1.11.2`
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
- None, this is just a version bump
# Expected complexity level and risk
1 - no real changes here
<!--
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
- NA this is just a version bump, no functionality change here.
# Description of Changes
Closes#3673
*NOTE*: C++ part will be in another PR
# Expected complexity level and risk
2
Adding a new type touch everywhere
# Testing
- [x] Adding smoke and unit test
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
# Description of Changes
#3538 added a `uuid_counter` field to ReducerCtx, which has no need to
be public. Implementing ReducerCtx as a class allows us to encapsulate
better, and lets us enumerate exactly the data that it needs to hold so
that the runtime could possibly optimize it.
# Expected complexity level and risk
1: straightforward switch
# Testing
- [x] Automated testing is sufficient.
# Description of Changes
TS equivalent of #3863. I also did optimized single-column indices such
that there's a special case that avoids branching.
# Expected complexity level and risk
1 - straightforward and there's Rust precedent to draw from.
# Testing
- [x] Automated testing is sufficient
# Description of Changes
Closes
[#3290](https://github.com/clockworklabs/SpacetimeDB/issues/3290).
Adds a new "special" type to SATS, `UUID`, which is represented as the
product `{ __uuid__: u128 }`. Adds versions of this type to all of our
various languages' module bindings libraries and client SDKs, and
updates codegen to recognize it and output references to those named
library types. Adds methods for creating new UUIDs according to the V4
(all random) and V7 (timestamp, monotonic counter and random)
specifications.
# API and ABI breaking changes
We add a new type
# Expected complexity level and risk
2
it impacts all over the code
# Testing
- [x] Extends the Rust and Unreal SDK tests, and the associated
`module-test` modules in Rust, C# and TypeScript, with uses of UUIDs.
- [x] Extends the C# SDK regression tests with uses of UUIDs.
- [x] Extends the TypeScript test suite with tests with uses of UUIDs.
---------
Signed-off-by: Mario Montoya <mamcx@elmalabarista.com>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
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. -->
This bumps the Typescript SDK to 1.11.3.
# 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! -->
NA - this is just a version bump and the CI passes
I will change the base to master once the `1.11.2` version bump merges.
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This bumps the Typescript SDK to 1.11.2 so that we can send out Noa's
fix.
# 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! -->
NA - this is just a version bump and the CI passes
# Description of Changes
Update the `useTable` hook in the `spacetimedb/react` package to use the
client language convention aware table accessor key to lookup the
correct table
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
I built and ran a client using this code change before and after.
Previously with multi-word table names in rust module (i.e.
`crew_assignments` table), the useTable hook would fail to lookup the
table information and hookup the onInsert/onDelete/onUpdate callbacks.
With this change, they successfully connect and data returned by the
useTable hook now flows.
All of my testing was with module_bindings generated with the 1.11.0
rust module crate. Additional testing for backwards compatibility might
be useful. I'm not sure what the clockwork labs target is for that sort
of thing.
# Description of Changes
Fixes#3919.
# Expected complexity level and risk
1
# Testing
- [x] Erroring code now works
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. -->
- Just bumping typescript size limits again
# API and ABI breaking changes
No
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
0 - this is just a release change.
<!--
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
I have not tested this but I've verified the new limit is greater than
the package size.
<!-- 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! -->
# Description of Changes
A few main goals here:
* have our iterator functions return an [`Iterator`
object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator)
so that users can use its combinators like `filter()` and `find()` and
`reduce()`. It's a very new JS api but we happen to know that the module
code will always be run in an environment that has it* :)
* improve lifecycle handling for iterator handles - mainly, if an
iterator is not run to completion, it will now eventually get garbage
collected, whereas before we would have a resource leak.
It turns out that the easiest way to do both of those things was to turn
TableIterator into a generator function, which also happens to make the
code much easier to read. Hooray :)
\* I did mention it in `table_cache` (which isn't run in our module
host) but it's fine, since that's only in the type system and
`IteratorObject` is defined in typescript's `lib.es2015.iterable.d.ts`
but is only given fancy methods in `lib.esnext.iterator.d.ts` - so if
the user uses esnext, they'll have access to them, but otherwise not.
# Expected complexity level and risk
1: this better separates concerns and makes the code clearer in its
purpose.
# Testing
- [x] Refactor, so automated testing is sufficient.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Bump version numbers to `1.11.1`
# 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
- [x] Verified that the license has been updated
- [x] `spacetime --version` on this commit is correct
There is also a corresponding private PR.
# Description of Changes
This helps with the issue reported in
https://github.com/clockworklabs/SpacetimeDB/issues/3811.
Right now we have a type representing the reducer, and a type for the
reducer args, and both have the same name. This adds `Reducer` to the
end of the args type, which is similar to what we are doing for
procedure arguments or the `Row` suffix for tables.
This will still cause some potential problems, since someone could have
a type that ends in `Reducer` (or `Row`), but this will fix the majority
of issues that are currently breaking people.
This also has some changes to get the basic react example to build.
# API and ABI breaking changes
This is technically a breaking change if people are using this for type
annotations (which doesn't seem too likely), but it should be an easy
one for people to fix.
# Expected complexity level and risk
1.
# Testing
I tested the quickstart.
# Description of Changes
Fixes#3807. Not sure what the best way to model this in the API is
(another argument to `t.row()`?), but it does work.
# Expected complexity level and risk
1
# 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. -->
# Description of Changes
`ParamsType` is a tuple, so we need to spread when we actually call
reducer functions.
Currently reducer arguments aren't being sent with the `useReducer`
hook.
# Expected complexity level and risk
1
# Testing
I tested this manually with the quickstart chat app.
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
This improves the type safety a bit from
https://github.com/clockworklabs/SpacetimeDB/pull/3812.
The core change is that the previous version typed queries based on the
typescript type, not the spacetime type. This meant that we allowed
queries for incorrect tables, like a table that had the same column
names and types, but had a u32 instead of a u64 somewhere.
This still has an issue with allowing results from tables where the rows
are reordered, which would actually be a problem, but hopefully that is
not too common.
# API and ABI breaking changes
This is technically a breaking change, because it changes some type
parameters. I don't think people should be relying on these though, so I
don't think we should be worried about breaking them.
This would only cause new type errors for apps that are likely to error
at runtime anyway.
# Expected complexity level and risk
1.5. This should be low risk, since it is just a typing change.
# Testing
This has some type checks in `view.test-d.ts`, and I've done some manual
e2e testing.
# Description of Changes
Don't throw an error if there is no `reducerInfo`. The code was
previously trying to handle the case of an unknown reducer, but was
effectively asserting that the reducerInfo existed too soon.
Now we should be fine handling a transaction, even if we can't determine
reducer information for it.
# Expected complexity level and risk
1.
# Testing
I tested this by running the quickstart chat app, and using the CLI to
delete rows (via `spacetime sql`). Before this change, the client
errors, but now it handles it correctly.
I also tested with the repro in
https://github.com/clockworklabs/SpacetimeDB/issues/3817
# Description of Changes
This should fix part of #3503. Adds an override modifier to generated
code and fixes a warning from the angular compiler.
# Expected complexity level and risk
1
# Testing
- [x] Code works fine with the added `override` modifier.
- [ ] Perhaps we should have an angular test project?
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Updated package sizes from a failed release dry-run:
https://github.com/clockworklabs/SpacetimeDBPrivate/actions/runs/20045893743/job/57491806595
# 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 - this is just a release fix
<!--
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! -->
I have not tested this, it is a trivial change.
# Description of Changes
Uses the `sourcemap` crate to map text locations in the bundle to text
locations in the original source code.
# Expected complexity level and risk
1 - essentially only related to diagnostics
# Testing
- [x] Manually tested
- [ ] Add an automated test for backtrace output
# Description of Changes
This adds a way to build queries with typescript views, and it allows
views to return queries (if the return type of the query is an array).
For examples and syntax, you can look at the tests in
[crates/bindings-typescript/tests/query.test.ts](https://github.com/clockworklabs/SpacetimeDB/compare/jsdt/ts-query-builder?expand=1#diff-4fd25c191f1207085a491cf84996c601f805f5e8280d1cf2a812ebad6aa6e75a).
To play around with the syntax, you might find it easier to look in
[crates/bindings-typescript/src/server/view.test-d.ts](https://github.com/clockworklabs/SpacetimeDB/compare/jsdt/ts-query-builder?expand=1#diff-4fd25c191f1207085a491cf84996c601f805f5e8280d1cf2a812ebad6aa6e75a).
This could still use some cleanup, and there are some places where the
type safety is imperfect. I'll try to list the known limitations here:
1. This will allow the use of `eq` for columns that are product types,
even though the query engine doesn't support it. This can be fixed
later, and it would only be a breaking change for modules that have
invalid queries.
2. When we check if a view is returning a query of the correct type, we
are checking with the typescript row type. We should be checking with
the spacetime type, since this type checking will allow a couple
incorrect things to be returned:
1. A different table with any superset of the fields (for example, a
different table that has one extra field). That will fail when
executing, but will be allowed by the typescript compiler.
2. A table with the same fields, but with those fields in a different
order would also fail at runtime, but be allowed by the typescript
compiler.
4. A table with fields of a different spacetimetype that map to the same
typescript type (like `u16` and `u32`).
I can also add back functions for things like inequality once we are ok
with the rest of it.
# API and ABI breaking changes
This adds some new API surface, but does not break existing code.
# Expected complexity level and risk
2.
# Testing
For automated tests, there are unit tests to see what sql gets emitted
in `tests/query.test.ts`, and some tests of the types in
`view.test-d.ts`.
I've also run some manual tests with a typescript module with views.
# Description of Changes
This adds some changes for how we return data from view functions.
Originally, we interpreted the output of a view function as a bsatn
encoding of an array of rows. Since we also want to be able to return
queries from view functions, we need to be able to return different
types too. At this point, this is effectively not a functional change,
since we don't use the new format, and we don't actually try to parse
the new format.
This introduces a new format for view returns, which is a
`ViewResultHeader`, potentially followed by additional data. For
example, if a view were returning rows directly, it would write a
`ViewResultHeader::RowData`, followed by an array of rows. Note that we
could have given that object a byte array with the rows instead of using
a header an a separate object, but that would force us create an extra
copy when encoding and when decoding.
To make this backward compatible with existing views, we have a
different way to return the new format. For v8 views, if they return a
byte array, we assume it is the old format. If they return an object, we
expect the `data` field of that object to be the actual return data.
For wasm views, we interpret a return code of 2 to mean that it uses the
new format.
On the host side, we handle this naively: we will perform the query, and
we will act as though the view has a read dependency on the tables in
the query. In follow up PRs we can make this more efficient.
# API and ABI breaking changes
This is not a breaking change, but it does make the ABI more complicated
(specifically to avoid breaking it).
# Expected complexity level and risk
1.5. This should not affect the existing return style.
# Testing
I've done manual testing of this with a version of the typescript
bindings that returns queries.
# Description of Changes
Bumping versions to 1.11.0 in preparation for an upcoming release.
# 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
NextJS 15 and 16 do not build without these development exports removed
tho they funnily enough have different errors.
<img width="961" height="262" alt="image"
src="https://github.com/user-attachments/assets/1e7ad634-d68f-4af3-a07e-302d252b41e5"
/>
Upon removing the development export everything works like a charm.
I couldn't find any benefit of having them but maybe @cloutiertyler
knows more why those are there in the first place🤷
This can be reproduced if you clone this repo i set up:
https://github.com/kistz/spacetime-next-react-hooks
Since its a build error it shouldnt matter if you have the actual module
running somewhere.
Step 1: `bun install`
Step 2: `bun dev`
Step 3: observe that the error above is appearing (not good)
Step 3: Go into `node_modules/spacetimedb/package.json`
Step 4: Remove the `development` fields under exports like in this pr
Step 5: `bun dev`
Step 6: Profit. (should only be a connection error (aka nothing renders)
at this point since the module your trying to connect to is missing)
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Not a whole lot since i dont fully grasp the impact of this change but
without it i cant even use the `spacetimedb` package with NextJS and
removing them fixes it.
But even development scenarios are working just fine without it.
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
I got these errors when I tried sending out the typescript NPM package:
```
cjs (brotli)
Package size limit has exceeded by 165 B
Size limit: 26 kB
Size: 26.16 kB brotlied
esm (brotli)
Size limit: 26 kB
Size: 25.87 kB brotlied
esm (gzip)
Package size limit has exceeded by 536 B
Size limit: 30 kB
Size: 30.54 kB gzipped
esm (uncompressed)
Package size limit has exceeded by 3.77 kB
Size limit: 160 kB
Size: 163.77 kB
esm min (brotli)
Package size limit has exceeded by 194 B
Size limit: 14 kB
Size: 14.19 kB brotlied
esm min (gzip)
Package size limit has exceeded by 144 B
Size limit: 16 kB
Size: 16.14 kB gzipped
esm min (uncompressed)
Package size limit has exceeded by 1.29 kB
Size limit: 65 kB
Size: 66.29 kB
```
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# 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] After this change I was able to publish the typescript NPM
package.
# Description of Changes
Fixes:
- [This
issue](https://discord.com/channels/1037340874172014652/1398209084699709492/1441556875647647816)
by exporting the `SubscriptionHandle` type with the `REMOTE_MODULE` type
applied.
- [This
issue](https://discord.com/channels/1037340874172014652/1398209084699709492/1441559246213746749)
by converting to `camelCase` for column names in code generation.
- Fixes an issue where `onMyReducer` callbacks were passing arguments as
variadic params, while the types indicated they would be passed as an
object. `onMyReducer((ctx, argA, argB, argC) => {})` vs
onMyReducer((ctx, { argA, argB, argC}) => {})`
- [Fixes an
issue](https://github.com/clockworklabs/SpacetimeDB/issues/3503#issuecomment-3566715928)
where the table type name was used instead of the table name in code
generation for constructing tables.
- [Fixes
issue](https://discord.com/channels/1037340874172014652/1398209084699709492/1441886030436499466)
with `ScheduleAt` being used in non-table types.
- [Fixes
issue](https://github.com/clockworklabs/SpacetimeDBPrivate/issues/2168)
where template projects do not use the correct lifecycle reducer setup
# API and ABI breaking changes
Adds a new export, and fixes casing in code genreation.
# Expected complexity level and risk
2
# Testing
- I have tested that the `SubscriptionHandle` is correctly exported
- I have tested that the constraint name is now output in `camelCase`
- I have tested that `onMyReducer` callbacks now return a single
argument
- I have tested that the table name (and view name) is now used instead
of the type name for code generation
- I have tested that the new lifecycle reducers correctly compile
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This upgrades the SpacetimeDB version to 1.10.0.
# 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
This is just a version bump - not tested.
This reverts commit b2e37e8008.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Reverts #3704 which I'm pretty sure contains some sort of bug which is
causing the smoketests to hang.
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# 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] CI passing again
# Description of Changes
Reworks how `SchedulerActor::handle_queued` works so that it first
determines the parameters of the call to a reducer or the parameters of
the call to the procedure. This also enables the removal of the special
case `call_scheduled_reducer`.
Fixes#3645.
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
A test `schedule_procedure` is added.
---------
Co-authored-by: Noa <coolreader18@gmail.com>
Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org>
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
We got some errors when publishing the typescript release related to the
size limits of these deps. This PR just increases those limits.
```
cjs (brotli)
Package size limit has exceeded by 348 B
Size limit: 25 kB
Size: 25.35 kB brotlied
esm (brotli)
Package size limit has exceeded by 5.19 kB
Size limit: 20 kB
Size: 25.19 kB brotlied
esm (gzip)
Package size limit has exceeded by 4.63 kB
Size limit: 25 kB
Size: 29.63 kB gzipped
esm (uncompressed)
Package size limit has exceeded by 8.45 kB
Size limit: 150 kB
Size: 158.45 kB
esm min (brotli)
Package size limit has exceeded by 1.65 kB
Size limit: 12 kB
Size: 13.65 kB brotlied
esm min (gzip)
Package size limit has exceeded by 490 B
Size limit: 15 kB
Size: 15.49 kB gzipped
esm min (uncompressed)
Package size limit has exceeded by 3.51 kB
Size limit: 60 kB
Size: 63.51 kB
react esm min (brotli)
Size limit: 10 kB
Size: 4.13 kB brotlied
react esm min (uncompressed)
Size limit: 10 kB
Size: 4.13 kB brotlied
react esm min (gzip)
Size limit: 15 kB
Size: 4.64 kB gzipped
sdk esm min (brotli)
Package size limit has exceeded by 3.41 kB
Size limit: 10 kB
Size: 13.41 kB brotlied
sdk esm min (gzip)
Package size limit has exceeded by 251 B
Size limit: 15 kB
Size: 15.25 kB gzipped
sdk esm min (uncompressed)
Package size limit has exceeded by 3.41 kB
Size limit: 10 kB
Size: 13.41 kB brotlied
Try to reduce size or increase limit in "size-limit" section of package.json
ELIFECYCLE Command failed with exit code 1.
ELIFECYCLE Command failed with exit code 1.
Error: Failed to publish package to npm
Error: Process completed with exit code 1.
```
# API and ABI breaking changes
None
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1 - This just fixes the release.
<!--
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
- I have not tested this because I want review before trying it on the
release.
<!-- 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! -->
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# Expected complexity level and risk
2
# Testing
- [x] The types for generated module bindings look right
- [ ] Actually test the client behavior (how?)
# 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. -->
Zeke Foppa