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
👍🎉 First off, thanks for taking the time to contribute! 🎉👍
3
+
First off, thanks for taking the time to contribute! 🎉👍
4
4
5
5
These are mostly guidelines, not rules. Use your best judgment,
6
6
and feel free to propose changes to this document in a pull request.
@@ -21,22 +21,21 @@ track of the issue.
21
21
22
22
If you intend to provide changes related to a add or remove rules you can follow these steps:
23
23
24
-
1. Run `dart tool/bump_version/main.dart <NEW_VERSION>` to generate a new version.
24
+
1. Run `dart tool/bump_version/lib/bump_version.dart <NEW_VERSION>` to generate a new version.
25
25
- Choose `<NEW_VERSION>` according to [Semantic Versioning](https://semver.org/) guidelines based on your proposed changes.
26
-
1. Add or remove the lint rules you want to change in the version file you generated in step 1.
26
+
1. Add or remove the lint rules you want to change in the version file you generated in step 1.
27
27
1. Document the rules that were removed with a reason as to why, if there is any.
28
28
- Link to an issue as to why a lint rule should not be used if there is any.
29
29
1. Create a pull request following the guidelines in the [Creating a Pull Request](#creating-a-pull-request) section below.
30
30
31
-
32
31
## Contributing rules from a new Dart version
33
32
34
33
If you intend to provide changes related to a **new Dart version** you can follow these steps:
35
34
36
35
1. Ensure you are on the latest stable Dart version.
37
-
1. Run `dart tool/bump_version/main.dart <NEW_VERSION>` to generate a new version.
36
+
1. Run `dart tool/bump_version/lib/bump_version.dart <NEW_VERSION>` to generate a new version.
38
37
- Choose `<NEW_VERSION>` according to [Semantic Versioning](https://semver.org/) guidelines based on your proposed changes.
39
-
1. Add or remove the lint rules you want to change in the version file you generated in step 2.
38
+
1. Add or remove the lint rules you want to change in the version file you generated in step 2.
40
39
- To find new rules more easily you can run the same command as in step 4 which will add new rules directly to the exclusion table.
41
40
1. Open a terminal in `tool/linter_rules` and run `dart lib/exclusion_reason_table.dart` to generate an up-to-date exclusion table.
42
41
1. Document the rules that were removed with a reason as to why, if there is any.
@@ -57,67 +56,55 @@ Before creating a pull request please:
57
56
1. Format your code (`dart format .`).
58
57
1. Analyze your code (`dart analyze . --fatal-infos`).
59
58
1. Follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) specification for your commit messages.
60
-
- This enables automatic version bumping and changelog generation as detailed in the [Release Process](#release-process) section.
59
+
- This enables automatic version bumping and changelog generation as detailed in the [Release Process](#release-process-🚀) section.
61
60
1. Create the Pull Request.
62
61
1. Verify that all status checks are passing.
63
62
64
-
65
63
While the prerequisites above must be satisfied prior to having your
66
64
pull request reviewed, the reviewer(s) may ask you to complete additional
67
65
design work, tests, or other changes before your pull request can be ultimately
68
66
accepted.
69
67
70
-
71
68
## Release Process 🚀
72
69
73
-
##### ‼️ Important
74
-
- Every snapshot of a version is saved on its own yaml file under the name pattern: `lib/analysis_options.<version>.yaml`.
75
-
70
+
> Every snapshot of a version is saved on its own yaml file under the name pattern: `lib/analysis_options.<version>.yaml`.
76
71
77
72
We use [`release-please-action`][release-please-action-link] to automate versioning and changelog generation, along with a GitHub workflow that automatically publish the Very Good Analysis to pub.dev.
78
73
79
-
### How it works:
74
+
### How it works
80
75
81
76
- 📌 **On Every Commit to main:**
82
-
- Commits are analyzed using [Conventional Commits][conventional_commits_link].
83
-
- If a version bump is needed, a **release PR** is automatically created or updated by [`release-please-action`][release-please-action-link].
84
-
- The **release PR** includes:
85
-
- An updated `CHANGELOG.md`
86
-
- A version bump in `pubspec.yaml`
87
-
88
-
##### ‼️ Important
89
-
- A version verification workflow (`.github/workflows/verify_version.yaml`) runs to ensure:
90
-
- The version in `pubspec.yaml` matches the version in `lib/analysis_options.yaml`
91
-
- The file `lib/analysis_options_<NEW_VERSION>.yaml` exists
92
-
- If any mismatches are found, the files need to be manually updated to match
77
+
- Commits are analyzed using [Conventional Commits][conventional_commits_link].
78
+
- If a version bump is needed, a **release PR** is automatically created or updated by [`release-please-action`][release-please-action-link].
79
+
- The **release PR** includes:
80
+
- An updated `CHANGELOG.md`
81
+
- A version bump in `pubspec.yaml`
93
82
94
-
##### 💡 Notes
83
+
> A version verification workflow (`.github/workflows/verify_version.yaml`) runs to ensure:
84
+
>- The version in `pubspec.yaml` matches the version in `lib/analysis_options.yaml`
85
+
>- The file `lib/analysis_options_<NEW_VERSION>.yaml` exists
86
+
>- If any mismatches are found, the files need to be manually updated to match
95
87
96
-
- The GitHub Action workflow that automates the release process is configured in `.github/workflows/release_please.yaml`
97
-
- release-please settings are defined in `.release-please-config.json` and `.release-please-manifest.json`
98
-
- The release PR can be manually edited before merging.
99
-
- The release PR should be merged **ONLY** when a new release is needed.
88
+
##### 💡 Notes
100
89
101
-
<br />
90
+
- The GitHub Action workflow that automates the release process is configured in `.github/workflows/release_please.yaml`
91
+
- release-please settings are defined in `.release-please-config.json` and `.release-please-manifest.json`
92
+
- The release PR can be manually edited before merging.
93
+
- The release PR should be merged **ONLY** when a new release is needed.
102
94
103
95
- ✅ **When the Release PR Is Merged:**
104
-
- A new Git tag is created.
105
-
- A GitHub Release is published with the changelog.
106
-
- A new version of Very Good Analysis is automatically published in pub.dev.
107
-
108
-
#### 💡 Notes
96
+
- A new Git tag is created.
97
+
- A GitHub Release is published with the changelog.
98
+
- A new version of Very Good Analysis is automatically published in pub.dev.
109
99
110
-
- The publishing process is automatically triggered when a version tag is created.
111
-
- The automated publishing workflow to pub.dev is defined in `.github/workflows/pub_publish.yaml`
100
+
#### 💡 Notes
112
101
113
-
<br />
102
+
- The publishing process is automatically triggered when a version tag is created.
103
+
- The automated publishing workflow to pub.dev is defined in `.github/workflows/pub_publish.yaml`
114
104
115
105
This document provides a good summary of how it works and how we use it, but we recommend that you also read the official documentation of [Conventional Commits][conventional_commits_link], [Semantic Versioning][sem_ver_link], [Publishing Dart packages][dart_publishing_link] and [`release-please-action`][release-please-action-link].
Copy file name to clipboardExpand all lines: tool/linter_rules/README.md
+2-5Lines changed: 2 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,7 +35,6 @@ Rules that are missing a reason in the `exclusion_reasons.json` file will be giv
35
35
| version | The Very Good Analysis version to use. | latest (from lib/analysis_options.yaml) |
36
36
| set-exit-if-changed | Set the exit code to 2 if there are changes to the exclusion reasons. | false |
37
37
38
-
39
38
## Analyze 🔍
40
39
41
40
If you're looking to update Very Good Analysis you might want to analyze the health of the latest rule set. You can use the script at `bin/analyze.dart` to do exactly that.
@@ -63,7 +62,6 @@ dart bin/analyze.dart $version
63
62
64
63
Where version is the existing Very Good Analysis version you would like to analyze, for example `10.0.0`.
65
64
66
-
67
65
## Check and remove deprecated rules 🔍
68
66
69
67
The script `tool/linter_rules/bin/remove_deprecated_rules.dart` helps maintain Very Good Analysis by automatically handling deprecated linter rules.
@@ -84,13 +82,12 @@ To check and remove deprecated rules, run the following command (from `tool/lint
84
82
dart bin/remove_deprecated_rules.dart
85
83
```
86
84
87
-
88
85
## Automations
89
86
90
87
There is a [GitHub workflow](../../.github/workflows/bot_updater.yaml) that automates the maintenance of the linter rules. This workflow runs on a schedule (every weekday) and can also be triggered manually.
91
88
92
89
It performs two main tasks:
93
90
94
-
1.**Update Exclusion Table**: It checks if there are any changes to the exclusion reasons for linter rules. If there are, it regenerates the exclusion table in this README and creates a pull request with the title `docs: update exclusion table`.
91
+
1.**Update Exclusion Table**: It checks if there are any changes to the exclusion reasons for linter rules. If there are, it regenerates the exclusion table in this README and creates a pull request with the title `docs: update exclusion table`.
95
92
96
-
2.**Remove Deprecated Rules**: It checks for deprecated linter rules currently used in Very Good Analysis. If any are found, it automatically removes them from the analysis options, creates a new version of the analysis options file, and opens a pull request with the changes, titled `feat: remove deprecated rules`.
93
+
2.**Remove Deprecated Rules**: It checks for deprecated linter rules currently used in Very Good Analysis. If any are found, it automatically removes them from the analysis options, creates a new version of the analysis options file, and opens a pull request with the changes, titled `feat: remove deprecated rules`.
0 commit comments