Generate Typescript documentation from wit files #1157
Conversation
|
|
The core changes are done, but I still need to debug an issue with the npm tests. After these changes Jest is not able to resolve the module imports, even though |
… .d.ts files using the `jco types` command. This command is better for our use case than `jco transpile` because it generates the declarations directly from the source .wit files, whereas `jco transpile` uses the WASM binaries to generate them. This means that `jco types` has access to the documentation that's written in the wit interfaces, and `jco transpile` does not. Since we're generating the interfaces in a separate step, I'm disabling typescript in the original `jco transpile` step. This is just a precaution to avoid confusion or possible conflicting declaration files interferring with each other.
…is correctly propagating through the build process.
…rpose of this is so that both processes use the same `CodegenFileSystem` instance. If they used separate instances, then the files generated in one function would get deleted by the next.
mjoerussell
force-pushed
the
feature/wit-ts-doc-comments
branch
from
8e79c75 to
096ad6d
Compare
crates/codegen/runtime/npm/package/wasm/generated/interfaces/nomic-foundation-slang-parser.d.ts
Show resolved
Hide resolved
crates/codegen/runtime/npm/package/wasm/generated/interfaces/nomic-foundation-slang-cst.d.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
I think there is still one remaining issue, but otherwise, LGTM.
…#1169) When generating documentation for `TerminalKind` and `NonterminalKind`, generate the EBNF grammar for the current variant and include that in the final output. This affects the Wit output and Rust output (using templates `cst.wit.jinja2` and `(terminal|nonterminal)_kind.rs.jinja2`). * [x] Depends on #1157 * [x] Depends on NomicFoundation/jco#3 Closes #1165
This PR uses the
jco typescommand to generate Typescript definitions for the wasm crates instead ofjco transpile. The reason is thatjco transpilegenerates ts definitions by decoding WASM component binaries, whereasjco typesparses .wit files directly and uses that information. This means that theResolveinstance created duringtypeshas access to the type documentation info, and the one created duringtranspiledoes not.I've modified
infra check npmwith a new step which callsjco typesand handles the resulting .d.ts files. When callingjco transpilewe're now passing the option--no-typescriptto avoid generating conflicting typescript outputs.These changes depend on NomicFoundation/jco#1, which augments the
typescommand to accept the same configuration file that we pass totranspile. Without this, the codegen intypeswill not be able to generate Typescript enums for Rust enums, or any other customization that we want.