Managed Package on Sandbox : Namespace is not removed and the entire app just crashes

Question

I've installed a managed package (released version) on a sandbox and it doesn't work because Namespaces are not removed on the Custom fields API name from Lightning component controllers :

From my dev org or any enterprise org where I've installed the package, the app works just fine: Namespaces are removed on Custom fields API name when receiving data: Apex actions return Custom_field__c instead of Mynamespace__Custom_Field__c.

But when testing on Sandbox, namespaces are not removed and my app just crashes: Custom_Field__c is undefined everywhere I expect data from apex actions.

EDIT:

From my dev org this why i get:

...
    var results = a.getReturnvalue();
     var name = results.record.Custom_field_name__c
console.log(name) ; //display John Doe
... 

From a sandbox org, i get this

... 
var results = a.getReturnvalue();
     var name = results.record.Custom_field_name__c
console.log(name) ; //display undefined

And if i do console.log(results) from the dev org i have:

{record : {''Custom_field_name__c'': '' John Doe''}} 
... 

And from the sandbox...

{record : {''MyNameSpace__Custom_field_name__c'': '' John Doe''}} 

Could you please advise how I can solve this? Any advice will be very much appreciated! A 1000 thanks!

Answer 1

The org edition or sandbox status is not what's determinative here. The key is how your code is installed: whether it is or is not installed as part of a managed package, and if not, whether or not you are in a packaging org.

In a context where your code is deployed unmanaged (not as part of a managed package, but simply a source deployment), including the packaging org and potentially other orgs where you deploy the bare source code, your code that references Custom_field_name__c will work just fine. This is not exactly because namespaces are removed, but because in that context either there is no namespace at all (some arbitrary org with unmanaged code) or because you're in an org that is inherently namespaced (packaging) and you've deployed your components without an explicit namespace.

When your code is installed in a managed package, your components are all namespaced, and are distinct from the components outside your managed package, which do not have a namespace. In some contexts, such as Apex code, the platform automatically resolves references to packaged components without a namespace to the correct namespaced component. However, the platform doesn't automatically munge field references in JavaScript to cope with the presence of the namespace. You can adopt one of several different strategies to manage this:

1. You can include explicit namespace references in your code. This is explicitly endorsed in the Aura developer guide, although I personally disagree with this advice. Using explicit namespace references in your code means you cannot deploy it unmanaged to an org that does not itself have that namespace, limiting you to doing development in packaging (bad practice! don't do that!) or in namespaced scratch orgs.
2. You can implement your Apex controller to do all communication with your JavaScript using an Apex wrapper class rather than actual sObject instances. Since the fields on Apex classes do not receive a namespace prefix, this can allow your code to be context-agnostic. Your Apex code would then be responsible for translating between wrapper instances and actual sObjects; in Apex code, the platform handles resolving references to your namespaced components appropriately.
3. Your component can introspect the data it is working with to dynamically determine at runtime whether or not the sObjects with which it is interacting have a namespace prefix, and adjust field accesses accordingly. This makes your code resilient to run in both managed and unmanaged environments.
4. You can build Lightning Web Components instead of Aura. LWCs don't completely remove the namespace problem, but they can make it easier because you can use imports to retrieve the schema and Apex class information from the platform, where namespaces are managed for you and it's easy to introspect against imported fields to determine whether they are namespaced.

Whatever you choose to do, it's critical to be clear about the managed code versus unmanaged code distinction.