1
1
# Contribution Guidelines
2
2
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:
4
4
5
5
``` ts
6
6
// http://officeopenxml.com/WPdocument.php
7
7
```
8
8
9
9
< ! -- cSpell :ignore datypic -- >
10
+
10
11
It can be a link to ` officeopenxml.com ` or ` datypic.com ` etc .
11
12
It could also be a reference to the official ECMA - 376 standard : https :// www.ecma-international.org/publications-and-standards/standards/ecma-376/
12
13
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 :
14
15
15
16
` ` ` ts
16
17
// <xsd:element name="tbl" type="CT_Tbl" minOccurs="0" maxOccurs="1"/>
17
18
` ` `
18
19
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.
20
21
21
- - Follow the ` ESLint ` rules
22
+ - Follow the ` ESLint ` rules
22
23
23
24
## Always think about the user
24
25
@@ -37,13 +38,15 @@ Please write good commit messages when making a commit: https://chris.beams.io/p
37
38
** Do not : **
38
39
39
40
< ! -- cspell : disable -- >
41
+
40
42
` ` `
41
43
c // What?
42
44
rtl // Adding acronyms without explaining anything else is not helpful
43
45
works! // Glad its working, but the message is not helpful
44
46
demo updated // Getting better, but capitalize the first letter
45
47
Unesesary coment removed // Make sure to use correct spelling
46
48
` ` `
49
+
47
50
< ! -- cspell : enable -- >
48
51
49
52
** Do **
@@ -104,22 +107,25 @@ private get _level: string;
104
107
private get level: string;
105
108
` ` `
106
109
107
- ## Interfaces over type alias
110
+ ## Types over interfaces
108
111
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 ` :
110
113
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 :
115
115
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
+ ` ` `
117
120
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 .
119
127
120
- ```ts
121
- type RelationshipFileInfo = { id: number ; target: string };
122
- ` ` `
128
+ Detailed discussion : https :// stackoverflow.com/questions/37233735/typescript-interfaces-vs-types
123
129
124
130
** Do :**
125
131
@@ -130,6 +136,12 @@ interface IRelationshipFileInfo {
130
136
}
131
137
` ` `
132
138
139
+ ** Do not :**
140
+
141
+ ` ` ` ts
142
+ type RelationshipFileInfo = { id: number; target: string };
143
+ ` ` `
144
+
133
145
## String enums vs type
134
146
135
147
To take full advantage of TypeScript ' s typing system, its best to use `string enums`:
0 commit comments