►
From YouTube: Node.js Tooling Group Meeting 2021-02-19
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
Okay
looks
like
we're
live
hi.
Everyone
welcome
to
the
node
tooling
meeting
for
february
19th,
so
yeah,
let's
jump
right
into
the
agenda
here,
looks
like
the
agenda
is
much
cleaned
up
over
the
last
few
times.
We've
only
got
a
couple
things
on
here,
so
we
can
run
through
those
and
then
get
on
to
any
new
business.
A
So
first
on
the
agenda
is
recursive
copy,
which
I
have
not
really
done
anything
else
on
since
our
last
meeting.
B
B
A
B
B
C
Yeah,
this
is
I'll
share,
last
week's
notes
in
case
anybody
wants
that's.
Last
week's.
A
B
B
B
A
Yeah,
so
I've
got
him
mentioned
here,
so
I
just
said:
we're
considering
using
the
fs
extra
recursive
copy
implementation
to
implement
this
in
node.js
love
your
feedback
on
this
proposal
and
on
incorporating
part
of
fs
extra
into
node
core.
B
B
B
Sorry
yeah,
I
put
it
in
the
notes
yeah
they
were
about.
They
were
both
like
really
had
some
really
good
feedback
on
the
rimroaf
implementation,
as
as
related
to
like
kind
of
operating
system
level
calls,
and
I
thought
they're
pretty
knowledgeable.
I
think
they'd
be
good
people
to
talk
to
about
the
copy,
recursive
stuff.
A
Okay,
so
I
posted
that
on
the
recursive
copy
issue
yeah,
like
I
said
other
than
that
I
haven't
worked
on
this
in
the
last
couple
weeks,
so
I
think
kind
of
we're
still
yeah
that
I
think
we
agreed
the
proposal
is
at
a
reasonable
state.
So
yeah,
I
guess
we're
just
looking
for
feedback
at
this
point,
see
what
they
have
to
say
and
then
move
it
on
to
the
main.
That
makes
perfect
sense
to
me.
B
I
have
done
no
work
on
that
and
but
I
think
my
action
item
is
prior
to
talk
to
joey.
B
Or
maybe
maybe
anna
okay.
A
B
B
A
B
I
don't
know
that,
there's
a
plan
to
backport
the
we'll
see
I
mean
it's
not
listed
as
a
breaking
change,
so
I
think
it
would
be
backported
by
default
to
active
release
lines
like
14
if
it's
not
breaking
so
we'll,
probably
end
up
in
14
and
I
think
12
they're
not
back
parting
to
anymore.
I
don't
think
if
I
recall
so.
B
D
B
B
How
does
that
work?
Do
you
just
like
make
it
against
the
14
point
x,
branch.
B
A
B
Yeah,
I
even
got
feedback
on
it.
Corey
said
he
liked
it
and
it's
gonna
update
nyc's
docs
to
point
to
it.
So
I
was
that
was
unsolicited
user
feedback
that
it's
working
well
for
them.
So
that's
good
and
I
use
the
heck
out
of
it.
It's
useful,
so
cool
all
right.
I
think
that's
all
there
is
to
say
there.
I
think
the
features
come
together
pretty
well
over
the
last
year.
So
I'm
pretty
happy
with
that.
A
Cool
yeah,
let's
move
on
so
next
on
the
agenda
is
argument
parsing,
I'm
not
sure.
If
we're
going
to
want
to
take
a
longer
time
talking
about
that,
though,
maybe
we,
if
anyone,
if
there's
any
like
new
business,
we
could
get
that
out
of
the
way
and
then
spend
the
rest
of
the
meeting
on
argument.
Parsing.
B
My
new
business
would
be
node
fetch.
I
saw
a
bunch
of
conversation.
I
saw
some
heated
conversation
happening
about
it
on
on
twitter
this
last
week
and
I
don't
know
the
state
of
it,
but
I'd
love
to.
B
A
A
that's
a
tough
one.
I
also
was
kind
of
following
some
of
that
conversation,
starting
to
feel,
though,
like
like
too
many
cooks,
you
know
what
I
mean
like
I
want
to
help,
but
I
also
don't
want
to
just
add
to
the
the
noise,
I'm
not
sure
how
best
to
approach
that.
B
It's
weird
what
I
found
weird
about
the
conversation
is
that
we've
had
some
pretty
good.
Well,
where
I
thought.
Let
me
I'm
going
to
backpedal
and
make
this
a
more
positive
sentence
where
I
think
we
could
help
this
conversation.
Is
we've
actually
done
a
a
really
good
job
of
just
pulling
in
third
party
stuff,
like
we
pulled
in
rimroaf
to
help
do
the
recursive
removal
stuff
and
it's
been
in
the
code
base
for
I
think
well,
over
a
year
now
it's
been
working.
B
Customers
like
it,
I'm
trying
to
figure
out
why
it
has
to
be
like
a
clean
room,
re-implementation
of
node
fetches
api.
If,
if,
if
there's
a
good
node
fetch
implementation
in
the
community
like-
or
I
guess,
the
two
arguments
I
saw
was
like-
we
can't
have
100
of
the
functionality,
so
we
shouldn't
have
the
functionality
was.
I
think
one
argument
I
saw
that
was
floating
around
in
a
thread
and
anyways.
A
B
A
Want
this
functionality
very
badly
like
I
want
to
help
with
it,
but
I'm
just
not
sure
what
the
best
way
to
do.
That
is
definitely
I
mean
yeah,
it's
definitely
worth
following
along.
I
also
don't
really
understand
the
argument
I
think
part
of
it
might
be
related
to
wanting
to
re-implement
it
on
top
of
ndg.
B
A
Right
he
was,
I
saw
on
twitter.
He
was
implying,
though,
that
it's
like
a
lot
of
work
like
like
six
months
or
more
like
full-time
work
for
someone
wow,
which
yeah
is
a
bit
surprising,
but
I
mean
I
assume
he
knows
what
he's
talking
about,
but
yeah
I
mean
it'd
be
interesting.
If,
if
that
work
was
happening,
you
know
be
great
to
help
out
with,
but
I
don't
know
what
the
state
of
that
is.
B
A
Yeah
that
was
kind
of
what
he
was
saying
is
like
it's
a
big
piece
of
work
like
that,
and
no
one
has
either
like
stepped
up
to
do
the
work
or
to
sponsor
someone
to
do
the
work
or
whatever.
A
Okay,
yeah,
I
mean
I
agree,
though
I
would.
I
very
much
would
love
to
see
that
in
node,
we'll.
E
I
think
ethan
from
microsoft
is
like
enthusiastically
trying
to
get
something
like
that
to
happen
right
that
he
could
work
full
time
on
something
like
this
he's
already
contributing
to
envy.
Quite
a
lot.
B
B
A
B
C
A
B
A
Okay,
if
there's
nothing
else
there,
I
was
just
quickly
going
to
mention.
There's
you
know
a
little
more
progress
on
the
rimder
recursive
deprecation,
that's
kind
of
still
ongoing.
Someone
opened
a
pr
to
sort
of
complete
the
deprecation
of
that
there's
a
little
bit
of
debate
about
the
actual
process.
A
You
know:
do
we
want
to
so
so
what's
happening
in
node
16,
I
think
is
the
permissive
functionality
will
be
it's
already
like
like
deprecated
and
it
will
be
removed.
But
then
the
question
is:
do
we
want
to
deprecate
like
the
recursive
option
entirely
from
rimder
and
what's
the
best
way
to
do
that?
Do
we
do
it
as
like
a
dock
only
deprecation
in
16
a
run
time
deprecation
in
17
and
then
remove
it
in
18
or
go
straight
to
the
runtime
deprecation.
A
So
that's
that's
kind
of
the
current
state
of
that
there's
a
bit
of
a
debate
to
vote
about
yeah
the
exact
process
for
deprecating
it
and,
I
think,
sounds
like
that
might
end
up
on
the
agenda
at
a
tsc
meeting.
I
think
you
proposed
that
right
then.
B
Yeah,
I
think
that,
just
to
like,
I
don't
feel
super
strongly
in
either
direction.
It's
like,
I
think
whether
we
end
up
with
a
runtime
deprecation
or
not
like
the
basic
plans
the
same
so
but
I
think,
would
be
good
just
for
visibility
for
the
tsc
to
see
it
because
it
will
bite
a
few
people,
because
when
you,
google,
rimrock
recursive
like
there's
a
few
thousand
users,
so
I
think
like
right.
It's
a
decision.
We
should
make
intentionally
I'm
willing
to
take
the
plan
to
the
tsc
and
see
if
they
have
a
strong
opinion.
A
B
A
F
A
On
it
but
yeah,
I
think
whatever
they
kind
of
whatever
the
consensus
is,
I'm
happy
with.
B
Yeah,
so
I
mean
the
plans
basically
the
way
I
read.
The
last
comment
was
the
first
steps,
basically
the
same,
which
is
that
we
actually
removed
the
permissive
behavior
in
16,
which
we,
which
we
already
had
a
runtime
deprecation
on
right.
But
the
question,
the
real
question
is:
do
we
output
to
the
console
a
message
hey?
This
is
deprecated,
don't
use
recursive
at
all
in
node
16,
or
do
we
just
have
that
in
docs?
That
says,
don't
use
this
in
16
is
going
to
go
away
in
17..
B
I
think
almost
have
a
slight
preference
for
the
runtime
deprecation
in
16
first
time.
That's
also.
A
My
preference
yeah,
if
we're
going
to
do
it
like
why,
why
wait
and
leave
it
there
longer
it
just
means
more
people
are
likely
to
start
using
it.
B
A
And
you
say:
there's
a
pr
I'm
trying
to
find
it.
There
is
a
pr
to
do
part
of
this.
The
deprecating,
the
the
like
permissive
behavior,
where
you
can
point
it
out
like
a
file
and
it'll
delete
the
file
or
you
can
point
it
at
something
that
doesn't
exist
and
it'll
just
silently
pretend
that
it's
succeeded
that
part
is
being
or
has
been
deprecated
and
is
being
removed.
A
B
A
Okay,
yeah,
that's
all
I
had
on
that
topic.
I
just
wanted
to
mention
the
progress
on
that.
Does
anyone
else
have
anything
they
want
to
bring
up
before
we
jump
into
oh
joe.
C
Yeah,
I
just
want
to
double
back
real
quickly
on
the
source
map.
One.
Looking
at
the
notes
ian,
you
said:
let's
be
proactive
about
backboarding
this.
Can
you
just
explain
to
me
what
needs
to
be
backported.
B
B
I
think
it's
relatively
low
risk,
because
one
we
didn't
want
to
call
it
breaking,
because
it's
an
experimental
feature
and
experimental
features
indicate
that
it
might
move
around
a
little
bit
and
I
think
it's
actually
pretty
low
risk
because
you
have
to
have
the
feature
turned
on
and
it's
it's
actually.
You
would
have
to
be
relying
on
like
if
you
wrote
tests
that
assert
against
your
console
output
like
node's
own
test.
Did
then
it's
breaking,
but
probably
it's
a
minority
of
projects
that
would
have
tests
that
actually
exercise
that
a
pretty
small
group
of
people.
A
F
Don't
know,
oh,
I
missed
that
I've
been
working
furiously
in
this
time
to
get
this
issue
together,
so
I've
my
last
week
or
so
has
been-
I
mean
I'm
sure
roy
can
attest
to
it
as
well,
pretty
busy
so
yeah
I'm
putting
together
this
consolidated
issue
with
everything
we
talked
about
and
I'm
I'm
probably
minutes
away
from
not
minutes,
probably
half
hour
away
from
having
the
issue
together
and
I
mean
think
I'm
gonna
essentially
label
it
or
title
it
like
parse,
argus
v2,
or
we
can
call
it
something
along
those
lines
with
the
consolidated
just
like
references
and
everything
to
what
we
discussed
last
week.
F
F
Cool,
so
this
is
preview
I'm
just
trying
to.
Essentially
I
wanna
outline
maybe
also
like
rich,
like
why
we've
taken
this,
so
I
don't
have
that
in
here
yet
but
like
why.
We've
taken
a
step
back
and
are
looking
at
this
again
so
anyways.
F
I
put
the
two
links
initially
to
the
original
issue
that
we've
been
tracking,
so
maybe
this
will
essentially
supersede
it
kind
of
like
say:
hey,
here's,
some
historical
reference
of
all
the
conversations
we've
had
and
then
here's
the
old
pr
and
then,
as
I
shared
before,
with
what
I
believe
to
be
sort
of
the
problem
statement
and
potential
solutions
left
those
in
and
then
would
like
to
track
some
action
items
in
terms
of
which
I
think
number
one.
F
I
just
want
to
make
sure
that
when
we
come
back
to
the
table,
we
have
like
a
whole
bunch
of
ed
cases
and
examples
together,
which
I
had
started
to
create
with
all
the
different
sort
of
examples
we
were
putting
together
last
last
time.
We
talked
about
this
and
then
I
think
that
the
the
next
steps
would
be.
I
would
I'm
going
to
pass
this
off
to
joe
and
let
joe
go
be.
F
The
have
the
those
conversations
I
think
with
as
long
as
we're
all
in
consensus
with
what
the
implementation
looks
like
then
go
back
to
the
maintainers
and
and
get
consensus
there
before
then
doing
the
work
to
actually
do
the
implementation.
So
I
don't
have
that
last
one
as
the
action
item
to
actually
do
the
work,
because
I
still
think
that
you
know
we
won't
be
mindful
that
we
don't
want
to
like
waste
our
time
if
we
design
something
that's
not
going
to
get
buy-in
from
the
folks
that
are
going
to
review
it.
F
I
don't
think
the
hard
thing
here
is
the
is
the
actual
writing
the
code
right
so
yeah
so
new
proposal.
I
also
like
created
just
like
a
diff,
so
folks
could
see
you
know
what
exactly
changed
between
at
least
the
documented
parse
documentation
here.
So
that
might
be
a
quick
like
synopsis,
there's
the
markdown
and
then
I'm
flushing
out
examples
right
now.
So.
C
I
would
you
know
one
thought
I'm
having
is
if
someone
came
to
this
issue,
I
mean
I
guess
this
is
you're
putting
this
in
the
tooling
repo,
but
if
someone
came
to
this
issue
without
the
previous
context
of
working
through
the
v1
of
this
attempt,
some
of
this
might
be
confusing.
Like
problem
statement,
almost
seems
to
imply
that
it's,
you
know
based
on
current
implementation,
as
opposed
to
previously
proposed
implementation.
You
know
what
I
mean.
F
I
don't
know
like
I
agree.
I
agree
with
what
you're
saying
gel
like
we
want
to
like
encapsulate
that
this
is
the
reason
why
I've
framed
it.
This
way
is
that
we're
you
know
we
went,
we
went
and
read
through
all
these
conversations.
We
went
and
tried
to
summarize
essentially
what
the
feedback
was.
So
maybe
it's
like
summary
summary
of
feedback,
initial
proposal.
C
F
Cool,
we
can
look
again
here
if
you
want
just
that,
essentially
what
the
differences
are.
So
again,
if
we
look
at
maybe
the
first
example
actually
I'll
wait
to.
I
have
to
clean
up
a
bunch
of
the
examples
I've
been
playing
around
with
them
with
joe
and
then
when
we
were
on
the
call
the
other
day
they
I
didn't
want
to
make
sure
they're
accurate,
but
yeah.
I
believe
the
the
actual
proposal
here
is
is
accurate,
so
cool
any
questions.
F
Any
thoughts
about
like
how
I
want
to
like
essentially
throw
this.
This
is
essentially
like
my
spaghetti
at
the
wall
and
then
I
think
like
hopefully,
if
there's
any
feedback,
then
we'll
capture
it
here
with
this.
F
I
know
that
isaac
wants
to
chime
in
on
this,
and
I
was
talking
with
him
so
just
want
to
also
make
sure
that
he
gets
a
chance
to
like
give
his
feedback
before
we.
We
go
for
round
two
here.
B
B
It's
clever.
I
really
like
that
because
it
just
the
fact
that
it
means
that
you
can
piece
together.
It
means
you're
not
losing
information
during
the
parse,
which
was
the
reason
a
lot
of
our
more
complex
behavior
existed
in
the
argument.
Parser,
I
think
so
to
me.
It's
seems
like
it
works
like
it's
like
it's.
My.
F
Like
you
know,
so,
it's
like
we're
not
going
to
change.
The
type
of
input
like
the
the
arg
v
like
like
passes
an
array.
It's
like
we're
not
going
to
array
of
strings
we're
not
going
to
typecast
we're
not
going
to
do
any
coercion
or
anything.
What
was
isaac's
got
about
this
approach?
I
don't
think
he
hasn't
seen
this,
but
we've
just
discussed
he's
like.
F
I
think
he
also
went
and
and
looked
at
the
historical
like
he
was
looking
at
the
original
pr,
and
so
like
I'm
gonna
get
his
input
on
this
as
well.
I'm
sure
he'll
get
a
strong.
He
says
he's
got
a
couple
like
edge
cases
that
I
think
again.
He
had
the
original
proposal
in
mind
when
he
was
brought
that
sentiment
up.
It
was
an
off-the-cuff
comment
that
he
made
in
one
of
our
calls
today,
just
as
I
said
that
we
were
gonna
be
on
this.
He
he
unfortunately
couldn't
make
it
today.
E
F
B
A
Opening
this,
this
issue
is
a
good
step.
I
I
would
also
be
interested
in
spending
spending
some
time
reading
it
over
and
yeah.
We
can
kind
of
give
some
some
initial
feedback
here
before
we
take
it
to
the
you
know,
main
repo,
so
yeah,
it
seems
like
it
seems
like
a
good
next
step
to
me.
F
Cool
so
I'll
keep
working
on
on
this,
like
I
said,
it's
probably
got
like
another
20
minutes
of
just
cleaning
up
and
and
also
when
this
gets
created,
I'm
not
sure
if
you
can
edit
joe
but
feel
free
to
edit.
This
like
feel
free
to
like,
come
in
and
add
your
spin
on
it,
because
you
know
I
think
you're
going
to
be
the
one
to
end
up
actually
doing
the
implementation
work.
So
I
want
to
make
sure
that,
like
this
speaks
to
you
know
I'll
I'll
put
your
name
on
here
as
well.
C
Cool
yeah,
I
I
don't
think
I'd
be
able
to
work
on
it
until
you,
you
know
submit
it,
but
if
you
want
to
work
on
a
hackmd
file
or
whatever
that's
fine
too,
but
I
think
probably
the
sooner
we
get
this
open,
probably
the
better
yeah.
F
Yeah
I
apologize
it's.
It's
been
a
bit
crazy,
so.
F
C
I
don't
know
yeah
be
cool
to
you
know
not
necessarily
right
this
moment,
but
it'd
be
cool.
To
start
writing
some.
You
know
tests
test
cases.
F
Yeah,
so
I'm
I'm
hoping
that
the
change
doesn't
change
as
much
of
the
code
like
that
is
already
there,
like.
My
hope,
is.
Actually
we
can
reuse
like
most
of
what
chris
had
put
proposed,
because
I
think
it's
it's
essentially
just
going
to
be
removing
a
lot
of
complexity.
It's
actually
just
like
really
like
ben's
note
is
is
is
true
like
the
idea
here
is
that
you
don't
lose
any
information
and
we
make
less
assumptions.
B
I
have
a
test
suite
that
we
could
use.
It
might
be
worth
looking
at
that.
I
will
link
right
now:
yard
parser
is
like
yards's
parts
are
split
out
of
its
own
project,
called
yard's
parser
and
has
like
pretty
pretty
big
test
suite
in
one
file,
which
we
don't
want
to
support
that
whole
test
suite,
but
we
can
at
least
see
a
bunch
of
weird
edge
cases
if
you
read
through
it,
because
it
has
basically
years
worth
of
weird
edge
cases
that
people
have
pointed
out.
B
C
F
No
problem,
I
apologize
again
trying
to
get
this
to
together,
yeah
yeah,
the
design.
F
Obviously
I
took
the
time
to
really
think
about
it
that
one
night
and
that
that
spawned
most
of
like
the
ideation
on
on
this
in
this
area
and
like
the
design
it
just
it
sort
of
yeah
again
it
just
kind
of
like
struck
me
as
like
the
perfect
like
like
why,
if
the
the
core
problem
here
is
that
we're
trying
to
do
too
much
and
makes
too
many
assumptions,
why
don't
we
just
like
parse
these
things
separately,
like
like
yeah,.
B
B
A
B
Yeah
well
because
I
think
about
it,
like
so
dino
she
just
ships
with
a
fork
of
minimus.
Basically,
that's
that's
their
standard
library
parser,
which
it's
kind
of
similar
to
what
we're
doing
here,
actually
like
it's
just
a
slightly
even
trimmed
down
version
of
minimist
python
is
something
closer
to.
I
think.
Python's
art
parsing
stuff
is
a
little
closer
to
yards
where
it's
kind
of
full-featured.
You
get
a
nice
output
like
it's
it's
it
does
a
lot
for
you,
so
I
don't
know.
A
Yeah
the
goal
was
to
keep
it,
keep
it
simple
right
and
you
know
people
need
something
more
advanced.
They
can
use
a
third-party
library,
yep.
F
A
bit
bare
bones,
like
validation
and
like
defaults
like
having
defaults
and
aliases
like
I
had
a
whole
like
little.
You
know,
like
I
know,
less
than
100
lines
or
something
yeah.
B
A
B
A
B
Yeah,
whatever
I've
been
thinking,
I've
been
thinking
about
like
what
the
journey
looks
like
for
yards
to
support
esm
as
we
move
towards
node,
12
and
beyond.
B
I
think
it's
actually
a
lot
easier
for,
like
new
libraries
to
just
do
that
from
the
get-go
that
don't
have
a
user
base
yet
and
then
some
of
these
older
libraries
like
yards,
where
they're
kind
of
hampered
down
by
their
existing
community
and
they
need
to
figure
out
a
path
forward.
It
could
be
an
interesting
year
for
javascript.
E
F
I
wasn't
going
to
say
that
on
this
call,
I
don't
know
if
that's
kosher,
but
yeah,
we
are
we're
growing.
Our
team
yeah
we're
we're
working
on
quite
a
quite
a
few
things
in
our
our
neck
of
the
woods.
I
know
roy's
working
on
improved
workspace
support
and
we're
sort
of
ideating
on
and
noodling
on
on
some
of
that,
yeah.
E
B
B
B
There
we
might
be
held,
actually,
we
might
be
held
to
some
things,
just
as
part
of
like
how
a
group
runs
as
part
of
the
node
project.
I
don't
know
probably
joe,
would
know
a
little
better
than
me
actually,
but
I
have
a
fun
thing
I'll
share
too,
but
not
a
hiring
announcement,
but
the
outfit
in
chat,
the
release
tool.
I've
been
working
on
for
the
last
couple
years
is
getting
really
cool
it.
My
colleague
added
support
for
multiple
branches.
B
B
So
we've
actually
been
landing
a
ton
of
features
around
like
it's
smart
enough
to
actually
have
releases
coming
from
multiple
branches.
Now,
so
you
can
have
like
your
main
branch,
which
always
has
what's
being
released,
and
then
you
can
have
a
like
lts
branch
that
will
also
get
release
prs
created
for
it,
it's
pretty
cool
and
then
we're
also
working
on
monorepo
support
right
now,
so
that
we
can,
because
I
have
this
need.
B
Oh,
it's
super
close
yeah
there's
a
there's,
a
fellow
on
a
different
team
than
mine
at
google.
Who's
been
pitching
in
to
build
it
because
his
team
needs
it
so,
but
it's
a
beautiful
design,
so
it
looks
like
it
should
be
done
pretty
soon,
whereas
I
would
have
just
tacked
something
together,
I'm
sure.
So
it's
been
been
humbling
to
see
someone
build
something
good
rather
than
the
sorts
of
things
I
build.
B
Okay.
Well,
I
guess
that's
all
of
the
items
in
our
agenda
for
the
week,
yeah
yeah!
That's
all
that's
on
my
mind.
We
still
haven't
had
the
meeting
to.
We
still
haven't
had
a
meeting
to
kind
of
outline
just
general
goals
for
2021,
but
we
also
have
a
bunch
of
things
in
the
in
the
works
that
seem
great.
So
I
don't
know
if
we
need
to.
I
don't
feel
any
huge
pressure
to
get
more
work
on
our
plate
right
now.
I
don't
know
how
people
are
feeling.
B
The
one
thing
I
would
like
to
maybe
say
is
especially
as
we
do
the
copy
dash
artwork
if
we
do
go
the
route
of
kind
of
using
something
for
the
community
and
just
kind
of
blessing
it
as
a
standard
library
inside
node
kind
of
continue
to
think
about
how
we
standardize
that
process
and
kind
of
make
that
continue
to
make
it
easier
for
even
an
external
contributor
to
to
make
that
kind
of
proposal,
because
because
one
thing
that
comes
to
my
mind,
is
that,
like
you
know,
has
a
huge
standard
library
comparatively
to
node
and,
like
I've
definitely
seen,
I
mean
in
the
in
the
next
10
years,
with
an
emphasis
on
usability
of
the
code
base
and
with
you
know,
people
getting
used
to
these
other
alternate
runtimes
for
javascript.
B
It's
just,
I
think
worth
having
on
our
minds
how
we
scale
this
type
of
work.
So,
if
we
were
gonna
have
a
meeting
where
we
plan
2021
work,
that
would
be
the
theme
I
would
be
advocating
is
like.
Can
we
scale
this
beyond
the
core
group
of
people
on
this
call?
Can
we
make
this?
Can
we
have
a
recipe
for
this
type
of
work
instead
of
just
doing
it
as
piecemeal
like
we
have
been
so
just
I
don't
know
food
for
thought,
yeah
put
on
people's
minds.
A
Yeah
yeah,
I
think,
maybe
maybe
even
getting
through
the
copy
dash
r
process,
will,
because
we
are
kind
of
trying
to
approach
it
in
a
little
bit
more
thoughtful
way
than
we
did
with
with
rimroaf.
So
maybe
even
that
becomes
kind
of
a
good
template
for
doing
that
in
the
future,
or
something.
B
I
agree
and
I
think
just
write
down
how
we
did
it
and
even
make
it
easy
for
other
people
to
propose
doing
that,
so
not
that
we
need
to
pull
everything
into
the
node
course.
It's
like
this
balance.
Right,
like
you,
want
something
that's
pretty
full
featured,
but
you
don't
want
it
to
be.
Have
everything
in
the
kitchen
sink.
So
it's
kind
of
it's
the
classic
argument
of
small
core.
A
If
you're
going
like,
you
know
full
like
serverless
framework,
where
you're
bundling
dependencies
and
all
of
that,
then
it's
fine
to
use
something
from
to
use
like
packages
from
npm,
but
if,
if
you're,
trying
to
just
build
a
quick
function
for
something
like
that
was
where
fetch
really
the
fetch
missing
really
was.
It
was
kind
of
an
issue
for
me
just
wanted
to
make
a
really
simple
request
to
an
endpoint
and
doing
that
with,
like
you
know,
the
http
library.