@mindvalley/design-system 4.0.1 → 4.1.1

package/docs/CONTRIBUTION.md

@@ -1,262 +0,0 @@
-## 🤝 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 following steps:
-
-```mermaid
-sequenceDiagram
-    participant Figma
-    participant Supernova
-    participant Tokens as src/tokens/brands
-    participant SD as style-dictionary build
-    participant JS as src/build/js & src/tailwind/plugins/tokens
-    participant Webpack
-    participant Dist as dist
-    participant NPM as Publish (NPM)
-
-    Figma->>Supernova: Designer publishes changes
-    Supernova->>Tokens: Supernova raises PR to update tokens
-    Tokens->>SD: style-dictionary parses & transforms
-    SD->>JS: Outputs JS modules (colors, typography)
-    JS->>Webpack: Bundling for distribution
-    Webpack->>Dist: Outputs bundled files
-    Dist->>NPM: CI publishes package
-```
-
-![token transformation](https://assets.mindvalley.com/api/v1/assets/7502f91d-8638-4940-a96f-a66386041a75.png)
-
-**1. The design tokens**  
-This is the starting point of the design token transformation process. When there are changes in the Figma design system (such as a color update), an automated workflow powered by Supernova detects these changes and creates a pull request in the repository to update the relevant token files in `src/tokens/brands/{brand}/` (e.g., `src/tokens/brands/mindvalley/colors.json`). This ensures that the tokens in the codebase stay in sync with the design system, reducing manual effort and the risk of inconsistencies.
-
-**2. Parsing and transformation**  
-Using [style-dictionary](https://styledictionary.com/getting-started/), the design tokens are parsed, merged, and transformed into the desired formats. The main outputs are JavaScript modules for colors and typography, but the output is configurable and can be extended to other formats (CSS, SCSS, etc.) in the future.  
-Run:  
-
-```bash
-npm run build:styledictionary
-```
-
-**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 the previous step are bundled and output to the `dist/` directory, which is not checked in for versioning.  
-Run:  
-
-```bash
-npm run build
-```
-
-**4. Publishing**  
-The last step is releasing and publishing the bundled files. This is automated and runs on CI, ensuring that changes are tested, versioned, and documented. Publishing is handled by [semantic release](https://semantic-release.gitbook.io/semantic-release/).  
-See more in the [release guide](RELEASING.md#releasing-🚀).
-
-#### 🗂 Directory structure
-
-Here is a simplified directory structure highlighting key areas for contributors:
-
-```bash
-├── LICENSE
-├── README.md
-├── __tests__
-├── babel.config.js
-├── build.ts
-├── dist/
-│   └── ...
-├── docs/
-│   ├── CONTRIBUTION.md
-│   ├── RELEASING.md
-│   └── USAGE.md
-├── package-lock.json
-├── package.json
-├── src/
-│   ├── assets/
-│   │   ├── brands/
-│   │   │   ├── mindvalley/
-│   │   │   │   └── icons/
-│   │   │   └── b2b/
-│   │   │       └── icons/
-│   │   ├── icons/
-│   │   └── wordmarks/
-│   ├── build/
-│   │   └── js/
-│   ├── helpers/
-│   ├── tailwind/
-│   │   └── plugins/
-│   │       └── tokens/
-│   ├── tokens/
-│   │   └── brands/
-│   │       ├── mindvalley/
-│   │       └── b2b/
-│   └── utilities/
-│       └── svg-import/
-│           ├── .figma_icons.js
-│           └── .figma_wordmarks.js
-├── webpack.config.js
-```
-
-#### Test Directory
-
-* All tests are under `__tests__/` (not `test/`).
-
-* Subfolders include `utilities/`, `src/tailwind/plugins/`, etc.
-
-#### Configuration Files
-
-* There is **no** root `config.json`.
-
-* Main configuration is in `build.ts`, `webpack.config.js`, and scripts in `package.json`.
-
-#### Important npm scripts
-
-* `build`: Runs both the style-dictionary build and webpack bundle.
-
-* `build:styledictionary`: Generates token outputs (see above for output locations).
-* `build:bundle`: Runs webpack for production.
-* `build:figma`: Runs both icon and wordmark export scripts.
-* `build:figma:icons`: Uses `src/utilities/svg-import/.figma_icons.js`.
-* `build:figma:wordmarks`: Uses `src/utilities/svg-import/.figma_wordmarks.js`.
-* `test`: Runs all tests with jest.
-* `commit`: Uses Commitizen CLI for conventional commits.
-
-#### ⌨️ Start development
-
-To get started with development, start by cloning the mv-design-system repo:
-
-```bash
-git clone git@github.com:mindvalley/mv-design-system.git
-```
-
-Change your current directory to the folder you just cloned and install the dependencies:
-
-```bash
-cd mv-design-system && npm install
-```
-
-###### 💡 Note
-
-This repo uses `npm` as the package manager.
-
-##### Making commits
-
-After making changes, stage your changes by issuing the standard `git add <filename>`, or however you stage your files.
-For commits, we leverage the power of conventional commits using [Commitizen](https://github.com/commitizen/cz-cli).
-
-**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
-```
-
-This will trigger a command line interface and all you have to do is answer the prompted questions which includes a Jira ticket ID number.
-
-![Commitizen prompt](https://assets.mindvalley.com/api/v1/assets/540d2b05-7953-4505-abfe-181c2a212566.png)
-
-If your branch name has a Jira ticket ID already included, then the prompt automatically extracts it.
-
-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.
-
-```bash
- type(scope): commit-message
-
- Jira-Issue-ID
-```
-
-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
-
-Here is an example commit message:
-
-```
-chore(asdf): Add .tool-versions file with current supported node version
-
-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.
-
-`MVHOME-765-branch-description-here`
-
-##### 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 build:styledictionary
-```
-
-This is the command that transforms our design tokens to the different desired formats we have defined.
-
-###### Bundle assets for release
-
-In the release step of the CI pipeline, we bundle the assets into a UMD module with the help of webpack to ensure that our package runs on both the server (Node.js) and the client side (browser).
-
-```bash
-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 update icons and wordmarks
-
-Icons and wordmarks are directly fetched from the respective Figma files where they are composed and updated by the designer.
-
-To update them, follow the steps below:
-
-1. Get your [Figma personal token](https://help.figma.com/hc/en-us/articles/8085703771159-Manage-personal-access-tokens)
-2. Clone the `.env.example` file on your root and rename it to `.env`
-3. Add your Figma token in the file `FIGMA_TOKEN=Y0urF1gM@T0k3n` and save the changes
-4. Then run `npm run build:figma`
-
-Running `npm run build:figma` triggers the workflows to fetch, generate sprites and generate documentation for sprites and wordmarks. `npm run build:figma` is an aggregate script that:
-
-1. Pulls and processes icons, using the script `npm run build:figma:icons`
-2. Pulls and processes wordmarks, using the script: `npm run build:figma:wordmarks`
-3. Clears the duplicate docs in the src/assets folder: `npm run clean:docs`
-
-Step 1 and 2 are run in parallel using the [npm-run-all](https://github.com/mysticatea/npm-run-all/blob/HEAD/docs/npm-run-all.md) package.
-
-The outputs go to `/src/assets/icons` for icons and `/src/assets/wordmarks` for wordmarks with additional generated markdown preview files added in `/docs/icons` and `/docs/wordmarks` directories respectively.
-
-Here is an image illustrating the process:
-
-![processing icons and wordmarks](processing-icons-wordmarks.png)
-
-If there is a newly added Figma page, remember to adjust the scripts with the new pages:
-
-* [wordmarks](../src/utilities/svg-import/.figma_wordmarks.js)
-* [Icons](../src/utilities/svg-import/.figma_icons.js)