►
From YouTube: 2022-09-21-Node.js Technical Steering Committee meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
node.js
technical
steering
committee
meeting
for
September
21st
2022
before
we
get
started,
we'll
follow
the
agenda
as
outlined
in
the
issue
in
the
the
TSC
repo.
Before
we
get
started,
does
anybody
have
any
announcements
they'd
like
to
share.
B
B
A
Okay,
we
might
as
well
move
on
then
to
the
issues
tag.
A
Have
a
further
light
agenda,
but
we
just
get
through
them,
we'll
we'll
end
there.
So
the
first
one
is
number
four.
Four,
five,
seven
six
talk
document
update
guidance
for
adding
new
modules;
I,
don't
know!
If
Antoine
you
want
to
cover
that
one.
C
C
B
B
A
To
make
sure
all
the
TSC
members
were
aware
and
had
a
had
a
an
opportunity
to
object
or
comment,
so
I
don't
know
Antoine
is,
is
it
like?
If
is
it?
If
we
don't
hear
any
objections
today,
we'll
move
forward
or
what?
What
else
do
we
think
we
need
to
do
on
that?
One.
C
A
D
Yeah
I
think
the
pr
has
been
ready
to
land
for
several
days.
It's
more
that
Jordan
was
hoping
that
someone
would
Express
remorse,
but
even
even
still,
if
it
were
to
go
to
a
boat.
There's
like
11
approvals
on
that
PR,
that's
half
the
TSC
already
so.
A
Yeah
I
don't
hear
anybody
like
there
hasn't
been
any
objections,
so
we
don't.
We
generally
only
vote
when
somebody
is,
you
know,
wants
to
object
or
has
some
objections
or
we're
discussing.
D
D
Yeah
I
think,
with
with
regards
to
Mateo's
point
about
like
trying
to
make
it
available
if
it's,
if
it's
also
available
in
the
npm
registry,
like
sure,
but
you
know,
I,
think
the
odds
of
that
happening
like
we
saw
with
tests
it's
like
either
that
can
be
a
goal
and
we're
going
to
try
to
come
up
with
names
that
aren't
already
claimed
like
like
test
Runner
was
like
the
best
we
could
come
up
with
for
that.
D
But
then
people
didn't
like
that
or
it
could
be
a
non-goal
and
we
come
up
with
like
whatever
the
best
name.
We
think
it
is
even
if
it
conflicts
and
then
it
just
lands
as
prefixed,
only
and
I
think,
based
on
how
test
went,
I
think
it's
more
likely
that
future
modules
will
fall
under
the
latter
category,
but
also
like
these
things
happen,
so
rarely
that
they
can
be.
You
know
considered
each
one
individually.
D
If
either
the
name
happens
to
be
available
or
there's
a
similar
name
for
that
new
module
that
is
available,
we
can
just
consider
it
as
a
one-off
I
feel
like.
But
you
know,
I
feel,
like
the
documentation
needs
to
assume
something.
So
it
should
probably
just
assume
the
node
test
scenario
and
we
can,
if
it
comes
up.
E
My
preference
is
not
that
hard
to
actually
cause
a
massive
amount
of
overhead
for
everybody,
so
I
am
not
willing
to
Champion
the
looking
for
just
supporting
both
okay.
Essentially,
it
seems
the
vast
majority
of
the
I.
Am
supportive
of
people
wanted
to
make
Clarity
for
the
reason
you
mentioned
Joffrey,
so
I'm,
just
like
not
objecting
and
approving,
essentially
because
it's
it
seems
the
good
thing
to
do,
but
it's
I
would
actually
prefer
to
have
the
module
open.
But
you
know
if
the
model
is
available.
E
A
E
A
A
Okay,
so
I
guess
I
still
hear
most
people
are
like
everybody's
comfortable
with
what's
there.
So
unless
we
hear
some,
some,
like
somebody
wants
to
you
know,
comment
with
concerns
in
the
issue
or
reach
out
to
you
know
one
of
us
any
one
of
us
really
with
the
private
concerns
we'll
plan
to
land
it
tomorrow,
based
on
the
discussions
that
sound
right
to
everybody,
foreign.
A
A
Okay,
then,
let's
just
take
a
quick
look
at
the
Strategic
initiatives.
B
A
I
know
Michael
mentioned
that
he's
on
a
connection
where
he
can't
speak,
but
in
terms
of
V8
currency
I
know
there
were
some
issues,
but
it
sounded
like
things
are
now
moving
moving
better
forward.
B
And
so
create
currency
in
in
terms.
A
In
terms
of
the
next
10
initiative
we
were
planning
to
today
for
the
club
Summit,
we
actually
did
a
not
mention
to
to
members
to
ask
people
to
fill
in
a
couple
of
easy
retro
brainstorms
for
technical
priorities,
and
you
know
what's
working
well,
what's
not
working
so
well
in
the
community
which
we'll
then
use
as
input
during
the
session
in
Dublin.
So
that's
kind
of
the
was
the
focus
we
were
working
on
today.
D
D
E
E
D
E
Thing
yeah
exactly
there
will
be
enough
people
in
the
room
to
like
you
know,
bracelet.
That
would
be
nice
for
half
an
hour
for
an
hour,
because
I
was
looking
at
it
and
they
were
just
like.
Oh
I
will
probably
need
to
you
know.
This
is
a
very
long
work.
Okay
and
I
I
really
need
to
write
down
that
session
topic.
Okay,
which
is
let's
get
Jeff
announcer,
but
I
want
them.
D
I
mean
the
bigger
question
would
be
like.
Is
this
whatever
you
want
to
call
it
the
issue
or
maybe
a
bug
that
I
found
like
even
a
problem?
Like
maybe
you
know,
I've
never
quite
got
an
answer
from
the
New
Relic
guys
about
like
well,
apparently
they
have
support
for
instrumentation
with
the
SMS.
So
like
is
it
that
their
support?
D
D
E
The
I
am
kind
of
sure
that
for
some
use
cases
it's
a
problem,
I'm,
not
sure
if
it's
a
problem
for
for
abms,
so
just
to
be
clear,
it's
I
am
I've
seen
it
those
areas
of
the
code
crash
when
using
domains
within
a
test
for
some
test
streaming
use,
domains
to
grab
errors
to
capture
errors
and
domains
are
based
on
us
in
Cooks,
okay
and
at
the
end
of
it.
They
there
are
I've,
seen
some
crashes
on
that
related
to
that
problem
when
using
domains
with
esm
on.
E
E
D
E
D
A
B
D
But
yeah
it
would
be
nice
to
I
mean
I.
Can
I
can
follow
up
with
them
and
be
like
hey
that
write-up
that
you
said
you
would
do
you
know?
D
Could
you
could
we
have
that
before
the
next
collaborate
or
something
because
then
at
least
that
kind
of
gives
them
a
deadline,
but
it
would
be
good
I,
don't
know
if
there
are
any
other
instrumentation
vendors,
maybe
coming
to
this
upcoming
Summit,
because
it
wouldn't
be
bad
to
get
a
similar
write-up
from
somebody
else,
so
that
we
have
like
more
than
just
one
perspective
on
like
what
the
shortcomings
are.
D
But
you
know,
and
then
spinning
off
from
that
you
know
we
might
need
to
figure
out
a
way
to
like
okay.
How
do
we
kind
of
put
the
onus
on
these
companies
to
like
you
know,
hey
you
want
such
and
such
then
you
need
to
like
contribute
to
to
add
whatever
feature
to
wherever
it
should
go:
Diagnostics,
Channel
or
who
knows
what,
like.
A
I
think,
like
you
know,
if
we,
if
we
can
document
the
way,
we
think
it
needs
to
be
fixed
or
like
yeah,
we
understand
and
here's
the
strategy
and
then
it's
back
to
like
if
there's
somebody
who's
who's
like
we
need
this
to
work.
For
us.
We
can
point
them
to
that
to
say
yeah.
We
understand
the
problem,
here's
the
way
we
think
it
should
be
fixed.
D
Yeah
there's
a
PR
in
progress
right
now
that
looks
not
looks
like
it
probably
won't
land
I
guess
where
someone
from
the
yarn
team
wants
to
expose
even
more
common
JS
loader
internals,
and
it's
basically
like
you
know.
Well,
you
know
they're
trying
to
implement
essentially
a
virtual
file
system
and
they're
like
well.
You
exposed
all
these
other
things,
but
not
these
two
little
pieces.
D
So
you
know
we're
trying
we're
overriding
all
these
other
things
you
know,
but
we
can't
override
this
so
expose
them.
So
we
can
override
those
as
well
and
everyone's
like.
Well,
no,
you
know,
we
don't
want
you
to
be
overriding.
D
You
know
big
chunks
of
like
the
fs
module
and
so
on,
like
you
know,
come
up
with
a
better
solution
and
there's
a
bit
of
like
a
standoff
where
it's
like
they
don't
want
to
do
the
work
of
coming
up
with
a
big,
elaborate
API,
or
how
do
we
want
to
allow
customization
of
file
system
calls,
which
would
essentially
be
something
similar
to
like
the
loaders
API,
but
we
don't
want
to
like
just
rubber
stamp
the
monkey
patch
like
quick
and
dirty
hacky
solution.
D
So
it's
like
you
know
this
could
be
a
kind
of
a
test
case
for
it.
It's
like
well,
if
you
want
that.
Okay,
we'll
do
the
work
of
giving
you
a
rough
outline
like
you're,
saying
of,
like
you
know,
a
rough
idea
what
we
would
approve,
but
then
you
know
it's
on
you
to
like
build
it
because
you're,
the
one
who
wants
to
like
you
know,
build
on.
A
B
Some
for
what
it's
worth,
that
the
the
API
that
you're
talking
about
has
already
landed
in
known.
So
it's
a
test.
That's
so
blocked.
B
The
module
that
underscore
stat
and
the
module
dot
underscore
read
package.
One.
D
Well,
they're
part
of
node
already
but
they're
internal,
like
I,
think
that
was
the
like
they're
in
they're,
internal
I,
think
by
accident
or
Legacy.
Somehow,
we've
like
exposed
publicly
other
private
methods
on
module
that
then
people
have
like
build
things
on,
but
and
but
these,
for
whatever
reason
were
never
exposed
publicly,
unlike
the
other
ones,
and
so
now
they
want
to
expose
them.
D
You
know-
and
maybe
we
should
just
for
consistency,
but
it's
also
like
you
know,
we've
been
trying
to
push
people
away
from
this
bad
pattern
for
a
long
time.
So
it's
sort
of
like
you
know,
is
this.
Maybe
some
like
we
have
a
point
of
Leverage
to
now
kind
of
force
the
issue
or
put
our
foot
down
and
be
like
no
more
doing
it
like
this
blah
blah
because,
like
the
esm,
loader
was
kind
of
built
in
a
different
way
where
it's
like.
D
You
know
you
can't
monkey
patch,
the
ESN
loader,
so
hence
the
need
for
the
loaders
API
to
like
be
able
to
do
a
lot
of
the
things
that
people
were
monkey
patching
kind
of
just
to
do
so,
it's
more
of
a
question
of
where
do
we
want
to
drive
people
going
forward.
A
D
I
mean
I
think
we
want
to
get
away
from
Monkey
patching
like
period.
You
know
it's,
never
the
approach
to
like
support
I
think
so
that.
B
If
he's
like,
somehow
stop
that
monkey
patching
thing
to
work,
it's
probably
gonna
break
a
lot
of
the
ecosystem,
so
I'm
not
sure
if
that's
the
right
way
to
go,
because
if
you
consider
things
like
electron
and
PKG
and
almost
all
packages
that
try
to
do
anything
related
to
single
executable,
like
they
all
kind
of
rely
on
this
whole
thing.
D
But
they
shouldn't,
you
know
like
they
can't
in
a
esm.
So
at
some
point
it's
like
you
know
it's
like
kind
of
a
legacy
that
we
left
behind
when
with
with
common
JS.
It's
like.
Yes,
it's
something
like.
If
we
actually
took
it
out
of
common
JS,
then
it
would
break
a
lot
of
things
or
they
would
be
forced
to
migrate.
D
We
could
really
push
the
issue
hard
by
taking
it
out
even
before
providing
an
alternative,
and
that
would
like
put
put
pressure
on
on
those
groups
like
the
electron
team
to
submit
PR
as
to
you
know,
extend
the
loaders,
API
or
whatever
similar
apis
to
to
restore
functionality
that
we
ripped
away
from
them.
D
Those
are
more
like
strategic
questions,
but
you
know
by
by
simply
not
supporting
it
in
esm.
That's
the
kind
of
like
more
soft
approach
of
like
at
some
point,
you're,
probably
going
to
want
to
migrate.
You
know
electron
framework
to
esm,
therefore,
you're
going
to
need
to
like
find
solutions
for
these.
For
these
things.
A
Know,
there's
a
whole
gray
thing
but
like
at
one
end,
is
like
trying
to
encourage
for
new
stuff.
Like
you
know,
in
terms
of
those
methods,
is
it
possible
to
use
the
loaders
to
you
know
instead
of
monkey
patching
right?
If
it
is
possible,
then
it
seems
like
encouraging
that
makes
sense
versus
adding
in
something
new
right.
D
Well,
because
then
it
becomes
like
an
actual
supported,
API.
You
know
monkey
patching,
node
internals,
it's
like
I
could
break
at
any
time,
and
you
know
what
I
mean
like
it's
it's.
It
makes
it
really
hard
for
us
to
do
any
changes
with
the
module
loading
system
or
whatever
other
people
are
monkey
patching,
because
it's
sort
of
like
even
things
as
specific
as
function,
signatures
and
internals,
become
part
of
like
a
public
API.
D
You
know
it
becomes
really
messy.
You
know
they're
not
intended
to
be
it's
not
intended
to
be
a
public
API,
and
so
something
like
the
loaders
API
or
whatever
we
spin
off
from
it
like.
If
loader
is
just
what
remains
specific
to
modules
and
then
customization
apis
for,
like
all
these
other
things
like
customizing
Source
maps
and
customizing,
the
rebel
and
blah
blah,
then
that's
like
okay
here
is
the
API
that
we're
creating.
For
these
purposes
of
you
want
to
do
these
customizations.
D
B
A
A
Sure
yeah
like
in
that
virtual
file
system,
like
my
first
question,
would
be:
is
it
possible
already
with
loaders
to
to
get
to
do
what
you
need?
If
the
answer
is
yes,
then
it
seems
like
that's
the
way
to
go.
If
the
answer
is
no,
then
the
collaboration
between
the
two
teams
to
figure
out
like
well
what
extension
to
loaders
or
whatever
would
be
needed
to
do.
That
seems
like.
D
It's
possible
with
loaders
today
when
you're
trying
to
load
something
through
like
import
and
maybe
require,
but
not
if
the
not
if
the
user
code
is
like
literally
doing
like
fs.read
file,
you
know
what
I
mean,
because
then
it's
like
okay.
Well,
then,
you
have
to
Monkey
patch
fs.read
file.
If
you
want
that
to
you
know,
be
actually
making
a
network
call
or
something
like
that,
so
it
would
be
about
creating
a
similar
type
of
thing
to
the
loaders
API.
D
A
D
There
are
a
few
issues
related
to
this,
there's,
probably
a
link
to
from
the
readme
just
on
the
front
of
that
repo
or
you
can.
Let
me
know
if
you
can't
find
them,
but
there's
talks
about
like
virtual.
If
you
search
for
like
virtual
files,
this
time
and
stuff
like
that,
you'll
find
the
discussions
about
it
and
like
the
use
cases
and
so
on,
are
have
been
explored
in
there.
A
Any
other
topics
we
should
discuss
so
that
was
the
end
of
the
agenda.
I
know.
One
of
the
people
asked
me
stick
around
for
a
private
session,
private
section,
I.
D
Can
just
give
a
quick
update?
It's
not
I!
Guess
it's
not
a
Melissa
strategic
issues,
but
the
loaders
work
is
getting
pretty
close
to
stable,
there's
only
two
items
on
the
like
the
roadmap
that
is
on
the
on
that
read
me
just
talked
about
that
remain
to
be
done
before
we,
you
know,
propose,
marking
the
API
stable,
there's
an
open
PR
for
one
of
them.
That's
the
like
loaders
effectiven,
following
loaders
PR
and
then
there's
the
other.
One
is
moving
loaders
off
thread
which
has
a
draft
PR
open.
D
It's
not
quite
ready
yet,
but
a
lot
of
progress
has
been
made
so
I'm
I'm
hopeful
that
within
a
week
or
two
that
should
be
ready
and
or
landed,
and
then
they'll
just
get
a
question
of
like
how
much
you
know
baking
time
do
we
want
to
let
go
by
before
we
consider
the
API
stable.
D
So
hopefully
this
could
all
you
know.
Hopefully
it's
gonna
land
before
1900
goes
out
whether
or
not
we
Market
a
stable,
but
at
least
it'll.
Have
you
know
what
should
be?
The
final
you
know
when
become
stable.
Api
would
be
in
19.
D
I
mean
there's
a
lot
of
stuff
that
people
want
that
is
in
like
the
phase
two
of
like
after
it
becomes
stable.
All
this
other
stuff
can
get
added
without
you
know,
basically,
everything
that
could
be
added
without
causing
a
breaking
change
got
pushed
into
phase
two,
so
we
could
just
like
get
to
get
to
stable
ASAP
and
we're
close
so.
E
I
think,
before
getting
stable,
we
want
to
see
buy-in
from
a
few
APM
vendors,
at
least
so
that
you
know
it's
it's
okay
for
them.
Okay,
like
that's.
A
Yeah
for
this
some
other
major
features
we
put
together
a
list
of
like
you
know,
and
it's
been
like
next
test
coverage
green
like,
and
it
was
some
things
like
that,
like
real
use
use
cases,
so
it
might
be
like
you
know,
2
8,
P.M
saying
yeah
we're
using
it.
It
looks
good
or
whatever.
So
maybe
that's
a
good
thing
to
think
about
Jeffrey
in
terms
of
like,
what's
the
proposal
of
this,
if
if
we
reach
this,
then
you
know
it's,
it
can
go
stable
right.
E
E
D
Okay,
you
mean.
E
It's
the
same,
doesn't
matter:
okay
like
we
have.
We
have
people
using
this
anyway
out
there
right
now
and
it's
kind
of
it
has
been.
We
have
been
asked
a
few
times
for
a
flag
to
disable,
showing
that
experimental
warning,
which
means
that
it's
dropping
it
might
you
know
it's
it's
annoying
for
people,
it's
just
a
name
for
people.
People
are
using
that
feature.
D
I
mean
I,
don't
know
how
this
happened,
but
like
the
flag
itself
is
it's
there's
both
experimental
loader
and
SS
loader.
That's
been
the
case
like
yeah
for
years.
I
think.
B
E
B
D
Version
was
added
by
accident,
but
yeah
I
know
you're
talking
about
the
warning.
I
would
be
fine
with
that
of,
like
maybe
dropping
the
warning
before
we
Market
a
stable
in
the
docks.
It's
like
a
separate
step
too.
E
D
A
D
I
think
it
needs
to
get
moved
internal,
not
necessarily
it
can't
be
removed
because
stable
apis
depend
on
it,
but
it
also
doesn't
need
to
be
public.
So
I
think
that
was
the
way
forward
that
they
come
up
with
a
few
years
ago
and
it's
still
I
guess
the
default
thing,
so
it's
sort
of
like.
But
what
needs
to
happen?
Actually,
you
know
make
it
internal
and
and
take.