|
1 | | -# Who are we? |
| 1 | +# <spectrum-web-components> element |
2 | 2 |
|
3 | | -Spectrum Web Components is a future-looking project to develop Adobe Spectrum design language based around web components, ES-Modules, and modern browser standards. |
| 3 | +The official implementation of Spectrum CSS in Web Components. |
4 | 4 |
|
5 | | -To this end, Spectrum Web Components only targets _modern_, evergreen browsers that fully implement the Custom Elements V1 specification, e.g. Chrome, Firefox, Safari. Polyfills will be avoided as much as possible but documented if necessary. |
| 5 | +## Installation |
6 | 6 |
|
7 | | -# Requirements |
| 7 | +Available on [npm](https://www.npmjs.com/) as [**@adobe/spectrum-web-components**](https://www.npmjs.com/package/@adobe/spectrum-web-components). |
8 | 8 |
|
9 | | -- NodeJS >= 20.0.0 |
10 | | -- Typescript |
11 | | -- Supported desktop browsers: |
12 | | - - Last 2 versions of Chrome |
13 | | - - Last 2 versions of Firefox |
14 | | - - Last 2 versions of Safari |
15 | | - - Last 2 versions of Edge |
16 | | -- Or appropriate [polyfills](https://github.com/webcomponents/webcomponentsjs) in older browsers. |
17 | | -- We support all viewport sizes across supported desktop browsers. |
18 | | -- While our components are designed to be responsive and mobile-friendly, we do not yet fully support mobile browsers due to limited testing in mobile hardware. We advise testing updates on mobile devices before updating and are happy to address any reported issues. |
19 | | - |
20 | | -# Getting started |
21 | | - |
22 | | -```bash |
23 | | -git clone https://github.com/adobe/spectrum-web-components.git |
24 | | -cd spectrum-web-components |
25 | | -yarn |
26 | 9 | ``` |
27 | | - |
28 | | -The call to `yarn` will install and setup everything you need for developing and running the packages in this library. |
29 | | - |
30 | | -Typical development will involve running `yarn storybook`, `yarn test`, and `yarn docs:start` if you're making documentation changes (see below for additional details). |
31 | | - |
32 | | -## Building a new component |
33 | | - |
34 | | -Creating a new component from the command line can be done by running the following: |
35 | | - |
36 | | -```bash |
37 | | -yarn new-package |
| 10 | +$ npm install --save @adobe/spectrum-web-components |
38 | 11 | ``` |
39 | 12 |
|
40 | | -This will scaffold your component's required architecture by prompting you for 2 data points - the desired name for your package and the name of the Spectrum CSS asset from which you will be building. |
41 | | - |
42 | | -? **SWC package name (i.e. color-area)** |
43 | | - |
44 | | -_Note_ that your component name should be provided in kebab case and should relate as closely as possible to the Spectrum core naming. |
| 13 | +## Usage |
45 | 14 |
|
46 | | -? **Spectrum CSS package name (i.e. colorarea)** |
| 15 | +### Script |
47 | 16 |
|
48 | | -You can find this information in the [Spectrum CSS GitHub project](https://github.com/adobe/spectrum-css) by finding the component package.json (i.e., `components/accordion/package.json`) |
| 17 | +Import as ES modules: |
49 | 18 |
|
50 | | -For additional information, please see the [generating components documentation](https://opensource.adobe.com/spectrum-web-components/guides/generating-components) and capturing the value of the package name: `"name": "@spectrum-css/accordion"`. In this example, that name is `accordion`. _Note_ that the project scope `@spectrum-css` is stripped out of the response. |
51 | | - |
52 | | -# Storybook |
53 | | - |
54 | | -Testing & reviewing changes can be done using the Storybook instance. Running `yarn storybook` will spin up a local instance of Storybook, triggering the browser to open at completion. From there you can make changes to your code and the browser will automatically refresh. |
55 | | - |
56 | | -You can run [Storybook](https://storybook.js.org) through the command: |
57 | | - |
58 | | -```bash |
59 | | -yarn storybook |
| 19 | +```js |
| 20 | +import '@adobe/spectrum-web-components'; |
60 | 21 | ``` |
61 | 22 |
|
62 | | -By default, the resulting site will be available at [http://localhost:8000](http://localhost:8000). |
63 | | - |
64 | | -# Documentation |
| 23 | +Include with a script tag: |
65 | 24 |
|
66 | | -The Spectrum Web Components documentation site is available via the following command: |
67 | | - |
68 | | -```bash |
69 | | -yarn docs:start |
| 25 | +```html |
| 26 | +<script type="module" src="./node_modules/@adobe/spectrum-web-components/dist/index.js"> |
70 | 27 | ``` |
71 | 28 |
|
72 | | -By default, the resulting site will be available at [http://localhost:8080](http://localhost:8080). |
73 | | - |
74 | | -In the case that you'd like to serve and test a static build of the documentation from the root directory (`localhost` or otherwise), use: |
75 | | - |
76 | | -```bash |
77 | | -yarn docs:build |
78 | | -``` |
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 |
91 | | - |
92 | | -There are several commands that can be useful in specific scenarios: |
93 | | - |
94 | | -- `yarn build:clear-cache` to remove previously created artifacts of the `tsc build` process. |
95 | | -- `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 | | -- `yarn build` to make sure the available JS has been built from the current TS source. |
98 | | - |
99 | | -## Linting |
100 | | - |
101 | | -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 | | - |
103 | | -### Dependency linting |
104 | | - |
105 | | -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 | | - |
107 | | -`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 | | - |
109 | | -## Testing |
110 | | - |
111 | | -### Unit tests |
112 | | - |
113 | | -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 | | - |
115 | | -``` |
116 | | -yarn test |
117 | | -``` |
118 | | - |
119 | | -During development you may wish to use `yarn test:watch` to automatically build and re-run the test suites. |
120 | | - |
121 | | -### Screenshot testing |
122 | | - |
123 | | -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. |
124 | | - |
125 | | -Visual regressions are tracked via screenshot testing powered by [`@web/test-runner-visual-regression`](https://github.com/modernweb-dev/web/tree/master/packages/test-runner-visual-regression). Due to the font metrics not being identical, it is difficult to rely on screenshot-based testing across operating systems. Because of this, the library manages its golden image cache internal to CircleCI, rather than as a part of the git repository. Neither the `screenshots-baseline` nor `screenshots-actual` directory should be added to git. When working with visual regression tests locally to manage changes you are making, be sure to create a baseline locally before you begin development (alternatively, you can pull down the main branch to generate the baselines for your in-progress work). |
126 | | - |
127 | | -To create a local baseline for comparing your changes to later in the development cycle, use the following: |
128 | | - |
129 | | -```bash |
130 | | -yarn test:visual:clean # start with a clean slate |
131 | | -# yarn test:visual:clean:baseline # removes only baseline images |
132 | | -# yarn test:visual:clean:current # removes only images updated in the most recent test pass |
133 | | - |
134 | | -# To enable comparison, it is generally recommended to generate baselines on the main branch. |
135 | | -yarn test:visual vrt-${component name} --update-visual-baseline |
136 | | -eg: yarn test:visual vrt-accordion --update-visual-baseline |
137 | | - |
138 | | -# Running the tests on the local branch |
139 | | -yarn test:visual vrt-${component name} |
140 | | -eg: yarn test:visual vrt-accordion |
141 | | - |
142 | | -# Running the tests of light medium ltr |
143 | | -yarn test:visual vrt-${component name}-single |
144 | | -eg: yarn test:visual vrt-accordion-single |
145 | | -``` |
146 | | - |
147 | | -#### Screenshot coverage |
148 | | - |
149 | | -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 | | - |
151 | | -#### Keeping CI assets updated |
152 | | - |
153 | | -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 | | - |
155 | | -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 | | - |
157 | | -``` |
158 | | -parameters: |
159 | | - current_golden_images_hash: |
160 | | - type: string |
161 | | - default: ${UPDATE_REVISION_NUMBER_HERE} |
162 | | -``` |
163 | | - |
164 | | -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 | | - |
166 | | -## Benchmarking |
167 | | - |
168 | | -You can acquire current runtimes for the individual elements with: |
169 | | - |
170 | | -``` |
171 | | -yarn build:tests |
172 | | -yarn test:bench |
173 | | -``` |
174 | | - |
175 | | -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 | | - |
177 | | -## Anatomy of a component |
178 | | - |
179 | | -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 | | - |
181 | | -- packages |
182 | | - - new-component-name |
183 | | - - src |
184 | | - - index.ts |
185 | | - - new-component-name.css |
186 | | - - new-component-name.ts |
187 | | - - spectrum-config.js |
188 | | - - spectrum-new-component-name.css |
189 | | - - stories |
190 | | - - new-component-name.stories.ts |
191 | | - - test |
192 | | - - benchmark |
193 | | - - test-basic.ts |
194 | | - - new-component-name.test.ts |
195 | | - - package.json |
196 | | - - README.md |
197 | | - - tsconfig.json |
198 | | - |
199 | | -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 | | - |
201 | | -## IDE Notes |
202 | | - |
203 | | -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 | | - |
205 | | -# Contributing |
206 | | - |
207 | | -We'd be very grateful if you contributed to the project! Check out our [contribution guidelines](CONTRIBUTING.md) for more information. |
| 29 | +## Browser support |
208 | 30 |
|
209 | | -<a name="patches"></a> |
| 31 | +Browsers without native [custom element support][support] require a [polyfill][]. |
210 | 32 |
|
211 | | -<details><summary><strong>Active patches</strong></summary> |
| 33 | +- Chrome |
| 34 | +- Firefox |
| 35 | +- Safari |
| 36 | +- Microsoft Edge |
212 | 37 |
|
213 | | -### lru-cache |
| 38 | +[support]: https://caniuse.com/custom-elementsv1 |
| 39 | +[polyfill]: https://github.com/webcomponents/custom-elements |
214 | 40 |
|
215 | | -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. |
| 41 | +## License |
216 | 42 |
|
217 | | -</details> |
| 43 | +Distributed under the MIT license. See LICENSE for details. |
0 commit comments