Add LLS addon support

[keithharvey]

Closes #953

Changes

• lx update: Introduce implicit and explicit LuaLS addon installation by cloning LLS-Addons and storing addon metadata in the lockfile whenever dependency.name matches LLS-Addons/addons/{dependency.name}/.
• lx check: Expand to scan every project folder, including tests.

TOML Configuration

lux.toml

check_dependencies = true  # default; set false to skip implicit addon resolution during `lx update`

[test_dependencies]
addons = ["busted", "luassert"]  # optional, but enforced if present. Missing entries fail the update.

All of these are pointless for my particular project, which relies on implicit detection.

Notes: this addons field is probably deficient because of its inability to pin specific versions of an addon (I guess with a commit hash?), but just let me know what you want to do there, it felt like overkill for a feature I wasn't sure we wanted (explicit addons) but I thought about it.

Lockfile Changes

lx update now emits addon records in lux.lock such as:

"addons": [
  {
    "name": "busted",
    "source": "lls_addons+https://github.com/LuaLS/LLS-Addons",
    "implicit": false,
    "library_paths": [".lux/5.1/lls_addons/addons/busted/library"],
    "version": null,
    "commit": "5ed85d0"
  }
]

LuaLS Configuration

luarc.json is regenerated with normalized, project-relative paths:

{
  "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
  "Lua": {
    "workspace": {
      "userThirdParty": [
        ".lux/5.1/lls_addons"
      ],
      "library": [
        "${3rd}/luassert/library"
      ]
    }
  },
  "workspace": {
    "library": [
      "types",
      ".lux/5.1/lls_addons/addons/busted/library",
      ".lux/5.1/lls_addons/addons/luassert/library",
      ".lux/5.1/test_dependencies/..."
    ]
  }
}

Lua.workspace.library entries (for example ${3rd}/luassert/library) come directly from each addon's config.json.

Testing

• Verified implicit and explicit addon handling.
• Confirmed typings now resolve for busted and friends.
• Lockfile captures addon commit hashes as versions.
• lx check runs successfully across test directories.

Does Not

• Integrate with the official Lua Addon list; that can follow in a separate PR by plugging the catalog into addons.

LLM Disclosure

GPT-5 Codex used

[mrcjkb]

Thanks again for the PR 🙏

#953 is more of a tracking issue in which I noted down some very rough ideas.
We need to give it a lot more thought before we move on to an actual implementation.
And I currently don't have the capacity to review an AI generated PR of this size (see our AI policy).

I'd like to try and start with something as minimal as possible (e.g. to first see if it's possible to distribute luarocks packages that can simply be added to test_dependencies without having to change anything in Lux).

We also don't want to target support for lua-ls explicitly. Whatever we come up with needs to be compatible with emmylua-analyzer-rust, which has much more active development and in my recent experience provides higher quality type checking and better performance than lua-ls.

Thanks to your efforts (and beyond-all-reason/Beyond-All-Reason#6005), I see there is a need to support 3rd party type annotations and can hopefully prioritise it soon 😄

[keithharvey]

@mrcjkb Hmm well I don't mind coding a design myself if you articulate the design you're after. Can you elaborate on "We also don't want to target support for lua-ls explicitly"? I did source it explicitly but our addon handling should be generic. I did review this but not super meticulously since I wasn't sure about the design itself yet. I tried to make something that followed the issue and still met my needs, but was largely putting this forward to vet the shape more than the implementation (which looked fine but not mergeable as is probably, it needs a manual spec pass to cleanup and dogfood it more). The AI policy mentions review and ownership but skips size (which is understandable), but I actually sat down and thought about this before and after implementing it and did think this was a decent first iteration.

Does the rust language server have a robust addon list/cross compatibility with the sumneko addons? I would honestly expect it to just work with this given it is all EmmyLUA and our 'luarc' points at the right paths. I'd need to look into it but it seems like you're telling me this is something you're going to solve in the future and to hold off solving it? I saw the link to that issue as an invitation to solve it that way. The only real deviation I made from my squinting interpretation of that issue was to move it to update instead of check and throw the addon versions in the lock file (do we agree with that decision to accommodate pinning specific addon versions?). Anyway, that issue seems like a better direction than my first attempt, happy to help, just let me know.

[mrcjkb]

if you articulate the design you're after

I don't have a design I'm after at this point. Before thinking of a design, I want to investigate if it would be even necessary to do anything in Lux at all.
As I mentioned, it may be possible to solve this just by packaging the LuaLS add-ons as luarocks packages so they can simply be added to the test_dependencies. I don't know - I'll have to investigate this.

I'm not really a fan of the add-on approach taken by LuaLS, because the meta-modules in th e add-ons can easily become out-of-sync with the respective libraries they are extending. For that reason, at this point, I'm inclined to say that if adding support for LuaLS add-ons means we have to make changes to the lockfile or lux.toml schemas, then we probably shouldn't add first class support for LuaLS add-ons at all.

Again, my rambling in #953 is just a very rough list of ideas that popped into my head and that I jotted down while opening the issue - so that future me doesn't forget them when I get around to looking into it. It was not meant to be a guideline.
I've put the issue in a needs-triage state, which means we should investigate/discuss pros and cons of various approaches before writing any code.

[keithharvey]

Sounds good—aligned on keeping it minimal, analyzer-agnostic, and avoiding schema changes. I’ll pause this and wait for triage; happy to help with a small types-only PoC later if that’s the direction.