1
1
# Maintaining types for Node.js
2
2
3
- While JavaScript is an untyped language, there are a number of complementary
4
- technologies like [ TypeScript] ( https://www.typescriptlang.org/ ) and
5
- [ Flow] ( https://flow.org/ ) which allow developers to use types within their
6
- JavaScript projects. While many people don't use types, there are enough
7
- who do that the project has agreed it's important to work towards having
8
- [ suitable types for end-users] ( https://github.com/nodejs/node/blob/master/doc/contributing/technical-priorities.md#suitable-types-for-end-users ) .
3
+ While JavaScript is a weakly-typed language, there are some complementary tools
4
+ like [ TypeScript] [ ] and [ Flow] [ ] , which allow developers to annotate the source
5
+ code of their JavaScript projects. While many people don't annotate their code,
6
+ or make use of annotations at all, there are enough who do that the project has
7
+ agreed it's important to work towards having [ suitable types for end-users] [ ] .
9
8
10
9
## High level approach
11
10
12
11
There are a number of ways that types could be maintained for Node.js ranging
13
12
from shipping them with the Node.js runtime to having them be externally
14
13
maintained.
15
14
16
- The different options were discussed as part of the
17
- [ next-10] ( https://github.com/nodejs/next-10/blob/main/meetings/summit-nov-2021.md#suitable-types-for-end-users )
18
- effort and it was agreed that maintaining them externally is the best approach.
15
+ The different options were discussed as part of the [ next-10] [ ] effort and it
16
+ was agreed that maintaining them externally is the best approach.
19
17
Some of the advantages to this approach include:
20
18
21
19
* Node.js maintainers do not need to be familiar with any given type
@@ -34,22 +32,22 @@ The agreement was that the ideal flow would be as follows:
34
32
35
33
When you run ` make doc ` the canonical markdown files used to
36
34
document the Node.js APIs in the
37
- [ doc/api] ( https://github.com/nodejs/node/tree/master/doc/api )
35
+ [ doc/api] [ ]
38
36
directory are converted to both an ` .html ` file and a ` .json ` file.
39
37
40
38
As part of the regular build/release process both the ` html ` and
41
- ` json ` files are published to [ nodejs.org] ( https://nodejs.org/en/docs/ ) .
39
+ ` json ` files are published to [ nodejs.org] [ ] .
42
40
43
41
The generator that does the conversion is in the
44
- [ tools/doc] ( https://github.com/nodejs/node/tree/master/tools/doc )
42
+ [ tools/doc] [ ]
45
43
directory.
46
44
47
45
## Markdown structure
48
46
49
47
The constraints required on the markdown files in the
50
- [ doc/api] ( https://github.com/nodejs/node/tree/master/doc/api ) directory
48
+ [ doc/api] [ ] directory
51
49
in order to be able to generate the JSON files are defined in the
52
- [ documentation-style-guide] ( https://github.com/nodejs/node/blob/master/doc/README.md#documentation-style-guide ) .
50
+ [ documentation-style-guide] [ ] .
53
51
54
52
## Planned changes (as of Jan 1 2022)
55
53
@@ -61,3 +59,12 @@ afterwards.
61
59
There is an ongoing effort to add additional markdown constraints and
62
60
then update the flow in order to be able to generate a better
63
61
JSON output.
62
+
63
+ [ Flow ] : https://flow.org/
64
+ [ TypeScript ] : https://www.typescriptlang.org/
65
+ [ doc/api ] : https://github.com/nodejs/node/tree/HEAD/doc/api
66
+ [ documentation-style-guide ] : https://github.com/nodejs/node/blob/HEAD/doc/README.md#documentation-style-guide
67
+ [ next-10 ] : https://github.com/nodejs/next-10/blob/HEAD/meetings/summit-nov-2021.md#suitable-types-for-end-users
68
+ [ nodejs.org ] : https://nodejs.org/en/docs/
69
+ [ suitable types for end-users ] : https://github.com/nodejs/node/blob/HEAD/doc/contributing/technical-priorities.md#suitable-types-for-end-users
70
+ [ tools/doc ] : https://github.com/nodejs/node/tree/HEAD/tools/doc
0 commit comments