v8.0.0

What's Changed

The breaking changes in this release only impact TypeScript users; there is no change in runtime behavior, as compared to v7.2.6.

Important

TypeScript's experimentalDecorators is no longer supported; you must either specify "experimentalDecorators": false or remove the option from your TSConfig.

This release contains changes to the type signature of the @wire decorator, to enable better type checking of the provided values. Given @wire(adapter, config) prop, the types of config and prop now must match the types used by adapter. The type checking also successfully resolves reactive props (string starting with $) to the type used by the component.

In the example below, the component passes type checking with LWC v7, but has three new type errors in LWC v8.

type Config = { id: number }
type Book = { title: string, author: string }
declare const getBook: WireAdapterConstructor<Config, Book>

class Component extends LightningElement {
  bookId = 123
  authorName = 'Codey the Bear'

  // Valid: simple case
  @wire(getBook, { id: 123 }) valid?: Book
  // Valid: `bookId` on the component is a number
  @wire(getBook, {id: '$bookId'} as const) validReactiveProp?: Book
  // Invalid: `Author` is not `Book`
  @wire(getBook, { id: 123 }) invalidPropType?: Author
  // Invalid: `true` is not a number
  @wire(getBook, { id: true }) invalidConfigType: Book
  // Invalid: `authorName` prop on the component is not a number
  @wire(getBook, {id: '$authorName'} as const) invalidReactiveProp?: Book

Limitations

• Due to the way decorators are implemented in TypeScript, the type of the prop cannot be inferred from the wire adapter; you must provide an explicit type.
• To get the most accurate validation of your types, use const assertions on your config object. Without a const assertion, the type system cannot distinguish between a reactive prop (e.g. "$authorName") and a regular string (e.g. "Codey the Bear"). As a consequence, all values of type string are not type checked.
  • For example, for a config of type {id: number}, providing the object {id: "123"} will pass validation, but {id: "123"} as const will not.
• Due to the above constraints, the reported type errors can appear complex and hard to understand. They typically boil down to validating that your config object and prop type both match the type expected by the wire adapter.

Full Changelog: v7.2.6...v8.0.0