Separating globals for files that run in different Lua States

[justarandomgeek]

Factorio mods use one shared Lua state (and thus do share globals) for some startup work and then one Lua state per mod (and thus do not share globals) at runtime. The Intellisense currently just assumes everything in the workspace shares one set of globals. For the most part this works okay, since we generally just don't refer to the objects from other "stages", and I don't generally create any new globals. However, Factorio provides a global table named global (a unique one per mod) for us to persist data in the save file, and my workspace has multiple mods in it, so the autocomplete for global is the union of all the open mods globals!

Also, the "defined globals" list really needs to vary per-file, because data-stage has a ton of globals while runtime has only a handful.

Is there any way to indicate these different sets of global variables?

[justarandomgeek]

I think my "ideal" method for handling this would be a tag like ---@globals data for the shared state and ---@globals modname for the per-mod states, at the top of the file and then have "defined globals" lists for each named context plus a "default" list when not tagged.

[zejji]

I'm running into this problem in a big way when using EmmyLua annotations for Defold script files.

Each script file in Defold has the same set of functions defined in the global space, e.g. see the default outline for a new script file below:

function init(self)
	-- Add initialization code here
	-- Learn more: https://defold.com/manuals/script/
	-- Remove this function if not needed
end

function final(self)
	-- Add finalization code here
	-- Learn more: https://defold.com/manuals/script/
	-- Remove this function if not needed
end

function update(self, dt)
	-- Add update code here
	-- Learn more: https://defold.com/manuals/script/
	-- Remove this function if not needed
end

function on_message(self, message_id, message, sender)
	-- Add message-handling code here
	-- Learn more: https://defold.com/manuals/message-passing/
	-- Remove this function if not needed
end

function on_input(self, action_id, action)
	-- Add input-handling code here. The game object this script is attached to
	-- must have acquired input focus:
	--
	--    msg.post(".", "acquire_input_focus")
	--
	-- All mapped input bindings will be received. Mouse and touch input will
	-- be received regardless of where on the screen it happened.
	-- Learn more: https://defold.com/manuals/input/
	-- Remove this function if not needed
end

function on_reload(self)
	-- Add reload-handling code here
	-- Learn more: https://defold.com/manuals/hot-reload/
	-- Remove this function if not needed
end

However, a soon as I have more than one script file, the Lua Language Server ignores my parameter annotations for the specific method and instead assumes that the passed parameter is a union type. In other words, it merges together the parameter types for all of the different functions defined using the same name.

See below for an example. Although I have only added the annotation ---@param obj LevelSelectGui for the on_message method, when I hover over the obj parameter it shows it as a union of all the different on_message functions in my various script files.

I'd imagine this is occurring because the Lua Language Server groups together all the annotations attached to the init, on_message function etc. across all files, on the assumption that there can only ever be one function with a given name in global space? If so, does there need to be some way of indicating that a file is a separate module? Or simply that the Lua Language Server should not assume that a function with the same name defined in multiple files (with a method body, as opposed to merely a forward declaration) is the same function?

[sumneko]

See below for an example. Although I have only added the annotation ---@param obj LevelSelectGui for the on_message method, when I hover over the obj parameter it shows it as a union of all the different on_message functions in my various script files.

This problem can be viewed as a separate bug, because I allow you to have multiple implementations of the same function (overload), and their parameters should not be confused at this time.

[zejji]

@sumneko - Thanks for your reply. Is the solution just to assume that where a function is defined multiple times with a method body (as opposed to merely a forward declaration), that it is a separate function?

[sumneko]

@zejji
There is no easy way to workaround at your side. You can open an issue separately, and I will fix the parameter confusion bug in a later version.
But the subject of this issue will take longer to be resolved.

[zejji]

@sumneko - Many thanks. I have created a separate issue for the parameter confusion bug here.

[FlashHit]

In Venice Unleashed we use lua for mods. We have a Server folder, Shared folder and Client folder.

If I put —-@globals Server on top of the file, then —-@class Player and the same on client with —-@globals Client.
Then I could have two different classes with the same name?

so if I got this right, with this solution I could manage it properly?

[sumneko]

You can use VSCode's Multi-Workspace feature, which will start a language server separately for each Workspace.

[FlashHit]

But then I couldn’t require the Shared folder files I think.
I had 3 workspaces: 1 client, 1 shared, 1 server folder. This didn’t work out.

i would need a workspace for client that has access to client and shared folder. A workspace for server that has access to server and shared folder. (And maybe even a workspace for shared that has access to all folders.)

[sumneko]

Use Lua.workspace.library to include the shared folder

[FlashHit]

The code in shared folder changes quite often and it seems that it doesn’t get cached again. So this method is probably only useful for static content. :/

[sumneko]

This extension should be able to correctly handle the file changes in library.
If not, it should be a bug, you may open an issue about it.

[FlashHit]

Oh you were right. The description for it still sounds like it wouldn’t update it. You might wanna update it :)