Add check for backend command generate-bindings#1115
Conversation
kasbah
force-pushed
the
kb/ci-generate-bindings
branch
3 times, most recently
from
59994f3 to
d507a42
Compare
kasbah
force-pushed
the
kb/ci-generate-bindings
branch
from
d04671a to
1f07af1
Compare
| Command::GenerateBindings => { | ||
| use qubit::TypeScript; | ||
|
|
||
| let path = std::path::PathBuf::from(env!("CARGO_MANIFEST_DIR")) | ||
| .join("pkg") | ||
| .join("src") | ||
| .join("index.ts"); | ||
|
|
||
| rpc::router() | ||
| .as_codegen() | ||
| .write_type(&path, TypeScript::new()) | ||
| .expect("Failed to write TypeScript bindings"); | ||
|
|
||
| info!("Successfully generated TypeScript bindings to: {}", path.display()); | ||
| return; | ||
| } | ||
| Command::GenerateBindings => unreachable!(), |
There was a problem hiding this comment.
I moved this so we can run generate-bindings without the DATABASE_URL env variable.
|
I'm wondering if this should become part of the nix build process instead of a check. We have a similar pattern for catcolab-wasm: in local dev it's generated with a pnpm/cargo command, when deployed it's built as a Nix package. I supposed a possibly meaningful difference is that the generate artifact is committed, but IMO we probably shouldn't be doing that anyway. The change itself fine if we don't want to open the bigger can of worms right now. |
|
We can talk about that separately but I am only aiming for a quick fix of the existing dev experience with this. |
epatters
changed the title
generate-bindings
|
What exactly was the issue that this was meant to solve? I could see a couple ways this could help, but I'm wondering what specifically motivated this? |
|
I want to freely run |
3 participants
Checks that we ran generate-bindings i.e. no diff in the output when it is run again.