Code completion breaks when a global table is reassigned

[Yoctillion]

When a global table variable is assigned multiple times — a common pattern in API definition files or defensive initialization like:

GlobalScope = GlobalScope or {}

code completion (intellisense) stops working for that table and its members.

Expected behavior:

The LSP should merge or resolve the type information across multiple assignments and continue providing code completion.

Actual behavior:

Code completion is unavailable after the table is reassigned, even if the type can be statically inferred.

Reproduction:

-- file: api1.lua
GlobalScope = {}
GlobalScope.foo = function() end

-- file: api2.lua
GlobalScope = {} -- or GlobalScope = GlobalScope or {}
GlobalScope.bar = function() end

-- file: main.lua
GlobalScope.  -- no completion suggestions

[CppCXY]

Someone asked me the same question yesterday. My answer was that this pattern occurs in systems where the definition order of global variables is uncertain, and I oppose this pattern. EmmyLua’s recommended way to get the best experience with global variables is to define them only once and never reassign them.

[CppCXY]

Currently EmmyLua treats variables as references to objects. With your way of defining them, the current globals in each file can end up preferentially pointing to a local anonymous table, so they cannot be indexed correctly. In the older EmmyLua this worked correctly because it directly treated or {} as combining into a new table, but that causes a severe drop in performance.

[Yoctillion]

Is there any workaround for this in the meantime?

In our case, the API definition files are auto-generated, so we can't easily change the assignment pattern. Additionally, some contributors have already written similar defensive initialization (X = X or {}) across the codebase, making it impractical to refactor everything.

[CppCXY]

add partial class to every x = x or {} like

--- @class (partial) CC
cc = cc or {}

[xuhuanzy]

Perhaps we can add a global quick fix for this kind of pattern.

X = X or {} --[[@as globalclass]]

[xuhuanzy]

But in any case, this global variable must belong to a specific class.