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!


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

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.