Support for .luacheckrc configuration file.

[Yakehira]

Support for .luacheckrc configuration file so that errors/warnings/globals etc can also be disabled over it and shared with other users properly instead of the current only way via settings.

[sumneko]

I don't use luacheck, so the configuration is not universal.
You could set Lua.diagnostics.enable to false, and use luacheck instead of built-in diagnostic feature.

[Stanzilla]

Would still be lovely to have as an option :)

[Stanzilla]

Any news about maybe reconsidering this?

[Stanzilla]

@sumneko thoughts? as an alternative maybe https://github.com/Kampfkarren/selene Kampfkarren/selene#22

[sumneko]

.luacheckrc is a special configuration file for luacheck. The diagnosis in my extension is implemented by myself and does not use luacheck . Therefore, most of the configurations in .Luacheckrc cannot be recognized.

Maybe when I'm free, I can support a small number of them, such as "defined global variables.".

[figsoda]

I was able to implement some basics for .luacheckrc in neovim, perhaps you can try something like this

https://github.com/figsoda/dotfiles/blob/58e993c2949a29fe3af85a932726244266da3cff/lib/nvim/plugins.lua#L297

[SwissalpS]

I understand that a full implementation would be a project of its own. Especially considering the directives such as std = "<popularproject>+max".

A minimal support for looking up the tree to find a .luacheckrc file and at least respecting the globals and read_globals tables in a minimal maner would eliminate a huge number of false-positives.

Question: does your parser support a similar file that we could include in our projects?
That would also help a lot. I'm a bit overwhelmed finding out how exactly this project works
but I'm liking most of the results I get in my editor since I started using it.
Big thanks for all the work so far :D

[SwissalpS]

Would putting https://luals.github.io/wiki/settings/#diagnosticsglobals in a .luarc.json file in my projects base directory do the trick? If so maybe we can come up with a basic converter of .luacheckrc files to .luarc.json

[tomlau10]

luacheck and luals are different tools

Clearly luacheck and lua-language-server (luals) are different tools.

• luacheck uses .luacheckrc
• luals uses .luarc.json

I don't think it is a good idea for luals to support .luacheckrc.
It's because the file format is maintained by luacheck, and is subject to change at anytime.
If you would like to use both luacheck and luals in your projects, (like what my team did: we uses both of them in our projects) you have to setup the correct .luacheckrc and .luarc.json which fits your projects.

maybe a generator tool?

I understand that a full implementation would be a project of its own.

Yeah, I agree with this point. 👍
Maybe you or others can come up with a tool that tries to generate a .luarc.json based on a .luacheckrc.
But definitely it will be a tool/project that's not part of luals. (luals still only reads .luarc.json)

global variable definition in luals

A minimal support for looking up the tree to find a .luacheckrc file and at least respecting the globals and read_globals tables in a minimal maner would eliminate a huge number of false-positives.
...
Would putting https://luals.github.io/wiki/settings/#diagnosticsglobals in a .luarc.json file in my projects base directory do the trick?

Considering only the globals related setting from .luacheckrc, yes I think putting them in diagnostics.globals key inside .luarc.json will do the trick.

• However, this will just silence the undefined-globals diagnostics from luals.
• And you will be missing the auto completion/suggsestion feature of luals when you write _G.<trigger completion>
  • because the type system doesn't know there is a global variable for it
  • that setting is for silencing diagnostic warnings only

luals-way to define globals

In a more luals-way to define globals, one would write definition files: https://luals.github.io/wiki/definition-files/

• you can create a file meta/global.d.lua in your project
  (any filename is fine, can split to multiple files as well)

---@meta

myglobal1 = nil  ---@type string
myglobal2 = nil  ---@type integer

---@class GlobalClass
GlobalClass = {}

---@param a string
---@return boolean
function globalFunc(a) end

• when luals is preloading your workspace, it will preload this unused file as well
• then you can enjoy type hint / completion related to global variables in your project 🚀

disabling some luals diagnostics

Each diagnostic can be disabled independently using the diagnostics.disable or diagnostics.neededFileStatus.
For example, you can just disable the undefined-global in luals side

• .luarc.jsonc

{
    "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",

    // will use luacheck to check for globals instead
    "diagnostics.disable": [
        "undefined-global"
    ]
}

=> no more undefined-global warnings generated from luals side in the codebase💆‍♂️
For more information, you may look up the wiki: https://luals.github.io/wiki/diagnostics/

---

I'm a bit overwhelmed finding out how exactly this project works

Hope this can give you some insights on how you can solve your problems 😄 @SwissalpS
Or if you have further questions, you may also consider posting to the discussion section: https://github.com/LuaLS/lua-language-server/discussions, where more people can see it.

[SwissalpS]

Cool, I now have a converter script for the basics. Support for the std option has to wait until I have created some more tools.

One small dent is that if I don't open my editor at the project root, the .luarc.json file isn't used. Maybe I need to adjust my editor or find an option for LuaLS that enables .luarc.json files that are not in the current working dir.

Example: I have a directory, A, in which I collect mods/plugins. Each mod/plugin has its own
.luarc.json file. But since I often need to work on multiple plugins simultaneously I tend to open the editor at A and not at the plugin folder.
On top of that some directories in A are themselves collections of other plugins/mods.

[tomlau10]

One small dent is that if I don't open my editor at the project root, the .luarc.json file isn't used. Maybe I need to adjust my editor or find an option for LuaLS that enables .luarc.json files that are not in the current working dir.

If you are using vscode, then you may try to use its multi-root workspace feature 🤔
LuaLS support multi-root workspace and will use the correct .luarc.json for each of the sub workspace.

There is a recent discussion (#3030) asking about how to scope the definition file:

• there is a client/ and server/ sub folder
  • client/ wants to use only share.d.lua and client.d.lua
  • server/ wants to use only share.d.lua and server.d.lua
• client shouldn't know server's class, and vice versa