@ShogunPanda if you send me your ssh key I'll add it to the host and give you instructions how to get into the machine.

I’m not sure what decision could need to be made? If you find a solution for the console.log issues then I think just make a PR, and if there are any tradeoffs involved they can be analyzed in the context of landing that PR.

we can do in this pr 👍🏼

CI: https://ci.nodejs.org/job/node-test-pull-request/50648/

What is the problem this feature will solve?

I'm currently in the process of putting together a Node and Deno networking library, but am running into some problems trying to align the runtime behavior around listen due to Node only supporting asynchronous (and non try/catch-able) network interface binding.

Node

import * as net from 'node:net'

try {
  const listener1 = new net.Server()
  listener1.listen(5000)
  const listener2 = new net.Server()
  listener2.listen(5000)
} catch (error) {
  console.log('unable to catch the error synchronously')
}

Deno

try {
  const listener1 = Deno.listen({ port: 5000, transport: 'tcp' })
  const listener2 = Deno.listen({ port: 5000, transport: 'tcp' })
} catch(error) {
  console.log('caught the error synchronously')
}

What is the feature you are proposing to solve the problem?

This feature request to suggest adding a possible listenSync() function to allow for synchronous listening and enable EADDRINUSE type errors to be caught via try/catch

Node

import * as net from 'node:net'

try {
  const listener1 = new net.Server()
  listener1.listenSync(5000)
  const listener2 = new net.Server()
  listener2.listenSync(5000)
} catch (error) {
  console.log('caught the error synchronously')
}

What alternatives have you considered?

I've tried a few things (including having Deno artificially return a listener via a Promise) but have settled on the following high level design (which unfortunately has both platforms throw at different locations)

Node

import { Net } from 'mylib'

const listener = Net.listen({ port: 5000 }) // Deno will throw here.

for await(const socket of listener) {       // Node will throw here (on first read)
}

I tend to think the Deno synchronous listen is quite intuitive and does help catch EADDRINUSE type errors early (which have historically been quite challenging to deal with in Node due to latent errors coming through on next tick). It would be great to see a similar listenSync() available both for the node:net, node:http and core modules.

I can meet. Do we need to make a decision (that should be recorded) or just pair/brainstorm (which could just be a huddle)?

Maybe we should include #47256

Even more reason not to rush, 2023b is now invalidated due to Lebanon withdrawing the change it was created to address, and users are recommended to either stick with 2023a (which we never landed in Node.js) or wait for 2023c.

Refs: https://mm.icann.org/pipermail/tz/2023-March/032829.html Refs: https://mm.icann.org/pipermail/tz/2023-March/032833.html

cc @nodejs/releasers So it seems that 2023b was for "Lebanon delays the start of DST this year": https://mm.icann.org/pipermail/tz-announce/2023-March/000078.html However it sounds like this decision has been reversed, (there's a lot of chatter on https://mm.icann.org/pipermail/tz/2023-March/thread.html) and for now users should either stick to 2023a or wait for 2023c. https://mm.icann.org/pipermail/tz/2023-March/032833.html

   e.g., the input to `JSON.parse()`.

I’m not sure I can attend today, but if you’d like to meet please feel free. @aduh95 or @JakobJingleheimer I assume either of you can run the Zoom/YouTube?

There are various ways to use streams in a way that is compatible with Promises. Support for async iterables is great, and you can also construct your own async iterators using events.on, for example. pipeline() and finished() also work nicely with Promises.

As @aduh95 mentioned, toArray() returns a Promise, and there are also forEach(), map(), etc. to solve common tasks.

If you want an API that is built on top of Promises, you can also use the Web Streams API.

All that being said, you are reading an entire stream and then pass the buffered contents to JSON.parse(). Doing so eliminates virtually all benefits of streams. Streams reduce latency and memory requirements only if the data is processed chunk by chunk, but passing it to JSON.parse() means that it is processed all at once. Why do you use a stream in the first place instead of a string or a Promise<string>? Either can be obtained easily in a sync or async fashion, and it can also be mocked trivially for testing.

Maybe we should include #47256

We'd either need to manually patch the timezone db for ICU 71.1 or update Node.js 16 to ICU 72.1 (which I'm a little hesitant about because we had issues raised about ICU 72.1 around the change to Unicode spaces -- although I think there was a V8 patch to revert (which we'd also then need to avoid breakage)).

I’m not sure why nodejs/node#30491 is on the agenda.

Because console.log flakiness inside worker threads is an issue for loaders (and has been a pain for our own tests). If we have time, we could discuss what solutions we could come up with.

Good to see that progressing in TC39.

This change brings Windows ARM64 one step closer to being a tier 2 supported platform, as described in https://github.com/nodejs/node/pull/47233.

With these changes, Windows ARM64 assets will get picked when releasing the following versions of NodeJS. Please note that these changes are partial, the rest of the required changes (eg. modifying the release job) will be done by @joaocgreis.

Since this is reverted on 19.8.1 is there a follow up issue I can track for a follow up diff that isn't crashy?

Maybe we should include https://github.com/nodejs/node/pull/47256