v5.0.8

What's Changed

• fix: pin chrome version to bypass shadowRoot issues with chrome 121 by @jye-sf in #3986
• refactor: disable formAssociated on custom element constructor spring24 by @jmsjtu in #3985

Full Changelog: v5.0.7...v5.0.8

v6.1.1

What's Changed

• fix(hydration): force native shadow when synthetic exists by @nolanlawson in #3907
• chore: warn on shadowSupportMode 'any' by @ekashida in #3972
• fix(engine-dom): support LWC v5 compiler slot format by @nolanlawson in #3973
• chore: release v6.1.1 by @nolanlawson in #3976
• chore: release v6.1.1 by @nolanlawson in #3977

Full Changelog: v6.1.0...v6.1.1

v6.1.0

What's Changed

• fix: use more helpful error message for invalid render() return value @W-14785069 by @wjhsf in #3943
• chore: improve license header checks @W-14846456 by @wjhsf in #3951
• test(errors): validate error object shapes and unique codes @W-14841223 by @wjhsf in #3949
• feat: allow computed properties in @wire if they are constants or primitives @W-14785085 by @wjhsf in #3955
• refactor: remove shadowSupportMode = 'any' by @jmsjtu in #3953
• chore: update non-breaking deps by @nolanlawson in #3966
• chore(copyright): update rollup config to use correct copyright by @wjhsf in #3967
• chore: fix broken test due to Firefox update by @nolanlawson in #3968
• refactor: remove polyfill globalThis by @SaurabhMulay999 in #3960
• chore: release v6.1.0 by @nolanlawson in #3969
• chore: release v6.1.0 by @nolanlawson in #3970

New Contributors

• @SaurabhMulay999 made their first contribution in #3960

Full Changelog: v6.0.0...v6.1.0

v6.0.0

Note

These release notes are for the Lightning Web Components framework in open source only. If you use Lightning Base Components, Lightning Web Security, or other Salesforce products on the Lightning platform, see the Summer '24 release notes.

LWC v6.0.0 contains breaking changes. Please read carefully below if you are upgrading from v5.

If you are upgrading from v4, please upgrade to v5 first.

Note

LWC v6 corresponds to Salesforce release Summer '24 (API version 61).

Summary of new features

• Form-Associated Custom Elements (FACE) and Element Internals are now supported.

Summary of breaking change

• Native custom element lifecycle
• Fixed light DOM slot remapping
• Standard shadowrootmode attribute in SSR

Breaking changes

Native custom element lifecycle

Note

This change currently only applies to consumers of the LWC open-source project outside of the Salesforce Lightning platform.

Previous versions of LWC used a synthetic (polyfill) system to call the connectedCallback and disconnectedCallback component lifecycle hooks. This was originally designed for legacy browsers such as Internet Explorer 11. Such browsers are no longer supported, and LWC v6 uses the native browser APIs instead.

Important

Native vs synthetic custom element lifecycle is not the same as native vs synthetic shadow DOM. They are two entirely separate concepts.

This change may affect the firing of connectedCallback and disconnectedCallback hooks in your components, since the previous implementation did not perfectly align with the browser standard. Most commonly, this will occur in unit tests, or when manually creating components using the lwc.createElement() API. The new behavior also fixes common memory leaks caused by disconnectedCallback not firing consistently.

Native custom element lifecycle also unlocks support for Form-Associated Custom Elements (FACE) and Element Internals.

Changes you may see to connectedCallback and disconnectedCallback behavior:

• New behavior when disconnected from the DOM
• New error behavior
• New timing behavior in native shadow DOM
• Shadow roots may be null after appending to disconnected elements
• New timing behavior during list rendering

New behavior when disconnected from the DOM

Note

This situation will probably only occur when writing tests that do not connect elements to the DOM.

LWC components now only fire connectedCallback when they are actually connected to the DOM. If they are disconnected from the DOM (i.e. they are not inside the document), then connectedCallback will not fire.

For instance, if you are testing for an event to be fired from a connectedCallback, this would previously work:

export default class Foo extends LightningElement {
  connectedCallback() {
    this.dispatchEvent(new CustomEvent('foo', { bubbles: true, composed: true }))
  }
}

const element = createElement('x-foo', { is: Foo })
const div = document.createElement('div')
div.addEventListener('foo', () => {
  console.log('received foo event!')
})
div.appendChild(element) // triggers connectedCallback

In the above example, received foo event! would be logged to the console.

After this change, the above no longer triggers the connectedCallback, nor the event.

Instead, you must ensure the element is connected to the DOM:

document.body.appendChild(div)

Once the element is in the DOM tree, connectedCallback will fire as expected.

New error behavior

Note

This situation will probably only occur if you are writing tests to capture errors thrown in connectedCallback/disconnectedCallback. Most component authors should never have to deal with this.

Errors thrown by connectedCallbacks and disconnectedCallback are dispatched globally, rather than locally when elements are added/removed from the DOM.

For example, let's say you have a component that throws an error in connectedCallback:

export default class Foo extends LightningElement {
  connectedCallback() {
      throw new Error('foo')
  }
}

And then you expect to be able to catch the error synchronously on appendChild:

const element = lwc.createElement('x-foo', { is: Foo })
try {
  document.body.appendChild(element)
} catch (error) {
  console.log('caught error', error)
}

• Old behavior: the error is caught.
• New behavior: the error is uncaught.

The solution is to use a global error listener:

const listener = (error) => {
  console.log('Caught error', error)
}
try {
  window.addEventListener('error', listener)
  document.body.appendChild(element);
} finally {
  window.removeEventListener('error', listener)
}

If you're using @lwc/jest-*, then you can use the new toThrowInConnectedCallback API which will handle this logic for you.

Note

Events dispatched in connectedCallback and disconnectedCallback are unaffected by this change.

New timing behavior in native shadow DOM

The timing of connectedCallback has changed slightly to align with native browser standards, when using native shadow DOM.

For example, the timing of when connectedCallback fires in child components relative to parent components has changed. Consider this DOM tree:

<x-a>
  #shadow-root
  | <x-a-child>
</x-a>
<x-b>
  #shadow-root
  | <x-b-child>
</x-b>
<x-c>
  #shadow-root
  | <x-c-child>
</x-c>

Old behavior: the order of connectedCallbacks firing is:

• x-a
• x-b
• x-c
• x-c-child
• x-b-child
• x-a-child

New behavior: the order of connectedCallbacks firing is:

• x-a
• x-a-child
• x-b
• x-b-child
• x-c
• x-c-child

Note that, with the new behavior, connectedCallback fires in standard DOM depth-first tree-traversal order. (The old behavior was defined by the synthetic lifecycle polyfill, and did not follow the standard.)

The relative timing of renderedCallback has also changed due the new native connectedCallback timing. For example, consider this DOM tree:

<x-grandparent>
  <x-parent>
    <x-child></x-child>
  </x-parent>
</x-grandparent>

(Note that, in the above example, the <x-parent> and <x-child> are slotted, not part of the shadow roots of their containers.)

Old behavior: the order of lifecycle hooks firing is (example):

Component	Lifecycle hook
grandparent	connectedCallback
parent	connectedCallback
child	connectedCallback
child	renderedCallback
parent	renderedCallback
grandparent	renderedCallback

New behavior: the order of lifecycle hooks firing is (example):

Component	Lifecycle hook
grandparent	connectedCallback
grandparent	renderedCallback
parent	connectedCallback
parent	renderedCallback
child	connectedCallback
child	renderedCallback

Note that the above only applies to native shadow DOM. In synthetic shadow DOM, the ordering is the same, regardless of native vs synthetic custom element lifecycle (example). The same is true of light DOM (example).

In general, your components should not rely on the particular timing of `connectedCall...

v5.3.0

What's Changed

• fix(template-compiler): exclude comments from static parts when lwc:preserve-comments is disabled by @jmsjtu in #3934
• chore: release v5.3.0 by @nolanlawson in #3938
• chore: release v5.3.0 by @jye-sf in #3941

Full Changelog: v5.2.2...v5.3.0

v5.0.7

What's Changed

• fix(engine-core): unrevert ARIA reflection fix and release 5.0.7 by @nolanlawson in #3937

Full Changelog: v5.0.6...v5.0.7

v5.0.6

What's Changed

• fix(template-compiler): fix static part comments and release 5.0.6 by @nolanlawson in #3936

Full Changelog: v5.0.5...v5.0.6

v5.0.5

What's Changed

• fix(engine-core): revert ARIA fix and release v5.0.5 by @nolanlawson in #3935

Full Changelog: v5.0.4...v5.0.5

v5.0.4

What's Changed

• chore(ci): pin chromedriver version [backport] by @nolanlawson in #3920
• fix(engine-core): fix non-native ARIA reflection [backport] by @nolanlawson in #3919
• chore: release v5.0.4 by @nolanlawson in #3932

Full Changelog: v5.0.3...v5.0.4

v5.2.2

What's Changed

• docs(lwc-engine): update README example by @JaydeepGo in #3922
• fix(engine-core): fix non-native ARIA reflection by @nolanlawson in #3918
• v5.2.2 by @abdulsattar in #3926
• v5.2.2 by @abdulsattar in #3927

New Contributors

• @JaydeepGo made their first contribution in #3922

Full Changelog: v5.2.1...v5.2.2