-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #26 from Mastercard/develop
CSS V2 & Design Tokens V2.2.0
- Loading branch information
Showing
443 changed files
with
83,526 additions
and
20,208 deletions.
There are no files selected for viewing
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| { | ||
| "prettier.tabWidth": 4, | ||
| "prettier.useTabs": true | ||
| } |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Code Review Checklist | ||
|
|
||
| * Are design tokens used? Ensure there are no hard coded values | ||
| * Are we following CSS Naming Conventions outlined here | ||
| * Are there existing styles that can reused? e.g. typography | ||
| * Does the code follow approved style guide? (Stylelint guidelines) | ||
| * No unnecessarily duplicated logic | ||
| * Code intent is clear upon initial reading | ||
| * Any code that isn't clear, but is needed, has an effective comment | ||
| * Commented code has been removed (comments themselves are fine). | ||
| * HTML5 tags are used where possible | ||
| * Title of MR matches Conventional Commits | ||
| * MR is checked and only intended changes are pushed. | ||
| * Commits messages are small and understandable. | ||
| * Code is tested on all supported browsers | ||
| * Code has on dev environment and tested. | ||
| * No conflicts in code. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| # Code Style | ||
|
|
||
| CSS guidelines/style guide ensures Made. can keep code as scalable, collaborative, maintainable and as flexible as possible. | ||
|
|
||
| * Follow Made. CSS naming conventions | ||
| * Use shorthand where possible. Using shorthand properties is useful for code efficiency and understandability. | ||
| * Avoid IDs in CSS - IDs are specificity heavyweights, and their use will throw our specificity completely out of joint. | ||
| * Avoid browser-specific hacks | ||
| * Avoid using !important to override styles | ||
| * Avoid using several attribute selectors (e.g., [class^="..."]) on commonly occurring components. Browser performance is known to be impacted by these. | ||
| * Don't target type selectors/tags e.g component, component ul li. Type selectors impact performance. Using selectors inhibits portability and reusability. | ||
| * Indentation one tab (4 spaces) | ||
| * Don't use negative margins. | ||
| * Keep specificity as low as possible so other styles are not overridden. | ||
| * Ideally, 80-characters wide lines; | ||
| * Keep classes as simple as possible so we can extend on them if needed. | ||
|
|
||
| **Rulesets** | ||
| Example CSS ruleset | ||
|
|
||
| ```css | ||
| [selector] { | ||
| [property]: [value]; | ||
| [<--declaration--->] | ||
| } | ||
| ``` | ||
|
|
||
| * a space before our opening brace ({); | ||
| * properties and values on the same line; | ||
| * a space after our property–value delimiting colon (:); | ||
| * each declaration on its own new line; | ||
| * the opening brace ({) on the same line as our last selector; | ||
| * our first declaration on a new line after our opening brace ({); | ||
| * our closing brace (}) on its own new line; | ||
| * each declaration indented by 2 spaces; | ||
| * a trailing semi-colon (;) on our last declaration. | ||
| * Put a blank line after ruleset | ||
|
|
||
| **Stylelint** | ||
|
|
||
| We use [Stylelint](https://stylelint.io/) to govern the styles above. See .stylelintrc.json. | ||
|
|
||
| To test your code against stylelint script run: | ||
|
|
||
| ``` | ||
| npm run stylelint:test | ||
| ``` | ||
| To fix any errors run: | ||
|
|
||
| ``` | ||
| npm run stylelint:fix | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,132 @@ | ||
| # Contributing | ||
|
|
||
| Made is always evolving – thanks to you. Every time you share local patterns, components, or documentation with us, you’re helping us to understand your needs. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| Before contributing to Made., you should make sure you have the following tools installed: | ||
|
|
||
| - Node.js: follow their installation through a [package manager here](https://nodejs.org/en/download/package-manager/) | ||
| - Git | ||
| - NPM | ||
| - Familiarise yourself with code standards and development workflow within Made. | ||
|
|
||
| You'll also need a code editor to make changes. There are many to choose from but some popular options are VSCode, Atom, and Sublime. | ||
|
|
||
| ### CSS Architecture | ||
|
|
||
| See [CSS Architecture](CSS-ARCHITECTURE.md) for more information. | ||
|
|
||
| ### Code Style Guide | ||
|
|
||
| See [Code Style](CODE-STYLE.md) for more information. | ||
|
|
||
| ### Naming Conventions | ||
|
|
||
| For more information on Made. CSS [Naming Conventions](CSS-NAMING-CONVENTIONS.md) | ||
|
|
||
| ### Branching | ||
|
|
||
| We use Git Flow to create branches. Read more about Git Flow here below: | ||
|
|
||
| * [Gitflow Workflow](https://confluence.mastercard.int/display/MAPI/Gitflow+Workflow). | ||
| * [Git Flow Cheat Sheet](https://danielkummer.github.io/git-flow-cheatsheet/) | ||
|
|
||
| ### Commit Rules | ||
| We follow [conventional commits'](https://www.conventionalcommits.org/en/v1.0.0/) specification. | ||
|
|
||
| Please follow the spec to have a successful commit. | ||
|
|
||
| ## Contribute | ||
|
|
||
| ### Propose an update or new feature | ||
|
|
||
| Whether you’re proposing an update, a new feature or simply making something better, we welcome contribution. | ||
|
|
||
| Simply open an issue and provide the following information: | ||
|
|
||
| - A brief description of the update you want to propose. | ||
| - Clarify whether it’s a variation of an existing token, format or a new theme | ||
| - Include mockups of any fidelity (optional) | ||
| - Include any inspirations from other products (optional) | ||
| - Once your request is raised, we’ll review and set up a meeting to discuss the proposal in greater detail. | ||
|
|
||
| We’ll cover the following: | ||
|
|
||
| - What exactly needs working on | ||
| - How much you’d like to contribute | ||
| - Support needed to get the job done | ||
| - Suitable timings that work for you | ||
| - If your work meets our contribution criteria, your request will be added to our backlog and marked as 'To do'. At this stage, you can either start contribution or leave it for a member of the Made production team to pick up. | ||
|
|
||
| ### Submit a Pull Request | ||
|
|
||
| Good pull requests - patches, improvements, new features - are a fantastic help, before starting please open a new issue as documented above for whatever you are adding. That way, we can also offer suggestions or let you know if there is already an effort in progress. | ||
|
|
||
| With that all in place, you're ready to start contributing to Made.! | ||
|
|
||
| **Fork this repo** | ||
| Click the Fork button in the top-right corner. This will create a copy repo of Made. Design Tokens to your account. | ||
|
|
||
| **Clone your fork** | ||
| [You can clone a repository by using the command line](https://docs.gitlab.com/ee/gitlab-basics/start-using-git.html#clone-a-repository) | ||
|
|
||
| ``` | ||
| # Clone your fork of the repo into the current directory | ||
| git clone http://labs.mastercard.com/gitlab8/<your-username>/made-design-tokens.git | ||
| # Navigate to the newly cloned directory | ||
| cd made-design-tokens | ||
| # Assign the original repo to a remote called "upstream" | ||
| git remote add upstream http://labs.mastercard.com/gitlab8/made-design-tokens.git | ||
| # Verify the remote was added | ||
| git remote -v | ||
| ``` | ||
|
|
||
| **Make sure you have the latest changes** | ||
|
|
||
| ``` | ||
| git checkout master | ||
| git pull upstream master | ||
| ``` | ||
|
|
||
| **Work on a feature branch** | ||
| When contributing to Made., your work should always be done in a branch off of your repo, this is also how you will submit your pull request when your work is done. To create a new branch, ensure you are in your forked branch in your terminal and run: | ||
|
|
||
| ``` | ||
| git checkout -b feature/your-branch-name | ||
| ``` | ||
|
|
||
| **Make the Change** | ||
|
|
||
| 1. Modify CSS in src folder | ||
| 2. If adding a new component add to `src/04-components/components.css` | ||
| 3. Run `npm run stylelint:test` to test code and `npm run stylelint:fix`to fix code to comply with Stylelint config. | ||
| 4. Run `npm run build` to ensure the build is running correctly | ||
| 5. Review [Code Checklist](CODE-CHECKLIST.md) before submitting MR. | ||
|
|
||
| **Commit Changes** | ||
| When the changes are done, add all changes | ||
|
|
||
| `git add .` | ||
|
|
||
| Commit the changes using conventional commits convention. | ||
|
|
||
| ```git commit -m "refactor - Issue 30: Update surface styles to use latest b2b styles"``` | ||
|
|
||
| Push the changes to Gitlabs | ||
|
|
||
| ```git push``` | ||
|
|
||
| **Open a new Merge Request** | ||
|
|
||
| When the branch has been pushed. Create a merge request for another developer to review your code. | ||
|
|
||
| See documentation on [Gitlabs create merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) for more information. | ||
|
|
||
| - Click on the Merge Request tab on the left hand side. | ||
| - Click the new merge request button | ||
| - Choose the branch you pushed and request to merge into master. Click merge branch and continue | ||
| - Add title (use conventional commit naming convention) and description of changes made. Assign the MR to a Made. developer for a code review and click Submit. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| Copyright (c) 2022 Mastercard | ||
|
|
||
| Licensed under the Apache License, Version 2.0 (the "License"); | ||
| you may not use this file except in compliance with the License. | ||
| You may obtain a copy of the License at | ||
|
|
||
| http://www.apache.org/licenses/LICENSE-2.0 | ||
|
|
||
| Unless required by applicable law or agreed to in writing, software | ||
| distributed under the License is distributed on an "AS IS" BASIS, | ||
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| See the License for the specific language governing permissions and | ||
| limitations under the License. |
Oops, something went wrong.