-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial guidelines for JavaScript and TypeScript #11
Conversation
2fbc8e3
to
31f6326
Compare
31f6326
to
b5d16de
Compare
6b3a793
to
6ec68d0
Compare
2a5ddf3
to
dffe1dd
Compare
72aadda
to
7269c7c
Compare
9f8db81
to
27219ab
Compare
27219ab
to
455be22
Compare
These were copied from the notes that I've been keeping in Notion (see "Code Guidelines"). I tried to list best practices that I thought were already being followed in some form, so hopefully none of them should be too controversial.
455be22
to
acbcc47
Compare
|
||
These guidelines specifically apply to TypeScript. | ||
|
||
## Provide explicit return types for functions/methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be enforced with ESLint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I've added the explicit-function-return-type
rule here: MetaMask/eslint-config#314
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, given that we have some ESLint rules that we've enabled ourselves, what do we feel about explicitly documenting the reason for doing so? That means we'd keep this here but then have something at the top that says something like:
> **Note**
> This guideline is enforced via [`explicit-function-return-type`](/link/to/rule/in/our/eslint-config).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems like a good idea to me. We can remove it later if we don't think it has been useful.
Generally it would be nice to keep this guide shorter, and let ESLint explain things for us where possible. But the ESLint rules don't explain our reasoning very well. I wish we could.... explain the reasons for lint rules inline and advise a course of action, something like that. Ah well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed... okay. I can add this in a followup PR once we have a new version of eslint-config
out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things that would be nice to have guidelines for:
- prefer
ts-expect-error
overts-ignore
- When should we use
ts-expect-error
? - When is it OK to use
any
? - How to effectively narrow types (particularly when dealing with
unknown
).- Related: how to write type guard functions
- No unnecessary generic parameters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay! I will add these in a followup PR.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* `jest.spyOn(object, method)` can be used in place of `sinon.stub(object, method)` (with the caveat that the method being spied upon will still be called by default). | ||
* `jest.useFakeTimers()` can be used in place of `sinon.useFakeTimers()` (though note that Jest's "clock" object had fewer features than Sinon's prior to Jest v29.5). | ||
|
||
## Don't test private code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to expand more on the reasoning behind this.
e.g.
- Explain how this ties in with a broader BDD-like testing philosophy,
- Tests are more useful for preventing regressions and helping document intended behavior when they only reflect the public API
- This ensures the tests help make refactoring easier, rather than getting in the way
This is a great start though! I can follow up to add more detail later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Co-authored-by: Maarten Zuidhoorn <maarten@zuidhoorn.com>
Co-authored-by: Maarten Zuidhoorn <maarten@zuidhoorn.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⭐ 💯
These were copied from the notes that I've been keeping in Notion (see "Code Guidelines"). I tried to list best practices that I thought were already being followed in some form, so hopefully none of them should be too controversial.
Fixes #10.
👉🏻 See rendered JavaScript guidelines 👈🏻
👉🏻 See rendered TypeScript guidelines 👈🏻