Customizable Globals

[seancroach]

I love this project, but I've encountered a minor annoyance and can't find any guidance on this issue online, so I can only assume this behavior hasn't been implemented yet.

I'm using mlua embedded in a Rust application for plugin support. In general, luau-lsp works excellent with the following .vscode/settings.json:

{
    "luau-lsp.platform.type": "standard",
    "luau-lsp.sourcemap.enabled": false,
    "luau-lsp.types.definitionFiles": [
        // path to file with new globals
    ]
}

mlua, wonderfully, supports a StdLib structure to opt in or out of various globals by default. This is generally fine, and things can be selectively torn apart and re-implemented when initializing a Lua VM. But! To my knowledge, it's impossible to tell luau-lsp what globals don't exist. While I recognize this is a niche problem, it would be incredibly helpful if there was at least some way to achieve this behavior. (After all, disabling getfenv and setfenv isn't that much of a stretch for embedded Luau outside of Roblox, among other things.)

[JohnnyMorganz]

Thanks! Yup, there is currently no way to disable builtin globals right now, but it would be useful to support. This was also requested in #700.

Luau's analysis system has a set of hardcoded global definitions for builtins (https://github.com/luau-lang/luau/blob/master/Analysis/src/EmbeddedBuiltinDefinitions.cpp). We end up registering these for the LSP:

luau-lsp/src/Workspace.cpp

Line 306 in 21826a4

Luau::registerBuiltinGlobals(frontend, frontend.globals);

We could potentially make this optional, and allow a user to disable all builtin globals. They could then write out the ones that are still relevant in their own definitions file. However, some of the builtin definitions have "magic behaviour" attached to them, and that would be lost (https://github.com/luau-lang/luau/blob/9a102e2aff99ecaf2ad1e5ca59fc1c893d5e9b7c/Analysis/src/BuiltinDefinitions.cpp#L293).

We might be able to hack around this and accept a list of luau-lsp.types.disabledGlobals (similar to luau-lang/luau#1538), then still register all globals but delete the ones we don't care about after they were already registered from frontend.globalScope. For global variables / functions, this should be OK, but this would be problematic for global types due to dangling references (but luckily there are no global types defined right now, so we don't have to worry about that just yet!)