Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

require path with custom package.loaders #2644

Open
Gerark opened this issue Apr 29, 2024 · 2 comments
Open

require path with custom package.loaders #2644

Gerark opened this issue Apr 29, 2024 · 2 comments

Comments

@Gerark
Copy link

Gerark commented Apr 29, 2024

In my project I'm adding new package.loaders which means I'm able to import things that are not real files.

local bindings = require "bindings.core" -- This is not a real file

Any path starting with bindings. is treated differently. Is there a way to instruct the Lua Language Server to treat those specific requires in a special way and have them returning the right type annotation?
I'd like to not specify the @type every time I'm requiring these special packages.

---@type CoreBindings  <---- I'm forced to specify the type
local bindings = require "bindings.core" 

If there's a valid solution I'd need it to work outside of VS code. I'm running LuaLS as a standalone check.

@Gerark Gerark changed the title Special require path and .luarc.json require path with custom package.loaders Apr 29, 2024
@CppCXY
Copy link
Contributor

CppCXY commented Apr 30, 2024

By design there should be --@module "xxx.fff", It may not be in effect for luals

@Gerark
Copy link
Author

Gerark commented Apr 30, 2024

By design there should be --@module "xxx.fff", It may not be in effect for luals

I'm not sure what the module annotation simulates tho. ( I saw the example but still a bit lost about it ) I need to tell what's the type returned by the module. Can that be done with --@module

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants