@mindvalley/design-system 2.0.0 → 2.1.0

package/docs/CONTRIBUTION.md

@@ -1,17 +1,22 @@
 ## 🤝 Contributing [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
+
 Before you get your hands dirty, let's first understand how the repo works and its structure. We are going to look at:
+
 * What happens in the repo and its inputs and outputs: Jump to [Token transformation](#-token-transformation-process)
 * How the repo is structured and its core parts: See [Directory structure](#-directory-structure)
 
 #### 🏭 Token transformation process
+
 Token transformation on a high level involves the four steps illustrated below:
 
 ![token transformation](https://assets.mindvalley.com/api/v1/assets/7502f91d-8638-4940-a96f-a66386041a75.png)
 
-##### 1. The design tokens:
+##### 1. The design tokens
+
 This is the starting point of the design token transformation process. This step is how the design tokens get into the repo. For example, If there are changes in the Figma design system to the value of a color, then this would be where we would need to update the token.  For simplicity, it is just a directory with some design tokens in a JSON file. More details in the [`src/properties`](#srcproperties) directory documentation.
 
-##### 2. Parsing and transformation:
+##### 2. Parsing and transformation
+
 Using [style-dictonary](https://amzn.github.io/style-dictionary/#/version_3), the design tokens from (1) above are parsed, merged, and transformed into desired formats. The output is a `.js` file. The output is configurable and can be extented to `.css`, `.scss`, `.less` files etc. in the future. See [all possible output file formats](https://amzn.github.io/style-dictionary/#/formats).
 The output of this step ends up in the [`src/build/`](#srcbuild) directory.
 Parsing and transformation can be triggered by running:
@@ -20,7 +25,8 @@ Parsing and transformation can be triggered by running:
 npm run styledictonary:build
 ```
 
-##### 3. Bundling:
+##### 3. Bundling
+
 Bundling is done using [webpack](https://webpack.js.org/concepts) to ensure the resultant files work across browser and server environments. The files from step 2 are bundled and output to the [/dist](#dist) directory.
 Bundling can be invoked by running:
 
@@ -28,11 +34,13 @@ Bundling can be invoked by running:
 npm run build
 ```
 
-##### 4. Publishing:
+##### 4. Publishing
+
 The last in the process is releasing and publishing the bundled files. This step is automated and runs on CI, ensuring that changes made are tested, versioned, and comprehensively documented.  All this is done with the help of [semantic release](https://semantic-release.gitbook.io/semantic-release/). Read more about the [release process](RELEASING.md#releasing-🚀).
  The end package is published to NPM where it can be installed from.
 
 #### 🗂 Directory structure
+
 Let's look at some important directories.
 
 ```shell
@@ -66,36 +74,46 @@ Let's look at some important directories.
 └── webpack.config.js
 
 ```
+
 ###### src/properties/
+
 This is the source of the design tokens. For now, we have the tokens checked in as JSON files.
 The process of updating the payload is manual, implying that when there are changes in the tokens, one must get the updated token from the [figma colors file](https://www.figma.com/file/Gmdp0kAAYsmBgCthFjGkpY/MV-Core?node-id=6437%3A207257) and update the files in this directory.
 
 *Yes, it's a manual step for now, automation will follow later.*
 
 ###### src/build/
+
 This is the output of the design token transformation process. **DO NOT** manually edit the contents of this folder as they are the output of running the [bundling step](#3-bundling).
 
 ###### src/utilities
+
 Holds the custom [transformations](https://amzn.github.io/style-dictionary/#/transforms) and [transformation groups](https://amzn.github.io/style-dictionary/#/transform_groups) which in a nutshell, are how we transform the json files in the `src/properties/` directory into the desired output file format in the `src/build/` directory.
 
 ###### dist
+
 It's the output directory of the Webpack build process and is not checked in for versioning.
 
 ###### test
+
 For tests, because code that cannot be tested is flawed. 🤷🏽‍♂️
 
 #### ⌨️ Start development
+
 To get started with development, start by cloning the mv-design-system repo.
+
 ```
 git clone git@github.com:mindvalley/mv-design-system.git
 ```
 
 Change your current directory to the folder you just cloned and install the dependencies.
+
 ```
 cd mv-design-system && npm install
 ```
 
 ###### 💡 Note
+
 This repo uses `npm` as the package manager
 
 ##### Making commits
@@ -106,6 +124,7 @@ For commits, we leverage the power of conventional commits using [Commitizen](ht
 **Why use conventional commits?** To enable automation of releases, semantic versioning, and release notes auto-generation.
 
 To make a commit, run the command below:
+
 ```
 npm run commit
 ```
@@ -118,6 +137,7 @@ If your branch name has a Jira ticket ID already included, then the prompt autom
 
 Though using `npm run commit` is highly recommended for this repo, you can alternatively write your commit without the Commitizen helper by ensuring you
 follow the conventional commits conventions.
+
 ```
  type(scope): commit-message
 
@@ -125,20 +145,21 @@ follow the conventional commits conventions.
 ```
 
 The commit type has to be one of:
-  - `feat`:     A new feature
-  - `fix`:      A bug fix
-  - `docs`:     Documentation only changes
-  - `style`:    Changes that do not affect the meaning of the code (white-space, - formatting, missing semi-colons, etc)
-  - `refactor`: A code change that neither fixes a bug nor adds a feature
-  - `perf`:     A code change that improves performance
-  - `test`:     Adding missing tests or correcting existing tests
-  - `build`:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
-  - `ci`:       Changes to our CI configuration files and scripts (example - scopes: Travis, Circle, BrowserStack, SauceLabs)
-  - `chore`:    Other changes that don't modify src or test files
-  - `revert`:   Reverts a previous commit
 
+* `feat`:     A new feature
+* `fix`:      A bug fix
+* `docs`:     Documentation only changes
+* `style`:    Changes that do not affect the meaning of the code (white-space, - formatting, missing semi-colons, etc)
+* `refactor`: A code change that neither fixes a bug nor adds a feature
+* `perf`:     A code change that improves performance
+* `test`:     Adding missing tests or correcting existing tests
+* `build`:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+* `ci`:       Changes to our CI configuration files and scripts (example - scopes: Travis, Circle, BrowserStack, SauceLabs)
+* `chore`:    Other changes that don't modify src or test files
+* `revert`:   Reverts a previous commit
 
 Here is an example commit message:
+
 ```
 chore(asdf): Add .tool-versions file with current supported node version
 
@@ -148,6 +169,7 @@ MVHOME-765
 Once your commits are done, you can do a normal push to remote.
 
 Read more on [commit conventions](https://www.conventionalcommits.org/en/v1.0.0-beta.4/).
+
 ##### Branch naming
 
 Branch names start with the Jira ticket ID eg.
@@ -157,19 +179,25 @@ Branch names start with the Jira ticket ID eg.
 ##### Important commands
 
 ###### Tests
+
 To run all the tests:
+
 ```
 npm run test
 ```
+
 ###### Transform design tokens
+
 Whenever there are changes that affect our design tokens, we need to regenerate the build assets using the command below and commit the results:
 
 ```
 npm run styledictonary:build
 ```
+
 This is the command that tranforms our design tokens to the different desired formats we have defined.
 
 ######
+
 In the release step of the CI pipline, we bundle the assets into a umd module with the help of webpack to ensure that our package runs on both the server(nodejs) and the client side(browser).
 
 ```
@@ -179,3 +207,10 @@ npm run build
 You can test it out on your development environment to see the output.
 
 Once your changes are made and merged, they'll need to be published. See how that is done in the [release guide](RELEASING.md#releasing-🚀).
+
+# How to generate icons from figma to code?
+1. Export all the icons from figma file to `Export` folder
+2. Launch terminal in the same folder.
+3. Run `npx svgo -f ./Export -o ./output` to generate compressed icons 
+4. Run `npx svg-sprite --symbol --symbol-render-css --symbol-example --dest=sprite/ output/*.svg` to convert exported icons to sprite
+5. Replace all white and black `fill="#fff"` & `fill="#000"` colors with `fill="currentColor"`

package/docs/USAGE.md

@@ -51,6 +51,8 @@ If you use TailwindCSS in your project, using the colors is a simple two-step pr
   }
 ```
 
+##### Gradients
+
 For gradient you can use the following tailwindCSS gradients:
 
 * Purple wave: `from-brand-accent to-purple-600`