Managed package Custom Label inconsistencies develop through scratch org

Question

We are recently facing some issue related to custom label when we are creating managed package and installing in another org the custom label value is not populating . Below is the code sample : This below code is working in scratch org . where we do our usual development .

const frequencyObjectArray = [];
for (let i = 0; i < frequency.length; i++) {
    component.set("v.displayMessageFrequency", $A.getReference(`$Label.c.${frequency[i].label}`));
    const frequencyObject = {
        label: component.get("v.displayMessageFrequency"),
        value: frequency[i].frequencyValue
    };
    frequencyObjectArray.push(frequencyObject);
}
return frequencyObjectArray;

If we change this .c $Label.c.${paymentfrequency[i].label with “Namesapce” in manage package like : $A.getReference($Label. Namespace.${paymentfrequency[i].label})); It is working in installed org. And if we keep $A.getReference($Label. Namespace.${paymentfrequency[i].label})) in scratch org it is not working. Hence if we have to maintain this type of conversion it will be overhead for further development. How can we solve this issue?

Answer 1

It's possible to introspect at runtime whether your code is running inside a managed package or not. Here's an example from the Nonprofit Success Pack:

    public static string getNamespace() {
        if (plainNamespace == null) {
            string withDotNotation = UTIL_Namespace.class.getName();

            if (withDotNotation.contains('.')) {
                plainNamespace = withDotNotation.substringBefore('.');
            } else {
                plainNamespace = '';
            }
        }
        return plainNamespace;
    }

This method lives in an Apex class that you package and simply looks at its own name, as installed in the org, to determine if it's running in a managed package or not.

Your Aura code could invoke such an Apex method at load time and defer any Label lookups until it receives the indication from Apex of which namespace it is operating under (or none). It can then decide, perhaps via a helper function, whether or not to inject the namespace or c in your dynamically-constructed label reference.

If you build your package without static namespace references, which I strongly recommend as it keeps you from having to use weird, quirky namespaced scratch orgs and preserves your ability to deploy unmanaged code into Developer Editions and sandboxes for testing, this is a pattern you'll have to live with, but you can abstract it enough that it shouldn't cause any ongoing slowdown to development.

Answer 2

You should be using namespaces, and create your scratch org with a namespace. This eliminates the need to decide if you need to use c/Namespace. This is the intended mode of development for managed packages.