Question about Intellisense

I am trying to learn about Intellisense in Roblox Luau.

I wanted to create a script that required all of the services in game, that could also be used as a reference for their functions in intellisense.

The problem is, if I were to make a script like this:

local Services = {
ServiceOne = require(game.ReplicatedStorage.ServiceOne),
ServiceTwo = require(game.ReplicatedStorage.ServiceOne)
}

return Services

Then it won’t show me intellisense in the services themselves.

For example, if this was in the ServiceOne script.

local Services = require(game.ReplicatedStorage.Services)
local ServiceTwo = Services.ServiceTwo – This option would not show up under services via intellisense

Is there anything I can do to get around that, without exporting every function of every service?

1 Like

Is the example you’ve given even possible? It looks like it would cause circular dependencies.

Edit: I just tested this myself. If your example is how you’re organizing and requiring your services, then the reason you don’t have intellisense is because there is a circular dependency there. Once you resolve that circular dependency, intellisense should work as intended.

1 Like

Ahh I see what you’re saying, yes it would be a circular dependency issue then.

Hmm. Suppose requiring each individual service may be the way to go

1 Like

Alright, well a new but related question.

Lets say I have two services.

Service one:

M = {}
M.DoStuff = function()
require(ServiceTwo).DoStuff2()
end
M.DoStuff2 = function()
print("Test1")
end
return M

Service two:

M = {}
M.DoStuff = function()
require(ServiceOne).DoStuff2()
end
M.DoStuff2 = function()
print("Test2")
end
return M

This works coding wise, but why does it break intellisense? Is there a way around it breaking intellisense?

Seems strange that it would pick up a circular dependency when it’s only requiring the other module within a function

1 Like

Have you tried making M a local variable. That makes it work for me. I’m not sure why it needs to be local though. Might be a bug with the typechecker itself? :man_shrugging:

Nevermind, that doesn’t fix it. My best guess is that while moving the requires inside the function does fix the runtime issue of the circular dependency, it does not fix it for the type checker. The type checker is going to run on the entirety of the file regardless of where the code is because it needs to resolve the types for you as you work. So it sees the require in DoStuff and tries to resolve the types of that module only to see the other service needs the types of the original module. So there’s still a static circular dependency issue

2 Likes