busted test stdlib extension is not working

[hramrach]

With luacheck 1.0.0 I get

• luacheck --std min --config tests/lua/.luacheckrc --codes tests/lua/command_log_spec.lua
  Checking tests/lua/command_log_spec.lua 31 warnings

  tests/lua/command_log_spec.lua:3:1: (W113) accessing undefined variable describe
  tests/lua/command_log_spec.lua:4:2: (W113) accessing undefined variable it
  tests/lua/command_log_spec.lua:5:3: (W143) accessing undefined field has_no.error of global assert
  tests/lua/command_log_spec.lua:6:3: (W143) accessing undefined field has_no.error of global assert
  tests/lua/command_log_spec.lua:8:2: (W113) accessing undefined variable it
  tests/lua/command_log_spec.lua:9:3: (W143) accessing undefined field has.error of global assert
  tests/lua/command_log_spec.lua:10:3: (W143) accessing undefined field has.error of global assert
  tests/lua/command_log_spec.lua:12:2: (W113) accessing undefined variable it
  tests/lua/command_log_spec.lua:13:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:14:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:15:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:16:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:18:2: (W113) accessing undefined variable it
  tests/lua/command_log_spec.lua:19:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:20:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:22:2: (W113) accessing undefined variable it
  tests/lua/command_log_spec.lua:24:13: (W113) accessing undefined variable spy
  tests/lua/command_log_spec.lua:25:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:26:3: (W143) accessing undefined field spy of global assert
  tests/lua/command_log_spec.lua:26:33: (W113) accessing undefined variable match
  tests/lua/command_log_spec.lua:28:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:29:3: (W143) accessing undefined field spy of global assert
  tests/lua/command_log_spec.lua:29:33: (W113) accessing undefined variable match
  tests/lua/command_log_spec.lua:31:3: (W143) accessing undefined field has.error of global assert
  tests/lua/command_log_spec.lua:32:3: (W143) accessing undefined field spy of global assert
  tests/lua/command_log_spec.lua:32:33: (W113) accessing undefined variable match
  tests/lua/command_log_spec.lua:34:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:35:3: (W143) accessing undefined field spy of global assert
  tests/lua/command_log_spec.lua:36:3: (W143) accessing undefined field equal of global assert
  tests/lua/command_log_spec.lua:37:3: (W143) accessing undefined field spy of global assert
  tests/lua/command_log_spec.lua:37:33: (W113) accessing undefined variable match

This is in conflict with what the documentation says:

files["/tests//*_spec.lua"].std = "+busted"

That is test files should recognize the busted test environment globals.

[alerque]

Did you try this without the  --std min override?

Also please update to v1.1.0 for bug reporting, I don't plan on doing patche releases against anything but the latest release series.

[hramrach]

It does work without --std min

It's not clear these two should interact in any way.

--std min is about the base library provided by the interpreter, and files["/tests//*_spec.lua"].std = "+busted" about running in a test environment.

I do not see anything related in the changelog between 1.0.0 and 1.1.0 but I will try updating anyway.

No difference with 1.1.0

[alerque]

If you explicitly specify a standard to use, it doesn't seem right that luacheck would keep around any special overrides. If you want to use the defaults then use the defaults, or put what you want in the config, but I would fully expect the CLI args to override whatever is in the config (whither my project's or the defaults).

[hramrach]

Default per-path std overrides
luacheck uses a set of default per-path overrides:

files["**/spec/**/*_spec.lua"].std = "+busted"
files["**/test/**/*_spec.lua"].std = "+busted"
files["**/tests/**/*_spec.lua"].std = "+busted"
files["**/*.rockspec"].std = "+rockspec"
files["**/*.luacheckrc"].std = "+luacheckrc"

Each of these can be overriden by setting a different std value for the corresponding key in files.

There is nothing about the global standard also overriding these default per-path overrides.

In fact these starting with + somewhat implies that they add to the toplevel globals whatever they are although it's not explicitly documented.

Also these defaults are pretty useless if selecting which interpreter you are targeting undoes them.

[alerque]

Does it do the same thing clearing the defaults if you change the base std in a .luacheckrc file?

[hramrach]

No, setting the standard in .luacheckrc works fine.

That however means that that the std option behaves differently between commandline and config file.

[alerque]

I for one would expect it to. I would expect the config file to integrate a bit more with defaults and the CLI options to clobber everything. I also wouldn't expect to have to specify all the possible options to get them all cleared on the CLI if I want to use a different std that the default.

I could see making a case for the CLI just changing the same value as the config, but where would the option be to not have any file matching rules playing around with anything?

[hramrach]

That's because you are aware of implementation details of the tool and know it's difficult or even impossible to override the default path rules from the commandline, and that gives rise to a need to have an override.

The problem here is that the override is implicit and undocumented rather than explicit.

I cannot find any reference to this change of behavior of the std option between configuration file and commandline, neither in description of the std option nor in the description of the default path overrides.

Ideally there should be a separate option for disabling the default path overrides, that's clear, transparent, and no less powerful.

Nonetheless in the situation that the existing behavior is quirky and changing it could break stuff it would be nice to at least clearly document it.

[hramrach]

BTW can users use this +something syntax for their own path overrides?

I can't find that documented anywhere either.

[hramrach]

Nevermind, the there is a notice about leading + in https://luacheck.readthedocs.io/en/stable/cli.html#sets-of-standard-globals

[hramrach]

Thanks for considering some improvements in this area.

My suggestion would be to add commandline options like --std-default-overrides, --no-std-default-overrides, and corresponding config file boolean option std_default_overrides.

That way users can both opt in to the default overrides regardless of how they specify the standard globals as well as opt out of all the current and future overrides rather than overriding them one by one.

I have no nice idea how to make the option reasonably short while it's also intelligible what it does.