Publish as WASM bundle with JS bindings

[sgarfinkel]

This might be a bit ambitious, but since CK3-tiger already implements its own index it would also be handy to expose some functions for accessing this publicly as well.

At the very least, programmatically running it and accessing its reports would be needed.

Publishing as WASM with JS bindings will also enable it to be included directly in an LSP/VSCode extension.

[amtep]

There is a vscode extension which might do what you want: https://github.com/unLomTrois/ck3tiger-for-vscode

The main problem with tiger as an LSP is that it's not designed for reading new files interactively. It operates in two phases, one for reading everything and one for validating everything.

[sgarfinkel]

That’s true, but WASM runs much more efficiently and opens up the option of adding better and more advanced bindings versus simply running ck3-tiger as a subprocess.

[my4ng]

Should be fairly straight-forward to expose some functions with something like wasm-bindgen. However, would be great if someone with the expertise in TS/JS and VSCode extension can complete the front end.

[amtep]

A useful API for tiger is another question, though :) I've been thinking about that for a while now. Exposing tiger's knowledge about the game script is difficult because it's nearly all imperative: tiger does a series of checks. It doesn't have an internal schema about what to expect where; it's just code. I've thought about converting to a schema-based approach, but supporting the full variety of checks tiger can do would be difficult. It's why I opted for the imperative approach in the first place.

There's currently a Rust interface to list all the Item types and their names, which can help people make mod compatches and may be useful for tab completion. This could be exposed as a binding. Additionally tiger could expose the parse tree in the form of (key, block) entries but I don't know how useful that is. And of course it can supply the reports, but TBH I think the existing JSON interface does a good job of that already.

I don't understand the claim that WASM would be more efficient. Surely native code is faster?