Does not use the re-assigned value type if it does not conform with the declared value type and is exported

[PeterCardenas]

Consider we have the following file:

-- a.lua
local M = {}
M.x = 1
M.x = ''
return M

And then we import it in another file:

-- b.lua
local a = require('a')
---@type string
local test = a.x

In a.lua we get a type error, which is somewhat ok since we never explicitly said if we wanted a union. However, the type of x should still be string since that is most correct. Inside of b.lua, a.x is an integer which results in a type error in b.lua, which is not correct.

[PeterCardenas]

might be a more specific case of #429, but still a problem nonetheless

[PeterCardenas]

a more practical example is here: https://github.com/neovim/neovim/blob/master/runtime/lua/vim/lsp.lua#L392, where the implementation of vim.lsp.config is defined in the setmetatable call below, but a separate function is defined to give specific hover documentation for the __call case of the setmetadata call.

[CppCXY]

Reusing values is difficult, because I can’t know what’s correct. I can only assume that the first definition in the current file is what people expect, and that functions always take precedence over ordinary field definitions.

[CppCXY]

Many things here are workarounds written for LuaLS, but I don't actually need these workarounds in emmylua_ls

[PeterCardenas]

would you prefer to support resolving the hover documentation for the __call case of the setmetatable call in the vim.lsp.config function?

[CppCXY]

if not a class define, I can use __call from setmetatable:

[clason]

Note: EmmyLuaLs is not a drop-in replacement for luals; the Neovim runtime needs quite a bit of effort to work with the stricter checks of EmmyLuaLs. See neovim/neovim#33344 for ongoing work (and the tracking issue here for the remaining blockers).