b47b9c9613
There's some bug in the frontend or KCL somewhere, which results in the TypeScript frontend sending an AST (serialized to JSON) to the KCL executor, but the JSON cannot be deserialized into an AST. If this happens, it's a bug in ZDS, not a user error. The problem is that this sort of error will cause the frontend to silently stop rendering KCL, and it won't show the user any errors. They need to open up the console and look at the error there, and even if they do, it's hard to understand. This PR changes how we report these unexpected errors due to bugs in ZDS. ZDS should not silently stop working, it should at least print a half-decent error like this: <img width="527" alt="nicer error" src="https://github.com/user-attachments/assets/1bb37a64-0915-4472-849c-d146f397356b" /> ## Fix Right now, the wasm library exports a function `execute`. It previous returned an error as a String if one occurred. The frontend assumed this error string would be JSON that matched the schema `KclErrorWithOutputs`. This was not always true! For example, if something couldn't be serialized to JSON, we'd take the raw Serde error and stringify that. It wouldn't match `KclErrorWithOutputs`. Now I've changed `execute` so that if it errors, it'll returns a JsValue not a string. So that's one check (can this string be deserialized into a JSON object) that can be removed -- it'll return a JSON object directly now. The next check is "does this JSON object conform to the KclErrorWithOutputs schema". To prove that's correct, I changed `execute` to be a thin wrapper around `fn execute_typed` which returns `Result<ExecOutcome, KclErrorWithOutputs>`. Now we know the error will be the right type.
kcl-lib
Our language for defining geometry and working with our Geometry Engine efficiently. Short for KittyCAD Language, named after our Design API.
Contributing a standard library function
We've built a lot of tooling to make contributing to KCL easier. If you are interested in contributing a new standard library function to KCL, here is the rough process:
- Open just the folder in your editor of choice. VS Code, for example, struggles to run rust-analyzer on the entire modeling-app directory because it's such a turducken of TS and Rust code.
- Find the definition for similar standard library functions in
./kcl/src/stdand place your new one near it or in the same category file. - Add your new code. A new standard library function consists of:
- A
pub asyncof the actual standard library function in Rust - A doc comment block containing at least one example using your new standard library function (the Rust compiler will error if you don't provide an example our teammates are dope)
- A
stdlibmacro providing the name that will need to be written by KCL users to use the function (this is usually a camelCase version of your Rust implementation, which is named with snake_case) - An inner function that is published only to the crate
- Add your new standard library function to the long list of CORE_FNS in mod.rs
- Get a production Zoo dev token and run
export KITTYCAD_API_TOKEN=your-token-herein a terminal - Run
TWENTY_TWENTY=overwrite cargo nextest run --workspace --no-fail-fastto take snapshot tests of your example code running in the engine - Run
just redo-kcl-stdlib-docsto generate new Markdown documentation for your function that will be used to generate docs on our website. - Create a PR in GitHub.
Making a Simulation Test
If you have KCL code that you want to test, simulation tests are the preferred way to do that.
Make a new sim test. Replace foo_bar with the snake case name of your test. The name needs to be unique.
just new-sim-test foo_bar
It will show the commands it ran, including the path to a new file foo_bar/input.kcl. Edit that with your KCL. If you need additional KCL files to import, include them in this directory.
Then run it.
just overwrite-sim-test foo_bar
The above should create a bunch of output files in the same directory.
Make sure you actually look at them. Specifically, if there's an execution_error.snap, it means the execution failed. Depending on the test, this may be what you expect. But if it's not, delete the snap file and run it again.
When it looks good, commit all the files, including input.kcl, generated output files in the test directory, and changes to simulation_tests.rs.
Bumping the version
If you bump the version of kcl-lib and push it to crates, be sure to update the repos we own that use it as well. These are: