Should "workspace.ignoreSubmodules" be false by default?

[morikosm]

Hello, I hope this message finds you well.

It seems counter-intuitive that submodules are ignored by default, as my workflow is multi-repo with each repo checked out in its own submodule, and I found that no submodules would load into intellisense. At first, I thought I was encountering a bug or an error in my code with how I was loading submodules, but after closely comparing a submodule to a non-submodule and finding they were identical, only then did I understand that this was a configuration issue.

It seems to me that the alternative of noisy intellisense, where one can opt-out with "workspace.ignoreSubmodules", rather than intellisense not finding the submodule with no explanation why, would be preferable.

For your kind consideration,

• Moriko

[tomlau10]

(First thing first, I'm no maintainer and following are just my own opinions, which cannot represent maintainer's view 😄 )

Most of the time, in a workspace one would use submodules as 3rd party libraries.
How the library is implemented has nothing to do with one's project.
For example in my team's project, we use:

• skynet (a lua framework)
• sprotodump (proto designed specifically for skynet framework)
• lua-cjson
• ... blah blah blah

If ignore submodule is not the default, this will certainly increase luals start up time and memory usage.
Because luals will scan and preload and (lua) files in all subdirectories recursively at startup.

In addition, this workspace.ignoreSubmodules also affects how diagnostics is performed.
When we do a full workspace diagnostics, if submodules (those libraries) are not excluded, then errors from them will be shown up too, which is undesirable.

(But you're right that one can opt-out with "workspace.ignoreSubmodules")

---

as my workflow is multi-repo with each repo checked out in its own submodule

You mentioned that you workspace is a multi-repo, I am not sure if this is the norm in luals's community / user base.
I don't have statistics though, but clearly changing something's default value may affect a large portion of users.

Meanwhile luals's default setting / single workspace mode might not be suitable for a mult-repo / monorepo.
There have been some issues/discussion going around this:

• [Feature Request] Multiple-project/Monorepo support #2962
• How to "scope" definition file? #3030

The main issue is that each repo might require a separate environment / meta definition scope, such that the types defined will not affect other projects.
By opening a multi repo in a single workspace, luals will just preload all lua files, merging all the types it can found, maybe polluting the global namespace as well, and I believe this is mostly undesirable.

To deal with this, luals provides support to the multi-root workspace of vscode.
You may want to check it out 👀 #3030 (comment)
Though I don't know if in your case, do you still need to disable workspace.ignoreSubmodules first or not 🙈