The base of this PR is #4186 because this is a TypeScript-only feature.
Details
In order to import HTML/CSS files, users need to provide module definitions for those files, because TypeScript does not otherwise know how to handle them. As part of adding TypeScript support, we must provide those module definitions. They are added in a new package, @lwc/types for ease of use. The new package is imported in lwc/index.d.ts, so TypeScript users will get the module definitions automatically, if they use lwc.
As a types-only package, @lwc/types does not follow the standard package.json format, so it required small changes to the enforcement script.
Does this pull request introduce a breaking change?
💔 Yes, it does introduce a breaking change.
TypeScript users who import { LightningElement } from 'lwc' will break if they provide their own module definitions that conflict with ours.
Does this pull request introduce an observable change?
The base of this PR is #4186 because this is a TypeScript-only feature.
Details
In order to import HTML/CSS files, users need to provide module definitions for those files, because TypeScript does not otherwise know how to handle them. As part of adding TypeScript support, we must provide those module definitions. They are added in a new package,
@lwc/types
for ease of use. The new package is imported inlwc/index.d.ts
, so TypeScript users will get the module definitions automatically, if they uselwc
.As a types-only package,
@lwc/types
does not follow the standardpackage.json
format, so it required small changes to the enforcement script.Does this pull request introduce a breaking change?
TypeScript users who
import { LightningElement } from 'lwc'
will break if they provide their own module definitions that conflict with ours.Does this pull request introduce an observable change?
GUS work item
@W-15972370@