Component Namespaces

Every component is part of a namespace, which groups related components together and prevents naming conflicts with components from another namespace. The default namespace is c.

To reference your own components, always code with the c namespace prefix. Use c regardless of where the code is running: in an org with or without a namespace, in a managed or unmanaged package.

Within an HTML template, to reference a component in the lightning namespace, use <lightning-component-name>. A hyphen character (-) separates the namespace from the component name.

A unique namespace prefix is required if you plan to make your components available in a managed package. When users install the managed package, the components can be referenced using that namespace prefix.

When you enable LWS in your org, your component can reference code in namespaces other than c and lightning. See Components From Different Namespaces.

This component uses lightning-card, which is a base Lightning component in the lightning namespace that's part of the Lightning Platform. The lightning-card component contains c-contact-tile, which is a custom component that's in the same project as the compositionBasics component.

Within a JavaScript class, to use a resource from an API module component (sometimes called a service component or a library), import the resource from its namespace/module. The forward slash character (/) separates the namespace from the module name.

To protect customer data, Lightning web components previously didn’t support the use of components and API modules from different namespaces. Your custom components could only use components and modules from the default c namespace and the base Lightning components in the lightning namespace. This restriction remains in effect when the legacy Lightning security architecture, Lightning Locker, is enabled. Lightning Locker is enabled when LWS is not enabled.

If you enable Lightning Web Security (LWS), you can include Lightning web components and modules from namespaces other than lightning and c in your custom components. The components from other namespaces must be deployed in the org to make them available to your component. For example, components from another developer that you install from a managed package use the developer’s namespace prefix in your organization.

LWS enables you to use components from different namespaces by virtually isolating code to its own namespace. This isolation prevents components from accessing data that belongs to another namespace, while still allowing code from different namespaces to interact.

Here’s an example that includes a component from the Lightning Messaging Utility, which was installed from AppExchange. The example crossNamespace component is in the c namespace and uses the component in the ltngmu namespace.

Consider these guidelines when you're working with a namespace.

  • A custom Lightning web component can't access a Lightning web component or module in a custom namespace when running in an org that’s using Lightning Locker instead of LWS.
  • A custom Lightning web component can access Lightning web components and modules only in the c and lightning namespaces when running in an org that’s using Lightning Locker instead of LWS.
  • A custom Lightning web component and a custom Aura component in the same namespace can't have the same name, whether the org uses Lightning Locker or LWS.

See Also