Skip to content

Commit 1403ac6

Browse files
authored
Update contribution guidelines (#3053)
1 parent ba0a502 commit 1403ac6

File tree

1 file changed

+27
-15
lines changed

1 file changed

+27
-15
lines changed

docs/contribution-guidelines.md

Lines changed: 27 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,24 +1,25 @@
11
# Contribution Guidelines
22

3-
- Include documentation reference(s) at the top of each file as a comment. For example:
3+
- Include documentation reference(s) at the top of each file as a comment. For example:
44

55
```ts
66
// http://officeopenxml.com/WPdocument.php
77
```
88

99
<!-- cSpell:ignore datypic -->
10+
1011
It can be a link to `officeopenxml.com` or `datypic.com` etc.
1112
It could also be a reference to the official ECMA-376 standard: https://www.ecma-international.org/publications-and-standards/standards/ecma-376/
1213

13-
- Include a portion of the schema as a comment for cross reference. For example:
14+
- Include a portion of the schema as a comment for cross reference. For example:
1415

1516
```ts
1617
// <xsd:element name="tbl" type="CT_Tbl" minOccurs="0" maxOccurs="1"/>
1718
```
1819

19-
- Follow Prettier standards, and consider using the [Prettier VSCode](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) plugin.
20+
- Follow Prettier standards, and consider using the [Prettier VSCode](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) plugin.
2021

21-
- Follow the `ESLint` rules
22+
- Follow the `ESLint` rules
2223

2324
## Always think about the user
2425

@@ -37,13 +38,15 @@ Please write good commit messages when making a commit: https://chris.beams.io/p
3738
**Do not:**
3839

3940
<!-- cspell:disable -->
41+
4042
```
4143
c // What?
4244
rtl // Adding acronyms without explaining anything else is not helpful
4345
works! // Glad its working, but the message is not helpful
4446
demo updated // Getting better, but capitalize the first letter
4547
Unesesary coment removed // Make sure to use correct spelling
4648
```
49+
4750
<!-- cspell:enable -->
4851

4952
**Do**
@@ -104,22 +107,25 @@ private get _level: string;
104107
private get level: string;
105108
```
106109

107-
## Interfaces over type alias
110+
## Types over interfaces
108111

109-
Do not use `type`, but rather use `Interfaces`. `type` cannot be extended, and a class cannot implement it.
112+
Using `type` aliases in TypeScript offers several advantages over `interfaces`:
110113

111-
> "In general, use what you want ( type alias / interface ) just be consistent"
112-
> "always use interface for public API's definition when authoring a library or 3rd party ambient type definitions"
113-
>
114-
> - https://medium.com/@martin_hotell/interface-vs-type-alias-in-typescript-2-7-2a8f1777af4c
114+
- **Flexibility with Complex Types**: `type` supports defining unions, intersections, and other complex type constructs that `interfaces` cannot handle. For example:
115115

116-
`Interface` is generally preferred over `type`: https://stackoverflow.com/questions/37233735/typescript-interfaces-vs-types
116+
```typescript
117+
type StringOrNumber = string | number;
118+
type Combined = TypeA & TypeB;
119+
```
117120

118-
**Do not:**
121+
- **Support for Primitive Types**: `type` can alias primitive types (e.g., `type ID = string`), while `interfaces` are limited to object shapes.
122+
- **Tuple and Array Types**: `type` allows defining tuples and specific array types easily (e.g., `type Point = [number, number]`), which `interfaces` cannot represent.
123+
- **Utility Types Compatibility**: `type` works seamlessly with TypeScript's utility types (e.g., `Partial<T>`, `Pick<T, K>`), enabling more expressive type transformations.
124+
- **Functional Programming**: `type` is ideal for functional programming patterns, such as defining function signatures or mapped types, due to its versatility.
125+
- **No Declaration Merging**: Unlike `interfaces`, type does not support declaration merging, which can prevent accidental type extensions and ensure predictable type definitions.
126+
- **Consistent Pattern**: This project uses `type` for all type definitions, so using `type` for all type definitions maintains consistency and readability across the codebase.
119127

120-
```ts
121-
type RelationshipFileInfo = { id: number; target: string };
122-
```
128+
Detailed discussion: https://stackoverflow.com/questions/37233735/typescript-interfaces-vs-types
123129

124130
**Do:**
125131

@@ -130,6 +136,12 @@ interface IRelationshipFileInfo {
130136
}
131137
```
132138

139+
**Do not:**
140+
141+
```ts
142+
type RelationshipFileInfo = { id: number; target: string };
143+
```
144+
133145
## String enums vs type
134146

135147
To take full advantage of TypeScript's typing system, its best to use `string enums`:

0 commit comments

Comments
 (0)