Provide autocompletion for namespaced unlocked package classes

[alpha-bytes]

I am implementing unlocked packaging more and more in client orgs and many of them are namespaced. It appears the Apex Language Server does not store symbol data (forgive any incorrect terminology) for unlocked packages in an org that are outside the default namespace (i.e. not namespaced).

I have tried adding namespaces to the sfdx-project.json, deleting the apex.db file and restarting VS Code to see if I could get the LSP to index the namespaced classes, but to no avail.

If anyone knows of any other workarounds unless / until this is implemented they would be much appreciated. Thanks as always for your hard work on making these extensions great tools for dev productivity on the platform.

[lcampos]

Thanks for opening this issue @alpha-bytes . I'd like to make sure we understand what you're looking for. In the scenario you're running, are the unlocked package classes part of the project you have locally ? Do you want the autocomplete to show unlocked package class data while working on an Apex class that's not part of the unlocked package ?

[alpha-bytes]

Right, sorry that wasn't clear. Ideally, if I list an 04t... package as a dependency for my project, and it's installed in the org configured as my default, the language server would retrieve the symbol data for classes in that package for language intelligence.

I realize that could get a bit hairy and I could just retrieve the classes to my local project, but it's an additional step and you have to make sure you (and team) don't add those files to source control. I guess basically I'm asking for an sfdx package manager a la npm...no big deal, right? 😝

[lcampos]

@alpha-bytes thanks for clarifying. This is something we definitely want to do. It's similar to #1177 but it's not part of the immediate roadmap (we're currently focusing in performance of deploys and retrieves).

I agree that downloading the other unlocked packages is not a good workaround but I can't think of a better workaround for now. If I find something I'll update this thread.

cc @smaddox-sf we should talk about this for our next release planning.

[git2gus]

This issue has been linked to a new work item: W-7376860

[git2gus]

This issue has been linked to a new work item: W-7376860

[git2gus]

This issue has been linked to a new work item: W-7376860