9

Sorry if this question has been asked before (please point me to the answer if that's the case). I have created and installed an unlocked package successfully in a scratch org. I want to go ahead and view or modify the code of some classes. I have a problem, because it's saying that it can't access them because some classes aren't global. And the global classes only show the definitions, not the actual code. This actually behaves like a managed package, and that doesn't work for my scenario.

Full context: I have a namespace registered to the target scratch org as I'm ultimately developing a managed package. The main thing that I want to do is the following:

  1. Develop in scratch orgs with DX push/pull
  2. Create unlocked packages to install in testing environments
  3. Once tested and validated, install Unlocked package in packaging org
  4. Create the managed package (fails on install because code is hidden)

Is this expected behaviour? I'd assume that being "Unlocked" the code will be completely open. I've tried this without namespaces, and it works properly, is this a known limitation? I can't find info for this anywhere

Thanks for your help!

Ivan

1
  • 1
    This is a bug and will be fixed in the future. Sorry for the trouble. Commented Nov 21, 2018 at 15:36

2 Answers 2

6

This is a known issue and we have an item in our roadmap to fix this so that apex code in namespaced unlocked packages is visible in installed orgs. The side effect of this is that it is difficult to work with debug logs in this scenario.

My suggestion is to explore (until we fix this) no-namespace unlocked packages. In a no-namespace unlocked package, Apex is visible. See this FAQ (https://sfdc-db-gmail.github.io/unlocked-packages/faq-unlocked-pkgs) for more details and if you have any questions, please post them in this Trailblazer group: https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000Lg5U

Also in the scenario that you are describing, the recommended approach is to deploy the metadata to the packaging org using force:mdapi:deploy instead of installing the unlocked package in the packaging org, if the objective is to make this metadata part of your managed package, you will do force:mdapi:deploy to the packaging org and then issue a force:package1:version:create command to create a package version of the managed package.

3

In a conversion with the 2GP team, I was told that namespaced unlocked packages will hide their code, just like traditional managed packages. So, I think that's a feature, not a bug/limitation.

4
  • Hi Aidan are you aware of a way to debug this type of package where it is installed? As well as hiding the code it hides the stack trace when debugging.
    – Jose
    Commented Feb 24, 2023 at 13:50
  • Sorry that it took ages to back to this... That's weird, I can see the traces in my namespaced unlocked packages. If you haven't already, I'd start a new question
    – Aidan
    Commented Mar 17, 2023 at 14:27
  • What's the point to be unlocked then!? It's simpler to just create another Managed instead :D Commented Jul 8 at 11:42
  • My original answer turned out to become outdated quite quickly. As you can see in Dileep's answer, the code and debug logs became visible after changes on the SF side. Dileep works in the packaging team at SF, so he's the one to listen to here :o)
    – Aidan
    Commented Jul 9 at 7:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .