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
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
Copy file name to clipboardExpand all lines: readme.md
+2-46
Original file line number
Diff line number
Diff line change
@@ -72,50 +72,6 @@ and your lint script will also need to pass in the location of the custom rule f
72
72
73
73
Consider upstreaming any rules you find useful as proposals to this repository.
74
74
75
-
## Development
75
+
## Contributing
76
76
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