luacheck VS LjTools

Not directly related, but luacheck can also help with this.

Yeah. While you're at it, make a habit of running luacheck on your files as it helps catch a lot of these issues that can sneak in by mistake: https://github.com/mpeterv/luacheck

Using something like https://github.com/mpeterv/luacheck might be helpful too. Will check all the files in a directory and will let you know which one might be problematic.

I'm trying to setup luacheck (via null-ls) to run alongside sumneko-lua (via nvim-lspconfig).

Most of the time nothing is used. The thing is that iterating is so quick, that you find the problems really fast.

Although, I've been using luacheck https://github.com/mpeterv/luacheck. It is quite nice, but you have to write down the global variables by hand on the config file.

Check out luacheck. It can help spot typos or mistakes you've made and warn against anti-patterns. I'd honestly only look into setting it up locally because there's no benefit to putting it in a CI pipeline unless you have one for another reason IMO. This should be all the config you need:

Sadly the scenario that the successor feature is intended to alleviate has very much become reality. The creator of Luacheck (Peter Melnichenko) passed away a couple of years ago, and ever since then the GitHub repository has been in a state of limbo. Multiple unofficial forks have come and gone, but Peter's is still the first result on Google if you search "luacheck". It isn't even possible to change the README or pin an issue to get people's attention about the fork; to this day people are still posting issues to the old repo.

And Luacheck is "the" Lua static analysis tool that pretty much everyone uses, so it's a very significant issue.

https://github.com/mpeterv/luacheck/issues/198

You are probably right, but luacheck is well aware of which global variables are built-in and it has special comments, such as -- no global or --ignore in case you very want to overwrite them.

Calling your function self is as much bad practice as calling it print. Use luacheck to avoid such mistakes.

I dug a little more and came across this tool which does seem to have the capability to view all LuaJIT Bytecode. https://github.com/rochus-keller/LjTools

> a large lua game code base, over 4000 files, 1.5 million lines of code

Interesting; how do you manage to keep consistency? Do you have special tools to e.g. detect inadvertent global variables? I once wrote a Smalltalk VM in Lua (https://github.com/rochus-keller/Smalltalk/blob/master/Inter...) which is a much smaller code base but even with this size I quickly would have lost track of e.g. scopes and names without tools I had to write myself (https://github.com/rochus-keller/LJTools).

Most of my languages have VM backends; see e.g. https://github.com/rochus-keller/Oberon; I implemented different backends generating LuaJIT bytecode; a year ago I switched to Mono which is based on ECMA-335; here is a discussion why I switched: https://github.com/rochus-keller/Oberon/releases/tag/IDEv0.9.0; I implemented utility libraries for both LuaJIT and CIL bytecode; see https://github.com/rochus-keller/LjTools/, https://github.com/rochus-keller/Pelib/ and https://github.com/rochus-keller/MonoTools/. I evaluated many VMs and think the mentioned ones are best suited. There were a lot of challenges with both technologies, what is to be expected, and too much to describe here.

LuaJIT is well suited as a backend/runtime environment for custom languages; I did it several times (see e.g. https://github.com/rochus-keller/Smalltalk, https://github.com/rochus-keller/Som/, https://github.com/rochus-keller/Oberon/). I also implemented a bit of infrastructure to ease the reuse: https://github.com/rochus-keller/LjTools. LuaJIT has some limitations though; if you require closures you have to know that the corresponding LuaJIT FNEW bytecode is not yet supported by the JIT, i.e. switches to the interpreter; as a work-around I implemented my own closures; LuaJIT also doesn't support multi-threading, but co-routines; and there is no debugger, and the infrastructure to implement one has limitations (i.e. performance is low when running to breakpoints). For most of my projects this was no issue. Recently I switched to CIL/Mono for my Oberon+ implementation which was a good move. But still I consider LuaJIT a good choice if you can cope with the mentioned limitations. The major advantage of LuaJIT is the small footprint and impressive performance for dynamic languages.

Implementing a VM is certainly interesting, but if you just need a fast backend you could generate LuaJIT bytecode (see e.g. https://github.com/rochus-keller/ljtools/ LuaJitComposer.h/cpp).

If you want to re-use LuaJIT as a backend, have e.g. a look at https://github.com/rochus-keller/ljtools

Recently I mostly use https://github.com/rochus-keller/LjTools#lua-parser-and-ide-features