►
From YouTube: 2022-09-01 Node.js Tooling Group 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
A
All
right,
I
think
I
hit
the
macro
here
from
the
YouTube
interface.
Sorry
about
that,
so
let's
go:
let's
go
for
the
agenda
here.
We
we
do
have
a
small
agenda
and
I
know
then
might
have
to
drop
a
little
bit
earlier
here
and
yeah
I
kind
of
wanted
to
start
with
this
promisifying
models.
Work,
Eric
kind
of
like
was
helping
out
that
this
is
pretty
cool
yeah,
so
yeah.
If
you
want
to
talk
about
a
little
like
the
one,
okay
I
know
you
yeah
I
have
at
least
one
poor
Quest.
B
All
right
so
I've
been
working
on
promisifying
the
apis
there,
but
there
are
a
lot
of
discussions
about
the
node
prefix
right
so
like
in
this
case
we
had
the
inspector
and
the
inspector
our
works
without
the
node
prefix
there,
however,
they
are
discussing.
If
we
should
like
ensure
that
for
new
modules,
it
will
have
the
node
prefix.
But
for
me
it
doesn't
make
much
sense,
because
the
inspector
is
already
there
right,
so
we're
gonna
have
slash
promises
and
then
only
for
our
promises.
B
We're
gonna
have
to
put
the
prefix
there,
but
the
problem.
Now
it's
about
the
consensus.
What
should
we
do
for
all
the
apis,
so
I'm,
trying
to
Promise
by
other
other
ones,
from
the
child
process
and
other
modules,
but
I
think
like
a
muser
as
a
music,
this
prefix
just
for
a
few
modules
like
suit
modules
that
already
works.
There
sounds
confusing.
C
I
kind
of
agree
like
because
I
mean
FS
slash
promises
is,
is
like
an
example
of
where
it's
been
done
already
and
you
don't
require
the
fs
or
you
don't
require
the
node
colon
prefix
for
FS.
Slash
promises
right,
so
I
think
that's
a
reasonable
argument
like
if
the
module
already
exists.
Maybe
it's
okay
to
add
the
promises.
If
the
module
doesn't
exist
already,
I
understand
that
that
they
want
to
namespace
any
new
modules
that
are
introduced.
C
B
C
A
A
C
C
B
C
Explicit
TSC
vote
and
say
this
like
we
would
like
to
vote
on.
If
the
module
already
exists,
we
can
add
the
slash
promises
endpoint
as
an
option
and
have
promises
available
without
having
the
node
colon.
If
and
only
if,
the
module
already
exists
in
the
system
and
then
the
compromise
I
would
say
is
supporting
both,
like
you
say,
like
we
will
support
the
node
colon
as
well,
but
and
maybe
even
document
the
node
colon
one
to
try
to
encourage
people
to
start
using
the
namespace.
But
at
least
it
doesn't
trip
up.
B
B
B
Like
bit,
no,
who
was
it
it
was
actually
actually
arguing
the
past
that
they
actually
voted
this
before,
because
the
test
Runner
already
decided,
like
all
the
modules,
should
have
it
and
now
he's
like.
Oh,
my
God,
it's
confusing
because
we
are
devoted
for
it,
and
now
we
have
a
second
thing,
but
that's
anything
I
think
this
voting.
We
will
clarify
everything
right.
B
A
C
A
C
C
A
C
C
Oh,
this
is
a
great
I
guess,
Jordan's
thinking
about
the
exact
same
problem.
A
C
Okay,
I
think
we
should
share
this
with
Daniel
Bankhead,
our
colleague
and
and
that
maybe
he
can
join
that
conversation
or
even
help
with
the
implementation
sure.
C
So
yeah
I
think
maybe
we
have
our
grooming
session
at
work
today
for
tickets.
So
that
might
be
a
good
time
to
mention
it
to
Daniel,
because
we'll
be
in
the
same
meeting
right.
C
A
Yeah,
so
we
we
kind
of
exploded
that
idea
over
the
last
few
meetings
and
comment
like
I,
think
Dorothy
follow
up
and
commented
on
it
with
a
few
stats
on
the
issue
there
on
GitHub,
but
then
yeah
there's
also
like
yeah.
In
the
conversation,
it's
kind
of
continuing
right,
but
I,
don't
know
like
from
from
the
get-go
I,
don't
think
a
lot
of
people
are
sold
on
the
idea.
I
think
you
really
need
to
kind
of
like
create
the
story.
The
argument
for.
C
A
C
C
That
would
be
a
really
good
candidate
for,
like
a
short-lived
ecma
group,
like
you,
can
kind
of
create
a
short-lived
ecuma
group
to
standardize
something
like
this.
It
could
also
be
like
a
good
like
an
I
I
like
a
it,
was
an
ie
at
TF
or
whatever
it
is.
There's
a
few
standard
bodies
that
this
might
make
sense
for
standardization
is
a
lot
of
work,
though,
and
like
the
other
option
is
if,
instead,
you
were
going
to
standard
and
if,
instead,
you
were
going
to
say
that
this
is
a
browser
standard
where
it's
like.
C
C
Easier
path-
and
it
gives
you
something
like
standardization,
but
the
argument-
I
guess
is:
if
it's
not
too
used
in
the
browser,
does
it
make
sense
to
to
be
standardizing
it
in
a
double
like
w3c
right,
so
yeah.
A
A
C
I
the
annoying
thing
about
it.
Would
you
nice
to
almost
have
a
standards
body
that
that
would
be
nice
to
have
a
standards
path?
That's
like
we
want
this
to
work
on
JavaScript
platforms
for
the
server,
but
we
don't
care
that
much
about
JavaScript
platforms
for
the
web,
like
crypto.random,
uuid
I,
think
is
more
beneficial
to
backend
platforms
like
Dino
and
node,
then
to
baby
front
end,
but.
A
Yeah
I
guess
we're
now,
just
there.
A
C
A
C
Feedback
from
the
browser
standards,
people
like
Kevin's
kind
of
feels
like
it
would
be
trouble
getting
support.
A
Oh
yeah
I
think
that's
a
lot
of
the
sentiment
like
the
initial
sentiment
when
yeah
when
bringing
it
up
and
there's
also
one
consideration.
I,
remember
narcissists,
saying
that
the
current
implementation
of
Sam
were
notes.
Them
were
right.
That
would
be
we
ship
with
node.js.
It
differs
from
the
spec
actually.
C
That's
fine
Kevin's
thing
like
exactly
what
I
was
arguing
like
in
his
comment,
which
is
like
there
needs
to
be
some
third-party
thing.
That's
kind
of
beyond
the
scope
of
our
working
group,
though.
A
A
C
I
mean
I
think
there's.
This
might
be
a
good
experiment
before
we
like
just
move
and
build
semper
and
node.
This
might
be
a
good
opportunity
to
like
I
think
we
do
need
to
start
thinking
about.
We
should
be
thinking
about
a
multiple
JavaScript,
runtime
world
I.
Think
right
now,
because
we
have
like,
like
that,
standardization
group,
like
cloudflare
workers
like
are
what's
talked
about
in
that
standardization
group
Dino
as
far
as
I
understand
buttons,
just
trying
to
match
node
functionality,
but
cool
cool
cool.
C
A
C
C
C
C
C
If
you
are
looking
for
work,
this
is
a
great
one
Eric,
because
it's
a
good
start
but
I
think.
Basically
what
happened
was
it
touches
a
lot
of
C
code
and
the
C
code.
The
little
the
C
code
for
the
event
looks
a
little
confusing
where
it
looks
like
procedural
code,
but
I'm
pretty
sure
it's
actually
was
not
procedural
code
and
then
I
think
the
implementation
is
is
blocking
so
so
I
think
for
the
the
problem
with
the
implementation.
C
If
I
was
reading
the
code
properly
and
I
could
be
wrong,
so
having
another
set
of
eyes
would
be
good,
I'm,
pretty
sure
that
the
asynchronous
API
is
actually
a
blocking
API
in
that
implementation,
whereas
we
want
the
recursive
reader
to
be
parallelized
so
that
you're
doing
the
evented
lookup
of
the
files,
basically
so
packaging
stuff.
A
C
C
A
C
C
I'm
very
well
applied.
You
might
be
wrong,
but
I'm
pretty
I'm,
pretty
sure
that
that
synchronous
call
that
I,
just
linked
in
chat,
might
be
hit
in
an
asynchronous
yeah,
because
I
think
the
oncomplete
is
the
asynchronous
implementation.
So
but
then
it's
doing
a
recursive
read
sync
as
part
of
that
flow.
C
So
I
think
it's
a
painful
algorithm
to
write,
but
I
think
you
I
think
to
like
to
really
get
like
the
performance.
You'd
want
out
of
reading
hundreds
of
thousands
of
directories.
You
need
to
figure
out
the
algorithm
so
that
you're
using
a
async
call
through
everything
that
needs
to
happen
and
in
that
algorithm.
C
So
like,
as
I
said,
it's
like
I
think
kind
of
this
annoying
algorithm
because
you
have
to
like
keep
keep
track
of
State,
like
probably
have
some
sort
of
plan
for
back
pressure
like
but
I
would
say
the
it's
a
cool
feature,
because
I
think
what
you
want
basically
is
to
be
able
to
point
it
at
a
directory
of
a
million
files
and
get
the
list
back
right.
So
that's
kind
of
the
it's
kind
of
the
ideal.
B
C
A
B
B
C
C
Landing
of
partial
synchronous
implementation-
if
it
maybe
got
the
feature
done
and
then
someone
can
come
in
and
say
why
the
heck
is
this
synchronous
and
make
it
more
performant
right.
So
yeah,
yeah
I
just
thought:
if
we're
going
to
claim
like
any
synchronous,
API
it
can
it
can,
it
can
actually
be
a
real
performance
hit
if
we're
dropping
down
to
like
blocking
calls
so
like,
especially
if
it's
like
being
running
in
a
server
or
something
eat
your
whole
event.
C
A
C
A
C
Other
thing
I
was
going
to
say
is
the
parse
RX
update
was
like
there's
I
haven't
been
keeping
a
super
close
eye,
I
think
the
most
recent
thing
that
happened
was
that
tokenizing
API
landed
and
the
hope
there
was
that
if
people
wanted
Fancy
Pants
features
beyond
the
simple
API,
they
could
at
least
have
the
parsed
output
to
use
as
a
starting
point,
because
the
basic
idea
was
to
not
have
this
turn
into
something
like
yards
or
yeah
Commander.
C
We
want
it
to
be
simple,
so
the
idea
was
maybe
expose
the
guts
and
then,
if
people
want
to
build
more
complicated
stuff,
they
can
use
that
I
I'm,
looking
at
I
haven't
seen
too
many
future
requests
come
in,
which
is
I.
A
Think
great
Eric
was
mentioning
last
time
he's
talking
about
type
casting
for
okay.
B
A
B
A
B
Are
supporting
yeah?
Actually,
we
are
just
supporting
the
string
and
Boolean
right
and
I
was
like.
Why
shouldn't
we
support
all
like
data
types
there
right,
the
native
the
primitive
data
types
there
to
Parsi
behind
the
scenes.
C
C
If
it's
seasoning
that
looks
like
an
integer,
it
will
parse
it
as
an
integer,
which
means
that
grids
go
outside
of
the
numeric
range
for
JavaScript,
frequently
so
people
so
people
end
up
with
people
are
trying
to
put
in
like
a
super
long
number,
that's
actually
a
unique
identifier
and
yards
tries
to
turn
into
a
number,
and
then
it's
not
a
number,
because
it's
outside
of
the
yeah
it's
outside
of
the
bit
range.
A
C
Bits
or
whatever,
so
that
was
one
of
the
reasons
I
shied
away
from
it.
But
I
mean
people
are
adults
like
if
they
know
it's
an
ID,
they
can
leave
it
as
a
string
as
long
as
we're
not
trying
to
automatically
parse
it
up
for
people
so
yeah.
C
If
you
know
it's
a
numeric
type
coming
in,
maybe
it's
good
that
we
throw
an
error
if
you're
passing
in
a
numeric
type
that
can't
be
held
inside
of
JavaScript
in
right,
so
yeah
that
seems
like
a
reasonable
future
Quest
you
can
I
should
try
to
open
the
feature.
Requests.
I
mean
the
node
repo
is
fine
or
we
can
also
keep
developing
in
the
Parts
Arts
org.
If
we
want
to
yes.
B
But
rui
you,
you
said
that
you
have
some
like
some
thoughts
about
this
kind
of
parsing
rate.
A
B
A
B
C
C
C
A
Because
I
was
I,
basically
had
a
quick
chat
with
Eric
and
I
was
explaining
like
a
a
it's
origin
like
the
whole
concept
of
having
the
Forest
arguments,
was
more
for
having
like
a
Bare
Bones
like
that,
we
can
use
for
samples
like
it
can
be
useful
as
a
foundational
kind
of
work
to
other
parts,
but
we
don't.
It
was
never
meant
to
kind
of
kill
all
the
other
argument.
Parsers
and
like
be
the
you
know
the
one
way
of
doing
things
like
yeah,
it's
listening
yeah,
but
it's
still.
B
C
This
yeah
I
was
going
to
say
outside
of
that,
like
I've
been
seeing
a
lot
of
like
it
looks
like
there's
gonna,
be
some
talks
that
nodeconf
EU
about
it
and,
like
I've,
seen
a
blog
post
when
I
was
that
was
really
popular.
C
So
if
oh,
no,
if
we
make
it
like
six
months
or
a
year,
and
we
keep
seeing
like
feedback,
that's
pretty
positive
and
don't
have
a
ton
of
bugs
being
open
against
it,
like
I'd,
probably
start
to
make
the
case
that
we
call
it
stable,
like
so
I,
think
to
call
it
stable
right
now.
For
me,
it's
mostly
just
a
baking
period
like
see
how
the
talks
go
at
nodeconfy
you
and
yeah
kind
of
go
from
there.
C
Perfect,
perfect
I,
don't
know
if
you
saw
that
blog
post
that
went
out,
but
it
was
cool.
You
can
see
it's
getting
adoption
already
because,
like
I
feel,
like
our
other
features,
we've
added
to
node
sometimes
take
years
to
get
any
adoption
at
all.
So
it's
kind
of
I
think
it
shows
yeah
like.
B
C
I
think
there
was
like
latent
latent
excitement.
People
wanted
this
feature,
so
so
I'm
feeling
like
pretty
like
if
we
make
it
a
year
and
there's
like
people
aren't
angry
like
if
we're
not
seeing
issues
flowing
like,
should
be
working
like
this,
but
it
works
like
that
or,
like
you
know,
if
we
don't
see
too
much
controversy
happening
like
like
I
mean
little
like
feature,
requests
are
fine
but
I.
C
Think
as
long
as
we
don't
see,
people
saying
this
is
absolutely
the
wrong
implementation
like
it
might
be
worth
trying
to
make
the
case
that
we
call
it
stable
and
then
I
think
like
a
year
or
two
from
now.
What
I'm
kind
of
hoping
is
people
might
I'm
hoping
there
might
be
a
new
argument,
parser
that
uses
it
as
a
foundation
all
right,
because
yards
is
pretty
crafty
at
this
point,
like
both
I
mean
I,
don't
know,
maybe
Commander
is
better
than
Yorks,
but
but.
C
B
Be
really
supportive,
but
just
a
less
thing.
We
will
support
like
streams
as
well
here,
because.
B
Standard
like
yeah,
like
you,
can
have
like
a
child
process
today
and
you
you
send
like
a
data
there
and
get
a
a
like
condemnator
essential
their
place,
but
piping
data
we
put
pipe,
should
other,
like
programs
like
cli's
right.
So
the
argument
there
should
should
not
want
to
work
with
the
parts
hacks
here,
because
the
data
types
right-
oh.
A
Yeah
yeah,
but
I
I
argue,
is
a
different
thing
like
and
and
I
had
an
issue
to
track
that
that
I
kind
of
like
closed
recently,
like
with
a
very
nice
outcome,
basically
like
recently
I,
think
Brian
English
landed
this
web
stream
API
how's.
It
called.
A
B
Yeah
but
I
saw
that
I
was
like
that,
it's
nice,
but
it's
still,
you
have
to
wait
for
the
whole
stream
right
like
just
to
give
an
example:
I
viewed.
B
A
I,
don't
think
there's
anything
like
in
the
realm
of
foreign,
something
else
that
could
make
that
better,
but
I
know
that
I
know
that
this
streams,
like
got
much
better
like
you,
can
actually
use
a
single
weight
if
I'm
not
mistaken,
like
at
least
you
can
have
a
better
like
more
user-friendly
API
to
do
that.
Yeah.