@mindvalley/design-system 1.3.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/RELEASING.md

@@ -12,6 +12,7 @@ By default, semantic-release uses the [Angular Commit Message Conventions](https
 Only the above type of commits will trigger a release.
 
 On merging to the main branch, several things will happen:
+
 1. Semantic release will start by analyzing the commit messages of the merged changes based on the commit messages.
 2. Determine what kind of release it is based on the table above.
 3. Generate a changelog for the new changes and generate the new package version number.
@@ -24,7 +25,23 @@ After release and publishing, the package should be available as a [scoped npm p
 
 Jump to the [usage guide](USAGE.md) to understand how to use the published package in your repo.
 
-##### 💡 Note:
+##### 💡 Note
+
 The above steps should all happen with no human intervention.
 However, for now, the steps 1 - 5 do happen on the CI/CD pipeline, but due to some issues with GitHub permissions, the automation has errors on steps 4 and 5, which means the release, semantic versioning, and npm publishing does not work automatically.
-For that reason, the releases will be manual for the time being, as the permissions get settled with the Infra Team.
+For that reason, the releases will be manual for the time being, as the permissions get settled with the Infra Team. Below is a guide on how to do a manual release from your development environment.
+
+#### Manual release (Release from developer's machine)
+
+A manual release needs is done from the main branch after the branch to be released has been merged into the orign/main branch. The following commands should be executed.
+
+1. We start off by deleting the `dist` folder: In CI environment, we do not need to do this since the
+   src folder is not present when the code is checked out on the CI environment: `npm run clean:dist`
+2. We run our tests: `npm run test`
+3. Then we build our tokens using style dictonary: This deletes the `src/build` directory and regenerates the files: `npm run styledictonary:build`
+4. And then we bundle all packages using webpack: `npm run build`
+5. And eventually use [np](https://www.npmjs.com/package/np) to bundle and publish the packages. Np does all the check for us and ensures we bundle and package our files properly. `npm run publish:dev`
+   This step triggers an interactive guided shell that when followed should lead to a smooth package release.
+
+Following these steps is crucial. For that reason, there is an additional one liner script that executes the steps in order to ensure the same output every time.
+Command: `npm run release:manual`

package/docs/USAGE.md

@@ -1,25 +1,27 @@
 ## Installation
 
 #### Using npm or yarn
+
 We recommend using either npm or yarn to install, as per your own preference.
 
 ```
-$ npm install @mindvalley/design-system
+npm install @mindvalley/design-system
 ```
 
 ```
-$ yarn add @mindvalley/design-system
+yarn add @mindvalley/design-system
 ```
 
-
 ## Usage
 
 ###### *ES module syntax*
+
 ```
   import { colors } from '@mindvalley/design-system'
 ```
 
- ###### *commonJS syntax*
+###### *commonJS syntax*
+
 ```
   const { colors } = require('@mindvalley/design-system')
 ```
@@ -29,12 +31,14 @@ $ yarn add @mindvalley/design-system
 To use the colors from the design system there are two options.
 
 ###### 1. TailwindCSS
+
 If you use TailwindCSS in your project, using the colors is a simple two-step process:
 
 1. Install the design system. See [installation](#using-npm-or-yarn).
 2. Use the [commonJS syntax](#commonjs-syntax) to include the colors and extend your `tailwind.config.js`.
 
 *Example tailwind.config.js*
+
 ```JavaScript
   const { colors } = require('@mindvalley/design-system')
 
@@ -47,14 +51,33 @@ 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`
+* Orange Wave: `from-orange-500 to-orange-600`
+* Yellow wave: `from-yellow-400 to-yellow-500`
+* Blue Wave: `from-blue-600 to-blue-700`
+* Grey wave (150 - white): `from-cool-grey-150 to-white`
+* Gray wave (600 - 700): `from-cool-gray-600 to-cool-gray-700`
+
+Example use:
+`<div class="bg-gradient-to-b from-brand-accent to-purple-600 ..."></div>`
+
+Will give you purple wave gradient.
+
 ##### 💡 Note
+
 If you'd like other custom names, you can make [tailwindcss color customizations](https://tailwindcss.com/docs/customizing-colors#using-the-default-colors) to the provided values and use them in your code.
 
 ###### 2. Using CSS-in-JS
+
 1. Install the design system. See [installation](#using-npm-or-yarn).
 2. Use the [ES module](#es-module-syntax) syntax to import your module and include it in your code.
 
-*Sample usage in a react app*
+ *Sample usage in a react app*
+
 ```Javascript
   import React from 'react'
   import { color } from '@mindvalley/design-system'