Newer Version Available
Understanding Namespaces
When you specify a package namespace, every component added to a package has the namespace prefixed to the component API name. Let’s say you have a custom object called Insurance_Agent with the API name, Insurance_Agent__c. If you add this component to a package associated with the Acme namespace, the API name becomes Acme__Insurance_Agent__c.
| Use No-Namespace Packages If | Use Namespace Packages If |
|---|---|
| You want to migrate metadata from your org’s monolith of unpackaged metadata to unlocked packages. Creating a no-namespace package gives you more control over how you organize and distribute parts of an application. | You’re new to packaging and you’re adopting packages in several stages. Using a namespace prefix such as Acme__ can help you identify what’s packaged and what’s still unpackaged metadata in your production orgs |
| You want to retain the API name of previously unpackaged metadata elements. | You have more than one development team. A namespace can ensure your API names
don’t collide with another team. In general, working with a single namespace is easier, and you can easily share code across packages that share a namespace. |
- You can develop more than one package with the same namespace but you can associate each package with only a single namespace.
- If you work with more than one namespace, we recommend that you set up one project for each namespace.
Namespace-Based Visibility for Apex Classes in Unlocked Packages
The @namespaceAccessible makes public Apex in a package available to other packages that use the same namespace. Without this annotation, Apex classes, methods, interfaces, and properties defined in an unlocked package aren’t accessible to the other packages with which they share a namespace. Apex that is declared global is always available across all namespaces, and needs no annotation.
Considerations for Apex Accessibility Across Packages
- A Lightning component outside the package can access a public Apex method installed from a no-namespace unlocked package. The component can be installed from another package or created in the org. For accessing Apex methods, a no-namespace unlocked package is treated the same as an unmanaged package.
- You can't use the @namespaceAccessible annotation for an @AuraEnabled Apex method referenced from a Lightning component.
- You can add or remove the @namespaceAccessibleannotation at any time, even on managed and released Apex code. Make sure that you don’t have dependent packages relying on the functionality of the annotation before adding or removing it.
- When adding or removing @namespaceAccessible Apex from a package, consider the impact to users with installed versions of other packages that reference this package’s annotation. Before pushing a package upgrade, ensure that no user is running a package version that would fail to fully compile when the upgrade is pushed.
1// A namespace-visible Apex class
2@namespaceAccessible
3public class MyClass {
4 private Boolean bypassFLS;
5
6 // A namespace-visible constructor that only allows secure use
7 @namespaceAccessible
8 public MyClass() {
9 bypassFLS = false;
10 }
11
12 // A package private constructor that allows use in trusted contexts,
13 // but only internal to the package
14 public MyClass (Boolean bypassFLS) {
15 this.bypassFLS = bypassFLS;
16 }
17 @namespaceAccessible
18 protected Boolean getBypassFLS() {
19 return bypassFLS;
20 }
21}