doc: add minutes for meeting June 18 2025

meetings/2025-06-18.md

@@ -0,0 +1,108 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2025-06-18
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=um3gtm07EiI>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1749>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Ruben Bridgewater @BridgeAR (voting member)
+* Gireesh Punathil @gireeshpunathil (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Darshan Sen @RaisinTen (voting member)
+* Richard Lau @richardlau (voting member)
+* Robert Nagy @ronag (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+
+## Agenda
+
+### Announcements
+
+### Reminders
+
+* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/recognizing-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.
+
+* Matteo - nothing for the public section
+
+### nodejs/node
+
+* Remove `Symbol.dispose` integration in `setTimeout` and `setInterval` [#58689](https://github.com/nodejs/node/issues/58689)
+  * Matteo, came from discussion I had with Lucas after presentation
+    which talked about leveraging the using feature.
+  * Michael, main issue is with compatibility Web.
+  * But it is different anyway in terms of the return, but actual code usage is the same because
+    the return type does not end up mattering when writing the code
+  * Matteo: So before the code would work on both despite the two different return types
+  * Richard, will point out it has already been shipped, so more complicated to change
+  * Matteo, in terms of back portable not possible because using syntax
+  * Joyee:  symbol dispose in timers has shipped since 18.x, will need a full deprecation cycle
+  * Darshan: likely not very practical to change the return types, maybe have a WebTimers API
+    which would allow us to support both.
+    * Ruben, challenge is that existing code likely still expects compatible API
+  * Joyee, not sure how widespread the use of the non-
+  * Darshan, possibility of feature flag where it would return different type
+  * Matteo, 2 concerns, first generic compatibility, unlikely we can every shift it back as ref and
+    unref are super popular. Don’t think we should embark on that journey unless other runtimes
+    willing to invest the significant time/effort that would be needed.
+  * Matteo, maybe we should invite Luca to to explain further. Biggest difference from the web
+  * Ruben, since it's already incompatible, maybe it would be better with new API
+    * Matteo, problem is that in the Web its used from the global
+  * Matteo how about we invite Luca? Ruben, not sure if that will add additional info.
+  * Joyee, how about we think about how to avoid it in the future.
+    * Michael agree that documenting that we won’t add changes that will take us away to from
+      web compatibility in general - Michael will volunteer.
+    * Joyee, bot that flags updates to globals,
+    * Matteo also good to have bot add comments on the issues
+  * Please jump into the issue to discuss
+
+* Update npm to v11 in Node.js v22 [#58423](https://github.com/nodejs/node/issues/58423)
+  * on agenda as it is technically SemVer major so would need TSC approval to land
+  * npm does not have an LTS policy, v11 has some changes we probably want
+  * Matteo: I believe we should land it.
+  * Michael: major breaking change?, Matteo -> warnings
+  * Joyee: could users just update their version of npm on their own. Comes down to the risk
+    balance between updating, versus not updating
+  * Richard: there is also an unknown breaking change as one of the life-cycle scripts is no
+    longer run
+  * Matteo: its also about Node.js 22 still having a long time to run, will make the life of the
+    project to move now versus possibly being forced to later.
+  * Ruben: We also have the concern related to security fixes. If we had to update later that
+    That would be worse. We can also run CITGM
+  * Joyee: what is the opinion of the npm team?  Cannot tell from the issue
+  * Rafael: in terms of security, I believe we could wait until there is a CVE, at that point we
+    could do a security release with the update to 11. It is our standard practice to include
+    breaking changes as SemVer minor when needed in security releases. Better to wait to give
+    more time to see how the changes affect people in 24.x
+
+* Revert <https://github.com/nodejs/node/pull/56664> [#58282](https://github.com/nodejs/node/pull/58282)
+  * Nothing to discuss this week.
+
+### nodejs/nodejs.org
+
+* Add blog post publishing guidelines [#7860](https://github.com/nodejs/nodejs.org/pull/7860)
+  * change is to align with Marketing discussion.
+  * On agenda as FYI to TSC members.
+
+### nodejs/TSC
+
+* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614)
+  * Skipped for this week.
+
+## Strategic Initiatives
+
+* Skipped for this week.
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.