-
Notifications
You must be signed in to change notification settings - Fork 133
/
2024-07-24.md
178 lines (159 loc) · 12.8 KB
/
2024-07-24.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
# Node.js Technical Steering Committee (TSC) Meeting 2024-07-24
## Links
* **Recording**: <https://youtube.com/live/BN7OrlNtQvo>
* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1600>
## Present
* Antoine du Hamel @aduh95 (voting member)
* Yagiz Nizipli @anonrig (voting member)
* Benjamin Gruenbaum @benjamingr (voting member)
* Ruben Bridgewater @BridgeAR (voting member)
* Geoffrey Booth @GeoffreyBooth (voting member)
* Joyee Cheung @joyeecheung (voting member)
* Chengzhong Wu @legendecas (voting member)
* Marco Ippolito @marco-ippolito (voting member)
* Matteo Collina @mcollina (voting member)
* Michael Dawson @mhdawson (voting member)
* Moshe Atlow @MoLow (voting member)
* Rafael Gonzaga @RafaelGSS (voting member)
* Richard Lau @richardlau (voting member)
* Robert Nagy @ronag (voting member)
* Ruy Adorno @ruyadorno (voting member)
* Paolo Insogna @ShogunPanda (voting member)
* Daniel Rosenwasser (invited, from the TypeScript team)
* Aaron Frost (invited, from the TypeScript team)
* Jake Bailey (invited, from the TypeScript team)
* Ryan Cavanaugh @ryanca (invited, from the TypeScript team)
## Agenda
### Announcements
* Marco, just released 20.16.0
### Reminders
* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight)
### CPC and Board Meeting Updates
*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
* No updates this week.
### nodejs/node
* module: add --experimental-strip-types [#53725](https://github.com/nodejs/node/pull/53725)
* Dan Rosenwasser: we don't want to have fragmentation. People asked for disabling namespace/module support, but we got pushback.
* Most typescript is not a subset and UX for many might be sub-optimal because of that
* Should Typescript be able to run from node modules, ie should ts files be run from
Dependencies.
* hard for IDEs to reparse/everything in node_modules
* syntax hazard. Don’t want to upgrade/degrade TypeScript just to use a dependency.
* typescript source should not be the single source of truth.
* so don’t think it’s a good idea to publish runnable ts in modules
* Not saying that we should not pursue anything, but need to have good design
consideration, otherwise doing a disservice
* Ryanca
* if you can run a ts file directly with Node.js, then what does that mean when you want to
publish that code.
* if Node.js does not run ts files in node_modules to force proper publishing, then …
* how to support monorepo without running ts files in node_modules
* Geoffery (chat): Support regular typescript is supported today via —import=tsx
* Benjamin
* concerns are reasonable, but want to emphasize that PR would be experimental, could take
a while to solidify, and that can include addressing concerns over time.
* (chat) Didn’t want to take everyone’s time - for Monorepo it’s not a new problem for Node+TS it’s something monorepo tools (and users) need to configure anyway?
* Matteo
* biggest struggle is workflow that many tools will run tests in typescript form, but then when in
production you can’t, running through type stripper or in compiled form.
* Agree that it should not run ts files in node_modules
* My idea is either for local development or , don’t want to change publishing workflow. That
should stay the same. Does mean that mono-repo users will have trouble. But those are
complex already, and ok to leave it to them to figure it out. Instead cater for the smaller
end user with what is in –experimental-strip-types
* Benjamin (chat): (As in, this happening in Node doesn’t save any configuration regarding
whether files are transformed, and users need to do that orthogonally anyway)
* Marco (chat): Spreadsheet with ts features from all runtimes <https://docs.google.com/spreadsheets/d/1CfWrPo4PNYC1db0ucyHPb54XhbaB9S1zN15pFQPfVVQ/edit?gid=0#gid=0>
* Marco: the PR is the first step.
* agree that node_modules should not be included.
* user want to use latest TypeScrpt features without been locked to a pinned version. The (type-strip) loader can be upgraded separately.
* Robert: a bit worried about the experimental rabbit hole, were we cannot remove
* Daniel: more worried about the messaging. Strong signal with the experimental feature landing. What’s the next step to push it to be more stable? This is actually people have been asked about?
* Benjamin (chat): I’m not worried about the experimental feature since there is a very easy off-ramp with the loader as a “regular loader"
* Michael (chat): What about starting with it as a regular loader, published as an npm from the nodejs org ?
* Daniel what would the next steps be after it landed?
* Marco: full typescript is already supported, this is to improve UX without having to go that far.
* Geoffrey (chat): I don’t know why people would use that when tsx already exists and does more
* Jake (chat): the monorepo thing can theoretically be solved with a custom monorepo specific condition (like what tshy can emit, what the zod dev has been trying for the v4 branch), though there are some big gotchas there
* Matteo (chat): `tsx` does not do any type checking.
* Geoffery (chat): Neither does our implementation
* Michael: why not a loader published to npm
* Marco: a loader already exists.
* Jake (chat): I think people in general do not want the type checking aspect at all, honestly
* Ryan (chat): People initially think they want typechecking pre-run and then quickly realize it's not a great idea
* benjamin (chat): I think DX wise a regular loader wouldn’t address the users’ ask
* Jake (chat): my hand is going to be to ask about the future of loaders, based on the comments from the last loaders meeting that we didn't have time to get into
* Dan Rosenwasser (chat): Yes, we've generally seen a lot of people decouple type-checking from building
* Matteo: is not doing any TypeChecking at runtime a good thing?
* one side, something that should run before running your code, other side is its just a UI
thing.
* this is a key question that we should answer, and possibly give the user the 2 options
* <https://github.com/nodejs/issues/43818>
* ts-node versus tsx, much more usage of ts-node versus tsx which just does type stripping
* Jake (chat): the answer to "do we want type checking at runtime" is "no"
* Joyee (chat): I think that flow can be achieved with something like noderc or a preload config in package.json + tsx/ts-node
* Joyee (chat): <https://github.com/nodejs/node/issues/53787> discussions about .noderc/preload in package.json
* benjamin (chat): ts-node also often runs as a type stripper
* Joyee (chat): I think tsx can also perform transforms?
* benjamin (chat): As in, I’ve used ts-node/traspileOnly (even using swc)
* Joyee (chat): It’s all configs
* Antoine: could have both type stripping feature, as well as what was proposed in Matteo’s earlier issue. But hide the feature with a build flag.
* Geoffrey (chat): tsx can do transforms. ts-node isn’t actively maintained anymore and can’t be used with —import
* Marco: the PR has no compile flag. It’s a runtime flag.
* Benjamin (chat): That’s fine, but if we’re measuring ts-node vs. tsx we can’t use ts-node as evidence for type checking
* Jake
* general consensus from TypeScript team at runtime is that typechecking should not be
done. Other runtimes seem to take that approach as well.
* future work to make loaders to use, some of the friction is that people don’t want to add
command line for loaders. What is the work to auto-load loaders? If that was done would we
need this feature in core? If it existed would people just use the existing loaders?
* Joyee (chat): I think a “preload” field in package.json would be very simple to implement
* Benjamin (chat): This “loader” work is essentially a more generic version of what Marco has been doing with amaro, it makes it “by default but replaceable and pluggable"
* Benjamin, the work to pull out is along the lines of what was mentioned in terms of auto
loading.
* users are looking very specifically for TypeScript, not loaders to help with that.
* Marco, since amaro has been separated out, makes supporting different options easier. What
would make me happy to continue to cooperate as part of amaro, but don’t see it starting
as something outside of core.
* Jake (chat): well, >70% of JS users are actually TS users, so that sort of checks out
* Geoffrey (chat): There was a PR for defining loaders in package.json, and likewise for the test runner configuration under a different key; we felt that it would be best to have an overall Node config file rather than isolated bits of configuration
* Ruben, need it to just run out of the box, needs to be in core versus having to install
something else.
* Jake (chat): anything would be good, I think; I can imagine a monorepo wanting to set that above packages of course
* Matteo:
* What I described in the earlier issue is a preconfigured loader, if checks, if dep not installed, then throws nice error.
* Joyee (chat): Is "preconfigured loader" an option here?
* Michael: main difference between current proposal and what Matteo proposed in the earlier
issue is the requirement for an npm install.
* Geoffrey (chat): That’s already in progress. —env-file with support for NODE_OPTIONS was a precursor for a proper config file. Once we have the config file, then we can add things like a prompt to automatically add the configuration to set up tsx etc when the user tries to run a .ts file
* Joyee (chat): If we just implement `”preload”: [“tsx”]` in package.json, it will just work out of the box. (Tsx is also a loader implementer, they implement both CJS hooks and ESM hooks)
* Benjamin (chat): I think when I compare user experienced the default behavior “just working” is better DX than the default behavior an error being thrown.
* Joyee (chat): e.g. to run TypeScript today, you already just do `node —import tsx test.ts`, and `preload` is just a on-disk config for `--import`
* Geoffrey (chat): I think it’s not so simple as a “preload” field in package.json (what about all the various scripts in package.json, would it apply to all of them?) but we can definitely figure out a config file solution that can work
* Benjamin (chat): Also I want to emphasize that we can land/iterate and see
* Joyee (chat): If it’s just script support, `“preload”: { “test”: [“tsx”] }` would suffice
* Daniel: opt-in at a package level basis.
* Daniel, had experimented with a loader in the past, hit a few challenges, in particular in supporting commonjs, did think about whether configurations where needed to be read. In the end why compete with the existing solutions like tsx that do a good job
* Antoine: can we go back to discussing Marco’s PR
* what would need to change for it to land?
* any concern with landing with a compile time flag,
* Marco will not likely be used?
* Daniel, from TypeScript team, would be a pain if it had a compile time flag.
* any concerns with landing with only runtime flag ?
* Benjamin, as long as we communicate that it is only there for experimentation. We should
also agree that we would not move to stable with a thumbs up from TypeScript team.
* Matteo, absolutely see the problems that Ryan is seeing. Happy to say npm publishing and
mono-repos are out of scope. But value if we can do
* Ryan, most concerns are around what is the next step for the users who want to publish, or
run in mono-repo. Don’t see paths forward for that. Which is ok. Good to set expectations if
some use cases are known as out of scope. If just local apps and scripts then good to
experiment.
* Jake (chat): I don't think locking it all the way behind a compile flag is really needed
* Daniel (chat): I think Ryan's concerns are still big. There is no built-in "grow-up" story in the current implementation when it comes to npm publishing or running in a monorepo.
* Benjamin (chat): Honestly at least for now - the “grow up” story is “build the code with TSC that generates .d.ts” and we likely should recommend tsc for that (we’re probably happy to have a blessed workflow in the docs)
* Discussion continued after that, we had consensus and blessing to land the type stripping PR as experimental and consensus to listen to and apply feedback from the TypeScript team.
## Strategic Initiatives
* skipped as we ran out of time
## Upcoming Meetings
* **Node.js Project Calendar**: <https://nodejs.org/calendar>
Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.