Andreas/markdownlint
1
0
Fork 0
mirror of https://github.com/DavidAnson/markdownlint.git synced 2025-12-16 14:00:13 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Minor updates to CONTRIBUTING.md, indefinite article fixes for Rules.md.

Browse source
This commit is contained in:
David Anson 2020-08-15 16:57:43 -07:00
parent 0acc578e52
commit ff40130e3e
2 changed files with 15 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

9
CONTRIBUTING.md
View file

@ -23,7 +23,7 @@ Try to break the new code now, or else it will get broken later.
Run tests before sending a pull request via `npm test` in the [usual manner](https://docs.npmjs.com/misc/scripts).
Tests should all pass on all platforms.
The test runner is [nodeunit](https://www.npmjs.com/package/nodeunit) and test cases are located in `test/markdownlint-test.js`.
The test runner is [tape](https://www.npmjs.com/package/tape) and test cases are located in `test/markdownlint-test.js`.
When running tests, `test/*.md` files are enumerated, linted, and fail if any violations are missing a corresponding `{MD###}` marker in the test file.
For example, the line `### Heading {MD001}` is expected to trigger the rule `MD001`.
For cases where the marker text can not be present on the same line, the syntax `{MD###:#}` can be used to include a line number.
@ -32,8 +32,8 @@ If `some-test.md` needs custom configuration, a `some-test.json` is used to prov
Lint before sending a pull request by running `npm run lint`.
There should be no issues.
Run code coverage before sending a pull request with `npm run test-cover`.
Coverage should remain at 100%.
Run a full continuous integration pass before sending a pull request via `npm run ci`.
Code coverage should remain at 100%.
Pull requests should contain a single commit.
If necessary, squash multiple commits before creating the pull request and when making changes.
@ -42,6 +42,9 @@ If necessary, squash multiple commits before creating the pull request and when
Open pull requests against the `next` branch.
That's where the latest changes are staged for the next release.
Include the text "(fixes #??)" at the end of the commit message so the pull request will be associated with the relevant issue.
End commit messages with a period (`.`).
Once accepted, the tag `fixed in next` will be added to the issue.
When the commit is merged to the main branch during the release process, the issue will be closed automatically.
(See [Closing issues using keywords](https://help.github.com/articles/closing-issues-using-keywords/) for details.)
Thank you!

18
doc/Rules.md
View file

@ -59,24 +59,24 @@ Parameters: level (number; default 1)
> [MD041/first-line-heading](#md041) offers an improved implementation.
This rule is intended to ensure document headings start at the top level and
is triggered when the first heading in the document isn't an h1 heading:
is triggered when the first heading in the document isn't a h1 heading:
```markdown
## This isn't an H1 heading
## This isn't a H1 heading
### Another heading
```
The first heading in the document should be an h1 heading:
The first heading in the document should be a h1 heading:
```markdown
# Start with an H1 heading
# Start with a H1 heading
## Then use an H2 for subsections
```
Note: The `level` parameter can be used to change the top level (ex: to h2) in
cases where an h1 is added externally.
cases where a h1 is added externally.
Rationale: The top level heading often acts as the title of a document. More
information: <https://cirosantilli.com/markdown-style-guide#top-level-header>.
@ -839,7 +839,7 @@ Aliases: single-title, single-h1
Parameters: level, front_matter_title (number; default 1, string; default "^\s*title:")
This rule is triggered when a top level heading is in use (the first line of
the file is an h1 heading), and more than one h1 heading is in use in the
the file is a h1 heading), and more than one h1 heading is in use in the
document:
```markdown
@ -861,7 +861,7 @@ headings:
```
Note: The `level` parameter can be used to change the top level (ex: to h2) in
cases where an h1 is added externally.
cases where a h1 is added externally.
If [YAML](https://en.wikipedia.org/wiki/YAML) front matter is present and contains
a `title` property (commonly used with blog posts), this rule treats that as a top
@ -870,7 +870,7 @@ To use a different property name in front matter, specify the text of a regular
expression via the `front_matter_title` parameter. To disable the use of front
matter by this rule, specify `""` for `front_matter_title`.
Rationale: A top level heading is an h1 on the first line of the file, and
Rationale: A top level heading is a h1 on the first line of the file, and
serves as the title for the document. If this convention is in use, then there
can not be more than one title for the document, and the entire document
should be contained within this heading.
@ -1566,7 +1566,7 @@ This is a file with a top level heading
```
Note: The `level` parameter can be used to change the top level (ex: to h2) in cases
where an h1 is added externally.
where a h1 is added externally.
If [YAML](https://en.wikipedia.org/wiki/YAML) front matter is present and contains a
`title` property (commonly used with blog posts), this rule will not report a