►
From YouTube: 2021-05-20-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
A
If
nobody
else
has
any
I'll
mention
that
the
opengs
world
is
the
first
week
of
june,
we
hope
to
see
you
there.
I
know
that
there
have
been
a
number
people
in
the
different.
At
least
I
know
of
a
few
working
groups
like
the
node
api
working
group,
the
package
maintenance
working
group
who
are
busily
recording
or
have
recorded
sessions
for
that.
So
it's
a
good
op
to
find
out
a
little
bit
about
what's
going
on
in
the
node
project.
A
A
The
meeting
this
month
was
cancelled,
but
again
you
know
that's
if
there's
anything
that
people
want
me
to
take
to
the
board
between
now
and
the
next
meeting.
Just
let
me
know
I
can
do
that.
I
don't
have
anything
that
I
know
know
of
on
the
list
to
do.
A
So,
in
terms
of
that,
I
I
can,
you
know,
see,
there's
some
some
reviews
going
on
and
I
expect
that'll
close
out
within
a
week
or
so
I
think
the
I'd
have
to
go
back
to
the
governance
for
the
for
the
cpc,
but
I
think
it's
like
a
two-week
cycle
or
something
to
do
those
approval,
so
shouldn't
be
too
bad
any
questions
on
that
front
or
things
people
want
to
ask
cpc
or
boardwise
before
we
move
on.
A
A
B
The
the
issue
here
is
that
we
do
have
an
http
client
in
node
core,
and
there
comes
issues
in
into
the
issue
tracker
about
things
we
should
fix
with
that
back
and
forth.
However,
we
don't
really
have
that
many
people
that
engage
with
those
issues
in
the
past.
It
has
been
a
lot
of
myself
and
mateo
and
danielle,
but
all
three
of
us
have
moved
over
to
work
on
indici,
which
is
in
the
under
the
node.js
organization.
B
At
the
moment,
as
you
know,
we
see
this
as
the
future
of
http
clients,
at
least
in
node,
and
then
it's
a
little
bit
strange
that
we
have.
You
know
a
client
in
node
core
that
is
semi-maintained
and
has
issues
while
we're
working
on
a
different
project
in
ditchi
and
per
the
node.js
documentation.
We
are
still
recommending
people
to
use
the
node.js
core
client
and
that's
kind
of
a
sub,
optimal
situation,
so
to
say.
B
B
I
would
you
know
for
me
personally,
I
just
like
it
if
the
node.js
docs
just
linked
to
the
unditched
docks
or
even
when
digidocs
were,
you
know,
merged
into
the
node.js
docs
with
an
appropriate
link,
and
you
know
this
is
how
you
install
it,
and
then
you
know
whether
it's
inside
of
node
core
or
you
know,
npm
package
or
not.
I
guess
that's
a
bigger
question,
but
you
know
just
to
have
something
to
start
with.
B
We
could
even
have
you
know
deprecating
or
you
know
not
recommending
the
core
client
with
the
link
to
indici
until
we
sort
this
out,
because
it's
a
little
unfortunate
situation
now
that
we
have,
we
have
what
we
believe
is
a
better
solution,
but
we're
still
indirectly
telling
people
to
use
the
old
one
that
we
don't
maintain
so
much
and
I
don't
think
that's
a
good
place
to
be.
E
Sorry
go
ahead,
has
has
been
been
been
tested
to
be
completely
equivalent
to
what
is
inside
node.js.
So
so
you
know,
could
could
it
work
for
all
the
use
cases
that
people
are
using
the
built-in
http
client
right
now.
B
As
far
as
we
know,
this
is
documented
in
the
indici
in
the.
If
you
go
actually
I'll
just
paste
a
little
link
here,
those
that
are
interested
here
in
the
bottom,
we
have
what
we
don't
do
and,
as
far
as
I
know,
the
only
thing
that
node
core
does
that
and
she
doesn't
do-
is
support.
The
you
know
expect
header
the
expect
request
header
and
there
is
an
issue
to
add
support
for
that,
but
that's
not
added
yet
other
than
that.
As
far
as
I
know,
it
should.
E
So
what
about
what
about
like,
like
api,
surface
wise,
you
know
like?
Could
you
just
instead
of
you
know
you
know
requiring
one?
Could
you
just
require
the
other
and
the
rest
of
the.
B
E
B
E
E
B
Good
question:
I
don't
know
we're
just
about
to
release
nichi4,
so
we
have
rc4
at
the
moment.
Of
course,
there
there
are
some
bugs
that
we
are
still
solving,
but
there
are
bugs
in
the
core
client
as
well
sure
yeah.
I
would.
A
B
A
A
A
B
F
So
if
we
would
build
a
separate
tool
and
then
users
could
opt
in
to
by
just
installing
and
then
they
would
hook
into
the
current
http
implementation
and
tell
them
how
to
switch
that
might
improve
the
situation
and
might
also
improve
the
or
at
least
lead
to
a
way
to
at
some
point,
maybe
switch
the
default.
Http
parser.
B
Yeah,
that's
I'm
not
sure
about
tooling,
but
we
could
certainly
do
more
documentation
about
you
know.
This
is
how
you
did
it
before,
and
this
is
how
you
should
do
it
now.
B
F
F
You,
I
guess
it
would
not
be
possible
for
all
use
cases
but
likely
for
a
lot,
and
are
you
thinking
like.
F
F
So
either
we
could
parse
the
code
and
use
an
ast
and
just
check
for
that,
or
we
would
and
just
let's
see
if
we
could,
I'm
not
certain
if
we
should
monkey
patch
http
and
that's
probably
not
a
good
idea
and
to
indicate
when
some
specific
functionality
is
how
it
could
be
implemented.
Instead
with
a
new
team.
B
I
think
that's
a
little
bit
too
in
to
what
we
call
it.
F
Invasive
well,
I
wouldn't
want
to
have
that
as
a
default,
but
as
an
opt-in
that
you
have
to
install
a
specific
module.
So
you
would
have
you
know
you
want
to
know
about
it.
That's
because,
as
a
module
author,
for
example,
when
I
have
a
written
code
written,
it
would
be
a
lot
easier
for
me
to
just
know
where
to
switch.
E
I
think
for
what
it's
worth.
Okay,
go
ahead,
sorry
for
for
what
it's
worth
in
in
node
api
we
have.
We,
we
also
have
a
conversion
tool
right
and
ours
is
just
based
on
regular
expressions
right,
because
we
have
the
benefit
of
having
like
like
something
to
latch
onto
like
nan
coal
and
colon
right.
That
kind
of
thing,
and
so
you
just
replace
that
with
an
api,
colon
colon.
E
E
We
have
like
a
we
have
this
repository
of
like
examples
you
know
of
of
how
to
like
common
use
cases
for
for,
for
you
know,
simple
tasks
that
that
native
add-ons
have
to
do,
and
so
I'm
wondering
if,
if
it
might
make
sense
to
do
like
like
a
side-by-side
sort
of
library
of
of
of
simple
http
clients
and
the
most
common
things
that
they
need
to
do,
and
so
you,
you
you'll,
have
a
thing
where
that's
actual
code
that
you
can
run
and.
B
Sorry
guys
I
just
got
an
emergency
support
call.
I
have
to
jump
out
a
little
bit
I'll
try
to
get
back
as
soon
as
possible.
Sorry,
okay.
A
Yeah,
I
I
think
we're
we're
kind
of
going
off
like
we're
going.
These
are
all
good
ideas.
We
should
probably
discuss
them
in
issues,
though
I
think
the
concrete
ask
was
it
sounded
to
me
like
adding
some
references
in
the
documentation
and
kind
of
the
way
I
understood
it
is
like
that
those
sections
could
be.
A
E
A
E
It's
kind
of
one
level
below
deprecated
right
now:
the
http
client,
it's
not
officially
deprecated,
but
it's
kind
of
sort
of
deprecated
right,
and
so
it.
A
E
D
E
Yeah,
I
was
just
gonna
say,
like
I
think
we
could.
We
could
explicitly
say
that
that
although
the
built-in
client
is
not
deprecated
because
it
isn't,
we
do
recommend
that
that
people
move
to
the
new
one,
because
the
the
maintainers
are
focused
on
the
new
one
and
they
maintain
the
old
one,
just
sort
of
sporadically.
A
We
can
come
to
something
which
is
like
helps
that
let's
get
the
next
step
of
more
people
using
it
to
val,
because
I
kind
of
heard
it's
like
well,
we
wouldn't
be
claiming
it
stable
yet,
but
we
need
help
to
get
there.
So
you
know,
let's,
let's
put
in
the
first
step
of
here's,
the
you
know
the
module,
the
thing
that
we'd
be
suggesting
you
look
at.
If
you
want
to
you,
know,
think
about
the
future.
D
D
D
The
docs
yeah
that
can
be
discussed
in
the
issue
tracker,
but.
A
A
A
Okay,
thanks,
okay,
we'll
move
on
to
the
next
issue,
which
is
tracking
issue,
commit
cue
issues
and
feedback.
This
is
34770,
I'm
not
sure
who
added
to
the
issue,
if
you're
here
to
speak
up
and
jump
in.
A
Or
if
you
have
some
some
thoughts
on
it,
I'll
still
feel
the
same.
While
I
look
for
who
did
I
see,
I
think
richard
added
it
to
the
tse
agenda,
richard
lyle,
I
think
the
the
reason
was
it.
It's
been
broken
for
quite
a
while,
and
maybe
some
of
the
discussion
I
remember
looking
at
it
before
is
like
we
need
to
say
like
if
it's
going
to
be
broken,
maybe
we
need
to
get
rid
of
it
or
we
need
to
fix
it
one
of
the
two.
D
C
Largely
worked
upon
by
the
build
working
group,
not
really
the
commit
queue,
was.
D
D
D
Oh
mary's
saying
the
token
that
that
they
have
should
work
so
yeah.
Maybe
we
ought
to
make
a
point
to.
I
don't
know
if
I
need
to.
I
don't
think
we
have
the
right
people
here
today
to
talk
about
this.
Okay.
D
Yeah,
I
don't
know
how
many
I
don't
know
how
many
more
weeks
we
want
to.
We
want
to
leave
this
broken,
but
yeah,
I
think,
maybe
making
a
point
to
see
if,
if
mary
or
maybe
joey
can
be
at
the
meeting
next
week,
and
if
not,
maybe
we
can
try
to
find
some
other
time
or
kick
start
some
other
way.
If
someone
wants
to
take
on
the
action
item
of
doing
that,
and
since
I'm
verbalizing
it,
I
guess
I'm
implicitly
volunteering
to
to
reach
out.
A
Okay,
anything
more
on
that
one.
Before
we
move
on.
A
A
You
know,
and
we
kind
of
figured
that
through
the
pr
we
can
agree
on
what
that
language
should
be.
It
sounded
like
it
wouldn't
be
like
hey.
We've
replaced
it
with
this,
but
it's
like
here's
something
we
want
you
to
come
out
and
you
know
use
and
give
us
more
feedback
on
so
that
we
can.
A
Okay,
so
back
to
33
864,
we
named
default
branch
to
master,
that's
just
sort
of
a
tracking
issue.
I
have
gone
through
and
done.
I
I
opened
issues
on
a
bunch
of
the
internationalization
ones,
so
we've
converted
a
bunch
of
those
ones
over
I've
got
another
set
of
issues
I
opened
in
a
second
pass.
A
A
few
other
people
like
I've
posted
some
on
some
other
issues.
So
again,
it's
just
a
matter
of
as
people
have
time.
If
we
can
go
through
and
you
know
communicate,
you
know
enough
with
the
people
who
are
active
in
those
repos
to
make
sure
we're
comfortable
in
changing
and
then
making
the
change,
and
I
think
it
seemed
to
me
actually
a
few
people
said
I
went
ahead
and
did
it
so
it
may
not
necessarily
just
need
to
be
the
org
owners
who
can
do
it.
A
But
I
don't
have
anything
beyond
like
making
some
slow
progress
on
it
anything
else.
People
want
to
bring
up
or
discuss.
D
Danielle
is
asking
if
there
are
instructions
listed
somewhere
to
do
this,
and
I
believe
the
answer
is
yes,
but
I'm
forgetting
where
and
there's
some
instructions
in
the
github
interface
but
yeah.
I
think
someone.
C
D
There's
in
the
github
interface,
there
are
like
specific
commands.
You
run
on
the
command
line
after
you've,
yeah
after
you've
done
the
update
and
everything
but
yeah.
So.
A
Those
instructions
are
actually
out
of
out
of
date
like
basically
all
you
all
you
need
to
do.
That
was
sorry.
I
pasted
them
only
to
you
rich,
so
ignore
them
anyway,
it's
like
you
basically
go
to
the
ui.
You
find
there's
a
place,
that's
branches
and
then
there's
an
option
to
rename
a
branch.
That's
all
you
have
to
do
it.
Retargets
prs.
A
They
have
to
start
using
main
instead
of
master,
but
existing
prs
are
still
okay,
so
you
don't
have
to
like
change
your
pr.
You
can
still
push
your
pr
and
that
kind
of
stuff.
G
Okay,
cool
yeah.
I
think
I
remember
initially
when
people
started
doing
this,
it
was
closing
pr's
when
you
renamed
the
branch
and
whatnot.
So
I
think
that
github
is
has
a
better
way
to
handle.
That
now,
though,
is
there?
If
somebody
already
has
a
like
an
open
pr
against
a
fork,
will
that
will
they
get
a
notification
or
something.
A
There's
stuff
in
the
ui,
so
I
I
don't
know
that
you
get
an
email
or
anything
like
that.
If
you
log
and
you're
on
the
ui,
you
definitely
get
a
pop-up
that
says:
hey
master's
been
renamed
to
maine
and
I
guess
like
I,
don't
think
you
necessarily
for
your
open
prs.
I
think
it
moves
them
to
maine.
A
In
a
lot
of
cases,
there's
no
like
I
haven't
had
anybody
complain
like
in
a
lot
of
the
cases
of
these
repos.
There
aren't
very
many
pr's
that
are
open
anyway,
and
I
I
you
know,
haven't
had
anybody
say
afterwards,
they
they
had
a
problem.
I
think
when
we
get
to
the
node
repo,
like
some
of
the
bigger
ones,
then
we're
gonna
have
to
be
more
careful.
A
A
If
not,
okay,
let's
go
to
the
next
issue,
which
is
migration
of
core
modules
to
primordials
three
zero:
six:
nine
seven
trying
to
remember
who
put
this
on
the
agenda.
H
Yeah,
so
I
think
it
was
me
okay,
my
internet
is
not
very
good,
so
I
might
disconnect
at
some
time
sure
hope
it's
going
to
be
okay,
so
I've
I've
opened
a
pr.
I've
put
the
link
in
the
chat
if
you
want
to
check
out
it
so
yeah
at
this
point
it
just
needs
some
reviews,
so
it's
appear
to
add
guidelines
for
contributors
and
pr
reviewers,
who
wants
to
know
better
about
prime
modules,
why
we
have
them
how
to
use
them
etc.
H
So,
if
you
want
to
to
have
a
look
and
yeah
find
any
typos
I've
made
or
yeah,
please
go
ahead.
F
We
spoken
about
and
that
before
an
ntsc
meeting
as
well,
that
there
were
multiple
performance
issues,
issues
with
using
primordials,
and
we
should
definitely
have
a
look
at
that
again
and
before
switching
more
things.
We
have
to
be
very
careful
about
those,
and
it
also
definitely
increases
the
difficulty
and
to
maintain
node.js
and
then
to
get
new
contributors.
F
H
That's
what
my
document
is
trying
to
address
sorry
to
interrupt
good.
F
Good
yeah,
so
there
are
definitely
a
lot
of
concerns
as
well
about
doing
this,
and
if
it
is
actually
the
right
way
to
to
like
to
use
primary
deals
as
we
did
so
far,
because
in
the
end
there
is
likely
almost
no
module
out
there.
That
would
do
something
similar
and
there
is
actually
no
module
that
could
do
something
similar.
So
if
you
write
something
without
always
being
very
careful,
it
would
not
be
possible
to
to
really
have
any
application
to
work
without.
F
H
So
I
I
know
there
are
some
part
of
the
code
in
which
it's
important
to
not
run
any
user
code,
so
on
top
of
my
head
as
the
the
worker
termination
path.
So
if
we
had
any,
if
we
rely
on
user
mutable
methods,
we
could
have
a
worker
that
refused
to
die.
Basically,
if
the
main
thread
terminates
terminate
it
it
could
it.
F
F
That
will
definitely
happen,
but
the
point
is,
it
would
also
happen
with
any
other
module
as
like,
even
if
node.js
itself
would
hundred
percent
use
primordials
and-
and
you
use
just
any
npm
package
out
there-
it
would
still
break
because
that
package
would
break
and
they
don't
have
access
to
the
primordials
as
we
do
so.
It
won't
actually
benefit
like
pretty
much
any
program
out
there.
Even
if
we
have
100
primordials.
H
Yeah
but
that's
just
javascript
works
right.
H
E
Bugs
will
not
come
to
us,
though,
right
because
application
application
users,
they
will
say-
oh
well,
gee,
I
I
traced
it
and
and
all
of
a
sudden
you
know,
I
traced
it
to
like
lib
internal
something
something
right
and
and
then
they'll
file
a
bug
against
node.js.
But
really
it's
because
somebody
monkey
patched
lib
internal,
something
something
so
would
this.
B
I
B
A
A
A
Right,
like
there
are
people
who
are
actively
supporting
and
pushing
for
this
work,
and-
and
it's
it's-
you
know,
they're
not
necessarily
going
to
go
and
do
something
else
in
the
list
of
what
we'd
wanted
to
do
right
so,
like
I
don't
think
you
can
do
a
straight
hey.
The
energy
that
goes
into
this
is
wasted
because
they're
not.
B
B
F
And
it's
it's
really
difficult
for
me
to
grasp
who
we
benefit
by
doing
that,
like
gabrielle,
as
you
said,
there
could
seriously
be
issues
reported
towards
node.js
instead
of
a
module
that
would
monkey
patch
a
basic
object
or
something
like
that.
F
Well,
that
is
very
unfrequently
happening
as
far
as
I
can
tell
at
least
I
cannot
remember
pretty
much
any
issue
that
we
would
have
related
to
that,
and
but
I
have
like
even
the
code
reviews
for
primordials
have
taken
a
lot
of
time.
You
have
to
deal
with
all
of
that
code.
Then
we
have
to
revert
it.
We
have
to
benchmark
things
and
because
we
found
issues
there,
it's
difficult
to
read
the
code
frequently
with
all
the
primordials,
so
whom
do
we
actually
really
benefit
by
doing.
H
That
so
do
you
mean
for
pro
modules
in
general
or
just
the
pr
I've
opened
documenting
them.
This
is
actually
a
general
question.
F
A
Don't
know
if
robert
and
reuben
you
were
in
the
last
time
we
discussed
this,
but
like
there
was
a
discussion
on
promotions,
one
of
the
earlier
meetings.
A
Nobody
was
like
willing
to
say
we
should
block
them
like
block
this
work
and
just
stop
it,
and
so
the
thing
that
we
thought
you
know
the
the
people
who
were
there
said
well.
One
thing
we
can
do
is
to
try
and
provide
some
guidance
that
will
help
minimize
the
impact
it
has
on
on
other
stuff.
A
So
that's
where
this
pr
comes
in,
I
think
if
we
want
to
have
the
should
we
just
stop
primordials
like
maybe
that
needs
to
be
an
issue
somewhere
or
because
I
don't
think
we're
probably
going
to
end
up
with
some
subset
of
the
tse
in
each
meeting
and
so
the
people
who
who
will
be
able
to
answer
your
question
like
well.
Why
are
we
doing
this
and
they
obviously
aren't
here
to
advocate
for
it
right?
A
So
I
you
know,
I
don't
know
if
opening
that
issue.
That
just
says,
is
you
know,
I
think
you
know
somebody
wants
to
say
we.
I
think
this
primordial
stuff
is
causing
us
more
more
pain
than
gain.
H
But
how
could
we
know
that,
because
I
mean
robert
said
that
maybe
we're
wasting
some
time
with
that
and
well
for
from
my
in
my
experience
I
actually
became
involved
with
ngs
thanks
to
pro
modules
in
in
a
big
part,
and
I'm
here
today.
So
I
don't
know
I
I
I
I
think
it's
hard
to
tell
als.
H
H
The
idea
is
having
prime
modules
is
not,
yes,
is
written
in
javascript
or
big
chunks
of
it
or
written
in
javascript,
but
that's
just
an
implementation
detail,
and
if
a
user
is
changing
the
you
know,
prototype
methods
or
whatever
it
it
should
not
make
not
just
for
so.
I've
pasted
an
example
of
a
user
issue.
So
what
what
they're
doing
they?
H
They
are
trying
to
trace
where,
where
their
code
is
using
a
function,
prototype.bind
so
to
understand
how
their
application
work
right,
I
don't
know
for
tinkering
basically,
and
it
doesn't
work
because
not
just
relies
on
it.
H
B
B
So
we're
still
going
to
get
an
issue
about
it.
So
this
issue
here
that
he
was
trying
they're
trying
to
rewrite
bind
to
so
they
can
console
log
something
now
if
we
do
it
with
primordials.
Of
course
they
can't
do
that,
but
then
we're
going
to
get
an
issue.
I
would
like
to
do
this.
Why
doesn't
it
work.
B
H
So
for
people
who
it's
a
issue,
three,
two,
three
six
one
so
they
are
trying
to
to
define,
redefine
function,
prototype
bind
and
they
call
in
console.log
inside
the
issue
is
that
console.log
is
using
that
bind
in
the
in
the
gut
path.
So
it
it's
an
infinite
bloop,
because
we
are
not
using
pro
modules
actually.
F
F
Programs
to
work
when
doing
that
and
the
answer
should
very
likely
be
no
and
that's
the
point
you
know
like
so
you
wouldn't
create.
G
F
Much
any
code
running
out
there,
not
of
course
we
are
running
javascript
and
you
are
able
to
mutate
javascript
code
at
runtime
and
that's
something
very
well.
It's
just
a
language.
You
know
that's
the
nature
of
the
language
and
if
we
change,
we
only
change
like
a
small
part.
Node.Js
itself
is
only
the
basis.
The
foundation
for
running
a
lot
more
code
like
there's
a
huge
amount
of
code,
normally
in
node
modules
and
node.js,
is
just
a
part
of
it
and
you
would
still
break
all
the
rest
of
the
code.
B
I
A
A
This
particular
pr,
you
know,
I
think
I
think,
should
at
least
in
my
personal
opinion
is
still
a
good
thing
to
do,
no
matter
where
we
end
up,
you
know.
Unless
and
if
we
end
up
sooner
than
later
on
something,
then
maybe
it's
less,
you
know
it's
it's.
We
won't
need
it
for
as
long,
but
it
seems
like
today
we
do
need
it.
A
Okay,
so
I
think
the
the
ask
there
was
like
for
people
to
you
know,
take
a
look
at
the
pr
make
specific
comments,
suggestions
or,
if
there's
things
you
think
are
wrong
or
whatever,
but
so
looking
for
more
reviews,
any
more
discussion
before
we
move
on
from
that
one.
A
No
okay,
well.
The
last
issue
on
our
agenda
is
potential
stagnation
of
open
issues
on
the
h1
bounty
program,
so
that
you
know
a
blog
post
went
out
earlier
this
week,
sort
of
to
people
who
had
open
issues
what's
going
to
happen,
and
you
know
effectively.
Those
issues
should
be
bulk
closed
on
the
ecosystem,
hacker
one.