Monaco Support #703
Replies: 2 comments 1 reply
-
|
This is pretty awesome! Cool to see other editor integrations, particularly with Monaco. I remember a few other folks who did some work to get Luau LSP working in Monaco, but not sure what progress they made (it is probably on GitHub somewhere). I don't believe they used emscriptem/wasm, and instead ran the binary somehow in the background, but it's been a while so my memory is a bit fuzzy. I would definitely be open to accepting fixes (or working on them if you've got a good repro) to help make your life easier. The bad handling of First party Monaco support could be interesting but my time is quite limited right now in terms of reviewing and maintaining it, so I wouldn't want to burden your dev work if branching your org-specific changes is a hassle. But more than happy to review smaller PRs to help make it easier to work with :) |
Beta Was this translation helpful? Give feedback.
-
|
Running the binary in the background is another option, yeah. We can always connect the language client module to a LSP via websocket, and what the language server would need in that case is either websocket support or a shallow host application that facilitates communication between a websocket server and the LSP. My attention is divided at the moment, but I'll take some of the work already done and split them out into dedicated branches for pull requests. The minimal viable change for extracting out stdio is awfully small. Would you like me to start there, or would you like a bigger bite, like a more holistic dependency inversion refactor that attempts to isolate other dependencies like documentation and definition files? |
Beta Was this translation helpful? Give feedback.
-
|
Though I am not working on this full-time, I am updating this on occasion. I have a half-functional demo at https://github.com/kylerudy-imvu/luau-lsp which uses Docker for the emscripten compilation and linking. Somewhere along the line, when extracting code from our production repos to a minimal demo, I lost the error squiggles and package resolution. This might be related to the transition from older versions of the various JS libraries to 2024's releases. Hover and global documentation still works as intended, and I'll continue to chip away every now and then. We're using this in production for an alpha feature now, and it's proven fairly stable, with admittedly ancient versions of the Monaco library. I introduced a MonacoPlatform.hpp in contrast to the RobloxPlatform, to handle some compatibility issues. In retrospect, this was the wrong solution, so I'll probably take another pass at fixing those issues before putting in a PR. A recurring issue with the integration are filesystem-oriented callouts to crawl a workspace folder for its contents. This makes sense in the scope of a traditional vscode workspace managed on a local disk, but it's a point of friction here. Emscripten has a fake filesystem, of course, and generating a fake folder for luau-lsp handles the problem in the short term. What's interesting about this problem, though, is that vscode / monaco's source roots workspace folders to URIs, so anchoring the workspace folder to, eg, a ftp site or some other shared networked resource is also on the table. It might be unnecessary work for a non-existent reward, but I'm tempted to add an abstraction for this too. |
Beta Was this translation helpful? Give feedback.
-
Edit: instructions at the bottom of this post have been updated to the latest change.
This regards https://github.com/kylerudy-imvu/luau-lsp which is very much a work in progress.
Our organization has a Lua scripting feature currently in alpha, and the online editor uses Monaco. Since we ported to Luau for the engine, this project felt like a natural best-fit for LSP, with the @codingame/monaco-languageclient package powering the javascript side. I've got a MVP working well enough locally, and I'm curious if there's an interest in integrating Monaco platform support with the rest of the library.
I'm using Emscripten for the wasm compilation, and for this revision, the filesystem emulation. I'm pretty sure we can get rid of the filesystem emulation and probably the whole Emscripten javascript harness, loading wasm directly, but it's going to take some more work on top of what I've already started. My existing change refactors out the i/o so we're not tied to stdin/stdout, but we'll also need to introduce a proper abstraction for documentation and definition provision, so we don't hit a filesystem that may not exist.
This first take is a little messy, and I've done my best to strip out the organization-specific stuff that I'm developing against for our org's own needs. Before I go any further (eg, creating an agnostic minimal demo app in javascript), I wanted to gauge if there's any interest. This entire development ecosystem (C++, CMake, Github Actions, etc.) is outside my normal wheelhouse, so I doubt I'll be able to provide you a complete and picture-perfect pull request at any stage of development.
An important issue I've discovered along the way is that the plugin simply does not support non-traditional protocols. The native workspace for Monaco is "inmemory://model/" with filenames like "1". The existing workspace management code does not handle "inmemory://", nor does it particularly like "file://" when the authority is an unexpected value. I have a hack in place right now, but I believe a better approach is possible.
I don't have integration with your build system yet. Right now I am getting by with a pair of batch files:
Right now, it works quite well. The full Debug build with DWARF symbols is absolutely enormous and slow, of course, but it provided useful stack traces for figuring out the issues with workspace support. The Release build generates <5MB of wasm, and is fairly snappy when used in a webworker.
If there's interest in supporting Monaco, I'll continue to keep our organization's specific changes branched from what I believe may be useful for the general audience, and collaborate for a pull request at some point.
Beta Was this translation helpful? Give feedback.
All reactions