@adobe/design-system-registry 3.3.0 → 5.0.1

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.
Files changed (39) hide show
  1. package/CHANGELOG.md +25 -0
  2. package/index.js +39 -139
  3. package/moon.yml +2 -29
  4. package/package.json +5 -34
  5. package/AUTHORING.md +0 -290
  6. package/PLATFORM_EXTENSIONS.md +0 -315
  7. package/ava.config.js +0 -21
  8. package/registry/alignments.json +0 -22
  9. package/registry/anatomy-terms.json +0 -739
  10. package/registry/categories.json +0 -55
  11. package/registry/color-families.json +0 -177
  12. package/registry/components.json +0 -277
  13. package/registry/densities.json +0 -17
  14. package/registry/easing-curves.json +0 -42
  15. package/registry/glossary.json +0 -181
  16. package/registry/motion-roles.json +0 -32
  17. package/registry/navigation-terms.json +0 -241
  18. package/registry/orientations.json +0 -17
  19. package/registry/platform-extensions/ios-states.json +0 -59
  20. package/registry/platform-extensions/web-components-states.json +0 -58
  21. package/registry/platforms.json +0 -37
  22. package/registry/positions.json +0 -32
  23. package/registry/property-terms.json +0 -212
  24. package/registry/scale-values.json +0 -126
  25. package/registry/shapes.json +0 -12
  26. package/registry/sizes.json +0 -71
  27. package/registry/states.json +0 -184
  28. package/registry/structures.json +0 -57
  29. package/registry/substructures.json +0 -12
  30. package/registry/token-objects.json +0 -32
  31. package/registry/token-terminology.json +0 -925
  32. package/registry/typography-families.json +0 -27
  33. package/registry/typography-styles.json +0 -22
  34. package/registry/typography-weights.json +0 -37
  35. package/registry/variants.json +0 -282
  36. package/schemas/platform-extension.json +0 -79
  37. package/schemas/registry-value.json +0 -230
  38. package/scripts/validate-registry.js +0 -134
  39. package/test/registry.test.js +0 -417
@@ -1,315 +0,0 @@
1
- # Platform Extensions Guide
2
-
3
- This guide explains how platform teams can extend the Spectrum Design System Registry with platform-specific terminology and implementation details.
4
-
5
- ## Overview
6
-
7
- The Platform Extension system allows platform implementations (iOS, Android, Web Components, Qt, etc.) to:
8
-
9
- * Define platform-specific terminology for registry terms
10
- * Document implementation differences
11
- * Provide code examples in platform-specific APIs
12
- * Map Spectrum terms to platform conventions
13
-
14
- ## Extension Approaches
15
-
16
- Platform teams have two options for contributing extensions:
17
-
18
- ### Option 1: Centralized Contributions (Recommended)
19
-
20
- Contribute platform-specific metadata directly to the central registry via pull requests.
21
-
22
- **Pros**:
23
-
24
- * Single source of truth
25
- * Easy to discover for all users
26
- * Maintained alongside core registry
27
- * Included in npm package
28
-
29
- **Cons**:
30
-
31
- * Requires PR approval from registry maintainers
32
- * May slow down platform-specific updates
33
-
34
- **When to use**: For stable, well-established platform terminology that benefits the entire Spectrum community.
35
-
36
- ### Option 2: Plugin/Extension System
37
-
38
- Maintain platform extensions in your own repository or as separate files.
39
-
40
- **Pros**:
41
-
42
- * Platform teams have full control
43
- * Faster iteration for platform-specific changes
44
- * Can be versioned independently
45
- * No approval required from central team
46
-
47
- **Cons**:
48
-
49
- * Users must load extensions separately
50
- * Risk of fragmentation
51
- * May become out of sync with base registry
52
-
53
- **When to use**: For experimental features, platform-specific implementations, or rapidly changing APIs.
54
-
55
- ## Creating a Platform Extension
56
-
57
- ### 1. Create Extension File
58
-
59
- Extensions are JSON files that reference base registry terms and add platform-specific information.
60
-
61
- **File naming convention**: `{platform}-{registry}.json`
62
-
63
- Examples:
64
-
65
- * `ios-states.json` - iOS extensions for interaction states
66
- * `android-sizes.json` - Android extensions for size values
67
- * `web-components-variants.json` - Web Components extensions for variants
68
-
69
- ### 2. Extension Schema
70
-
71
- ```json
72
- {
73
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/platform-extension.json",
74
- "platform": "iOS",
75
- "platformVersion": "iOS 17+",
76
- "description": "iOS-specific terminology for interaction states",
77
- "extends": "states",
78
- "extensions": [
79
- {
80
- "termId": "hover",
81
- "platformTerm": "highlighted",
82
- "platformAliases": ["isHighlighted"],
83
- "notes": "iOS uses 'highlighted' state for pointer interactions",
84
- "reference": "UIControl.State.highlighted",
85
- "codeExample": "button.isHighlighted = true",
86
- "differences": [
87
- "Only available on devices with pointer support",
88
- "Not triggered by touch interactions"
89
- ]
90
- }
91
- ]
92
- }
93
- ```
94
-
95
- ### 3. Extension Fields
96
-
97
- | Field | Required | Description |
98
- | ----------------- | -------- | --------------------------------------------------------- |
99
- | `platform` | Yes | Platform name (iOS, Android, Web Components, Qt, etc.) |
100
- | `platformVersion` | No | Platform or framework version |
101
- | `description` | No | What this extension provides |
102
- | `extends` | Yes | Which registry it extends (sizes, states, variants, etc.) |
103
- | `extensions` | Yes | Array of term extensions |
104
-
105
- ### 4. Term Extension Fields
106
-
107
- | Field | Required | Description |
108
- | ----------------- | -------- | -------------------------------------------- |
109
- | `termId` | Yes | ID of the base term (must exist in registry) |
110
- | `platformTerm` | No | Platform-specific term name |
111
- | `platformAliases` | No | Platform-specific aliases |
112
- | `notes` | No | Implementation notes |
113
- | `reference` | No | API name or documentation reference |
114
- | `codeExample` | No | Code snippet showing usage |
115
- | `differences` | No | Key differences from base term |
116
-
117
- ## Using Platform Extensions
118
-
119
- ### In Code
120
-
121
- ```javascript
122
- import {
123
- states,
124
- getTermForPlatform,
125
- loadPlatformExtension
126
- } from '@adobe/design-system-registry';
127
-
128
- // Load platform extension
129
- const iosStates = loadPlatformExtension('./platform-extensions/ios-states.json');
130
-
131
- // Get platform-specific term
132
- const hoverTerm = getTermForPlatform(states, 'hover', 'iOS', iosStates);
133
-
134
- console.log(hoverTerm.platform.term); // "highlighted"
135
- console.log(hoverTerm.platform.reference); // "UIControl.State.highlighted"
136
- console.log(hoverTerm.platform.codeExample); // "button.isHighlighted = true"
137
- ```
138
-
139
- ### Loading All Extensions
140
-
141
- ```javascript
142
- import { loadAllPlatformExtensions } from '@adobe/design-system-registry';
143
- import { join } from 'node:path';
144
-
145
- const extensionsDir = join(__dirname, 'registry', 'platform-extensions');
146
- const allExtensions = loadAllPlatformExtensions(extensionsDir);
147
-
148
- // Filter by platform
149
- const iosExtensions = allExtensions.filter(ext => ext.platform === 'iOS');
150
- ```
151
-
152
- ## Example: iOS States Extension
153
-
154
- Here's a complete example showing how iOS extends the states registry:
155
-
156
- ```json
157
- {
158
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/platform-extension.json",
159
- "platform": "iOS",
160
- "platformVersion": "iOS 17+",
161
- "description": "iOS-specific terminology for interaction states",
162
- "extends": "states",
163
- "extensions": [
164
- {
165
- "termId": "hover",
166
- "platformTerm": "highlighted",
167
- "platformAliases": ["isHighlighted"],
168
- "notes": "iOS uses 'highlighted' for pointer interactions on devices with pointer support",
169
- "reference": "UIControl.State.highlighted",
170
- "codeExample": "button.isHighlighted = true",
171
- "differences": [
172
- "Only available on iOS devices with pointer support",
173
- "Not triggered by touch interactions",
174
- "Maps to UIControl.State.highlighted property"
175
- ]
176
- },
177
- {
178
- "termId": "disabled",
179
- "platformTerm": "disabled",
180
- "platformAliases": ["isEnabled"],
181
- "notes": "iOS uses isEnabled property (inverted boolean)",
182
- "reference": "UIControl.isEnabled",
183
- "codeExample": "button.isEnabled = false",
184
- "differences": [
185
- "Property is named 'isEnabled' but inverted (false = disabled)",
186
- "Affects both visual appearance and interaction"
187
- ]
188
- }
189
- ]
190
- }
191
- ```
192
-
193
- ## Contributing Centralized Extensions
194
-
195
- ### 1. Fork and Clone
196
-
197
- ```bash
198
- git clone https://github.com/adobe/spectrum-design-data.git
199
- cd spectrum-design-data
200
- pnpm install
201
- ```
202
-
203
- ### 2. Create Extension File
204
-
205
- Create your extension file in `packages/design-system-registry/registry/platform-extensions/`.
206
-
207
- ### 3. Validate
208
-
209
- ```bash
210
- cd packages/design-system-registry
211
- pnpm validate
212
- ```
213
-
214
- ### 4. Test
215
-
216
- Ensure helper functions work with your extension:
217
-
218
- ```bash
219
- pnpm test
220
- ```
221
-
222
- ### 5. Create Changeset
223
-
224
- ```bash
225
- pnpm changeset
226
- ```
227
-
228
- Select `@adobe/design-system-registry` and describe your changes.
229
-
230
- ### 6. Submit Pull Request
231
-
232
- ```bash
233
- git checkout -b feat/add-{platform}-{registry}-extension
234
- git add .
235
- git commit -m "feat(registry): add {platform} extensions for {registry}"
236
- git push origin feat/add-{platform}-{registry}-extension
237
- ```
238
-
239
- Create a PR with:
240
-
241
- * Clear description of platform and what's being extended
242
- * Examples of how the extension improves platform consistency
243
- * Link to platform documentation
244
-
245
- ## Maintaining Platform Extensions
246
-
247
- ### Versioning
248
-
249
- * Extension files should evolve with the platform
250
- * Use `platformVersion` field to indicate compatibility
251
- * Breaking changes should be documented in commit messages
252
-
253
- ### Deprecation
254
-
255
- When platform APIs change:
256
-
257
- 1. Add new extension for the new API
258
- 2. Mark old extension term with deprecation note
259
- 3. Provide migration guidance in `differences` field
260
-
261
- Example:
262
-
263
- ```json
264
- {
265
- "termId": "hover",
266
- "platformTerm": "highlighted",
267
- "notes": "DEPRECATED: Use isPointerInteractionEnabled instead (iOS 18+)",
268
- "differences": [
269
- "Deprecated in iOS 18",
270
- "Replace with isPointerInteractionEnabled property"
271
- ]
272
- }
273
- ```
274
-
275
- ### Review Cycle
276
-
277
- Centralized extensions should be reviewed:
278
-
279
- * Annually for accuracy
280
- * When platform versions update
281
- * When base registry terms change
282
-
283
- ## Best Practices
284
-
285
- ### DO
286
-
287
- * ✅ Use official platform terminology
288
- * ✅ Link to official platform documentation
289
- * ✅ Provide code examples in platform's language
290
- * ✅ Document key differences from base term
291
- * ✅ Use platform naming conventions
292
-
293
- ### DON'T
294
-
295
- * ❌ Invent new terminology not used by platform
296
- * ❌ Duplicate information already in base term
297
- * ❌ Include deprecated APIs without notes
298
- * ❌ Skip validation before submitting
299
- * ❌ Mix multiple platforms in one extension file
300
-
301
- ## Questions?
302
-
303
- For questions or feedback:
304
-
305
- * Slack: #spectrum\_dna
306
- * GitHub: [Spectrum Design Data Issues](https://github.com/adobe/spectrum-design-data/issues)
307
- * Email platform leads for platform-specific questions
308
-
309
- ## Related Resources
310
-
311
- * [Design System Registry README](README.md)
312
- * [Authoring Guide](AUTHORING.md)
313
- * [Platform Extension Schema](schemas/platform-extension.json)
314
- * [Example: iOS States Extension](registry/platform-extensions/ios-states.json)
315
- * [Example: Web Components States Extension](registry/platform-extensions/web-components-states.json)
package/ava.config.js DELETED
@@ -1,21 +0,0 @@
1
- /*
2
- Copyright 2025 Adobe. All rights reserved.
3
- This file is licensed to you under the Apache License, Version 2.0 (the "License");
4
- you may not use this file except in compliance with the License. You may obtain a copy
5
- of the License at http://www.apache.org/licenses/LICENSE-2.0
6
-
7
- Unless required by applicable law or agreed to in writing, software distributed under
8
- the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
9
- OF ANY KIND, either express or implied. See the License for the specific language
10
- governing permissions and limitations under the License.
11
- */
12
-
13
- export default {
14
- files: ["test/**/*.test.js"],
15
- environmentVariables: {
16
- NODE_ENV: "test",
17
- },
18
- verbose: true,
19
- failFast: false,
20
- failWithoutAssertions: true,
21
- };
@@ -1,22 +0,0 @@
1
- {
2
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/registry-value.json",
3
- "type": "alignment",
4
- "description": "Horizontal text-alignment values for text-align tokens. Assigned via the `alignment` name-object field. Corresponds to the CSS text-align axis.",
5
- "values": [
6
- {
7
- "id": "start",
8
- "label": "Start",
9
- "description": "Align text to the inline-start edge"
10
- },
11
- {
12
- "id": "center",
13
- "label": "Center",
14
- "description": "Center text horizontally"
15
- },
16
- {
17
- "id": "end",
18
- "label": "End",
19
- "description": "Align text to the inline-end edge"
20
- }
21
- ]
22
- }