Shared config for Smartcare's projects.
There are 2 packages of interest:
@smart-care/tsconfig
: Shared basetsconfig.json
. See README.@smart-care/eslint-config-smartcare
: Shared ESLint config. See README.
These guidelines are adapted from the TypeScript core's contributor coding guidelines.
Table of Contents
- Names
- Exports
- Components
- Types
null
andundefined
- General Assumptions
- Flags
- Comments
- Strings
- When to use
any
- Diagnostic Messages
- General Constructs
- Style
- Use PascalCase for type names.
- Do NOT use "I" as a prefix for interface names.
- Use PascalCase for enum values.
- Use camelCase for function names.
- Use camelCase for property names and local variables.
- Do NOT use "_" as a prefix for private properties.
- Use whole words in names when possible.
- Use
isXXXing
orhasXXXXed
for variables representing states of things (e.g.isLoading
,hasCompletedOnboarding
). - Give folders/files/components/functions unique names.
- Only use named exports. The only exception is the component is being code-split.
- 1 file per logical component (e.g. parser, scanner, emitter, checker).
- If not kept in a separate folder, files with ".generated.*" suffix are auto-generated, do not hand-edit them.
- Tests should end with ".test.*" filename suffix
- Filename should match the component name. Interfaces for React components should be called
<ComponentName>Props
and<ComponentName>State
. The only exception is when writing a render prop. In this situation, you, the author, should call the interface for your component's props<ComponentName>Config
and then the render prop interface<ComponenName>Props
so it is easy for everyone else to use.
- Do NOT export types/functions unless you need to share it across multiple components.
- Do NOT introduce new types/values to the global namespace.
- Shared types should be defined in 'types.ts'.
- Within a file, type definitions should come first.
- Use
undefined
. Do not usenull
. EVER. If null is used (like in legacy Redux code), it should be kept isolated from other code with selectors.
- Consider objects like Nodes, Symbols, etc. as immutable outside the component that created them. Do not change them.
- Consider arrays as immutable by default after creation.
- More than 2 related Boolean properties on a type should be turned into a flag.
- Use JSDoc style comments for functions, interfaces, enums, and classes.
- Document crazy stuff. Always add
@see <url>
and the current date when referencing external resources, blog posts, tweets, snippets, gists, issues etc. - Make note conditions upon which hacks and smelly code can be removed.
- Use single quotes for strings. Double quotes around JSX string props.
- If something takes you longer than 10 minutes to type or you feel the need to read through TS Advanced Types docs, you should take a step back and ask for help, or use
any
. - Custom typings of 3rd-party modules should be added to a
.d.ts
file in atypings
directory. Document the date and version of the module you are typing at the top of the file. - Consider rewriting tiny modules in typescript if types are too hard to think through.
- Use a period at the end of a sentence.
- Use indefinite articles for indefinite entities.
- Definite entities should be named (this is for a variable name, type name, etc..).
- When stating a rule, the subject should be in the singular (e.g. "An external module cannot..." instead of "External modules cannot...").
- Use present tense.
- Use active voice.
For a variety of reasons, we avoid certain constructs, and use some of our own. Among them:
- Do NOT use
for..in
statements; instead, usearr.forEach
,Object.keys(obj).forEach
,Object.values(obj).forEach
andObject.entries(obj).forEach
. Be aware of their slightly different semantics. - Try to use
arr.forEach
,arr.map
, andarr.filter
instead of loops when it is not strongly inconvenient.
- Use Prettier and ESLint.
- Use arrow functions over anonymous function expressions.
- Only surround arrow function parameters when necessary.
For example,(x) => x + x
is wrong but the following are correct:x => x + x
(x: T) => x + x
(x,y) => x + y
<T>(x: T, y: T) => x === y
- Always surround loop and conditional bodies with curly braces. Statements on the same line are allowed to omit braces.
- Open curly braces always go on the same line as whatever necessitates them.
- Parenthesized constructs should have no surrounding whitespace.
A single space follows commas, colons, and semicolons in those constructs. For example:for (var i = 0, n = str.length; i < 10; i++) { }
if (x < 10) { }
function f(x: number, y: string): void { }
- Use a single declaration per variable statement
(i.e. usevar x = 1; var y = 2;
overvar x = 1, y = 2;
). - Use 2 spaces per indentation.
MIT LICENSE