You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+16-27Lines changed: 16 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,48 +77,37 @@ In the case that you'd like to serve and test a static build of the documentatio
77
77
yarn docs:build
78
78
```
79
79
80
-
# Updating Spectrum CSS
81
-
82
-
There are two mechanisms for broadly updating SWC's Spectrum CSS dependencies:
83
-
84
-
-`yarn update:spectrum-css` brings all Spectrum CSS dependencies to 'latest'
85
-
-`yarn update:spectrum-css:nonbreaking` brings them to the latest minor or patch version
86
-
87
-
We aim to keep Spectrum CSS as current as possible, to track the Spectrum design system closely.
88
-
The `:nonbreaking` variant lets us release patch updates quickly in cases where more work is required to be compatible with 'latest.'
89
-
90
-
# Advanced development
80
+
## Advanced development
91
81
92
82
There are several commands that can be useful in specific scenarios:
93
83
94
84
-`yarn build:clear-cache` to remove previously created artifacts of the `tsc build` process.
95
85
-`yarn process-icons` to make sure that the most recent icons are included.
96
-
-`yarn process-spectrum` to process the spectrum CSS style sources into the individual packages.
97
86
-`yarn build` to make sure the available JS has been built from the current TS source.
98
87
99
-
## Linting
88
+
###Linting
100
89
101
90
The project will be linted on a pre-commit hook, but you can also run the lint suite with `yarn lint`. It uses ESLint to lint the JS / TS files, and StyleLint to lint the CSS files.
102
91
103
-
### Dependency linting
92
+
####Dependency linting
104
93
105
94
There are downstream issues that can arise from multiple packages in this mono-repo using dependencies with mismatched version strings. By default, [changesets](https://opensource.adobe.com/spectrum-web-components/guides/writing-changesets/) will bump version numbers of internal dependencies when the various packages are published and the depended version is pointing to the latest release, which can help to mitigate this issue. Running `yarn lint:versions` will check that all version strings for each dependency match across the repo.
106
95
107
96
`yarn list:versions --fix` will modify the `package.json` files, updating all dependencies to the latest version available in the library — _a potentially dangerous operation_. If this is what you want to do when `yarn lint:versions` discovers mismatched versions, this step can greatly reduce the amount of work to achieve matching version numbers.
108
97
109
-
## Testing
98
+
###Testing
110
99
111
-
### Unit tests
100
+
####Unit tests
112
101
113
102
Unit tests are run with [Web Test Runner](https://modern-web.dev/docs/test-runner/overview/) in Playwright using the Chai, Mocha and Sinon helper libraries. These tests can be executed with:
114
103
115
-
```
104
+
```sh
116
105
yarn test
117
106
```
118
107
119
108
During development you may wish to use `yarn test:watch` to automatically build and re-run the test suites.
120
109
121
-
### Screenshot testing
110
+
####Screenshot testing
122
111
123
112
Note: visual regression is done automatically on pull requests via CircleCI; however, the following outlines how you can run these tests local to your machine.
Visual regression testing is done against screens derived from the exports of the `*.stories.js` files in each package. As you add packages or story files to existing packages, they will automatically be added to the visual regression suite and will require updating the cache key (outlined below).
150
139
151
-
#### Keeping CI assets updated
140
+
#####Keeping CI assets updated
152
141
153
142
If you find the `visual-*` jobs failing on CircleCI for reasons that you expect (you've updated the Spectrum CSS dependencies, you've added new tests, etc.) then you will need to update the golden images cache key before your build will pass. You can review and share the diffs for a test pass via a URL shaped like `vrt--spectrum-wc.netlify.app/${branchName}`. Before updating the cache key, be sure that the updated caches are both complete (there are times when process errors prevent images from being correctly created or when certain test passes take longer than others) and appear as expected. If you agree with the updated cache content, update the golden images cache key as follows.
154
143
155
144
Your failing branch will have created a new cache with a key of `v1-golden-images-{{ .Revision }}-<< parameters.regression_color >>-<< parameters.regression_scale >>-<< parameters.dir >>-{{ epoch }}`. Here `{{ .Revision }}` outlines the git commit hash of the current CI pass. In `.circleci/config.yml`, you will use that to update the cache that is requested at the beginning of the `run-regressions` job. As part of the review site, the git commit hash will be listed in the side navigation UI for easy access, use this number to update the `current_golden_images_hash` paramater that appears as follows:
156
145
157
-
```
146
+
```yaml
158
147
parameters:
159
148
current_golden_images_hash:
160
149
type: string
@@ -163,18 +152,18 @@ parameters:
163
152
164
153
This will ensure that tests on this branch point to this cache key for at least the next 30 days (keep-alive time of caches on CircleCI). Once the branch is merged to `main`, a cache key of `v2-golden-images-main-<< parameters.regression_color >>-<< parameters.regression_scale >>-<< parameters.regression_dir >>-{{ epoch }}` will be created on each successful build of `main` that will be long-lived and act as the "fallback" once the revision keyed cache has expired.
165
154
166
-
## Benchmarking
155
+
### Benchmarking
167
156
168
157
You can acquire current runtimes for the individual elements with:
169
158
170
-
```
159
+
```sh
171
160
yarn build:tests
172
161
yarn test:bench
173
162
```
174
163
175
164
This will run the defined [Tachometer](https://www.npmjs.com/package/tachometer) tests and report the current runtime cost of each individual element. When not making changes to the benchmarks on your local machine, you can skip `yarn build:tests` for later passes.
176
165
177
-
## Anatomy of a component
166
+
### Anatomy of a component
178
167
179
168
There is extended documentation on adding a new component to the library in the [documentation site](https://opensource.adobe.com/spectrum-web-components/guides/generating-components). However, at a high level, you will be building the following structure:
180
169
@@ -198,19 +187,19 @@ There is extended documentation on adding a new component to the library in the
198
187
199
188
For a list of component waiting to be implemented, visit our [`missing components`](https://github.com/adobe/spectrum-web-components/labels/missing%20components) tag.
200
189
201
-
## IDE Notes
190
+
### IDE Notes
202
191
203
192
The build process compiles `.css` files using PostCSS and wraps them in the `lit-html` `css` template tag and writes out a `.css.ts` file for easy import into TypeScript files. This file should not be edited, and is ignored by `.gitignore`, but you may also wish to hide the files in your IDE.
204
193
205
-
# Contributing
194
+
## Contributing
206
195
207
196
We'd be very grateful if you contributed to the project! Check out our [contribution guidelines](CONTRIBUTING.md) for more information.
The `lru-cache` leveraged by `@web/dev-server` can interact negatively with ARM based macOS machines causing a critical hang in the cache of transpiled file responses. This only effects development time operations and specifically effects the local test passes. To avoid this `[email protected]` has been patched to make its `set` method a noop, avoiding the caching process all together.
0 commit comments