@kroo-web/design-system 1.13.0 → 1.13.2
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/README.MD +66 -20
- package/dist/index.es.js +26523 -0
- package/dist/index.umd.js +221 -0
- package/package.json +5 -5
- package/dist/index.js +0 -148
package/README.MD
CHANGED
|
@@ -29,9 +29,10 @@ Next, add the following the highest up in your application, usually in the `App.
|
|
|
29
29
|
This adds the tokens used in the design system to the root of the application. (the css modules come prebundled in the build this step is only for the tokens and odd global styles included in the design system).
|
|
30
30
|
|
|
31
31
|
```jsx
|
|
32
|
-
import
|
|
33
|
-
|
|
34
|
-
import
|
|
32
|
+
import '@kroo-web/design-system/dist/styles/styles/global.css' <-- this is the tokens
|
|
33
|
+
|
|
34
|
+
import '@kroo-web/design-system/dist/styles/styles/style.css' <-- this is the css modules
|
|
35
|
+
|
|
35
36
|
```
|
|
36
37
|
|
|
37
38
|
That's all folks! You can now use the components in the design system in your application.
|
|
@@ -48,35 +49,80 @@ for setup you will need to add the `ToastContainer` component from `react-toasti
|
|
|
48
49
|
|
|
49
50
|
## Testing without deploying the package
|
|
50
51
|
|
|
51
|
-
If you would like to test the design system without deploying the package you can
|
|
52
|
+
If you would like to test the design system without deploying the package, you can use `npm pack` to create a local tarball of the package:
|
|
52
53
|
|
|
53
54
|
```bash
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
in the design system repo you will also have to run to use the react version from the repo where the design system is being used
|
|
58
|
-
|
|
59
|
-
```
|
|
60
|
-
npm link ../myproject/node_modules/react
|
|
61
|
-
npm link ../myproject/node_modules/react-dom
|
|
55
|
+
# In the design system repo
|
|
56
|
+
npm run build # Make sure to build the package first
|
|
57
|
+
npm pack # This creates a .tgz file
|
|
62
58
|
```
|
|
63
59
|
|
|
64
|
-
|
|
60
|
+
Then in your project where you want to use the design system, you can install the local package:
|
|
65
61
|
|
|
66
62
|
```bash
|
|
67
|
-
|
|
63
|
+
# In your project directory
|
|
64
|
+
npm install /path/to/design-system/kroo-web-design-system-1.0.0.tgz
|
|
68
65
|
```
|
|
69
66
|
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
<i>**Note**: Does not show up in the package.json it just replaces the node_modules package. this is so an unreleased version of the package cannot be deployed to prod (so after development make sure you npm install again to overwrite the local version of the package).</i>
|
|
67
|
+
The exact filename will depend on your package version. This method will properly update your package.json and is more reliable than using `npm link`.
|
|
73
68
|
|
|
69
|
+
To update the package after making changes:
|
|
70
|
+
1. Make your changes in the design system
|
|
71
|
+
2. Run `npm run build`
|
|
72
|
+
3. Run `npm pack` again
|
|
73
|
+
4. Reinstall the new .tgz file in your project
|
|
74
74
|
|
|
75
75
|
## Next Steps
|
|
76
76
|
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
77
|
+
Here are the key areas for improving and evolving the design system:
|
|
78
|
+
|
|
79
|
+
### 1. Token Management
|
|
80
|
+
- Create a separate `@kroo-web/tokens` package to manage design tokens independently
|
|
81
|
+
- Implement Token Studio integration with Figma for real-time token management
|
|
82
|
+
- Set up a CI/CD pipeline for automatic token updates from Figma to code
|
|
83
|
+
- Add support for theme switching (light/dark mode) using token sets
|
|
84
|
+
- Document token usage and naming conventions
|
|
85
|
+
|
|
86
|
+
### 2. Documentation Improvements
|
|
87
|
+
- Set up a documentation site using tools like Docusaurus or Storybook Docs
|
|
88
|
+
- Create comprehensive usage guidelines for each component
|
|
89
|
+
- Add accessibility documentation and WCAG compliance status
|
|
90
|
+
- Include interactive examples and code playgrounds
|
|
91
|
+
- Document component composition patterns and best practices
|
|
92
|
+
- Add visual regression testing documentation
|
|
93
|
+
|
|
94
|
+
### 3. Component Architecture
|
|
95
|
+
- Implement a more robust component composition system
|
|
96
|
+
- Add support for component variants using a consistent API
|
|
97
|
+
- Create higher-order components for common patterns
|
|
98
|
+
- Improve type definitions and prop documentation
|
|
99
|
+
- Add performance benchmarks for components
|
|
100
|
+
|
|
101
|
+
### 4. Testing and Quality
|
|
102
|
+
- Implement end-to-end testing using Cypress or Playwright
|
|
103
|
+
- Add visual regression testing with tools like Percy or Chromatic
|
|
104
|
+
- Improve unit test coverage
|
|
105
|
+
- Add accessibility testing using tools like axe-core
|
|
106
|
+
- Set up automated performance monitoring
|
|
107
|
+
|
|
108
|
+
### 5. Developer Experience
|
|
109
|
+
- Add better error messages and development-time warnings
|
|
110
|
+
- Create codemods for breaking changes
|
|
111
|
+
|
|
112
|
+
### 6. Design-Development Workflow
|
|
113
|
+
- Set up automated design token sync from Figma
|
|
114
|
+
- Implement a component request and review process
|
|
115
|
+
- Create a changelog automation system
|
|
116
|
+
- Add design system analytics to track component usage
|
|
117
|
+
- Establish a regular design system review process
|
|
118
|
+
|
|
119
|
+
### 7. Performance Optimization
|
|
120
|
+
- Add bundle size monitoring
|
|
121
|
+
- Optimize asset loading and delivery
|
|
122
|
+
|
|
123
|
+
## Automated Changelog
|
|
124
|
+
|
|
125
|
+
We use [Conventional Commits](https://www.conventionalcommits.org/) and [Release-Please](https://github.com/googleapis/release-please) to automate our changelog generation.
|
|
80
126
|
|
|
81
127
|
## Deployments of storybook
|
|
82
128
|
|