doc: add minutes for meeting 2 Aug 2023

meetings/2023-08-02.md

@@ -0,0 +1,103 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2023-08-02
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=QfIO1M68FfY>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1421>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Yagiz Nizipli @anonrig (voting member)
+* Benjamin Gruenbaum @benjamingr (voting member)
+* Ruben Bridgewater @bridgear (voting member)
+* Colin Ihrig @cjihrig (voting member)
+* Geoffrey Booth @GeoffreyBooth (voting member)
+* Gireesh Punathil @gireeshpunathil (voting member)
+* James Snell @jasnell (voting member)
+* Chengzhong Wu @legendecas (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Moshe Atlow @MoLow (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Darshan Sen @RaisinTen (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Tobias Nießen @tniessen (voting member)
+* Rich Trott @Trott (voting member)
+
+## Agenda
+
+### Announcements
+
+* Rafael, next security release will come out on next Tuesday
+
+### CPC and Board Meeting Updates
+
+*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting.
+
+* No board meeting updates
+* No CPC meeting updates, was working meeting this week
+
+### nodejs/node
+
+* src: add built-in `.env` file support [#48890](https://github.com/nodejs/node/pull/48890)
+  * Yagiz gave an overview as the author.
+    * In order to support NODE_OPTIONS, it needs to be read before v8 options are initialized
+    * Tweet about feature resulted in lots of feedback
+  * Geoffrey, requests going back years related to being able to define loaders through a file versus through command line arguments
+    * There had been a few PRs reading from package.json showing desire to read config through a file
+    * Ideally it would be a nicely formatted json file, but due to need to read early in startup that is difficult.
+    * Idea was then to use an already defined format based on what is used for .env
+      * still complications related to NODE_OPTIONS
+    * Not sure if we should land without support for NODE_OPTIONS, but might want to land in a stage.
+  * Matteo - have not dug into thread, but have not found answer - some of our options would then need to be extended as environment variables if NODE_OPTIONS is not supported. Geoffrey not sure it would land if NODE_OPTIONS are not supported, which answer question.
+  * Yagiz - different opinion, 90-98% positive feedback, believe we should land regardless of whether NODE_OPTIONS is supported.
+  * Darshan - are the dotenv maintainers ok with this happening, Yagiz - yes they have said they are happy to support
+  * Rafael - agree that we don’t need to support NODE_OPTIONS initially, some concerns related to permissions, reading file before options are set.
+  * Michael - another naive question not having read through the issue - just read a file with the options from a file as a string instead of environment variables.
+  * Tobias - popularity is not necessary the bar,  non-contributors always like new features. If we had added every requested feature, Node.js would contain every single npm package in core.
+    * Rich +1
+  * Benjamin - do we have consensus on landing with NODE_OPTIONS support
+    * Geoffrey - best to work for a few weeks to try to land together first
+  * Tobias - What about environment variables that affect dependencies such as UV_THREADPOOL_SIZE? If we really add this to core, it should cover the vast majority of use cases.
+  * All - worth people looking at - <https://openjs-foundation.slack.com/archives/C027PSG2PJR/p1690225162828989>
+  * Moshe, .env support is really a different feature than the support for NODE_OPTIONS, configuring options for Node.js is a separate concern
+  * Antoine - agree its a separate concern, don’t see point of waiting.
+  * Matteo, may be an argument about not supporting anything that applies to Node.js.
+    * Geoffrey but then that is the same as .env
+  * Michael but if whole point is to configure Node.jh how does it makes sense to land without NODE_OPTIONS  and other Node environment  
+  * Geoffrey, any concerns about continuing work to to figure out the NODE_OPTIONS support and then re-discuss once we figure that out
+    * nobody raised any concerns.
+  * Colin, no strong opinion on supporting environment variables, but NODE_OPTIONS is a bad way from configuring, configuring through command line flags is the better way
+
+* esm: add import.meta.dirname and import.meta.filename [#48740](https://github.com/nodejs/node/pull/48740)
+  * Antoine, ask is to add properties to import.meta. Would only be on the file protocol and would be the path and filename.  From my perspective ESM should be using URLs, strange to have properties that are only available for one protocol
+  * Geoffrey, agree with Antoine but that is not necessarily the blocker for me, but block is that this should be standardized and agreed in WinterCG before this would be added. Past experience is that if not standardized, will cause issues later on. Would be fine to add them once WinterCG agrees on a standard - <https://github.com/wintercg/proposal-common-minimum-api/issues/50>
+  * Matteo - have been one of the people who have been frustrated by this. Discussions have not been productive. Seems like people believe that it should be agnostic or that it needs to be aware of how/where it runs. What I like about Node.js is that you have that affinity with the file system. In the past it was not clear how we could provide the info. It’s a philosophical discussion so that’s why called vote as unlikely to get agreement. Getting into WinterCG is a separate discussion. Change does not remove anything from anybody not using it.
+  * Yagiz, Benjamin + 1 to what Matteo mentioned.
+  * Michael, the lack of this information has been raised as one of the blockers in moving to ESM in the latest Node.js survey.
+  * From WinterCG viewpoint, should be treated like X (missed it), we should treat things in global scope which import.meta is. Should be treated as SemVer major.  Already plan to add `import.meta.url` and `import.meta.resolve` to the minimum. That said, ok to add the bit of metadata being proposed, but ask would be some write up to WinterCG to get input to avoid other runtimes from doing something different. So coordination would be good.
+  * Michael 2 concerns, would we add, do we get on WinterCG feedback.
+  * Antoine - Bun has already exposed with different names - Bun has installed the same fields with different names: <https://bun.sh/docs/api/import-meta>
+  * Matteo no strong view on implementation or gating in terms of WinterCG, but believe we need to do it.
+  * Matteo, will open an issue, on philosophical question so that we can see if we can agree on that or not.
+
+### nodejs/TSC
+
+* Freeze releases and website changes, pending cache fixes? [#1416](https://github.com/nodejs/TSC/issues/1416)
+  * No real update.
+
+* Remaining OSSF Funding [#1384](https://github.com/nodejs/TSC/issues/1384)
+  * Heads up, next step is to move forward with proposal. Have 39k, proposal is to work on automating security release process.
+    * If there are any objections please object otherwise we’ll move forward with that.
+    * If no objections by the end of week we’ll move forward -  some of the work is outlined in <https://github.com/nodejs/security-wg/issues/860>
+
+## 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.