►
From YouTube: 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
Cool
welcome
everyone
on
youtube
to
the
node.js,
tooling
group
meeting.
Let's
kick
it
off.
A
First
thing
on
well
kind
of
maybe
an
order
of
business,
I'm
just
I'm
just
kind
of
looking
at
our
agenda
and
it
seems
like
some
of
the
stuff
is
a
little
stale
or
doesn't
have
like
there's
some
stuff.
That
should
definitely
be
on
here,
like
the
discussion
around
the
work
we've
been
doing
for
our
recursive
rmrf,
which
I
think
you
can
talk
about
in
that
first
bullet
point,
but
it
doesn't
really.
A
I
don't
think
it
links
down
to
the
right
issues
really,
and
some
of
our
issues
on
here
are
maybe
a
little
bit
stale
at
this
point.
So
we
might
want
to
do
some
issue.
Grooming
at
some
point
soon,.
A
C
I'm
having
some
trouble,
your
audio
is
like
breaking
up
and
the
video
is
really
choppy
we'll
try.
Turning
that
video
off.
I
don't
know
yes,.
A
A
I
was
on
my
wi-fi
accidentally.
My
phone
has
way
better
bandwidth
all
right.
So
let
me
reiterate
what
I'm
saying
then
two
things.
Basically,
I
think
we
should
clean
up
the
agenda
a
little
bit.
That's
just
an
action
item.
I
think
we
should
do
out
of
band
because
the
agenda
has
stuff,
we
kind
of
always
kick
out
of
it.
At
this
point,
I
think
so
I
don't
know
who
wants
to
I
mean
I
can.
D
A
That
action
item
all
right.
Let's
send
it
to
me
and
maybe
I'll
just
comment
on
some
of
those
issues
and
see
if
anyone
does
still
want
to
champion
them
or
if
we
can
kind
of
boot
a
few
out
and
the
first
topic
of
conversation
is
the
recursive
file
system
stuff,
and
I
want-
and
I
think
this
has
been
a
really
interesting
topic
recently-
I'm
linking
ian's
pr
and
I'm
ranking.
A
A
Lots
of
people
rely
on
it,
we're
going
to
remove
the
experimental
flag,
but
then,
interestingly,
we're
also
going
to
indicate
that
that
flag
is
deprecated
in
node,
14.,
sorry,
deprecated,
node,
15.,
and
that
and
then
we're
then
going
to
work
on
adding
a
new
rm
method.
That's
more
permissive!
A
A
C
B
I
think
one
other
thing
that
might
be
a
good
learning
here
is:
there's
nothing
wrong
with
offering
two
apis
one.
That's
strict
and
one
that's
loose
like
you
know,
had
it
come
in
with
like
a
really
strict
or
original
approach
which
didn't
necessarily
solve
all
the
user
problems,
and
then
you
had
an
a
second
api,
which
was
the
the
loose
and
actually
usable
for
most
cases
feature
like
that.
That,
I
think,
would
you
could
you
could
make
the
argument
when
people
come
in
and
say,
look
yeah,
but
it
doesn't
do
this
behavior.
B
I
want
you,
you
can
always
point
to
the
in
the
lower
level
or
stricter
or
you
know
whatever
you
want
to
call
it
for
that
kind
of
thing,
which
is
effectively
all
that's
happening
here.
Right,
like
the
change,
is
basically
we're
moving
it
to
a
another
name
and
keeping
the
behavior.
E
A
Yeah-
and
I
do
think,
like
probably
will
make
it
so
the
rather
than
getting
the
recursive
rid
of
the
recursive
flag
completely.
I'm
I'm
gonna
make
the
case.
We
should
probably
move
it
to
like
the
behavior
of
net
or
to
dino
or
one
of
the
other
apis
where
you
still
have
the
recursive,
but
it
is
throwing
on
a
few
situations
yeah.
You
know
I
agree
with.
I
agree
with
that
comment,
though,
that,
like
it's,
not
the
end
of
the
world
like
if
we
could
maybe
could
have
started
here
right.
A
F
So
let
me
ask,
I
think,
joe
sepi
here
I
think
that
maybe
ian
and
I
have
an
action
item
to
start
to
work
on
an
rfc
around
that
ben.
Can
you
capture,
I
I'm
on
my
phone,
so
I
don't
have
the
notes
in
front
of
me
what
the
decisions
were
from
the
tsc
and
and
we
can
start
to
put
that
together
in
some
sort
of
rfc.
So.
A
C
I
think
that
was
the
one
yeah.
I
think
there
were
two
things.
One
was
to
put
together
a
list
of
other
file
system
operations
that
we
could
make
recursive
and
the
second
one
I
think,
was
maybe
to
do
an
initial
rfc
for
something
I
don't
that
one.
I
don't
actually
remember
often
I've.
I
haven't
had
time
to
do
anything
on
that
in
the
last
two
weeks,
because
I've
been
focused
on
this
this
new
pr,
but
I
should
have
that
done
this
weekend,
so
we
can
maybe
start
on
that
next
week.
A
I
think
it
may
be
a
good
way
to,
I
would
say,
maybe
a
good
way
to
to
approach
that
action
item
would
be.
We
take
the
stock
of
what
like
ian
said,
take
stock
of
what
we've
done
so
far
and
like
have
this
like
here's
our
plan
for
the
ap
for
the
file
system,
api
and
here's,
the
four
things
we
think
should
be
recursive
that
aren't
and
here's
the
one
additional
recursive
method,
we'd
like
to
add
that
we
think
would
be
really
valuable
to
the
community.
C
A
And
then
yeah-
and
I
think,
like
I
do
think
like
this-
has
been
a-
I
think
we
can.
I
think
we
have
buy-in,
we
have
a
plan.
I
think
I
think
we're
going
to
get
rim-raf
over
the
finish
line,
but
I
think,
like
the
learning
from
this,
is
to
not
do
this
in
a
slapshot
way
like
we
have
been,
because
we,
I
wouldn't
say
we
wasted
a
year
but
like
this
is
a
year
of
time,
is
a
lot
of
time
to
spend
on
one
api
method
being
added
to.
If
I
add
it
to
something
right,.
C
If
I,
if
I
count
vrs,
that
I've
made
and
remade,
I
think
this
is
this
new
one
will
be
number
seven,
none
of
which
have
actually
landed
so
yeah
it'd
be
nice
to
not
repeat
that.
A
Sounds
like
the
it
sounds
like
you
want.
It
would
like
to
work
potentially
work
with
joe
a
little
bit
when,
as
that
issue
starts
coming
together
again,
is
that
it
sounds.
C
Yeah,
I
think
we
talked
about
about
doing
both
so
yeah.
Maybe
it
maybe
makes
sense
to
start
with
like
putting
together
a
list
of
things
to
make
recursive.
A
F
Sounds
good,
and
also
ian,
if
you
want
to
you,
know,
sit
down
in
an
out-of-band
meeting
or
something
and
kind
of
go
through
some
of
the
stuff
I'd
be
happy
to
try
to
make
that
work.
A
Some
kind
of
related,
like
I
wasn't
sure,.
A
Something
I
want
to
touch
on
even
if
and
I'm
going
to
run
in
about
10
or
15,
so
I
might
be
opening
a
can
of
worms,
but
is
it
okay,
I'm
going
to
sneak
in
agenda
tomorrow
because
I
think
it's
important,
which
is
the
command
line
argument
stuff
that
chris
did
that's
been
abandoned,
yeah.
F
Oh
yeah
yeah:
let's
let's
talk
about
that,
it's
something
that
I
you
know
I
talked
to
chris
about
and
I'm
trying
to
find
time
to
do
more
stuff,
and
so
it
was
something
that
I
was
considering
picking
up
and
trying
to
get
over
the
finish
line.
So
I'm
happy
to
try
and
take
that
on
or
if
anyone
else
wants
to,
or
I
guess
we
should
discuss
what
we
want
to
do
about
it.
C
Was
gonna
say
I
definitely
agree
that
you
know
it's
like
it's
unfortunate
that
chris
didn't
want
to
keep
working
on
it,
but
that's
fine,
but
I
do
think
someone
from
this
group
should
should
pick
it
up
where
he
left
off
and
try
and
get
it
over
the
finish
line,
because
I
think
we
were
pretty
close
so.
A
I
was
speaking
for
myself.
I
was
really
happy
with
where
it
had
gotten
to
and
I
and
I
and
I
there
were
like
100.
I
totally
understand
where
chris's
frustration
came
from
like
there
was
200
comments
or
something
on
it.
From
my
perspective
of
someone
not
dealing
with
every
one
of
those
comments
like
it's
actually
really
close,
there's
like
two
or
three
kind
of
contentious
points
that
need
to
be
sorted
out.
C
F
Cool
I'd
be
happy
to
try
and
do
that,
and
so
is
it
cool
to
just
kind
of
reopen
it
and
and
just
start
addressing
issues
or.
E
F
Okay,
that
makes
sense
I'll
I'll
do
my
best
to
pull
that
together
and
make
sure
that
any
of
the
unanswered
things
are
brought
over
to
the
new
pr
I
don't
want
to.
I
don't
want
to
seem,
like
I'm
kind
of
sidestepping
any
concerns
or
anything.
D
A
I
have
one
of
the
one
of
the
contentious
points,
I'm
very
much
in
an
agreement,
but
didn't
want
to
even
throw
more.
I
didn't
want
to
throw
more
into
that
thread
which
is
which
is
like,
I
think
it
if
it
throws
by
default,
then
every
single
command
line,
app
anyone
in
the
world
writes,
is
going
to
be
start
with
a
try
statement,
and
that
means
that
you're
going
to.
D
A
D
F
Yeah,
I
think
it's
your
internet.
I
definitely
want
to
hear
what
you
had
to
say,
but
you
completely
cut
out
there
for
30
seconds
or
more
so
you
were
saying
the
try
catch.
You
know
the
throw
what
what
what
what's
your
perspective
there
and
then
we
can
move
on.
F
Yeah
yeah
so
ben,
maybe
let
us
know
when
you're
able
to
speak
in
a
way
that
we
can
hear
you,
because
I
can't
hear
you
at
all
so
so
roy.
Maybe
you
can
share
your
comment.
D
Yeah,
you
know
the
only
thing.
I
also
have
no
internet
issues,
I'm
on
a
satellite
internet,
so
I
have
like
a
huge
latency,
but
so
that
I'm
not
being
rude
if
I'm
talking
over
other
people,
it's
just
that
internet
but
yeah.
But
my
my
my
issue
with
that.
That
comment
in
particular
was
that
maybe
we
could
make
a
counter
proposal
in
which
the
error
at
least
become
usable
for
final
users,
so
that
the
error
is
like
very
specific
and
has
like
readable.
D
You
know
message
overall
for
final
user
so
that
it
could
be
able
to
identify
right
with
the
users
they
would
be
able
to
identify
by
reading
the
error
message
so
read
like
flag
name
like
should
not
accept
like
any
value.
It
should
just
be
a
b
because
it
is
a
boolean
right
like
try
to
at
least
steer
that.
F
What
you
were
saying,
I
think
you
cut
out
right
at
the
very
beginning.
A
Okay,
I
was
just
gonna
say
I
was
gonna,
make
a
case
that
the
ergonomics
of
a
try-catch
is
really
bad,
because
you're
going
to
end
up
having
a
let
variable
outside
of
the
scope
of
your
command
line.
Parsing,
because
you
need
to
assign
the
outcome
from
the
parse
to
it
and
now
you're,
not
using
a
constant
variable
for
your
arguments,
which
is
so
it's
just
kind
of
creates.
Worse
ergonomics
for
the
api.
A
C
I
do
kind
of
I
think
you
and
roy
are
kind
of
saying
the
same
thing
like
throwing
kind
of
sucks
in
that
instance,
but
what
roy
was
saying
like
yeah,
maybe
maybe
by
default-
it's
actually
like
a
useful
error
message
like
this
flag
was
you
you
specified
this
value.
It
should
be
this
type
of
value
and
then
that's
at
least
a
good
default
error
message,
and
maybe
then
people
have
the
option
of
of
catching
it
and
printing
their
own
error.
A
F
C
Yeah,
I
think
I
mean
just
just
thinking
about
it
as
like
a
user
of
something
like
that.
You
know
if
it.
If
it
had
pretty
good
default
error
messages,
I
would
probably
not
really
worry
too
much
about
customizing
them.
If
they're
good
out
of
the
box.
A
C
Yeah
sure
so
I
mean
the
next
thing
on
here
is
is
chmod-r.
I
don't
know
if
we
need
to
discuss
that.
Specifically,
I
think
that's
kind
of
going
to
become
part
of
you
know
the
fs
road
map.
I
know
that's
one
of
the
one
of
the
things
that
we
discussed,
adding
to
that
so
unless
anyone
has
something
they
want
to,
they
want
to
bring
up
on
that
particular
function.
C
No
okay,
there's
a
few
things
here.
I
think
like
ben,
was
kind
of
mentioning
earlier
like
foreign
function
interface.
I
think
that
was
brian
english.
That
was
knew
more
about
that
or
was
more
kind
of
concerned
about
that,
and
so,
since
he's
not
here,
I
would
say:
let's
just
skip
that
for
today.
C
Deep
dive
meeting
proposals,
so
I'm
just
gonna
look
at
this
issue
here
oops,
so
we
did.
I
guess,
do
our
our
first
deep
dive.
I
see
this.
This
issue
is
basically
what
should
the
topic
be
for
the
second
one
looks
like
esm.
Reloading,
I
think
was,
was
one
that
was
discussed
or
could
be
command
line
parsing.
Does
anyone
have
thoughts
on.
A
C
Yeah,
I
kind
of
agree
with
that.
We
was,
did
you
or
chris
attend
the
modules
meeting?
I
know
that
was
something
you
guys
were
thinking
about.
A
We
I
ended
up
not
attending,
I'm
not
sure
if
chris
attended
or
not
the
one
thing
I
do
know
is
that
chris
has
been
working
with
the
collaborator.
I
don't
know
if
maybe
on
mocha
who's
written
some
tooling
around
reloading
modules
he's
mentioned
a
few
times.
I
think
would
be
good
for
someone
in
this
group
to
understand
how
that
works
and
see
if
it
works.
Well,
because
maybe.
C
This,
I
guess
I
mean
I
think,
that's
a
good
topic
for
a
deep
dive.
When
would
we
want
to
do
that.
A
C
C
So
october
30th
tentatively
we
can,
we
can
follow
up
next
meeting
and
see
and
then
yeah.
So
I
guess
the
next
agenda
item
is
the
esm
module
reloading,
but
I
I
don't
know:
if
does
anyone
have
anything
on
that?
They
want
to
talk
about.
A
C
C
Problems:
okay,
what
else
do
we
have
here?
Support
for
hooking
spawn
spawn
sync,
I
don't
that
was
corey
that
was
sort
of
championing
that
one,
I
think
and
he's
not
here.
So
I
guess,
let's
move
on
better
way
to
detect
a
process
is
exiting.
A
A
On
the
call,
oh
oh
great
lurking
are
hooks
still
something
that
you
have
on
your
mind.
I
know
I
think
you
were.
It
was
one
of
the
things
you
talked
about
at
one
of
the
meetings
like
in
person
yeah.
It's.
E
It's
still
something
I
want
to
do
something
with
haven't
really
had
the
time
to
do
too
much
with
it,
but
yeah
essentially
like
yeah.
We
have
a
couple
different,
a
couple,
different
overlapping
needs
for
hooks,
and
so
I
I'm
kind
of
hoping
to
get
like
people
from
these
different
camps
gathering
together
and
coming
to
some
sort
of
consensus
on
like
what
the
lower
level
needs
are.
So
we
can
share
certain.
E
A
C
Okay,
I
guess
next
on
the
agenda
was
argument
parsing,
which
we,
I
think,
we've
covered.
The
last
thing
that
was
on
here
is
the
creeping
scourge
of
tooling
config
files
in
project
root
directories.
I
don't
know
if
we
have
anything
new
to
add
on
this
one.
I
don't
know
where
we
kind
of
landed.
I
think
we
all
kind
of
realize
that
it's
a
really
big
problem
to
tackle.
A
Yeah,
like
I
kind
of
like
I
converted,
I
I
had
it
top
of
my
mind,
because
I
was
in
the
middle
of
converting
yards
over
to
being
dual
mode
module.
So
suddenly
I
had
like
tsc
end
roll
up
and
and
all
the
other
stuff
I
already
had
for
config,
and
then
I
was
just
like
whatever
okay,
I
have
a
million
config
files.
Now
this
is
life
and
I
kind
of
just
moved
on.
C
A
B
C
I
think,
like
the
one
example
that
I
think
I
ran
into
was
oh
ben's
gotta
go
all
right,
see
you
ben.
The
one
example
that
I
ran
into,
for
example,
was
that
was
prettier.
You
can't
move
that
config
file.
As
far
as
I
know,
I
think
there
are
maybe
a
few
other
tools
like
that
out.
There.
B
That
seems
like
a
pretty
straightforward,
like
set
of
steps
for
us
to
take,
but
it
doesn't
necessarily
solve
the
problem
because
then
you
have
to
go
and
convert
all
the
projects
right.
I
guess
obviously
it
helps
for
maintainers
but
again
like
I
don't
have
this
problem
because
I
already
use
those
when
I
need
them.
I
also
avoid
config
file
based,
you
know,
tooling,
when
I
can
too
so
that's
you
know
maybe
doesn't
apply
as
much
to
me,
but.
C
Yeah,
I
think
I
mean
yeah
projects
would
have
to
update
if
they
chose,
I
think,
just
the
to
me.
The
issue
is
like
you:
don't
even
have
that
option
with
a
lot
of
them
today,
your
your
only
choice
is
to
put
the
the
config
file
in
the
project
route,
even
just
having
the
option.
So
you
know
I'm
starting
a
new
project.
I
decided
I
want
to
put
my
config
files
in
this
directory,
be
nice
to
be
able
to
choose
that
for
myself,.
B
I'm
just
a
little
concerned
that
we're
going
to
then
just
if
we
start
promoting
that
and
then
somebody's
going
to
say.
Well,
I
don't
want
it
in
the
dot
config
directory
that
you
know
the
tooling
group
said
I
want
it
in
my
test
directory,
because
this
is
my
test
config,
and
I
want
my
my
other
config
in
my
build
directory,
because
that's
the
one
that
is
my
build
config
and
you
know
it
like
it-
doesn't
really
solve
the
proliferation
it
just.
C
C
So
I
think,
like
a
middle
ground
might
be,
let's
just
see
if
we
can
encourage
tools
to
make
the
config
location
customizable.
So
then
you
have
the
choice.
B
With
that
in
mind,
do
we
do
we
keep
this
open,
or
I
mean,
like
the
issue
hasn't
gone
away?
It's
just
what
we're
going
to
do
about
it
might
have
a
better
might
be
better
if
we
rephrased
it
and
said
here
are
popular
projects
where
we
want
to
take
the
initiative
to
get
a
c
flag
or
whatever
you
know
it,
caught
whatever
it
needs
for
that
project,
and
that
will
be
that
like
will
close
off
the
open-endedness
that
is
currently
in
that
the
open
issue.
You
know.
C
Yeah,
I
agree.
I
think
we
talked
about
making
a
new
issue
anyways,
because
there
was
a
bunch
of
it
got
on
like
hacker
news
or
whatever,
and
it
got
a
bunch
of
comments
so
yeah,
maybe
maybe
closing
that
and
opening
a
new
issue
where
yeah.
Maybe
we
just
identify
like
a
list
of
some
some
initial
tools
that
don't
provide
this
customization
and
open
issues
with
them
or
something.
C
Sounds
good
okay,
so
I
mean
that
was
it
for
the
agenda.
I
I
threw
one
more
thing
on
here
just
because
we
did
talk
about
it.
I
think
it
was
last
time
of
the
deep
dive.
Maybe
it
was
the
meeting
before
that
about
trying
to
become
an
actual
chartered
working
group.
C
I
believe
chris
did
talk
to
michael
dawson
about
this,
and
it
sounded
like
he
was
encouraging
of
the
idea.
I
think
the
maybe
the
the
steps
if
we
want
to
move
forward
with
that
are
I
mean
we
need
to.
We
need
to
write
some
kind
of
a
charter
which
I
think
it
doesn't
have
to
be
anything
like
crazy.
It
can
be
fairly
short
and
then
sort
of
included
with
that
is.
Is
the
road
map.
C
So
we
could,
I
think
it
would
be
enough
if
we,
if
we
were
like
hey
here's
our
road
map
for
the
next
year
and
our
charter
is
to
do
the
road
map.
I
kind
of
got
the
impression
that
was
sort
of
what
we
would
need
to
do,
but
maybe
maybe
I
mean
that
might
be
a
good,
deep
dive
thing
too.
We
could
just
spend
one
meeting
just
talking
roadmap.
G
C
All
right
yeah,
because
I
mean
I
don't
I
don't
have
anything
sort
of
top
of
mind
for
that,
but
that's
definitely
something
that
as
a
group,
we
should
kind
of
work
through.
I
think,
like
obviously
you
know
we're
planning
some
additional
like
recursive
file
system
stuff.
I
think
that
would
be
a
part
of
it.
I
guess
kind
of
like
going
through
and
like
grooming.
Some
of
these
issues
and
in
the
backlog
as
well
would
help
with
that.
C
Yeah
roy
in
the
chat
said
someone
should
should
own
that
if
chris
isn't
going
to
be,
I
don't
know
I
I
don't
actually
know
what
chris's
plans
are.
It
sounds
like
he's
he's
just
taking
a
bit
of
time
off
from
the
project.
Hopefully
you
know,
I
don't
think
this
has
to
happen
like
today,
so
I
mean,
if
he's
back
in
like
a
month
or
something
and
wants
to
to
keep
moving
forward
with
that.
I
think
that's
fine.
C
If
it
looks
like
he's
gonna
be
away
for
longer
than
that
then
yeah.
Maybe
we
can
get
someone
else
with
ben
or
something
maybe
to
take
that
up.
F
I
don't
know,
and
I
don't
want
to
speak
for
him
for
sure,
but
based
on
my
conversation,
I
think
he
might
kind
of
focus
elsewhere,
not
like
totally
go
away
from
the
node
project,
but
maybe
do
something
different
and
something
where
he
doesn't
have
to
pr
code
in
and
stuff,
but
be
helpful
in
other
ways.
So
my
guess
is
maybe
he'll
come
back
at
some
point,
but
I
think
a
month
is
probably
not
realistic.
C
Okay,
I
mean
that's
good
to
know
so
yeah,
maybe
maybe
that's
a
maybe
we
can
talk
about
that
next
meeting
kind
of
decide
who
is
maybe
going
to
take
over
that
effort
and
spend
a
little
bit
of
time
discussing
road
map
ideas.
C
I
mean
we
can
do
that
now
too.
If
anyone
has
anything
they
wanna
they
wanna
add.
I
haven't
really
had
a
chance
to
put
much
thought
into
it.
C
But
yeah,
I
can't
really.
I
don't
really
have
anything
else
on
the
top
of
my
mind
that
we
would
want
to
include
in
that
okay.
Well,
so
maybe
that's
sort
of
an
action
item
for
everyone
for
for
next
meetings,
like
put
a
little
bit
of
thought
into,
you
know
what
what
we
think
this
group
should
work
on
over
say
the
next
year
and
then
yeah.
Maybe
we
can
discuss
that.
C
Hopefully,
we'll
have
some
of
the
issues
cleaned
up
by
next
time,
and
then
we
can
at
least
like
bullet
point
like
here's,
some
of
the
stuff
we
want
to
put
on
our
roadmap
and
then
also
yeah
kind
of
decide
who
who
we
want
to
get
to
to
take
over
that
effort.
C
B
Well,
I
didn't
want
to
cut
that
short
or
or
anything
so
I
was
wondering-
and
I
think
I
actually
even
pinged
the
team
in
on
this,
so
the
package
manager
manager
discussion
has
been
ongoing
and
I
I
I
have
opinions
that
I
think
somebody
needs
to
own
this
in
the
form
of
a
group,
and
I
think
the
ones
that
come
closest
to
the
space
are
the
package
maintenance
working
group,
and
this
group,
I
think
maybe
the
package
maintains
group-
is
closer,
but
but
I'm
not
actually
sure
because
really
to
be
honest,
like
the
foundation
of
a
lot
of
the
things
that
you
know
anyway,
the
package,
installation
story
and
and
tooling
we
provide
from
node
core-
is
very
important
in
this
space.
B
I
just
wanted
to
bring
up
and
see
if
anybody
had
any
feelings
on
this
group's
participation
in
that
discussion,
if
it
if
it
fits
with
people's
sort
of
vision
or
if
not
and
and
you
know
when,
then
I
I
won't
bring
that
up
again,
but
I
I
just
I
I
hesitate
right
now
with
that,
because
I
think
that
it's
a
couple
of
ics
driving
it,
which
is
fine.
I
mean
you
need
that
it's
totally
great,
but
also
without
the
structure
that
some
of
these
groups
give.
B
I
think
it
can
easily
go
astray
or
like
if
a
couple
of
those
ics
no
longer
participate,
then
like
the
whole.
The
whole
thing
is
is
got
nobody
to
support
it
and
I'm
worried.
You
know,
as
this
is
moving
forward.
People
are
talking
about,
including
it
as
an
opt-in
or
something
in
one
of
the
upcoming
majors
that
you
know
without
some
sort
of
ownership
story.
You
know
it's.
People
are
gonna,
start
using
it
right
away.
B
You
know,
as
we've
seen
with
all
of
the
experimental
apis
like
that's,
not
gonna,
stop
anybody,
especially
yarn
users,
who
want
this
thing.
I
mean
because
of
course
they
want
the
thing
you
know,
but
then
we
are
now
as
as
node
the
node
project.
You
know
stuck
holding
the
bag
without
really
a
a
good
plan
for
for
what
that
looks
like
so
I
don't
know
if
anybody
has
ideas
on
that
or
or
feedback.
C
Yeah
I've
been
I've
been
following
along
with
that
issue
as
well.
C
I
do
I
do
agree
that,
like
some
sort
of
ownership
of
that
project
in
a
working
group,
whether
it's
an
existing
one
or
maybe
like
a
new
one,
probably
makes
sense,
and
I
do
agree
that
there
there
is
definitely
a
little
bit
of
overlap
with
the
tooling
group.
I'm
not
sure
enough
that,
like
we
should
own
that
project,
that's
like
my
personal
opinion,
but.
B
Yeah
that
was
totally
my
take
too,
is
like
it.
We
have
this
venn
diagram
where,
like
everybody,
has
a
little
bit
of
steak,
you
know,
so
I
think
I
agree
with
this.
The
sentiment
that,
if
somebody
is
going
to
own
it,
it
definitely
probably
should
be
a
package
maintenance
or
sorry,
not
packaging.
It's
a
package
manager,
tooling
group
or
something
but
yeah
I
mean
that's.
C
I
think,
like
probably
package
maintenance,
or
it
gets
its
own
group-
makes
the
most
sense.
I
mean
there
is
definite
overlap
with
tooling,
and
you
know,
having
maybe
one
of
us
involved
in
that-
wouldn't
make
sense.
D
B
Yeah
naming's
hard
yeah
we
could,
we
could
come
up
with
the
name.
If
we
want
to
do
that.
B
It
crosses
so
many
boundaries
that
I
think
it's
going
to
be
a
really
tough
thing
to
get
the
right
group
of
people
in
the
room
for
those.
C
I
think
that
is
maybe
a
good
argument,
though,
for
it
to
like,
if
no,
if
no
group,
really
no
existing
group
really
fits
in
terms
of
owning
it.
Maybe
that
is
a
good
argument
for
there
being
a
new
group
and
then
just
having
like
participants
in
that
group
from
those
other
various
groups.
B
Okay,
well,
if
that's
it,
then
I'll
I'll
add
that
maybe
to
the
conversation
over
there
at
some
point
you
know
I'm
hesitant.
B
I
didn't
get
involved
in
the
original
threads,
because
it's
just
so
contentious-
and
I
just
don't
want
to
don't-
want
to
really
deep
dive
on
that
if
I
don't
have
to
but
but
I
think
that
I'll
I'll
I
I
already
commented
in
the
thread
to
this
point
so
I'll
just
make
sure
we
echo
that
the
tooling
team
is
sort
of
in
support
of
some
somebody
else
having
ownership.
C
I
was
even
thinking
about
chiming
in
on
that
issue
and
saying,
like
hey,
I'm
willing
to
to
help
with
like
the
maintenance
of
this
project,
so
yeah,
some
kind
of
representation
I
agree,
would
be
good,
especially
I
mean
I
don't
know
if
you
know,
for
example,
that
would
affect
like
if
a
project,
if
a
command
line
tool
has
like
bin
links.
If
that
suddenly
is
affecting
like
what
is
invoking
those
things,
you
know
that
definitely
seems
relevant
to
us.
B
Yeah
I
I
very
much
agree
on
that.
I
I've
been
trying
to
think
through
all
the
different
use
cases
where
having
a
shim
in
the
middle
might
like
actually
end
up
being
a
breaking
change,
and
I
imagine
there's
there's
got
to
be
at
least
a
few.
B
C
Yeah
definitely
agreed.
Does
anyone
else
have
anything
they
want
to
add
on
that.
C
C
C
Okay,
sure
yeah,
so
roy
just
wanted
to
mention
that
npm
seven
rc
is,
is
just
released
and
that
that's
they're
aiming
to
have
the
the
stable
version
of
that
ready
in
time
for
the
node
15
release,
which
I
think
is
happening
like
on
the
21st
or
something.
D
Miles
brought
up
in
the
tsc
meeting
that
just
to
make
sure
nobody
basically
opposes
the
idea,
because
the
since
december
cut
was
already
long
gone,
but
it
seemed
that
everybody
is
on
board
with
the
idea
so
yeah
just
to
make
sure
a
quick
heads
up.
If
done
what
anyone
wants
to
take
a
look
at
the
pr
but
yeah.
It's
an
important
rewrite.
C
Yeah
yeah,
I
know
that's,
that's
awesome.
I'm
excited
to
to
have
that
stable.
I
personally
am
hoping
to
make
use
of
it.
Although
I
did
open
a
discussion
and
then
found
out,
there
was
an
rfc
for
like
resolution
support
in
package.json
right,
that's
a
big
one.
Yeah.
We
need
to
move
from
yarn.
D
D
D
Yeah,
it
has
a
different
name:
it's
overrides
in
the
npm
rfc
world,
yeah
yeah.
C
But
yeah
I
mean
that's
awesome,
I'm
personally
looking
forward
to
yeah,
hopefully
switching
some
some
new
projects
over
to
npm,
seven.
C
There
sounds
like
a
no
okay
yeah,
so
I
guess
just
over
the
next
couple
weeks.
Let's
give
some
thought
to
what
we
think
should
be
on
our
roadmap
for
this
group,
and
I
will
see
you
all
in
two
weeks.