A function for declaring globals with LSP support

[Polanas]

Greetings! I'm trying to find a way to implement a custom SET_GLOBAL that would also provide hints.

---@generic T
---@param name string
---@param value T
function SET_GLOBAL(name, value)
  _G[name] = value
end

Combined with __newindex metamethod on _G preventing new globals, I believe this is a rather common method of achieving more predictable behaviour and overall safety. It would be very nice to also get strongly typed hints as if the global is declared like normal.

[CppCXY]

I don't think this is a good approach. Emmylua's static analysis can almost directly detect unintended global variable definitions. Also, locking global variable definitions using _newindex is not suitable during the loading phase. A better way is to allow global variables to be defined directly while files are loading, and then set the metatable for G after loading is complete. This way, you don't need to use a function like SET_GLOBAL to achieve this.

[Polanas]

Okay! Yes, you indeed can't use this for loading phase.
Though by setting a metatable for _G you disallow globals forever onward. I was thinking about using SET_GLOBALS as a replacement for usual syntax a = b as it's much more noticeable, while also allowing for easy grepping.

[CppCXY]

Okay! Yes, you indeed can't use this for loading phase. Though by setting a metatable for _G you disallow globals forever onward. I was thinking about using SET_GLOBALS as a replacement for usual syntax a = b as it's much more noticeable, while also allowing for easy grepping.

In fact, these restrictions are more like a placebo—they can't truly prevent the definition of global variables. They're just meant to avoid accidental definitions, since you can simply remove the metatable from G and then set global variables, or use rawset to do so. That's why I think relying directly on linting tools is a better solution than these approaches.

[Polanas]

Yeah totally see your point. This may very well be a placebo indeed.
Oh and, is it fine to ask about something else here: are there any plans/interest to bring a feature like plugins from luals to emmylua-analyzer?

[CppCXY]

Yeah totally see your point. This may very well be a placebo indeed. Oh and, is it fine to ask about something else here: are there any plans/interest to bring a feature like plugins from luals to emmylua-analyzer?

I have no intention of supporting plugins. Firstly, this would reduce performance. Secondly, it would introduce a scripting language runtime, which would significantly increase the binary size. Additionally, due to Rust's lifetime issues, data would almost always need to be copied to be shared with the scripting system. I would also have to write a lot of API bindings for the scripting system, which I don't like. Furthermore, I have security concerns about scripts that contain executable logic.