mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-11 10:29:21 -04:00
c83f55f65e
# 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
100 lines
2.6 KiB
JavaScript
Executable File
100 lines
2.6 KiB
JavaScript
Executable File
#!/usr/bin/env node
|
|
import { readFileSync, writeFileSync } from 'fs';
|
|
import { unified } from 'unified';
|
|
import remarkParse from 'remark-parse';
|
|
import remarkStringify from 'remark-stringify';
|
|
|
|
/**
|
|
* Plugin that:
|
|
* 1) ## `Title` -> ## Title
|
|
* 2) ###### **Heading** -> ###### <b>Heading</b>
|
|
*/
|
|
function pluginTransform() {
|
|
return tree => {
|
|
const visit = (node, fn, parent = null, index = -1) => {
|
|
fn(node, parent, index);
|
|
if (node.children) {
|
|
node.children.forEach((child, i) => visit(child, fn, node, i));
|
|
}
|
|
};
|
|
|
|
// Normalize lists to "tight" so Prettier won't remove blank lines later
|
|
visit(tree, node => {
|
|
if (node.type === 'list') {
|
|
node.spread = false;
|
|
if (Array.isArray(node.children)) {
|
|
for (const li of node.children) {
|
|
if (li && li.type === 'listItem') {
|
|
li.spread = false;
|
|
}
|
|
}
|
|
}
|
|
}
|
|
});
|
|
|
|
visit(tree, node => {
|
|
if (node.type !== 'heading') return;
|
|
|
|
// Case 1: H2 with a single inlineCode -> replace with plain text
|
|
if (
|
|
node.depth === 2 &&
|
|
node.children?.length === 1 &&
|
|
node.children[0].type === 'inlineCode'
|
|
) {
|
|
node.children = [{ type: 'text', value: node.children[0].value }];
|
|
}
|
|
|
|
// Case 2: H6 with a single strong -> wrap in HTML <b>...</b>
|
|
if (
|
|
node.depth === 6 &&
|
|
node.children?.length === 1 &&
|
|
node.children[0].type === 'strong'
|
|
) {
|
|
const strong = node.children[0];
|
|
const textOnly =
|
|
strong.children?.length === 1 && strong.children[0].type === 'text'
|
|
? strong.children[0].value
|
|
: null;
|
|
|
|
if (textOnly !== null) {
|
|
// Emit raw HTML inside the heading
|
|
node.children = [{ type: 'html', value: `<b>${textOnly}</b>` }];
|
|
}
|
|
}
|
|
});
|
|
};
|
|
}
|
|
|
|
function transformMarkdown(input) {
|
|
return unified()
|
|
.use(remarkParse)
|
|
.use(pluginTransform)
|
|
.use(remarkStringify, {
|
|
// Keep HTML the way we injected it
|
|
handlers: {},
|
|
})
|
|
.processSync(input)
|
|
.toString();
|
|
}
|
|
|
|
function main(argv) {
|
|
const files = argv.slice(2);
|
|
if (files.length === 0) {
|
|
console.error('Usage: markdown-fix.mjs <file.md> [more.md]');
|
|
process.exit(2);
|
|
}
|
|
|
|
for (const f of files) {
|
|
const before = readFileSync(f, 'utf8');
|
|
const after = transformMarkdown(before);
|
|
if (after !== before) {
|
|
writeFileSync(f, after, 'utf8');
|
|
console.log(`Updated: ${f}`);
|
|
} else {
|
|
console.log(`OK (no change): ${f}`);
|
|
}
|
|
}
|
|
}
|
|
|
|
main(process.argv);
|