paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-12 09:58:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Apply sentence single-spacing from Prettier.

Browse Source 
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit 35c1c8d41b)
This commit is contained in:
Anders Kaseorg
2021-08-20 12:53:28 -07:00
committed by Tim Abbott
parent 0147c6adce
commit aa6e70382d
104 changed files with 1528 additions and 1528 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/testing/typescript.md
View File

@@ -2,7 +2,7 @@
Zulip is early in the process of migrating our codebase to use
[TypeScript](https://www.typescriptlang.org/), the leading static type
system for JavaScript. It works as an extension of the ES6 JavaScript
system for JavaScript. It works as an extension of the ES6 JavaScript
standard, and provides similar benefits to our use of
[the mypy static type system for Python](../testing/mypy.md).
@@ -33,7 +33,7 @@ The following resources are valuable for learning TypeScript:
## Type checking
TypeScript types are checked by the TypeScript compiler, `tsc`, which
is run as part of our [lint checks](linters.md). You can run the
is run as part of our [lint checks](linters.md). You can run the
compiler yourself with `tools/run-tsc`, which will check all the
TypeScript files once, or `tools/run-tsc --watch`, which will
continually recheck the files as you edit them.
@@ -41,13 +41,13 @@ continually recheck the files as you edit them.
## Linting and style
We use the Eslint plugin for TypeScript to lint TypeScript code, just
like we do for JavaScript. Our long-term goal is to use an idiomatic
like we do for JavaScript. Our long-term goal is to use an idiomatic
TypeScript style for our TypeScript codebase.
However, because we are migrating an established JavaScript codebase,
we plan to start with a style that is closer to the existing
JavaScript code, so that we can easily migrate individual modules
without too much code churn. A few examples:
without too much code churn. A few examples:
- TypeScript generally prefers explicit `return undefined;`, whereas
our existing JavasScript style uses just `return;`.
@@ -72,22 +72,22 @@ Our plan is to order which modules we migrate carefully, starting with
those that:
- Appear frequently as reverse dependencies of other modules
(e.g. `people.js`). These are most valuable to do first because
(e.g. `people.js`). These are most valuable to do first because
then we have types on the data being interacted with by other
modules when we migrate those.
- Don't have large open pull requests (to avoid merge conflicts); one
can scan for these using [TinglingGit](https://github.com/zulip/TinglingGit).
- Have good unit test coverage, which limits the risk of breaking
correctness through refactoring. Use
correctness through refactoring. Use
`tools/test-js-with-node --coverage` to get a coverage report.
When migrating a module, we want to be especially thoughtful about
putting together a commit structure that makes mistakes unlikely and
the changes easy to verify. E.g.:
the changes easy to verify. E.g.:
- First a commit that just converts the language to TypeScript adding
types. The result may potentially have some violations of the
long-term style we want (e.g. not using `const`). Depending on how
types. The result may potentially have some violations of the
long-term style we want (e.g. not using `const`). Depending on how
we're handling linting, we set some override eslint rules at the top
of the module at this stage so CI still passes.
- Then a commit just migrating use of `var` to `const/let` without