Commands · reference
config-weave wscripti
wscripti writes weave.wscripti, the wscript interface file describing the whole host API, plus a starter wscript.toml that points at it. With both files next to your scripts, wscript check and the wscript language server type-check against the exact surface config-weave provides. See The host API.
Synopsis
config-weave wscripti [OPTIONS] [OUTDIR]
Arguments
| Argument | Meaning |
|---|---|
| OUTDIR | Directory to write both files into. Optional. Defaults to the current directory. Created when missing. |
Options
Only the global options are accepted, and none affect the output.
The interface file
weave.wscripti is generated from the host modules compiled into the binary, so it is the authoritative description of the host API for the version of config-weave that wrote it. Every module, function, struct and enum a script can use appears in it with its exact signature. Regenerate it after upgrading config-weave. It is the same surface config-weave validate compiles scripts against, so a script the editor accepts is one validation accepts.
The starter wscript.toml has one line.
= ["weave.wscripti"]
An existing wscript.toml is left untouched, so you can extend it. weave.wscripti is always overwritten.
Editor and LSP use
Write the files where your scripts live, or at a directory the editor treats as the workspace root. The wscript LSP reads wscript.toml, loads the listed interfaces, and then offers completion, hover types and diagnostics for fs::, shell::, log:: and every other host module. wscript check uses the same file from the command line.
Examples
Generate the files into a package's resources directory.
config-weave wscripti ./my-playbook/pkgs/core/resources
wrote ./my-playbook/pkgs/core/resources/weave.wscripti and wscript.toml
Generate them at the playbook root so one workspace covers every package.
cd ./my-playbook && config-weave wscripti
Exit status
0 when both files were written. 2 when the directory or a file could not be written.