@lwc/errors
9.5.3 · 27 Oct 2026MIT384.1k / weekRepositoryHomepagenpmAtom feed
8.28.2 is the newest release of 8.x.
In short
2 breaking3 changed
- breaking
The breaking changes in this release only impact TypeScript users; there is no change in runtime behavior, as compared to v7.2.6.
- breaking
TypeScript's experimentalDecorators is no longer supported; you must either specify "experimentalDecorators": false or remove the option from your TSConfig.
Release note
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?: BookLimitations
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
constassertions on your config object. Without aconstassertion, 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 typestringare not type checked.For example, for a config of type
{id: number}, providing the object{id: "123"}will pass validation, but{id: "123"} as constwill 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.