Duplicate Declaration error while working on multiple VBA-Enabled files inside the same project

[DecimalTurn]

While working on VBA-Build, I can have 2 modules with the same name, but they belong to different files.

In the example below, I have 2 Excel files ExcelAddin.xlam and ExcelWorkbook.xlsm and they both have a Module1 which is identified as an error by VBA-Pro.

I'm going to change the module name of one of them to fix the issue, but it would be nice if there was a way to define a namespace to avoid those conflicts.

Looking at XVBA, they use a VBA comment to define a namespace for he file:
https://youtu.be/pqSOvxEFaFA?si=FYKvWb5szHOugxtV&t=49

[DecimalTurn]

Actually, this problem is not only for Module names it's also for public sub/functions that can't have the same name if they are in the same namespace.

[SSlinky]

Yep, there's been a massive scopes overhaul in the interim but it's not finished so I can't really push it out just yet.

2025-05-21 22:49:12.057 [debug] resolved onRenameRequest: returning
{"changes":{"file:///c%3A/Repos/vba-LanguageServer/sample/project/Modules/Bar.bas":[
    {"range":{"start":{"line":25,"character":8},"end":{"line":25,"character":18}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":27,"character":4},"end":{"line":27,"character":14}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":27,"character":17},"end":{"line":27,"character":27}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":28,"character":4},"end":{"line":28,"character":14}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":28,"character":17},"end":{"line":28,"character":27}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":29,"character":4},"end":{"line":29,"character":14}},"newText":"exampleNameChangeVariable"},
    {"range":{"start":{"line":29,"character":17},"end":{"line":29,"character":27}},"newText":"exampleNameChangeVariable"}
]}}

So that's exciting. I really need to properly figure out chaining which is a real pest due to implicitly qualified things. For example, if I have a public X in Foo.bas, I don't need to reference it with Foo.X in another module, I can simply reference X (no thoughts on best practice, it's what's legal).

I can even declare another X in Bar.bas and it won't have a problem until I try to reference X from a third module without qualifying it. Then and only then does VBA throw its toys out of the pram.

[SSlinky]

TBH I'm not personally a fan of needing to manage namespaces and other things with comments as it's a bit of a hit to compatibility. I'd prefer to use features like multi-root workspace to separate names. In the scopes hierarchy, there would be two projects which would fork the names.

There's still the problem of references, but in that I'm actually not too against using a comment somewhere since it actually adds clarity to the project. It just feels dirty.

[SSlinky]

Actually, another thought I had was a project properties file. Doesn't get imported into VBA but can store information like references or details of methods and objects you know your code does have access to so that (once we get to) typing can resolve. It's something I'll need to do for the VBA / App models anyway.

Maybe in the end it could look something like this:

{
    "model": "excel",
    "linkedFiles": [{
        "test": "my\test\file.xlsx"
    }],
    "references": ["path\to\another\project"]
}

[DecimalTurn]

I'm not necessarly arguing for the namespace with comments solution, but I thought I'd mention it. I think the project properties file (aka. manifest file) would be much better, but would take a bit more work.

Are you aware of the vba-blocks manifest format? I've been personally working on a VS Code extension that would use the vba-blocks manifest to sync between VS Code and the VBE. We could eventually combine the 2 extensions if you think that would be a good addition to VBA Pro.

Note that I've modified the manifest format to support wildcards as it's not part of the standard at the moment. I've also worked on the toml-patch package to make it more robust for parsing and editing TOML files.

[SSlinky]

Interesting, no I had not heard of it. Looks like it could be solving the same problem we're discussing in a very similar way so it makes sense to align rather than create a new standard. Maybe it's something to tackle once improved scopes is released and associated dust has settled. Thanks for bringing it up.