vshaxe

vshaxe copied to clipboard

Intro: Having used FlashDevelop for the last ~10 years, I am trying to keep up with the cool kids and give VS Code a chance for Haxe development. There are many things I already like about VS Code in general and the vshaxe extension in particular.

There is one point where FlashDevelop's built-in completion really shines, while vshaxe has troubles with. When your code has even one tiny little compile error, and you start VS Code or reload the language server because it was hogging all the CPU for some reason, there is this error that the language server couldn't be started. As a result, there is no completion for anything. So I found out that for comfortable work with VS Code, it's best to try to minimize the amount of time when the project is in non-compileable state. So any refactoring is better done piece-by-piece, or even by adding some substitute dummy code that would later be removed. This is kinda cramping my style, I like to sometimes break a lot of things and then rebuild them piece-by-piece. Also if you have some curly brace or parenthesis missing (or an extra one) somewhere, it still shouldn't be a reason to not have any completion anywhere. Even if the current file can't be properly parsed and completion information extracted from it, why should it mean I can't use completion that relates to other files and/or libraries? Perhaps I'm misunderstanding something, or there is something wrong with my VS Code / haxe setup, but this is what I have experienced in the last couple of months.

I keep VS Code and the vshaxe extension up to date, and am using a rather recent haxe nightly (pre-rc2, didn't try the rc2 yet).

there is this error that the language server couldn't be started

That's not what the error says. The language server is started, and completion also works. It's just much slower than it otherwise could be.

Does it mean it couldn't build any cache, or just cache about the erroneous file? Especially if I'm using some external library (which doesn't have any compile errors), would completion for it work as fast as if my project didn't have errors?

"Building Cache" really just means that it runs a normal compilation with --no-output through a haxe server. If that succeeds, everything is cached, if it doesn't nothing is. Check out the completion cache wiki page.

Apart from the initial cache build, you can also update the cache simply by compiling through the server. This is done by default (you've probably seen that vshaxe adds --connect to the arguments of tasks).

I agree that it's far from ideal that a single missing semicolon can cause the entire cache build to fail, but it doesn't seem like something that's easy to solve. I have been wondering before if at least parts of the cache could eventually be persisted to disk, in which case that could be loaded up when opening a project you've previously had open instead of doing a fresh build each time. But that doesn't exactly seem trivial either, due to cache invalidation issues and whatnot.

Thanks for explaining. That's what I thought was happening. I knew about compiling through server with --connect - because from time to time it hangs and never completes for some reason (running haxe build.hxml on the command-line works fine), I have to kill the haxe process in that case. That's a separate issue I suppose, in my case there's also lix/haxeshim in play, could be related to that as well.

I understand that the task is not trivial (otherwise it would have been done already, for sure), but since I didn't find an existing issue about this topic, I've decided to open one (hope I didn't miss an existing one). I do hope that someone is able to implement that one day. Until then, I personally find this the weakest point in the whole (otherwise great and promising) VSCode+vshaxe combination. I suppose if/when this is implemented, I would probably switch from FD to VSCode fully.

I also have experience that the haxe binary runs indefinitely, eating my CPU and battery. Is this a lix-only problem?

It can definitely also happen without Lix, if something triggers a compiler hang. Two of those issues were recently fixed on Haxe dev: https://github.com/HaxeFoundation/haxe/issues/8174, https://github.com/HaxeFoundation/haxe/issues/8110

There's a good chance there's more, but fixing them would require somebody to report some reproducible example.