4

When developing a managed package for further publication on AppExchange, should the Apex code include the managed package namespace? I can actually code it either way and it works (seems like SF adding the namespace in at runtime is still available); but not including it makes it easier to switch orgs (e.g. if i want to deploy the same code to DevHub).

However, when i import custom object definitions in the org with a managed package namespace, all my .cls files in VS Code do contain the namespace.

What's the best practice?

Improve this question
2
  • I've asked for you on Twitter. I expect we'll get a decent response in the next 12 hours or so. Have a +1 from me, though, this is a good question.
    – sfdcfox
    Feb 26, 2019 at 3:34
  • @sfdcfox Thanks heaps!
    – zaitsman
    Feb 26, 2019 at 3:37

1 Answer 1

Reset to default
3

If your scratch org is configured with a namespace, then the assumption seems to be that this org is for package development, and any customisations (including fields from unmanaged packages) are automatically prefixed with the namespace. Generally if you're in an org with a namespace, everything gets that namespace.

Code in a managed package does not need to use the namespace to refer to other packaged components (fields, classes, objects etc.) and this means you can develop that same code inside of other dev orgs etc. too where the namespace isn't present. I recommend never using the namespace for the current package in Apex for this exact reason.

If you're using a scratch org and install another managed package that you depend on (for instance, we use a base package with our schema then other stuff on top) then you do need to use the namespace to reference components of that pacakge, and those will show locally with the namespace.

Sidenote on Packages and Client Orgs

This may or may not be relevant to you, but it's related to this question. If a client org (i.e. org where your managed package is installed) contains a field with the same API name as a field in your package on the same object, your code can never access the field that exists natively in the org. Even using dynamic SOQL/Apex, if you reference Field__c in your code then the namespace will always be added under the hood, so you'll only ever be able to access NS__Field__c and never Field__c. I had to learn this one the hard way.

Improve this answer
2
  • Code in a managed package does not need to use the namespace to refer to other packaged components (fields, classes, objects etc.) and this means you can develop that same code inside of other dev orgs etc. too where the namespace isn't present Why does SFDX Refresh SObject definitions pull down the namespace if this is the recommended way forward?
    – zaitsman
    Feb 26, 2019 at 4:53
  • 3
    Honestly, I don't think a lot of people within Salesforce do much with managed packages themselves. It might have been assumed this was the cleaner way to go, but I've been working on various packages for over 6 years, and I would strongly recommend against using the namespace when you don't have to.
    – Matt Lacey ♦
    Feb 26, 2019 at 4:57

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.