Skip to content

Conversation

drogus
Copy link
Collaborator

@drogus drogus commented Oct 7, 2025

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)

@drogus drogus self-assigned this Oct 7, 2025
@drogus drogus marked this pull request as draft October 7, 2025 10:55
@drogus drogus force-pushed the drogus/spacetime-init branch 18 times, most recently from c022d34 to ea0f0f7 Compare October 15, 2025 20:52
@drogus drogus force-pushed the drogus/spacetime-init branch from ea0f0f7 to e536cc3 Compare October 15, 2025 20:53
@drogus drogus force-pushed the drogus/spacetime-init branch from 10f14ee to cc118cc Compare October 16, 2025 11:49
@drogus
Copy link
Collaborator Author

drogus commented Oct 16, 2025

This PR is now almost ready for a review with two caveats:

I've included TypeScript as a module language, but due to #3327 it obviously is not finalised, so I think this PR should wait for #3227, so I don't have to rip out all of the mentions of module TS, just to introduce it when the other PR is merged

I don't really like how the arguments to the subcommand turned out due to leaving the old usage intact. here are the changes in the command output, and honestly I can't really make too much sense out of it, even though I implemented the new version. The problem is, that now we have legacy --lang, and a new --server-lang, and then a few options that are not really compatible with the old way the command worked. We need to use different arguments in order to detect if we want to run in the interactive mode, or not. More specifically, the legacy --lang assumes the old way, ie non-interactive mode and the old functionality, but we also need to have a case where --server-lang is passed just to pre-select the option from the interactive mode. There are a few ways we could fix this:

  1. Remove the legacy options from the help message. This would still leave older tutorials working, but also not create confusion about the new options. That said, it may as well be confusing to not include the options if someone is wondering why --lang works
  2. Remove the old functionality altogether
  3. Write a fully custom help message that will list both modes

Personally I'd go for two as it would also allow to massively simplify the implementation, but if we really want to keep the functionality then I'd probably try 3. so the message makes more sense

The summary of the PR so far:

  • the init command now goes into interactive mode by default
  • the templates list is defined in a JSON file in the repo: https://github.com/clockworklabs/SpacetimeDB/pull/3366/files#diff-12a92074e42916d3615fc6c567db3f12460b81a1e9f668d69d64a4ec709426f6
  • the interactive mode allows choosing one of the predefined "highlited" templates or choosing one of the other templates or a GH based template
  • the old version of the command used project directories with files with suffixed extensions like Cargo._toml. This doesn't play too well with cloning, so I moved those projects to the templates directory with the files and directory structure the same as the resulting project. I'm not sure if there are any problems with that - I can't see any. It seems to me like the underscored extensions were created mostly because the templates were inside the src directory. With the templates dir outside of src I don't think cargo will pick them up
  • we now ask users for a name and update the project name in the client side of the project, for example in the toml config, or package.json

@cloutiertyler cloutiertyler mentioned this pull request Oct 16, 2025
2 tasks
@drogus drogus force-pushed the drogus/spacetime-init branch from 1a87bbf to 47e5c2d Compare October 17, 2025 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant