Add LUA support

[AlejandroSuero]

Is your feature request related to a problem? Please describe.

The LUA projects are not benefitting from this project

Describe the solution you'd like

In the LUA ecosystem there are 2 linters (at least this are the ones I know), luacheck (which hasn't been updated since 6 years ago) and selene (currently updating), and 1 formatter, stylua.

Note

The listed ones, are those which are popular and widely used.

In my personal opinion, I think that selene is better because, apart from being currently maintained, it has a more human-like way of configuring and displaying the errors than luacheck.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

I have made a selene linter action and there is one for stylua.

[echoix]

I think both of these are directly in the spirit of what we look for for linters in MegaLinter. I'm glad to hear feedback on what users use in the Lua ecosystem.

Selene seems like a great start, might be easily integratable (as written in rust, should be easily packable). And Stylua too, as it's packaged inside a Docker image as a binary too.

Would you mind making a try at editing the descriptor file here: https://github.com/oxsecurity/megalinter/blob/main/megalinter/descriptors/lua.megalinter-descriptor.yml
For StyLua, their docker instructions (if it works on alpine with muslc), you can inspire yourself from kubeconform here https://github.com/oxsecurity/megalinter/blob/main/megalinter/descriptors/kubernetes.megalinter-descriptor.yml#L39

[nvuillam]

If luacheck has not been updated for 6 years... is it still relevant ?
Do you think we should deprecate it after adding the modern lua linters ?

[AlejandroSuero]

@nvuillam the thing with luacheck it is that there are codebases with luacheck I don't know which ones use MegaLinter, but if there is a way of having a message like GitHub does when using Node16 for actions where now should be using Node20, could be a nice start.

But luacheck is still good, I think is not maintained anymore because the people behind it are glad with the state is in (not sure though), but in your .luacheckrc you have to use rules like this:

• .luacheckrc from neovim:

-- vim: ft=lua tw=80

stds.nvim = {
  read_globals = { "jit" }
}
std = "lua51+nvim"

-- Ignore W211 (unused variable) with preload files.
files["**/preload.lua"] = {ignore = { "211" }}
-- Allow vim module to modify itself, but only here.
files["src/nvim/lua/vim.lua"] = {ignore = { "122/vim" }}

-- Don't report unused self arguments of methods.
self = false

-- Rerun tests only if their modification time changed.
cache = true

ignore = {
  "631",  -- max_line_length
  "212/_.*",  -- unused argument, for vars with "_" prefix
  "214", -- used variable with unused hint ("_" prefix)
  "121", -- setting read-only global variable 'vim'
  "122", -- setting read-only field of global variable 'vim'
  "581", -- negation of a relational operator- operator can be flipped (not for tables)
}

-- Global objects defined by the C code
read_globals = {
  "vim",
}

globals = {
  "vim.g",
  "vim.b",
  "vim.w",
  "vim.o",
  "vim.bo",
  "vim.wo",
  "vim.go",
  "vim.env"
}

exclude_files = {
  'test/_meta.lua',
  'test/functional/fixtures/lua/syntax_error.lua',
  'runtime/lua/vim/treesitter/_meta.lua',
  'runtime/lua/vim/_meta/vimfn.lua',
  'runtime/lua/vim/_meta/api.lua',
  'runtime/lua/vim/re.lua',
  'runtime/lua/coxpcall.lua',
  'src/nvim/eval.lua',
}

• selene.toml + neovim.yml from freeze-code.nvim

std="neovim"

exclude = ["./*.rockspec"]

[rules]
global_usage = "warn"
multiple_statements = "allow"
incorrect_standard_library_use = "allow"
mixed_table = "allow"
unused_variable = "warn"

---
base: lua51

globals:
  jit:
    any: true
  vim:
    any: true
  assert:
    args:
      - type: bool
      - type: string
        required: false
  after_each:
    args:
      - type: function
  before_each:
    args:
      - type: function
  describe:
    args:
      - type: string
      - type: function
  it:
    args:
      - type: string
      - type: function

As you can see, in the .luacheckrc the rules are just numbers that you usually need to comment what they do or search for them in the documentation while selene uses a more descriptive approach as well as adding more specific rules.

[AlejandroSuero]

@echoix I made a PR for selene, since it's my first PR in this codebase, tell me if some things need changing or improvement.

[nvuillam]

Ok let's keep luacheck for now :)

Thanks for your PR, i posted a comment :)