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
- If you are running against more than a standalone make sure your ulimit settings are in accordance with mongo's recommendations
65
-
- Changing the settings on the latest versions of [macos can be trickyread here][macos-ulimt] (unless you know you need it you shouldn't have to do the complicated maxproc steps)
65
+
- Changing the settings on the latest versions of macos can be tricky: [read here][macos-ulimt] (unless you know you need it you shouldn't have to do the complicated maxproc steps)
66
66
- How can I run just one test?
67
67
- To run a single test, use mocha's grep flag: `npm run test -- -g 'test name'`
68
68
- If it's easier you can also isolate tests by adding `.only` Example: `it.only(‘cool test’, function() {})`
69
69
70
70
### Commit messages
71
71
72
-
Please follow the [Angular commit style][angular-commit-style].
72
+
Please follow the [conventional commit style][conventional-commit-style].
73
73
The format should look something like this (note the blank lines):
74
74
75
75
```txt
76
76
<type>(<scope>): <subject>
77
77
78
78
<body>
79
-
80
-
NODE-XXXX
81
79
```
82
80
83
-
If there is a relevant NODE ticket number it should be in the footer section of the Angular style commit.
81
+
If there is a relevant NODE ticket number it should be referenced in the scope portion of the commit.
82
+
83
+
Note that a BREAKING CHANGE commit should include an exclamation mark after the scope, for example:
84
+
85
+
```text
86
+
feat(NODE-xxxx)!: created new version api, removed support for old version
87
+
```
84
88
85
89
This helps the team automate [HISTORY.md](HISTORY.md) generation.
86
90
These are the commit types we make use of:
@@ -98,14 +102,11 @@ These are the commit types we make use of:
98
102
99
103
Below are some conventions that aren't enforced by any of our tooling but we nonetheless do our best to adhere to:
100
104
101
-
-**Ensure Promise usage is optional**
102
-
- There is a measurable overhead to Promise usage vs callbacks.
103
-
To support the broadest of driver usage scenarios we maintain an internal callback api while exposing a surface layer Promise API.
104
105
-**Disallow `export default` syntax**
105
106
- For our use case it is best if all imports / exports remain named.
106
107
-**As of 4.0 all code in src is in Typescript**
107
108
- Typescript provides a nice developer experience
108
-
As a product of using TS we should be using es6 syntax features whenever possible.
109
+
As a product of using TS we should be using es6 syntax features whenever possible.
109
110
-**Errors**
110
111
- Error messages should be sentence case, and have no periods at the end.
111
112
- Use driver-specific error types where possible (not just `Error`, but classes that extend `MongoError`, e.g. `MongoNetworkError`)
@@ -116,18 +117,47 @@ Below are some conventions that aren't enforced by any of our tooling but we non
116
117
wish to make, if applicable.
117
118
1. Add any appropriate tests.
118
119
1. Make your code or other changes.
119
-
1. Review guidelines such as [How to write the perfect pull request][github-perfect-pr], thanks!
120
-
121
-
Take a look at [Github Flow][github-flow] for a more detailed explanation of this process.
1. Please adhere to the guidelines in [How to write the perfect pull request][github-perfect-pr], thanks!
121
+
1. Please perform a self-review using the reviewer guidelines below prior to taking the PR out of draft state.
122
+
123
+
### Reviewer Guidelines
124
+
125
+
Reviewers should use the following questions to evaluate the implementation for correctness/completeness and ensure all housekeeping items have been addressed prior to merging the code.
126
+
127
+
- Correctness/completeness
128
+
1. Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
129
+
1. Does the code meet the acceptance criteria?
130
+
- If there is an associated spec, does the code match the spec?
131
+
1. Is the intention of the code captured in relevant tests?
132
+
- Does the description of each test accurately represent the assertions?
133
+
- For any test explicitly called out on the ticket as desirable to implement, was it implemented?
134
+
- If there are prose spec tests, were they implemented?
135
+
- If there are associated automated spec tests, were they all pulled in and are they all running and correctly interpreting the spec inputs?
136
+
- Are any runner changes needed to process new input types?
137
+
1. Could these changes impact any adjacent functionality?
138
+
1. Are there any errors that might not be correctly caught or propagated?
139
+
1. Is there anything that could impact performance?
140
+
1. Are there any race conditions in the functional code or tests?
141
+
1. Can you think of a better way to implement any of the functional code or tests? "Better" means any combination of:
142
+
- more performant
143
+
- better organized / easier to understand / clearer separation of concerns
144
+
- easier to maintain (easier to change, harder to accidentally break)
145
+
- Housekeeping
146
+
1. Does the title and description of the PR reference the correct jira ticket and does it use the correct conventional commit type (e.g., fix, feat, test, breaking change etc)?
147
+
- If the change is breaking, ensure there is an exclamation mark after the scope (e.g., "fix(NODE-xxx)!: \<description\>" )
148
+
1. If there are new TODOs, has a related JIRA ticket been created?
149
+
1. Are symbols correctly marked as internal or public?
150
+
1. Do the Typescript types match expected runtime usage? Are there tests for new or updated types?
151
+
1. Should any documentation be updated?
152
+
- Has the relevant internal documentation been updated as part of the PR?
153
+
- Have the external documentation requirements been captured in jira?
0 commit comments