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
Thank you for your interest in contributing to the Node.js `api-docs-tooling` project! We welcome contributions from everyone, and we appreciate your help in making this project better.
4
4
5
-
## Getting started
5
+
## Table of Contents
6
6
7
-
The steps below will give you a general idea of how to prepare your local environment for the Node.js Website and general steps
8
-
for getting things done and landing your contribution.
7
+
-[Getting Started](#getting-started)
8
+
-[Prerequisites](#prerequisites)
9
+
-[Setting Up Your Development Environment](#setting-up-your-development-environment)
10
+
-[Development Workflow](#development-workflow)
11
+
-[Making Changes](#making-changes)
12
+
-[Submitting Your Changes](#submitting-your-changes)
-[Use Node.js Built-in Test Runner](#use-nodejs-built-in-test-runner)
18
+
-[Test Structure](#test-structure)
19
+
-[Best Practices](#best-practices)
20
+
-[Example Test File](#example-test-file)
21
+
-[Running Tests](#running-tests)
22
+
-[Code Quality](#code-quality)
23
+
-[Linting and Formatting](#linting-and-formatting)
24
+
-[Pre-commit Hooks](#pre-commit-hooks)
25
+
-[Commit Guidelines](#commit-guidelines)
26
+
-[Commit Message Format](#commit-message-format)
27
+
-[Commit Message Rules](#commit-message-rules)
28
+
-[Common Types](#common-types)
29
+
-[Examples](#examples)
30
+
-[Developer's Certificate of Origin 1.1](#developers-certificate-of-origin-11)
31
+
-[Getting Help](#getting-help)
9
32
10
-
1. Click the fork button in the top right to clone the [Node.js `api-docs-tooling` Repository](https://github.com/nodejs/api-docs-tooling/fork)
33
+
## Getting Started
11
34
12
-
2. Clone your fork using SSH, GitHub CLI, or HTTPS.
35
+
The steps below will give you a general idea of how to prepare your local environment for the Node.js `api-docs-tooling` project and general steps for getting things done and landing your contribution.
36
+
37
+
### Prerequisites
38
+
39
+
- Node.js (latest LTS version, check the [`.nvmrc` file](/.nvmrc))
40
+
-[Git]
41
+
- A GitHub account
42
+
43
+
### Setting Up Your Development Environment
44
+
45
+
1.**Fork the repository**
46
+
47
+
Click the fork button in the top right, or the link in this paragraph, to clone the [Node.js `api-docs-tooling` Repository](https://github.com/nodejs/api-docs-tooling/fork)
8. Perform a merge to sync your current branch with the upstream branch.
89
+
Make your code changes, add features, fix bugs, or improve documentation.
90
+
91
+
3.**Keep your branch up-to-date**
49
92
50
93
```bash
51
94
git fetch upstream
52
95
git merge upstream/main
53
96
```
54
97
55
-
9. Run `node --run format` and `node --run lint` to confirm that linting and formatting are passing.
98
+
4.**Test your changes**
56
99
57
100
```bash
58
-
node --run format
59
-
node --run lint
101
+
node --run test
102
+
node --run test:coverage # To check code coverage
60
103
```
61
104
62
-
10. Once you're happy with your changes, add and commit them to your branch, then push the branch to your fork.
105
+
5.**Check code quality**
63
106
64
-
```bash
65
-
cd~/api-docs-tooling
66
-
git add .
67
-
git commit -m "describe your changes"
68
-
git push -u origin name-of-your-branch
69
-
```
107
+
```bash
108
+
node --run format
109
+
node --run lint
110
+
```
70
111
71
-
> [!IMPORTANT]\
72
-
> Before committing and opening a Pull Request, please go first through our [Commit](#commit-guidelines);
112
+
### Submitting Your Changes
73
113
74
-
11. Create a Pull Request.
114
+
1.**Add and commit your changes**
75
115
76
-
## Commit Guidelines
116
+
```bash
117
+
git add .
118
+
git commit -m "describe your changes"
119
+
```
77
120
78
-
This project follows the [Conventional Commits][] specification.
121
+
2.**Push to your fork**
122
+
123
+
```bash
124
+
git push -u origin <name-of-your-branch>
125
+
```
126
+
127
+
3.**Create a Pull Request**
128
+
129
+
Go to your fork on GitHub and create a Pull Request to the main repository.
130
+
131
+
> [!IMPORTANT]
132
+
> Before committing and opening a Pull Request, please go through our [Commit Guidelines](#commit-guidelines) and ensure your code passes all tests and quality checks.
133
+
134
+
## Writing Tests
135
+
136
+
Testing is a crucial part of maintaining code quality and ensuring reliability. All contributions should include appropriate tests.
137
+
138
+
### Test Coverage
139
+
140
+
-**Patches (PRs) are required to maintain 80% coverage minimum**
141
+
-**Contributors are encouraged to strive for 95-100% coverage**
142
+
- New features and bug fixes should include corresponding tests
143
+
- Tests should cover both happy path and edge cases
79
144
80
-
### Commit Message Guidelines
145
+
### Test File Organization
81
146
82
-
- Commit messages must include a "type" as described on Conventional Commits
83
-
- Commit messages **must** start with a capital letter
84
-
- Commit messages **must not** end with a period `.`
147
+
Tests should be organized to mirror the source code structure:
148
+
149
+
- For a source file at `/src/index.mjs`, create a test file at `/src/test/index.test.mjs`
150
+
- For a source file at `/src/utils/parser.mjs`, create a test file at `/src/utils/test/parser.test.mjs`
151
+
- Test files should use the `.test.mjs` extension
152
+
153
+
- For a fixture used in `/src/test/some.test.mjs`, place the fixture at `/src/test/fixture/some-fixture.mjs`.
154
+
- When fixtures are used in multiple tests, place them in the test directory of the closest shared ancestor. For instance, if a fixture is used by both `/src/test/some.test.mjs`, and `/src/utils/test/parser.test.mjs`, the fixture belongs in `/src/test/fixtures/`.
155
+
156
+
### Writing Test Code
157
+
158
+
Tests should follow these guidelines:
159
+
160
+
#### Use Node.js Built-in Test Runner
161
+
162
+
```javascript
163
+
importassertfrom'node:assert/strict';
164
+
import { describe, it } from'node:test';
165
+
```
166
+
167
+
#### Test Structure
168
+
169
+
Use `describe` and `it` syntax for organizing tests:
170
+
171
+
```javascript
172
+
describe('MyModule', () => {
173
+
describe('myFunction', () => {
174
+
it('should return expected result for valid input', () => {
175
+
// Test implementation
176
+
assert.strictEqual(actual, expected);
177
+
});
178
+
179
+
it('should throw error for invalid input', () => {
180
+
assert.throws(() => {
181
+
// Code that should throw
182
+
});
183
+
});
184
+
});
185
+
});
186
+
```
187
+
188
+
#### Best Practices
189
+
190
+
-**Use strict assertions**: Always use `node:assert/strict` over `node:assert`.
191
+
-**Focused testing**: Tests should ideally only test the specific file they are intended for
192
+
-**Use mocking**: Mock external dependencies to isolate the code under test
193
+
-**Code splitting**: Encourage breaking down complex functionality for easier testing
194
+
195
+
#### Example Test File
196
+
197
+
```javascript
198
+
// tests/index.test.mjs
199
+
importassertfrom'node:assert/strict';
200
+
import { describe, it } from'node:test';
201
+
202
+
import { myFunction } from'../index.mjs';
203
+
204
+
describe('index.mjs', () => {
205
+
describe('myFunction', () => {
206
+
it('should process valid input correctly', () => {
207
+
constinput='test input';
208
+
constresult=myFunction(input);
209
+
assert.strictEqual(result, 'expected output');
210
+
});
211
+
212
+
it('should handle edge cases', () => {
213
+
assert.strictEqual(myFunction(''), '');
214
+
assert.strictEqual(myFunction(null), null);
215
+
});
216
+
217
+
it('should throw for invalid input', () => {
218
+
assert.throws(() =>myFunction(undefined), {
219
+
name:'TypeError',
220
+
message:'Input cannot be undefined'
221
+
});
222
+
});
223
+
});
224
+
});
225
+
```
226
+
227
+
### Running Tests
228
+
229
+
```bash
230
+
# Run all tests
231
+
node --run test
232
+
233
+
# Run tests with coverage
234
+
node --run test:coverage
235
+
236
+
# Run specific test file
237
+
node --test src/test/index.test.mjs
238
+
```
239
+
240
+
## Code Quality
241
+
242
+
### Linting and Formatting
243
+
244
+
This project uses automated code quality tools:
245
+
246
+
```bash
247
+
# Format code
248
+
node --run format # To apply changes, use `format:write`
249
+
250
+
# Lint code
251
+
node --run lint # To apply changes, use `lint:fix`
252
+
```
85
253
86
254
### Pre-commit Hooks
87
255
88
-
This project uses [Husky][] for Git pre-commit hooks.
89
-
It's lint and format stages your code before committing.
90
-
You can disable the pre-commit hooks by using the `--no-verify` flag.
256
+
This project uses [Husky][] for Git pre-commit hooks that automatically lint and format your code before committing.
257
+
258
+
You can bypass pre-commit hooks if necessary (not recommended):
91
259
92
260
```bash
93
261
git commit -m "describe your changes" --no-verify
94
262
```
95
263
264
+
## Commit Guidelines
265
+
266
+
This project follows the [Conventional Commits][] specification.
267
+
96
268
## Developer's Certificate of Origin 1.1
97
269
98
270
```
@@ -114,5 +286,5 @@ By contributing to this project, I certify that:
0 commit comments