Meeting notes for 09/29

meetings/2025-09-29.md

@@ -0,0 +1,100 @@
+# Node.js Web Team Meeting 2025-09-29
+
+## Links
+
+* **GitHub Issue**: https://github.com/nodejs/web-team/issues/43
+
+## Present
+
+* Aviv Keller @avivkeller
+* Claudio Wunder @ovflowd
+* Alex Bit @alexbit-codemod (Guest, Userland Migrations)
+* Dario Piotrowicz @dario-priotrowicz
+* Matt Cowley @MattIPv4
+* Rene @Renegade334 (Guest, TypeScript)
+* Jake Bailey @jakebailey (Guest, TypeScript)
+* Brian Muenzenmeyer @bmuenzenmeyer
+* Bruno Rodriguez @brunocroh (Guest, Userland Migrations)
+
+## Agenda
+
+* Extracted from **web-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
+
+
+### nodejs/nodejs.org
+
+* content(`userland-migration`): make up to date [#8053](https://github.com/nodejs/nodejs.org/pull/8053)
+    * Alex, Codemod explanation. Codemods are only used when they are officially endorsed
+    * Alex, plan:
+        * "Userland Migrations" blog cat
+            * Migration guides
+            * Changelogs
+            * See other frameworks, like React, for inspiration
+        * "Userland Migrations" learn
+            * What is a codemod?
+            * Basic description
+            * **Not for migration guides**
+        * Use Docs banner for migration guides 
+    * Claudio, Migrations don't need to go in Learn, it's for concepts, not "things"
+        * Leave things light, people can use MDN for specifics
+        * Release/Other blog posts are the ideal place for these
+            * (Aviv +1)
+            * It's important to understand that certain blog posts must come from a certain team, that's not entirely in the website team's control. Perhaps get in touch with Releasers and/or Marketing.
+    * Brian, can we add banners _after_ the fact, since Codemod's take time to develop
+        * Claudio, true, Codemod's won't be instantly ready, we'd need to change the banner dynamically.
+
+### nodejs/doc-kit
+
+* Generate Type Declarations [#437](https://github.com/nodejs/doc-kit/issues/437)
+    * Brian, why doesn't Node.js ship it's own types
+    * Claudio, no runtime does, each provides out-of-house
+        * It's hard for the system to know _which_ version of Node.js you are using, and thus, another package is ideal
+        * It's hard to identify _where_ the types are
+    * Jake, if it were bundled, we (Node.js) would be respnsosible for a lot of compat we aren't expert in
+    * Current issues:
+        * "Goofy" types for cross-compat with the DOM
+        * Too many manual changes
+        * The script doesn't really use the docs *super* offten
+    * Claudio, we would like to reduce the manual work
+        * New engine (`doc-kit`) can infer interfaces
+    * Aviv, while making `doc-kit`, we noticed many issues with the current Structure
+    * Rene, the source is _human_ readable, but not very _machine_ readable
+        * Current tooling can't do multiple types in a single Array, i.e. `buffer.Blob`
+        * It's hard to interop with the Web API
+        * Making it machine readable it's fruitful, since it'll still need changes in TypeScript
+        * Documentation isn't the primary focus of code review
+        * If the docs were strongly-typed, it would help, but it would make them extremely rigid.
+    * Claudio, this is something we can and should change
+    * Jake, types are also generic, when, it reality, they are different in various TypeScript versions.
+        * In TS's DOM Lib, the raw spec is taken, converted to types, and patches are applied on top.
+    * Brian, even if we don't make it perfect and hands-off, we can make it better
+    * Aviv, we should bring these types to the collaborators, and work to make the docs rigid
+    * Rene, unless there is a shift in code review, that'll always be a problem
+        * We could, however, build better types in the markdown
+    * Claudio, we have AST in our new generator to create very precise JSON
+        * We can make this format entirely our own, as consumable and reliable as possible
+        * It's worth it to make the DX high and the pain low
+    * Claudio, DefinetelyTyped can import `doc-kit` for their parsing
+        *  Aviv, we can add a generator to put it in a format best of them
+        *  Claudio, we can lint the docs to make their types compatible
+    * Rene, we can leverage this, but garbage in -> garabage out
+        * It'll cause an awful lot of upstream changes 
+        * Aviv's PR to use the same list format was an example of something that helped standardize 
+        * The primary objective is to make the docs readable for DT maintainers
+    * Claudio, if you (Rene + Jake) can look over the codebase, and find what stands out, and what is needed, now is the best time to make changes
+        * We appreciate DTS, and we wan't to give back
+        * We have the ability to do so much
+        * We do need to, however, change the status quo on the docs
+    * 
+
+### nodejs/web-team
+
+* Create Means for Private Communications [#14](https://github.com/nodejs/web-team/issues/14)
+
+    * 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.