@lwc-bolts/lightning-base-components 0.0.0-stage → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE.md +7 -0
- package/README.md +56 -2
- package/dist/components.generated.d.ts +3 -0
- package/dist/components.generated.js +4190 -0
- package/dist/index.d.ts +2 -0
- package/dist/index.js +1 -0
- package/dist/types.d.ts +13 -0
- package/dist/types.js +2 -0
- package/package.json +42 -4
package/LICENSE.md
ADDED
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
Copyright 2025 Anthony Heber
|
|
2
|
+
|
|
3
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
|
|
4
|
+
|
|
5
|
+
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
|
|
6
|
+
|
|
7
|
+
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
package/README.md
CHANGED
|
@@ -1,3 +1,57 @@
|
|
|
1
|
-
#
|
|
1
|
+
# @lwc-bolts/lightning-base-components
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Definitions of the Salesforce `lightning-*` base components: each component's properties (with the types they accept and their descriptions), methods and events, by tag. The [content mapper](../typescript-content-mapper)'s template checks use them through [sf2ts](../sf2ts).
|
|
4
|
+
|
|
5
|
+
```ts
|
|
6
|
+
import { LIGHTNING_COMPONENTS } from "@lwc-bolts/lightning-base-components";
|
|
7
|
+
|
|
8
|
+
LIGHTNING_COMPONENTS["lightning-combobox"].events.change.type; // 'CustomEvent<{ value: string }>'
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## Updating the definitions
|
|
12
|
+
|
|
13
|
+
`src/components.generated.ts` is generated by `npm run generate` from two sources, whose versions `lightning/sources.json` pins:
|
|
14
|
+
|
|
15
|
+
- The Salesforce LWC language server's component metadata (`@salesforce/lwc-language-server`'s `lib/resources/transformed-lwc-standard.json`, BSD-3-Clause), which lists components and their attributes, most with a type and a description.
|
|
16
|
+
- The base component stubs Salesforce's Jest preset uses (`@salesforce/sfdx-lwc-jest`'s `src/lightning-stubs`, MIT): an LWC class per component, with an `@api` member for each property and method, without types.
|
|
17
|
+
|
|
18
|
+
Components, properties and methods are the union of both, typed and described from the language server's metadata where it has them, and `any` otherwise. Neither has events. The generated file carries both licenses. `npm run generate -- --update` moves both sources to their latest versions first, and pins them.
|
|
19
|
+
|
|
20
|
+
`lightning/overrides.jsonc` changes the definitions by hand, and wins over both sources. Its schema, `lightning/overrides.schema.json`, describes it to editors:
|
|
21
|
+
|
|
22
|
+
```jsonc
|
|
23
|
+
{
|
|
24
|
+
"$schema": "./overrides.schema.json",
|
|
25
|
+
"components": {
|
|
26
|
+
"lightning-input": {
|
|
27
|
+
"methods": { "reportValidity": { "type": "() => boolean" } }, // change a member's type
|
|
28
|
+
"events": { "change": { "detail": "{ value: any; checked?: boolean }" } } // add an event
|
|
29
|
+
},
|
|
30
|
+
"lightning-card": {
|
|
31
|
+
"properties": { "actions": null, "footer": null } // remove members: these are slots
|
|
32
|
+
},
|
|
33
|
+
"lightning-legacy-thing": null, // remove a whole component
|
|
34
|
+
"lightning-new-thing": { // add a component neither source has
|
|
35
|
+
"properties": { "size": { "type": "number" } }
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
}
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
- `null` removes a component, property, method or event, and blocks it: the overrides are applied every time the file is generated, so an update can't bring it back.
|
|
42
|
+
- A member's `type` and `description` replace the imported ones. A member or component neither source has is added; a member without a type gets `any` (methods `(...args: any[]) => any`, events `CustomEvent<any>`). An event's `detail` is shorthand for `CustomEvent<detail>`, and its name is the one `on<name>` handles.
|
|
43
|
+
- `"replace": true` ignores a component's imported members, so it has only those the overrides give it.
|
|
44
|
+
|
|
45
|
+
The script checks the overrides before using them, and warns about removals that no longer match anything imported, so they can be cleaned up. Run it after changing the overrides, and commit both. The tests check that the generated file reflects the overrides, and compile every component's definition.
|
|
46
|
+
|
|
47
|
+
The overrides' events, method types and descriptions, and the components neither source has (`lightning-select`, `lightning-empty-state` and `lightning-illustration`), come from the [Lightning Component Reference](https://developer.salesforce.com/docs/platform/lightning-component-reference/guide/components.html), with its descriptions verbatim. Where the reference disagrees with how a component behaves (such as `lightning-combobox`'s `change` event, whose detail is `{ value }` rather than the documented `selectedValue`), a comment says so.
|
|
48
|
+
|
|
49
|
+
`npm run compare-docs` crawls the reference and compares it with the generated definitions, to find what to add to the overrides or what's out of date there:
|
|
50
|
+
|
|
51
|
+
```sh
|
|
52
|
+
npm run compare-docs # every component in the reference
|
|
53
|
+
npm run compare-docs -- lightning-input lightning-tabs # only these
|
|
54
|
+
npm run compare-docs -- --cache .reference-cache --json comparison.json
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
For each component it reads the reference's Markdown page (its description and custom events) and its specification (attributes, methods and slots, from the endpoint the page's Specifications tab uses), and lists, per component: attributes, methods and events one has that the other doesn't, attribute types whose kinds don't overlap, methods whose argument count differs, documented event parameters our detail type lacks, and the documented slots, which the definitions don't model. Members every component gets from its host element (`title`, `aria-*`, `focus()` and the like) aren't listed. The site refuses bursts of requests, so the script fetches one page at a time and backs off when refused; with `--cache`, an interrupted run resumes where it stopped. `--json` also writes what it read and the comparison.
|