Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(contributing): spelling and grammar fixes #879

Merged
merged 1 commit into from
Apr 23, 2022
Merged

docs(contributing): spelling and grammar fixes #879

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
## Testing changes locally

You might try a TDD approach and add tests within the `test` directory,
to try different configs, you may find it easier to try out changes in
to try different configs you may find it easier to try out changes in
a separate local directory.

You can run [`npm link`](https://docs.npmjs.com/cli/link) for this purpose,
Expand All @@ -18,7 +18,7 @@ npm link ../eslint-plugin-jsdoc

After running `npm install` to get the latest dependencies and devDependencies,
you can run the following command to update the `dist` files, with `dist/index.js`
being the `main` entrance point from `package.json`:
being the `main` entry point from `package.json`:

```shell
npm run build
Expand All @@ -33,22 +33,22 @@ items needing fixing.

## Documentation building

In order to make changes that are reflected in the README, you will need to
To make changes that are reflected in the README, you will need to
modify files within the `.README` directory. `.README/README.md` contains the
main README skeleton and details on the project, its global `settings`, etc.,
while the documentation for specific rules (that will get pulled into the
while the documentation for specific rules (that will be pulled into the
README) ought to be modified within the relevant file within `.README/rules`.
Once these files are modified, you can run `npm run create-readme` to have
these files integrated into the main `/README.md`. While you should include
the built file in your PR, you will do not want to make manual changes
directly to this file as they will be overwritten.
the built file in your PR, you will not want to make manual changes
directly to this file, as they will be overwritten.

## Testing

Tests are expected. Each rule file should be in CamelCase (despite the rule names themselves being hyphenated) and should be added within `test/assertions` and then imported/required by
`test/rules/index.js`.

Each rule file should be an ESM default export of an object which has `valid` and `invalid` array properties containing the tests. Tests of each type should be provided.
Each rule file should be an ESM default export of an object that has `valid` and `invalid` array properties containing the tests. Tests of each type should be provided.

`parserOptions` will be `ecmaVersion: 6` by default, but tests can override `parserOptions`
with their own.
Expand All @@ -57,8 +57,8 @@ See ESLint's [RuleTester](https://eslint.org/docs/developer-guide/nodejs-api#rul
for more on the allowable properties (e.g., `code`, `errors` (for invalid rules),
`options`, `settings`, etc.).

Note that besides `npm test`, there is `npm run test-cov` which shows more
detailed information on coverage. Coverage should be maintained at 100%, and
Note that besides `npm test` there is `npm run test-cov`, which shows more
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note that besides `npm test` there is `npm run test-cov`, which shows more
Note that besides `npm test` there is `npm run test-cov` which shows more

I don't think there is need for a comma here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thrown the comma in front of "which" because it is introducing a non-defining/non-restrictive clause.

I think the following article explain this change far better than I can!:

detailed coverage information. Coverage should be maintained at 100%, and
if there are a few guards in place for future use, the code block in question
can be ignored by being preceded by `/* istanbul ignore next */` (including
for warnings where the block is never passed over (i.e., the block is always
Expand All @@ -75,7 +75,7 @@ You can further limit this by providing `--invalid` and/or `--valid` flags
with a comma-separated list of 0-based indexes that you wish to include (also
accepts negative offsets from the end, e.g., `-1` for the last item). For
example, to check the first and third invalid tests of `check-examples`
alon with the second valid test, you can run:
along with the second valid test, you can run:

`npm run --rule=check-examples --invalid=0,2 --valid=1 test-index`.

Expand All @@ -84,7 +84,7 @@ alon with the second valid test, you can run:
PRs should be mergeable, [rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
first against the latest `master`.

The number of commits will ideally be limited in number, unless extra commits
The number of commits will ideally be limited unless extra commits
can better show a progression of features.

Commit messages should be worded clearly and the reason for any PR made clear
Expand All @@ -96,5 +96,5 @@ We use [semantic-release](https://github.com/semantic-release/semantic-release)
for preparing releases, so the commit messages (or at least the merge that
brings them into `master`) must follow the
[AngularJS commit guidelines](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) with a special format such as `feat: describe new feature`
in order for the releasing to occur and for the described items to be added
for releases to occur and for the described items to be added
to the release notes.