Benjamin-Dobell / IntelliJ-Luanalysis

Type-safe Lua IDE — IntelliJ IDEA plugin
Apache License 2.0
154 stars 21 forks source link

How can I limit the global scope to specific files #115

Closed LelouBil closed 2 years ago

LelouBil commented 2 years ago

Environment

Name Version
IDEA version RD-213.6461.51
Luanalysis version 1.2.2
OS Windows 10

Preferences

(Preferences -> Languages & Frameworks > Luanalysis)

Lua

Name Setting
Language level Lua 5.2

Type Safety

Name Setting
Strict nil checks ☑️
Unknown type (any) is indexable
Unknown type (any) is callable

What are the steps to reproduce this issue?

  1. Create multiple Lua files in the same project
  2. Define a global variable in one of them.

I would like an option to make every file have its own global namespace, except files in a certain directory that declare into the global namespace of every other project file.

I am using Lua for a game project using MoonSharp (a Lua interpreter in C#) and I thought that Luanalysis's typing features could help me. However, since I declare the same fields and methods at the global level in all of my script files, I get autocompletion from files that are not where my typing stubs are present.

I would like to know if I can limit where Luanalysis looks for files for the global scope.

Benjamin-Dobell commented 2 years ago

There's certainly more that can be done re: scoping. However, I'm curious, what are your project requirements whereby each file has its own global scope?

The expected Lua workflow is to write Lua modules i.e. 99.99% of what you write ought to be local declarations and you return "exported" symbols from these modules.

Re: MoonSharp, I initially wrote Luanalysis with a MoonSharp project in mind. So I don't believe there's anything inherently MoonSharp specific that should come into play. However, one thing that's perhaps a bit unusual about MoonSharp is that it calls a VM a Script. As a general rule I recommend isolation via Lua modules rather than running multiple VMs because Lua modules are much more performant and easier to work with. Basically you can avoid complexities surrounding copying/and or MoonSharp's prime tables by sticking to standard Lua modules.

There is an issue with types only existing in the global scope though. I would definitely like to improve this, so internal module utility types etc. can be kept private.

LelouBil commented 2 years ago

I'll admit I don't know a lot about Lua, the MoonSharp tutorials used the Globals object to get objects from scripts, so I'm just creating a new Script instance and querying the Globals object to find my exported fields.

In the end I solved the problem by doing what you said, putting everything that could be local as local (since it was not done at all), because I didn't knew you could mark functions as local 😅

Thanks for maintaining this, EmmyLua had me in trouble with generics x)