[Error] tl types has returned an empty response.

[quienn]

Just installed the vscode-teal extension through the editor itself, version 1.57.1, Windows 10.

When run from PowerShell, tl types does work perfectly fine.

Edit: I'm running tl 0.13.1. I'll check if this happens in latest master branch.

[pdesaulniers]

OK, I've seen this error before: #34

How did you install tl? Did you use LuaRocks?

[pdesaulniers]

In any case, I assume Node.js is unable to find tl in the PATH for some reason. The extension is probably failing to detect the ENOENT correctly, and it encounters an error later on because stdout is empty:

vscode-teal/server/server.ts

Lines 227 to 230 in 6282f7b

	if (isEmptyOrSpaces(typesCmdResult.stdout)) {
	showErrorMessage("[Error]\n" + "`tl types` has returned an empty response.");
	return null;
	}

[quienn]

How did you install tl? Did you use LuaRocks?

Yes, using LuaRocks 3.5.0. I'm managing my Lua install using hererocks.

Instead of relying in Node.js magic, what about letting the user choose a path where tl is located? It could first search for it in the PATH and then, if it is not found, use the one at tl.compilerPath instead.

[pdesaulniers]

Yes, using LuaRocks 3.5.0. I'm managing my Lua install using hererocks.

OK, good. Can you please run cmd.exe and check if tl is available in the PATH? If not, can you add it to the PATH and check if that fixes the issue?

Instead of relying in Node.js magic, what about letting the user choose a path where tl is located?

The extension used to have an option for customizing the compiler path, but it would lead to some issues due to how LUA_PATH works.

The tl driver always require the first tl.lua that it finds in the LUA_PATH. Even if we call /subdirectory/tl/tl directly, this doesn't mean that the driver will necessarily pick up /subdirectory/tl/tl.lua. It could pick a different one, say, /usr/local/lua/tl.lua instead. So, the tl.compilerPath option did not behave as expected in some cases :/

[quienn]

Can you please run cmd.exe and check if tl is available in the PATH?

It worked! But that just defeats the whole purpose of using hererocks to manage different Lua versions for me. 😞
The cool thing about my setup at least is that I can change a $LuaVersion variable in PowerShell and get that version up and running easily.

What about bundling tl.lua into the project? Something like fengari or even wasmoon would do the job of running it. Relying in the user compiler could lead to inconsistencies and errors because of different versions being tested.

[pdesaulniers]

Yes, I think this could be a good solution. I'll think about it!

The tl releases on GitHub contain standalone executables for Windows and Linux. Instead of running tl.lua using fengari, it would probably be easier to bundle these platform-dependent tl executables along with the extension.

[pdesaulniers]

The error message should be indirectly fixed by 85cffb7.

The extension will now display the following message when opening a file, if tl cannot be found:

Could not find the tl executable. Please make sure that it is available in the PATH.

Type-checking has been disabled for this file.

I'm closing this issue in favor of #44. Thanks!

[quienn]

The error message should be indirectly fixed by 85cffb7.

Though the error I reported actually got fixed with ae605c9 somehow, that was the other thing I wanted to open an issue for, because it became an annoyance while breaking stuff in my existing codebase. I'm glad it's fixed!