Skip to content

Commit 925e064

Browse files
authored
Create CONTRIBUTING guidelines (#15)
1 parent ea1958d commit 925e064

File tree

2 files changed

+53
-46
lines changed

2 files changed

+53
-46
lines changed

CONTRIBUTING.md

+51
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
# Contributing Guide
2+
3+
Thank you for your interest in contributing.
4+
5+
## Developing
6+
7+
Depending on your needs, you may have one of two development paths:
8+
9+
- via integrating with an existing usage (ideal for modifying the interface of our rules)
10+
- via unit testing (ideal for adding a new rule)
11+
12+
For that reason we've included two paths to develop. Feel free to use either, or both.
13+
14+
### Behavioral troubleshooting
15+
16+
It may be useful to work on this in tandem with a codebase that uses the rules. In that case, we encourage improving local development experience by leveraging `npm link` functionality:
17+
18+
1. In this repository on your machine, create the symlink to your local development directory
19+
20+
```bash
21+
npm link
22+
npm ls @github/markdownlint-github # should show a symlink
23+
```
24+
25+
2. In the codebase you want to test against, replace the package in your `node_modules` folder with the symlink reference
26+
27+
```bash
28+
cd ../your-codebase
29+
npm link @github/markdownlint-github
30+
```
31+
32+
If you go to the `node_modules` directory in your codebase and try to navigate into the package, you'll notice that whatever changes you make in your local development directory will be reflected in the codebase.
33+
34+
3. Reset symlinks at any time by reversing the steps via `npm unlink`.
35+
- in your codebase: `npm unlink @github/markdownlint-github`
36+
- in this directory: `npm unlink`
37+
38+
### Unit and Interface Testing
39+
40+
We use `jest` tests as well, which should be an equally comfortable development experience. Refer to existing test files for any patterns you may find useful.
41+
42+
## Publishing
43+
44+
To publish, merge your work to main (after PR process completed).
45+
46+
Manage version and publish on a new branch, and create a PR to merge these changes into main.
47+
48+
```bash
49+
npm version [major|minor|patch] # alternatively, manage version in package.json
50+
npm run publish
51+
```

readme.md

+2-46
Original file line numberDiff line numberDiff line change
@@ -72,50 +72,6 @@ and your lint script will also need to pass in the location of the custom rule f
7272

7373
Consider upstreaming any rules you find useful as proposals to this repository.
7474

75-
## Development
75+
## Contributing
7676

77-
Depending on your needs, you may have one of two development paths:
78-
79-
- via integrating with an existing usage (ideal for modifying the interface of our rules)
80-
- via unit testing (ideal for adding a new rule)
81-
82-
For that reason we've included two paths to develop. Feel free to use either, or both.
83-
84-
### Behavioral troubleshooting
85-
86-
It may be useful to work on this in tandem with a codebase that uses the rules. In that case, we encourage improving local development experience by leveraging `npm link` functionality:
87-
88-
1. In this repository on your machine, create the symlink to your local development directory
89-
90-
```bash
91-
npm link
92-
npm ls @github/markdownlint-github # should show a symlink
93-
```
94-
95-
2. In the codebase you want to test against, replace the package in your `node_modules` folder with the symlink reference
96-
97-
```bash
98-
cd ../your-codebase
99-
npm link @github/markdownlint-github
100-
```
101-
102-
If you go to the `node_modules` directory in your codebase and try to navigate into the package, you'll notice that whatever changes you make in your local development directory will be reflected in the codebase.
103-
104-
3. Reset symlinks at any time by reversing the steps via `npm unlink`.
105-
- in your codebase: `npm unlink @github/markdownlint-github`
106-
- in this directory: `npm unlink`
107-
108-
### Unit and Interface Testing
109-
110-
We use `jest` tests as well, which should be an equally comfortable development experience. Refer to existing test files for any patterns you may find useful.
111-
112-
## Publishing
113-
114-
To publish, merge your work to main (after PR process completed).
115-
116-
Manage version and publish on a new branch, and create a PR to merge these changes into main.
117-
118-
```bash
119-
npm version [major|minor|patch] # alternatively, manage version in package.json
120-
npm run publish
121-
```
77+
Please read [Contributing Guide](./CONTRIBUTING.md) for more information.

0 commit comments

Comments
 (0)