--- /dev/null
+## Git Commit Message Convention
+
+> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
+
+#### TL;DR:
+
+Messages must be matched by the following regex:
+
+```text
+/^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,50}/
+```
+
+#### Examples
+
+Appears under "Features" header, `compiler` subheader:
+
+```
+feat(compiler): add 'comments' option
+```
+
+Appears under "Bug Fixes" header, `v-model` subheader, with a link to issue #28:
+
+```
+fix(v-model): handle events on blur
+
+close #28
+```
+
+Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:
+
+```
+perf(core): improve vdom diffing by removing 'foo' option
+
+BREAKING CHANGE: The 'foo' option has been removed.
+```
+
+The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header.
+
+```
+revert: feat(compiler): add 'comments' option
+
+This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
+```
+
+### Full Message Format
+
+A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+### Revert
+
+If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body, it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+
+### Type
+
+If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However, if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.
+
+Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks.
+
+### Scope
+
+The scope could be anything specifying the place of the commit change. For example `core`, `compiler`, `ssr`, `v-model`, `transition` etc...
+
+### Subject
+
+The subject contains a succinct description of the change:
+
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize the first letter
+- no dot (.) at the end
+
+### Body
+
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
+The body should include the motivation for the change and contrast this with previous behavior.
+
+### Footer
+
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
--- /dev/null
+# Vue.js Contributing Guide
+
+Hi! I'm really excited that you are interested in contributing to Vue.js. Before submitting your contribution, please make sure to take a moment and read through the following guidelines:
+
+- [Code of Conduct](https://github.com/vuejs/vue/blob/dev/.github/CODE_OF_CONDUCT.md)
+- [Issue Reporting Guidelines](#issue-reporting-guidelines)
+- [Pull Request Guidelines](#pull-request-guidelines)
+- [Development Setup](#development-setup)
+- [Project Structure](#project-structure)
+- [Contributing Tests](#contributing-tests)
+- [Financial Contribution](#financial-contribution)
+
+## Issue Reporting Guidelines
+
+- Always use [https://new-issue.vuejs.org/](https://new-issue.vuejs.org/) to create new issues.
+
+## Pull Request Guidelines
+
+- Checkout a topic branch from a base branch, e.g. `master`, and merge back against that branch.
+
+- If adding a new feature:
+
+ - Add accompanying test case.
+ - Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
+
+- If fixing bug:
+
+ - If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
+ - Provide a detailed description of the bug in the PR. Live demo preferred.
+ - Add appropriate test coverage if applicable. You can check the coverage of your code addition by running `yarn test --coverage`.
+
+- It's OK to have multiple small commits as you work on the PR - GitHub can automatically squash them before merging.
+
+- Make sure tests pass!
+
+- Commit messages must follow the [commit message convention](./commit-convention.md) so that changelogs can be automatically generated. Commit messages are automatically validated before commit (by invoking [Git Hooks](https://git-scm.com/docs/githooks) via [yorkie](https://github.com/yyx990803/yorkie)).
+
+- No need to worry about code style as long as you have installed the dev dependencies - modified files are automatically formatted with Prettier on commit (by invoking [Git Hooks](https://git-scm.com/docs/githooks) via [yorkie](https://github.com/yyx990803/yorkie)).
+
+## Development Setup
+
+You will need [Node.js](http://nodejs.org) **version 10+**, and [Yarn](https://classic.yarnpkg.com/en/docs/install).
+
+After cloning the repo, run:
+
+```bash
+$ yarn # install the dependencies of the project
+```
+
+A high level overview of tools used:
+
+- [TypeScript](https://www.typescriptlang.org/) as the development language
+- [Rollup](https://rollupjs.org) for bundling
+- [Jest](https://jestjs.io/) for unit testing
+- [Prettier](https://prettier.io/) for code formatting
+
+## Scripts
+
+### `yarn build`
+
+The `build` script builds vue-router
+
+### `yarn dev`
+
+The `dev` scripts starts a playground project located at `playground/` that allows you to test things on a browser.
+
+```bash
+$ yarn dev
+```
+
+### `yarn test`
+
+The `yarn test` script runs all checks:
+
+- _Typings_: `test:types`
+- _Linting_: `test:lint`
+- _Unit tests_: `test:unit`
+- _Building_: `build`
+
+```bash
+# run all tests
+$ yarn test
+
+# run unit tests in watch mode
+$ yarn jest --watch
+```
+
+## Project Structure
+
+This repository employs a [monorepo](https://en.wikipedia.org/wiki/Monorepo) setup which hosts a number of associated packages under the `packages` directory:
+
+- `reactivity`: The reactivity system. It can be used standalone as a framework-agnostic package.
+
+- `runtime-core`: The platform-agnostic runtime core. Includes code for the virtual dom renderer, component implementation and JavaScript APIs. Higher-order runtimes (i.e. custom renderers) targeting specific platforms can be created using this package.
+
+- `runtime-dom`: The runtime targeting the browser. Includes handling of native DOM API, attributes, properties, event handlers etc.
+
+- `runtime-test`: The lightweight runtime for testing. Can be used in any JavaScript environment since it "renders" a tree of plain JavaScript objects. The tree can be used to assert correct render output. Also provides utilities for serializing the tree, triggering events, and recording actual node operations performed during an update.
+
+- `server-renderer`: Package for server-side rendering.
+
+- `compiler-core`: The platform-agnostic compiler core. Includes the extensible base of the compiler and all platform-agnostic plugins.
+
+- `compiler-dom`: Compiler with additional plugins specifically targeting the browser.
+
+- `template-explorer`: A development tool for debugging compiler output. You can run `yarn dev template-explorer` and open its `index.html` to get a repl of template compilation based on current source code.
+
+ A [live version](https://vue-next-template-explorer.netlify.com) of the template explorer is also available, which can be used for providing reproductions for compiler bugs. You can also pick the deployment for a specific commit from the [deploy logs](https://app.netlify.com/sites/vue-next-template-explorer/deploys).
+
+- `shared`: **Private.** Platform-agnostic internal utilities shared across multiple packages. This package is private and not published.
+
+- `vue`: The public facing "full build" which includes both the runtime AND the compiler.
+
+### Importing Packages
+
+The packages can import each other directly using their package names. Note that when importing a package, the name listed in its `package.json` should be used. Most of the time the `@vue/` prefix is needed:
+
+```js
+import { h } from '@vue/runtime-core'
+```
+
+This is made possible via several configurations:
+
+- For TypeScript, `compilerOptions.path` in `tsconfig.json`
+- For Jest, `moduleNameMapper` in `jest.config.js`
+- For plain Node.js, they are linked using [Yarn Workspaces](https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/).
+
+### Package Dependencies
+
+```
+
+ +---------------------+
+ | |
+ | @vue/compiler-sfc |
+ | |
+ +-----+--------+------+
+ | |
+ v v
+ +---------------------+ +----------------------+
+ | | | |
+ +------------>| @vue/compiler-dom +--->| @vue/compiler-core |
+ | | | | |
+ +----+----+ +---------------------+ +----------------------+
+ | |
+ | vue |
+ | |
+ +----+----+ +---------------------+ +----------------------+ +-------------------+
+ | | | | | | |
+ +------------>| @vue/runtime-dom +--->| @vue/runtime-core +--->| @vue/reactivity |
+ | | | | | |
+ +---------------------+ +----------------------+ +-------------------+
+```
+
+There are some rules to follow when importing across package boundaries:
+
+- Never use direct relative paths when importing items from another package - export it in the source package and import it at the package level.
+
+- Compiler packages should not import items from the runtime, and vice versa. If something needs to be shared between the compiler-side and runtime-side, it should be extracted into `@vue/shared` instead.
+
+- If a package (A) has a non-type import from another package (B), package (B) should be listed as a dependency in the `package.json` of package (A). This is because the packages are externalized in the ESM-bundler/CJS builds and type declaration files, so the dependency packages must be actually installed as a dependency when consumed from package registries.
+
+## Contributing Tests
+
+Unit tests are located inside `__tests__`. Consult the [Jest docs](https://jestjs.io/docs/en/using-matchers) and existing test cases for how to write new test specs. Here are some additional guidelines:
+
+- Use the minimal API needed for a test case. For example, if a test can be written without involving the reactivity system or a component, it should be written so. This limits the test's exposure to changes in unrelated parts and makes it more stable.
+- Use the minimal API needed for a test case. For example, if a test concerns the `router-link` component, don't create a router instance, mock the needed properties instead.
+
+- If a test is specific to a browser, make sure to indicate it on the test. TODO: example
+
+## Credits
+
+Thank you to all the people who have already contributed to Vue.js!
+
+<a href="https://github.com/vuejs/vue/graphs/contributors"><img src="https://opencollective.com/vuejs/contributors.svg?width=890" /></a>
projects / thirdparty / vuejs / router.git / commitdiff
