meeting 2024-08-28

.gitignore

@@ -128,3 +128,4 @@ dist
 .yarn/build-state.yml
 .yarn/install-state.gz
 .pnp.*
+.DS_Store

meetings/2024-08-28.md

@@ -0,0 +1,78 @@
+# Node.js  TypeScript team Meeting 2024-08-28
+
+## Links
+
+* **Recording**: <https://zoom.us/rec/share/I0O7u3h6xFIay4lOBrIuvOXJNyDQloSdxk3IOmCjU-iaR_ExDTlcsQjAW_VMOpTf.BButid5V-V6h1-oq>
+* **GitHub Issue**: <https://github.com/nodejs/typescript/issues/5>
+
+## Present
+
+* Typescript team: @nodejs/typescript
+* Marco Ippolito: @marco-ippolito
+* Rob Palmer @robpalme
+* Lucas Santos @khaosdoctor
+* Andrew Branch @andrewbranch
+* Daniel Rosenwasser @DanielRosenwasser
+* Michael Dawson @mhdawson
+* ZiJian Liu @Lxxyx
+* Shadrach Ekpo @shadrach-se
+* Jake Bailey @jakebailey
+* Jake Yuesong Li @jakecastelli
+
+## Agenda
+
+## Announcements
+
+* Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
+
+### nodejs/loaders
+
+* Roadmap for experimental TypeScript support [#217](https://github.com/nodejs/loaders/issues/217)
+
+  * Node.js advancing in the roadmap, fixing bugs, (some work on sourcemaps).
+  * Consensus is before unflagging we need to test with bigger codebase and have proper tooling.
+  * TypeScript working on <https://github.com/microsoft/TypeScript/issues/59601>
+to support –strip-types with ‘.ts’ extensions (might be released on ts 5.7).
+  * Andrew showcasing the work.
+    * showed a way to use the Node.js experimental features with monorepos
+    * Marco mentioned that monorepos were out of scope to start, but great to see that it worked better than expected.
+    * Rob, people are naturally want to grow up to larger projects so important to explore this
+      * There are two bits that we need for this to work, one that we’ve just seen, forking imports to `.js’ and`.ts`, will see that pattern a lot and still be bit more overhead that ideal
+      * The other bit is that it implies that something is doing extension re-writing as part of the compilation.
+      * Daniel, only need to work about that if you are publishing to npm, as Node.js will not run TS from npm modules
+      * Andrew, the demo that was least visible, is that it does rely on the prototype of a flag in TS that does rewrites, tsconfig flag that rewrites relative imports. One PR into functionality that might make it into the next version of TS.
+      * Andrew, agreeing on the boilerplate side of things, originally thought that maybe we should do something. Had thought that maybe Node.js should set a condition, but after experimenting I was much more hesitant about that, as I liked the level of control by setting them myself. Lower chance of affecting people using/consuming the library. Happy to brainstorm ideas/approaches but current thought that it is safer to avoid Node. defining the condition.
+      * Daniel, if there was a way to make a condition truly private that would be useful, but I guess it would be nice to have.
+
+* Import specifiers in `--experimental-strip-types` [#214](https://github.com/nodejs/loaders/issues/214)
+  * This is kind of what we were just talking about
+  * It implies that if you are allowing people to write ts files, then there must be a tool to rewrite to
+     js to run.
+  * Jake, no action needed, the current iterator works as expected?
+  * Rob, without Marco here it's a bit harder to understand the intent.
+  * Rob, intent do they like the concept of extension rewriting
+    * rewriting is implied because you want to publish
+  * Jake, if you don’t care about anybody running without the flag. But what happens if people
+    publish code, it also adds another dimension of support
+  * Andrew, what we’ve seen users really like to think in terms of their Typescript files, like to write .ts extensions, strategy also makes Node.js not have to change its module resolution algorithm. Re-writing support, that makes specifying the ts specifiers makes the approach more durable. There was a suggestion that Node.js accept js, but if we can get rewriting working then that is the best approach to pursue to start
+  * Daniel, not much to add even with a workspace, you technically don’t need to rewrite, mostly a product of how you want to set things up. Room for these things to develop over time.
+  * Don’t want people to have to worry about TS compatibility
+  * Michael, asked question to clarify understanding of extension re-writing
+  * Rob, runtime versus ahead of time rewrite, from past history, very important that imports can be statically analyzed. So even if runtime shim did it, would consider constraining it to those that could be done ahead of time.
+    * Daniel, for example, if it could not be rewritten ahead of time?
+    * Rob, existing tools offer options to constrain
+    * Andrew, were not going to put restriction that some part needs to be statically analysable
+    * Limited to relative paths as can be more confident as to what will happen, versus bare specifiers.
+    * Rob, typescript needs to know to provide types
+    * Daniel, in that case you need to provide a typecast that convinces us that you know what you are doing.
+    * Jake made a good next step, look at existing bundlers. They are so widely used, the constraints they impose are well respected. e.g. esbuild can resolve the ts in a dynamic import <https://jakebailey.dev/esbuild-playground/#v3=PTAEAEDMEsBsFMB2BDAtvAXKaiAm8APAOgBcBnAKEIAcB7AJxNGTIE9EBjUSAV05Oi1EoAILVqACgCUoAN4VQoDkLJMCoALzMA7smhNoqOowkAiIsGS589UmVNSA3AtD14JHvWHEruCQEYAGlAAJikKAF8KChAIGAQUdCxfeFtyKgJjJl5+QWFfCWQsRB5UACNU4LLi0or6GXlFNw8vZlAAalAy5yigA>
+
+## Q&A, Other
+
+[Q] Do other runtimes support sourcemaps by default? And do the users think it's a performance issue?
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.