Re: [ANN] typecheck 3.0 released

["Gary V. Vaughan" <gary@...>]

On Feb 1, 2023, at 12:52 AM, bil til <biltil52@gmail.com> wrote:
> 
> Did you try for comparison the type recognition features of VS Code
> (freeware, do not mix up with VS, and please install a Lua extension,
> sumneko recommended)? - this is really VERY impressive... for your own
> Lua functions you can quite easily add own help files/ type info lua
> code.

As far as I can tell, VS Code itself doesn't typecheck bare lua code? I started using the sumneko lsp plugin for neovim a year or so ago though. It is excellent work, but it is an out of band static code analyzer and Lua being a very dynamic language it gets extremely confused with a lot of the code in Luarocks I maintain... primarily because I use std.normalize and std.strict to manage the contents of the _G table, and sumneko consequently thinks that all my internal symbols are undefined :-/ Does sumneko do type inference when it is not confused by automatic function import and hoisting?

For a time I used mpeterv's luacheck, also a (fantastic!) static analyzer, and extremely helpful for finding latent issues in clean code. As with all static typecheckers for extremely dynamic languages that run ouside of the target language, it too is easily confused by e.g.  symbol import helpers and the like.

Another tool that I like is Hisham's teal, though I don't use it on any of the Luarocks I maintain because it bloats the dependency tree. If you haven't seen it, teal is to Lua as typescript is to javascript - both transpile to their respective base language.

IMHO The advantage of my typecheck Luarock is that it is executed in the runtime as part of the code that uses it so you can't confuse it with unusual or dynamic coding styles. Ofcourse that could also slow the typechecked code down and introduce more dependency bloat... but we have std._debug for zero cpu cost disabling of typechecking in production code, and I've set up all my Luarocks to check whether typecheck is on LUA_PATH and automatically enable or disable typechecking accordingly - that is, you can develop with typecheck installed to get runtime type errors from your testsuite, but ship without typecheck installed to sidestep the overhead. (note that all my rockspecs currently depend on typecheck, because the testsuites expect the richer error messages it provides... recent releases of luarocks introduced test_dependencies so using that everywhere is on my TODO).

> Does typescript give very strong benefits here?

Do you mean the language server protocols implemented in typescript? Sure, despite the inherent brittleness of static analysis, its nice to get fixits in your editor as you work on your Lua code! More so as more editors support LSP. I'm still on the fence about whether to forgo the convenience of dynamic symbol imports in my code to enjoy the convenience of sumneko fixits in my editor.

Use of typecheck is orthogonal and useful while developing whether or not you use sumneko or luacheck IMHO.

Cheers,
Gary