├── .github ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE │ └── bug_report.md ├── PULL_REQUEST_TEMPLATE.md └── workflows │ └── deploy-gh-pages.yml ├── .gitignore ├── .vuepress ├── config.js ├── public │ ├── analyzer.png │ ├── android-chrome-192x192.png │ ├── android-chrome-512x512.png │ ├── apple-touch-icon.png │ ├── architecture.jpg │ ├── favicon-16x16.png │ ├── favicon-32x32.png │ ├── favicon.ico │ ├── logo.png │ ├── manifest.json │ └── v5 │ │ ├── new-rest-api.gif │ │ ├── vue-box.png │ │ ├── vue-columns.png │ │ ├── vue-inline.png │ │ └── vue-stack.png └── styles │ ├── index.styl │ └── palette.styl ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── en ├── README.md ├── v4 │ ├── FAQ.md │ ├── README.md │ ├── deep_dives │ │ ├── build.md │ │ ├── design-system.md │ │ ├── i18n.md │ │ ├── npm-scripts.md │ │ ├── update.md │ │ └── vuex.md │ ├── guide │ │ ├── clean-up.md │ │ ├── cli.md │ │ ├── contribute.md │ │ ├── install.md │ │ ├── run.md │ │ └── test.md │ └── introduction.md └── v5 │ ├── README.md │ ├── guide │ ├── community-and-support.md │ ├── concepts.md │ ├── design-system.md │ ├── development.md │ ├── getting-started.md │ └── introduction.md │ └── tutorials │ ├── i18n.md │ ├── layout-components.md │ └── theming.md ├── package-lock.json └── package.json /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | We would love for you to contribute and help make it even better 4 | than it is today! As a contributor, here are the guidelines we would like you 5 | to follow: 6 | 7 | - [Question or Problem?](#question) 8 | - [Issues and Bugs](#issue) 9 | - [Feature Requests](#feature) 10 | - [Submission Guidelines](#submit) 11 | - [Coding Rules](#rules) 12 | - [Commit Message Guidelines](#commit) 13 | 14 | ## Got a Question or Problem? 15 | 16 | Please, do not open issues for the general support questions as we want to keep GitHub issues for bug reports and feature requests. 17 | 18 | ## Found an Issue? 19 | 20 | If you find a bug in the source code or a mistake in the documentation, you can help us by 21 | [submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can 22 | [submit a Pull Request](#submit-pr) with a fix. 23 | 24 | ## Want a Feature? 25 | 26 | You can _request_ a new feature by [submitting an issue](#submit-issue) to our [GitHub 27 | Repository][github]. If you would like to _implement_ a new feature, please submit an issue with 28 | a proposal for your work first, to be sure that we can use it. 29 | 30 | First open an issue and outline your proposal so that it can be 31 | discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, 32 | and help you to craft the change so that it is successfully accepted into the project. 33 | 34 | **All features require a proper design and review by team members and product owners.** Before starting work, you might want to 35 | discuss with us to figure out: 36 | 37 | - Is this something we want? 38 | - What's the impact? 39 | 40 | Answering those questions first in the request might help us make a decision. 41 | 42 | ## Submission Guidelines 43 | 44 | ### Submitting an Issue 45 | 46 | Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you. 47 | 48 | We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. Having a reproducible 49 | scenario gives us wealth of important information without going back & forth to you with additional questions. 50 | 51 | You can file new issues by filling out our [new issue form](https://github.com/vuesion/packages/issues/new). 52 | 53 | ### Submitting a Pull Request (PR) 54 | 55 | Before you submit your Pull Request (PR) consider the following guidelines: 56 | 57 | - Search [GitHub](https://github.com/vuesion/packages/pulls) for an open or closed PR 58 | that relates to your submission. You don't want to duplicate effort. 59 | - Make your changes in a new git branch: 60 | 61 | ```shell 62 | git checkout -b my-fix-branch 63 | ``` 64 | 65 | - Create your patch, **including appropriate test cases**. 66 | - Run the full test suite, 67 | and ensure that all tests pass. 68 | - Commit your changes using a descriptive commit message that follows our 69 | [commit message conventions](#commit). Adherence to these conventions 70 | is necessary because release notes are automatically generated from these messages. 71 | 72 | ```shell 73 | git commit -a 74 | ``` 75 | 76 | Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files. 77 | 78 | - Push your branch to GitHub: 79 | 80 | ```shell 81 | git push origin my-fix-branch 82 | ``` 83 | 84 | - In GitHub, send a pull request to `packages:master`. 85 | - If we suggest changes then: 86 | 87 | - Make the required updates. 88 | - Re-run the test suites to ensure tests are still passing. 89 | - Rebase your branch and force push to your GitHub repository (this will update your Pull Request): 90 | 91 | ```shell 92 | git rebase -i 93 | git push -f 94 | ``` 95 | 96 | That's it! Thank you for your contribution! 97 | 98 | #### After your pull request is merged 99 | 100 | After your pull request is merged, you can safely delete your branch and pull the changes 101 | from the main (upstream) repository: 102 | 103 | - Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: 104 | 105 | ```shell 106 | git push origin --delete my-fix-branch 107 | ``` 108 | 109 | - Check out the master branch: 110 | 111 | ```shell 112 | git checkout master -f 113 | ``` 114 | 115 | - Delete the local branch: 116 | 117 | ```shell 118 | git branch -D my-fix-branch 119 | ``` 120 | 121 | - Update your master branch with the latest upstream version: 122 | 123 | ```shell 124 | git pull --ff upstream master 125 | ``` 126 | 127 | ## Coding Rules 128 | 129 | To ensure consistency throughout the source code, keep these rules in mind as you are working: 130 | 131 | - All features or bug fixes **must be tested** by one or more specs (unit-tests or e2e-tests). 132 | 133 | ## Commit Message Guidelines 134 | 135 | We have very precise rules over how our git commit messages can be formatted. This leads to **more 136 | readable messages** that are easy to follow when looking through the **project history**. But also, 137 | we use the git commit messages to **generate the change log**. 138 | 139 | ### Commit Message Format 140 | 141 | Each commit message consists of a **header**, a **body** and a **footer**. The header has a special 142 | format that includes a **type**, a **scope** and a **subject**: 143 | 144 | ``` 145 | (): 146 | 147 | 148 | 149 |