You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!-- Please insert your description here and provide especially info about the "what" this PR is solving -->
6
+
7
+
### Additional context
8
+
9
+
<!-- e.g. is there anything you'd like reviewers to focus on? -->
10
+
11
+
---
12
+
13
+
### What is the purpose of this pull request? <!-- (put an "X" next to an item) -->
14
+
15
+
-[ ] Bug fix
16
+
-[ ] New Feature
17
+
-[ ] Documentation update
18
+
-[ ] Other
19
+
20
+
### Before submitting the PR, please make sure you do the following
21
+
22
+
-[ ] Read the [Contributing Guidelines](https://devtools.vuejs.org/guide/contributing.html).
23
+
-[ ] Read the [Pull Request Guidelines](https://devtools.vuejs.org/guide/contributing.html#pull-request-guidelines) and follow the [Commit Convention](https://github.com/vuejs/devtools/blob/main/.github/commit-convention.md).
24
+
-[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
25
+
-[ ] Provide a description in this PR that addresses **what** the PR is solving, or reference the issue that it solves (e.g. `fixes #123`).
26
+
<!-- @TODO tests - [ ] Ideally, include relevant tests that fail without this PR but pass with it. -->
> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
Appears under "Bug Fixes" header, `dev` subheader, with a link to issue #28:
23
+
24
+
```
25
+
fix(dev): fix dev error
26
+
27
+
close #28
28
+
```
29
+
30
+
Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:
31
+
32
+
```
33
+
perf(build): remove 'foo' option
34
+
35
+
BREAKING CHANGE: The 'foo' option has been removed.
36
+
```
37
+
38
+
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.
39
+
40
+
```
41
+
revert: feat(compiler): add 'comments' option
42
+
43
+
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
44
+
```
45
+
46
+
### Full Message Format
47
+
48
+
A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
49
+
50
+
```
51
+
<type>(<scope>): <subject>
52
+
<BLANK LINE>
53
+
<body>
54
+
<BLANK LINE>
55
+
<footer>
56
+
```
57
+
58
+
The **header** is mandatory and the **scope** of the header is optional.
59
+
60
+
### Revert
61
+
62
+
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.
63
+
64
+
### Type
65
+
66
+
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.
67
+
68
+
Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks.
69
+
70
+
### Scope
71
+
72
+
The scope could be anything specifying the place of the commit change. For example `dev`, `build`, `workflow`, `cli` etc...
73
+
74
+
### Subject
75
+
76
+
The subject contains a succinct description of the change:
77
+
78
+
- use the imperative, present tense: "change" not "changed" nor "changes"
79
+
- don't capitalize the first letter
80
+
- no dot (.) at the end
81
+
82
+
### Body
83
+
84
+
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
85
+
The body should include the motivation for the change and contrast this with previous behavior.
86
+
87
+
### Footer
88
+
89
+
The footer should contain any information about **Breaking Changes** and is also the place to
90
+
reference GitHub issues that this commit **Closes**.
91
+
92
+
**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.
Copy file name to clipboardExpand all lines: docs/guide/contributing.md
+47-6Lines changed: 47 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,11 @@
1
1
# Contributing
2
2
3
+
Hi! We are really excited that you are interested in contributing to the Vue devtools. Before submitting your contribution, please make sure to take a moment and read through the following guide.
4
+
3
5
## Monorepo
4
6
7
+
The repository is a monorepo with several nested packages:
8
+
5
9
|Package|Description|
6
10
|-------|-----------|
7
11
[api](https://github.com/vuejs/devtools/tree/main/packages/api) | The public devtools API that can be installed in Vue plugins |
@@ -25,18 +29,48 @@
25
29
3. then run `yarn run build:watch` and `yarn run dev:vue3` in parallel
26
30
4. A plain shell with a test app will be available at [localhost:8090](http://localhost:8090/).
27
31
32
+
## Pull Request Guidelines
33
+
34
+
Thank you for your code contribution! Before opening a PR, please make sure to read the following:
35
+
36
+
- Checkout a topic branch from a base branch, e.g. `main`, and merge back against that branch. For example: `feat/my-new-feature`.
37
+
38
+
- Please make sure that you allow maintainers to push changes to your branch when you create your PR.
39
+
40
+
- If adding a new feature:
41
+
42
+
<!-- @TODO Add accompanying test case.-->
43
+
- Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
44
+
45
+
- If fixing bug:
46
+
47
+
- 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. `fix: update entities encoding/decoding (fix #3899)`.
48
+
- Provide a detailed description of the bug in the PR. Live demo preferred.
49
+
<!-- @TODO - Add appropriate test coverage if applicable.-->
50
+
51
+
- It's OK to have multiple small commits as you work on the PR - GitHub can automatically squash them before merging.
52
+
53
+
<!-- @TODO - Make sure tests pass!-->
54
+
55
+
- Commit messages must follow the [commit message convention](./.github/commit-convention.md) so that changelogs can be automatically generated.
56
+
57
+
## Running tests
58
+
59
+
1. Run `yarn lint` to check code quality with ESLint.
60
+
2. Run `yarn test` to run all tests. (@TODO)
61
+
28
62
## Testing as Chrome addon
29
63
30
64
This is useful when you want to build the extension with the source repo to get not-yet-released features.
31
65
32
66
1. Clone this repo
33
67
2.`cd vue-devtools` the newly created folder
34
-
2. run `yarn install`
35
-
3. then run `yarn run build:watch` & `yarn run dev:chrome` in parallel
36
-
4. Open the Chrome extension page (currently under `Menu` > `More Tools` > `Extensions`)
37
-
5. Check "developer mode" on the top-right corner
38
-
6. Click the "load unpacked" button on the left, and choose the folder: `vue-devtools/packages/shell-chrome/` (it will have an orange disk icon)
39
-
7. Make sure you disable all other versions of the extension
68
+
3. run `yarn install`
69
+
4. then run `yarn run build:watch` & `yarn run dev:chrome` in parallel
70
+
5. Open the Chrome extension page (currently under `Menu` > `More Tools` > `Extensions`)
71
+
6. Check "developer mode" on the top-right corner
72
+
7. Click the "load unpacked" button on the left, and choose the folder: `vue-devtools/packages/shell-chrome/` (it will have an orange disk icon)
73
+
8. Make sure you disable all other versions of the extension
40
74
41
75
## Testing as Firefox addon
42
76
@@ -56,3 +90,10 @@ This is useful when you want to build the extension with the source repo to get
56
90
3. run `yarn install`
57
91
4. then run `yarn run build:watch` and `yarn run dev:chrome` in parallel
0 commit comments