Allow the user to attach local source to OST for installed packages

Issue #1543 new
Raihan Navroze created an issue

Opened as "Package methods with @NamespaceAccessible are not available to orgs in the same namespace". Changed to be more clear that this is now about being able to attach local sources for types from installed packages.

Steps to reproduce:

  1. Make a package with classes and methods marked as @NamespaceAccessible
  2. Create a new project in IC, create a new scratch org within the same namespace and install the package to this new scratch org
  3. Build the OST from the new scratch org with the plugin installed
  4. Attempt to write code referring to the @NamespaceAccessible methods

Expected result:

The method is available in the OST and can be used to autocomplete code.

Actual result:

The method shows up in red and shows a warning of “Cannot resolve symbol”

Example case:

This class and method is inside a package within the same namespace.

This is in the new scratch org:

(PS Same issue with namespace.TestNamespaceAccessible.testing())

Comments (13)

  1. Scott Wells repo owner

    Raihan, I apologize but I don't think there's anything I'm going to be able to do about this right now. Any second-generation package with a namespace, whether managed or unlocked, applies code obfuscation to all packaged Apex types. In the case of global symbols in global types, the accessible skeleton is available, but for a class like the one in your example, the body is returned as (hidden). As a result, there's no way to access the @NamespaceAccessible interface of that type programmatically from the API.

    Salesforce is aware of this, though I'm not sure when it will be resolved. Once they do resolve it, I will update IC's OST generation to ensure that the @NamespaceAccessible interface is available to callers in the same namespace.

  2. Matt Simonis

    As a workaround to this, I have been pulling down the outside project code annotated with @NamespaceAccessible into an untracked (gitignored) folder in the sfdx source format. This will allow the OST to pick up on those classes, but not pick it up when making commits.

  3. Cesar Parra

    Was running into this as well and ended up creating a tool as a (hopefully) temporary fix, so sharing here in case anyone else finds it useful:

    What it does is read parse through the dependent package source code (needs to be locally pulled down to your machine), and using that it updates the target OST and adds the missing definitions necessary for auto-complete to work.

  4. Scott Wells repo owner

    Thanks for sharing, Cesar. This got me thinking again about how to solve this until Salesforce stops applying code obfuscation to these packages that shouldn't be obfuscated. I was thinking that perhaps I could provide a way for you to attach source files to a namespace in the OST so that IC has more information about the contents of the package that produced that namespace. I think before I do that, I'll check with Salesforce to see if this is at all on their radar and, if so, whether they have any ETA for addressing it.

  5. Cesar Parra

    Not a problem! If this can be something directly integrated into IC that would be amazing, but I’ll be the first one to admit that this is a total workaround hack 😅, so ideally Salesforce provides you the tools that you need for this to be done more reliably.

  6. Scott Wells repo owner

    I spoke with one of the Salesforce PMs today about this, but unfortunately this wasn't under his ownership. I'm reaching out to the correct PM shortly. Ultimately it comes down to the fact that installed unlocked packages with namespaces shouldn't be obfuscated but currently are. They've recognized that as a bug in the past, but I'm not sure if/when it will be addressed. We'll see what that PM says.

  7. Scott Wells repo owner

    Okay, I heard back from the correct PM and he said that this was fixed a bit back. So let me make sure that we're talking about the same issue here. Can you verify that you're doing/seeing the following?

    1. Install an unlocked managed package with a namespace into an org.
    2. Create an IC2 project against a connection to that org.
    3. Generate your OST for that connection.
    4. You do NOT not see the @NamespaceAccessible symbols in the OST.

    Is that correct? If so, I'll play with it tomorrow and see whether I can reproduce that behavior or not. It's VERY possible that I need to update something in IC2 now that this is fixed on the server.

  8. Scott Wells repo owner

    Gotcha. I was so focused on unlocked packages with namespaces that I missed that scenario completely. I've followed up again with the PM, but my guess is that it's not only not fixed but likely not scheduled to be fixed. Assuming I hear back from them along those lines, I'll investigate what would be required to allow users to "attach sources" for namespaces in the OST when they're available.

  9. Log in to comment