Peter Melnichenko
Peter Melnichenko
Not your bad, it should have been documented
Yes, this is a nice idea! For modules within same package as the file being checked Luacheck could read source of required modules and infer available fields from there. This...
> Oh, as I see _G part can be omitted. Nice. Is it documented? It's mentioned [here](https://luacheck.readthedocs.io/en/stable/cli.html#sets-of-standard-globals): > Leading plus sign adds new sets to default [set of standard globals]...
> BTW, before 0.19.0 _G meaning was different: read globals from current environment. Why that feature removed? > Can you reintroduce it (with some other name)? I wanted to have...
>I suppose in many cases such mapping can be done using current package.path. Often modules being checked are not in `package.path` during development. E.g. luacheck itself has modules in `src/`,...
> You are right, we need some option, Can it be in form package.path? Sometimes source file layout is weird and does not correspond to any `package.path`. So probably will...
Luacheck doesn't use package.path or any include paths, it checks only files that are passed to it. By default it does not tolerate any custom globals, even if they are...
So the idea is that calling a pure setter method should not mark the table as accessed, but instead it should be considered a mutation. This makes sense, although I'm...
(FTR the message is improved on maser branch)
@hishamhm I don't think there is anything incomplete to hold us back. I've got a few PRs but they can wait. Although I'd love to get at least the download...