Roadmap to MVP

[tamasfe]

With the current bugs fixed, I think the language server could get into its first shippable state.

Here are the steps that I think need to be done in order to properly ship it:

TODO before shipping

• [x] fix all the breaking bugs in the HIR and language server (#52)
• [ ] write a lot more tests for the HIR
• [x] include a default set of hand-written definition files (#35)
• [x] figure out a seamless way for users to load their own metadata for definitions (#35)
• [x] finalize configuration file format and actually use it (#39)
• [ ] document the vscode extension

Steps to ship

We'll need to

• either merge this repo into rhai and create a universal CLI that includes the language server
• or create the WASM bindings and use them in the extension

and then

• [ ] create CI/CD jobs that builds the vscode extension either for multiple platforms or just one in case the WASM step above was chosen
• [ ] publish the extension to marketplaces

[tamasfe]

/cc @schungx

Actually the CLI and WASM parts are orthogonal, but we need at least one of them. With WASM the vscode extension is a lot easier to distribute, but some users might want to use the language server wherever (e.g. vim, emacs).

I think we should focus on vscode first as that's where I develop anyway, and WASM bindings are a lot easier than multi-platform builds.

[schungx]

I agree. We should at least get vscode working. WASM will be great.

For all others, we'd need to start distributing binaries, which will be a chore.

[schungx]

@tamasfe I have updated the Definitions part a bit to include types for variables/constants in generated definition files. You can pull from latest to check those.

For example, __scope__.d.rhai would have let hello_there: string;

So far I don't see any particular problems with those types added, so I assume that it is safe...