Lightning component cannot be created: c:myComponent

A developer commits a small change to a Lightning Web Component used on the Account record page. The change is one line in the template. Deploy succeeds. He opens the Account page and the right rail is blank with a small red banner: Lightning component cannot be created: c:accountInsightsPanel. The component worked an hour ago. Other Lightning pages in the org load fine. The team needs to find out what broke the component at runtime.

What the platform is checking

When a Lightning page renders, the framework asks the metadata service for each component referenced on the page. The service returns the component bundle (template, JavaScript class, design metadata, supporting modules). The framework parses the bundle, instantiates the component class, attaches it to the DOM, and binds the wire adapters.

The Lightning component cannot be created message fires when any step in that pipeline fails. The framework reports the component name in the message but does not include the failure detail. The cause could be a metadata lookup failure (the component does not exist or the user lacks access), a JavaScript parse error (the bundle is syntactically invalid), a module resolution failure (an imported module is missing or its name is wrong), a runtime error in the constructor (an exception thrown before mount), or a security boundary rejection (the component lives in a Locker Service profile that doesn't permit the API the component uses).

The browser console is the canonical source for the detail. Salesforce logs the underlying exception to the console at the moment the framework gives up on the component. The on-page banner is the user-visible fallback; the console has the stack trace.

The broken example

A Lightning Web Component that fetches Account insights:

import { LightningElement, api, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';
import getInsights from '@salesforce/apex/AccountInsightsService.getInsights';
import { CurrentPageReference } from 'lightning/navigation';

export default class AccountInsightsPanel extends LightningElement {
  @api recordId;
  insights;

  @wire(getInsights, { accountId: '$recordId' })
  wiredInsights({ data, error }) {
    if (data) {
      this.insights = data;
    }
  }
}

The component looks fine. The deploy succeeds because metadata validation passes. At runtime the framework throws because AccountInsightsService.getInsights is annotated @AuraEnabled but is missing cacheable=true. The @wire adapter requires cacheable Apex methods. The framework rejects the component at construction.

A second shape: an import path with a typo.

import { LightningElement } from 'lws';  // Should be 'lwc'

The bundle fails to load because the import name does not resolve. The framework reports the component as failed to create even though the JavaScript file is syntactically valid.

A third shape: a missing component access grant. The component bundle was deployed but the running user's profile lacks Apex Class Access on the Apex controller the component references, or the user is in a Community where the component is not listed in the available components on the community Builder page.

A fourth shape: an exception thrown in the connectedCallback lifecycle hook before the component's UI renders. The framework treats a constructor or connectedCallback throw as an uncreatable component.

connectedCallback() {
  if (!this.recordId) {
    throw new Error('recordId is required');  // Halts component creation
  }
}

The runtime failure pipeline

Three failure phases produce this message. Knowing which phase failed narrows the fix.

The first phase is metadata resolution. The framework asks the platform for component bundles by reference name. If the bundle does not exist (deploy failed silently, a managed package was uninstalled, the component is in a namespace the user cannot see), the resolution fails. The banner appears immediately when the page loads. The console reports a 404 or a metadata-not-found error.

The second phase is bundle parsing and module instantiation. The framework parses the JavaScript, resolves imports, instantiates the class. If imports do not resolve, the JavaScript file has a parse error, or the constructor throws, the framework reports the failure here. The console reports the JavaScript exception or module-resolution error.

The third phase is wire-adapter binding. The framework binds each @wire decorator to its adapter. If the adapter rejects the binding (an Apex method is not cacheable, a uiRecordApi field name is wrong, a custom adapter is misconfigured), the binding fails and the component is marked uncreatable.

The fix, three paths

Read the browser console for the detail and fix the specific cause. This is the canonical first step. Open DevTools, refresh the page, search for the component name in the console output. The stack trace under the failure tells you which phase failed and what went wrong.

For the cacheable-Apex example, the console shows:

Error: Wire adapter requires cacheable=true: AccountInsightsService.getInsights

The fix is to add cacheable=true to the @AuraEnabled annotation on the Apex method:

@AuraEnabled(cacheable=true)
public static List<Insight> getInsights(Id accountId) {
    return [
        SELECT Id, Source, Score
        FROM Account_Insight__c
        WHERE Account__c = :accountId
    ];
}

Verify the user has access to every dependency. A component fails to create when the user cannot reach one of its imports. The most common offenders are Apex classes, custom objects referenced by lightning/uiRecordApi, and external resources (static resources, Visualforce pages used in iframes).

Setup → Profile or Permission Set → Apex Class Access. Add the controller. The user should retry the page.

For object-level access, ensure the user has Read on the object the component reads. For lightning/uiRecordApi, the framework respects field-level security; fields the user cannot read return undefined values rather than throwing, but a malformed field reference (a deleted field, a renamed field) throws.

Defensively handle missing data and lifecycle exceptions. Code that throws in the constructor or in connectedCallback should be reviewed. The lifecycle methods run before the UI renders, so any throw there blocks creation.

Replace synchronous throws with declarative checks:

connectedCallback() {
  // No throw; the template renders an error message instead
}

get hasValidContext() {
  return Boolean(this.recordId);
}

The template uses lwc:if to render either the panel or an error message based on hasValidContext. The component always creates successfully; the UI conveys the problem.

The fixed example

A resilient panel with cacheable Apex, defensive lifecycle, and inline error handling:

import { LightningElement, api, wire } from 'lwc';
import getInsights from '@salesforce/apex/AccountInsightsService.getInsights';

export default class AccountInsightsPanel extends LightningElement {
  @api recordId;
  insights = [];
  error;

  @wire(getInsights, { accountId: '$recordId' })
  wiredInsights({ data, error }) {
    if (data) {
      this.insights = data;
      this.error = undefined;
    } else if (error) {
      this.error = error.body?.message ?? 'Could not load insights';
      this.insights = [];
    }
  }

  get hasInsights() {
    return this.insights && this.insights.length > 0;
  }

  get hasError() {
    return Boolean(this.error);
  }
}

public with sharing class AccountInsightsService {
    @AuraEnabled(cacheable=true)
    public static List<Account_Insight__c> getInsights(Id accountId) {
        if (accountId == null) {
            return new List<Account_Insight__c>();
        }
        return [
            SELECT Id, Source__c, Score__c
            FROM Account_Insight__c
            WHERE Account__c = :accountId
            ORDER BY Score__c DESC
            LIMIT 20
        ];
    }
}

The component creates regardless of data state. The template handles loading, empty, error, and populated states. The Apex method is cacheable and returns an empty list rather than throwing for null inputs.

Edge case: managed-package components and namespaces

When the failing component is in an installed managed package (the reference name starts with the package namespace), the cause is often that the package's licenses or feature set does not cover the running user.

Setup → Installed Packages → manage licenses or features. Assign the user to the package's license. The component should create after a refresh.

Another managed-package edge case: a package upgrade introduced a new Apex method signature, but cached bundles in the user's browser still reference the old signature. A hard refresh (Ctrl+Shift+R) or a cache clear resolves the stale-bundle case.

Edge case: Locker Service and Lightning Web Security

Aura components run under Locker Service or Lightning Web Security. The security profiles restrict certain DOM APIs and global objects. A component that uses window.localStorage directly may work in a sandbox without LWS enabled and fail with Lightning component cannot be created in a production org that has LWS on.

The fix is to use approved APIs. For local storage in LWS contexts, use the platform-provided storage primitives or refactor to avoid the storage dependency.

Edge case: components in Experience Cloud

Experience Cloud renders components through the Builder, which requires the component to be exposed in the design metadata.

<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>62.0</apiVersion>
    <isExposed>true</isExposed>
    <targets>
        <target>lightningCommunity__Page</target>
        <target>lightningCommunity__Default</target>
    </targets>
</LightningComponentBundle>

Without the lightningCommunity__Page target, the component cannot be dropped onto a community page. If it appears on a page (because metadata was deployed) but the target is missing, the framework refuses to create it at render time.

Edge case: stale browser cache after a deploy

Lightning aggressively caches component bundles. After a deploy that changes a component's JavaScript or template, the user's browser may serve a stale bundle that references methods that no longer exist. The console shows a mismatch (a method or property is not defined) and the framework gives up.

The fix is a cache flush. From the user side, a hard refresh works. From the org side, bumping the org's session caching parameters or deploying a no-op change to force a cache reset can help. For mission-critical deploys, schedule a maintenance window and notify users to refresh.

Test patterns

Jest tests for LWC components catch import errors, lifecycle throws, and template binding errors before deploy.

import { createElement } from 'lwc';
import AccountInsightsPanel from 'c/accountInsightsPanel';

describe('AccountInsightsPanel', () => {
  it('renders without throwing when recordId is missing', () => {
    const element = createElement('c-account-insights-panel', { is: AccountInsightsPanel });
    document.body.appendChild(element);
    expect(element).not.toBeNull();
  });
});

A passing test confirms the component instantiates. Adding additional cases that mock the wire adapter result covers the data-rendering paths.

For Apex methods backing LWCs, a test that asserts cacheable=true is set ensures the wire adapter binding works.

@IsTest
static void getInsightsReturnsForNullId() {
    List<Account_Insight__c> result = AccountInsightsService.getInsights(null);
    System.assertEquals(0, result.size(), 'Null id returns empty list');
}

Diagnosing in production

When the error fires:

1. Open the browser DevTools console.
2. Find the message that names the failing component.
3. Read the stack trace under the message; identify the underlying cause.
4. Match the cause to a fix category: metadata access, import path, cacheable annotation, lifecycle throw, missing access grant.
5. Apply the fix and have the user hard-refresh.

The console message is verbose. Spend the minute to read it carefully; the framework usually tells you exactly which line failed.

Defensive habits

Use @AuraEnabled(cacheable=true) for any Apex method consumed by @wire. Mark methods that have side effects as non-cacheable and call them imperatively, not through @wire.

Avoid throwing in constructors and connectedCallback. Move validation to declarative template checks.

Test every Lightning Web Component with Jest. The test catches imports that don't resolve and lifecycle exceptions before they reach a real page.

Set up monitoring for the Lightning component cannot be created console message via a frontend instrumentation tool. Production users rarely report the error, but it appears in console logs and can be aggregated.

Audit Apex Class Access on every permission set after a deploy. New classes need explicit grants.

Quick recovery checklist

1. Open DevTools console, find the underlying error.
2. Identify the failure phase: metadata, parse, lifecycle, wire.
3. Apply the targeted fix.
4. Add a Jest test for the case.
5. Deploy and verify.

Most Lightning component creation failures resolve in 15-30 minutes once the console message is read. The longer ones involve managed-package interactions or Locker Service boundaries and benefit from a Salesforce Support case if the root cause is in platform code.

Further reading from Salesforce

• Lightning Web Components Developer Guide: Reactive Wire Service
• Apex Developer Guide: AuraEnabled Annotation
• Lightning Web Components Developer Guide: Lightning Web Security
• Architect: Lightning Component Architecture
• Trailhead: Build Lightning Web Components