►
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
All
right,
okay,
so
here
we
are
node.js,
tooling
group
meeting
on
this
29th
of
29th
of
may
2020.
A
If
people
could
go
in
and
as
briana
has
done
here
in
the
minutes,
add
yourself
to
the
list
of
those
present.
If
you
cannot
do
that,
please
say
so,
and
somebody
will
add
you
so
does
anybody
got
anything
that
they
want
to
add
to
this
agenda?
That's
not
already
on
the
agenda.
D
C
I
have
a
quick
thing
to
share.
I
have
the
npn.
This
command
might
be
nice
to
share
at
the
end,
if
there's
time.
A
It's
it's
the!
What
command
different
command
to
npm.
A
C
Okay,
so
I'd
like
to
share,
because
I
think
it's
yeah
folks
from
this
group
might
be
interested
on
it.
A
Okay,
do
we
want
to
does
anybody
care
if
we
do
that
at
the
beginning,
or
should
we
do
that
to
the
end.
B
If
we
have
time,
I
I
wanted
to
bring
up
I'm
running
a
team
of
interns
this
summer
and
we're
working
on
something
that
I
want
to
do
partially
for
the
node.js
project.
So
I'd
like
to
talk
about
it,
it's
like
tooling
adjacent.
I.
A
Think,
okay
cool,
so
the
first
thing
on
the
agenda
would
be
this
standard
in
and
you
know
what
before
I
start,
I
want
to
put
something
on
this
too.
A
Okay,
so
standard
and
read
interface,
I
do
not.
I
have
not
kept
up
with
this
one.
It
looks
like
top
level
await
it
kind
of
makes
this
less
like
painful
to
use.
I
don't
know
if
you
you
think
we
want
to
table
this
one
or
if
we,
if
we
still
want
to
keep,
keep
it
on
the
agenda
going
forward,
or
I.
C
I
think
it's
yeah,
it's
probably
good-
to
keep
the
issue
there
just
to
collect
feedback,
but
we
can
take
it
off
the
agenda.
Yeah.
A
I
will
do
that
right
now:
okay,
yeah,
definitely
good
to
have
have
a
place
to
discuss
if
anything
else
comes
up,
all
right,
next
fs
hooks,
and
so
there
was
something
you
may
have
missed
unless
you
have
been
very
quick
on
your
notifications,
vladimir
popped
into
the
issue,
and-
and
this
is
issue
63
and
I'll-
just
put
it
in
the
chat-
just
put
it
in
the
chat
but
down
there
at
the
bottom.
So
he's
been
sidetracked
with
some
stuff.
A
He
says
he
has
a
prototype,
but
he's
not
happy
with
the
api.
A
He
kind
of
explains
a
little
bit
of
how
it
works,
but
he's
not
to
the
stage
of
the
make
fs
lie
yet
so
yeah
he
he
essentially
he
doesn't
have
anything
to
to
to
show
off
yet,
but
it's
it's
still,
you
know
it's
on
his
plate.
Does
anybody
have
anything
else?
They
want
to
bring
up.
E
There's
a
there's
a
a
number
of
similar
efforts
going
on
at
the
same
time,
or
at
least
one
other
one
which
is
diagnostic
channel.
So
that's
steven,
I
think,
yeah,
that's
kind
of
your
thing.
Maybe
you
want
to
say
something
about
that.
F
I'm
currently
responsible
for
the
diagnostics
channel
thing,
which
has
kind
of
been
sitting
for
a
while,
but
it
overlaps
quite
a
bit.
The
idea
is
basically
just
to
have
a
way
to
intercept,
calls
to
just
and
any
anything
interesting
like
io
related
things
or
things
like
that
and
be
able
to
capture
like
inputs
and
have
some
information
about
like
what
the
call
is
just
for
diagnostics
purposes,
so
get
apms
use
all
this
kind
of
stuff,
and
currently
we
monkey
patch
everything.
F
A
A
Okay,
bradley
has
his
hand
up
his
virtual
hand,.
G
So
I
do
a
lot
with
the
es
module
loader
stuff.
We
are
currently
in
the
very
slow
going
process
of
adding
features
until
we
can
move
loaders
off
thread
that
would
at
least
be
part
of
the
discussion
here.
Part
of
the
file
system.
Interception
hooks
is
about
the
ability
to
instrument
common
js
and
this.
G
A
Thank
you,
okay,
so
yeah
so
he's
this
is
180..
Let
me
throw
that
into
here.
A
Okay,
all
right
so.
E
Okay,
there
is,
there
is
one
more
thing
to
point
out
with
with
that
as
well.
Is
that
there's
also
the
efforts
currently
going
forward
to
add
policies
which
being
a
thing
that's
sort
of
in
the
chain
sort
of
blocking
the
path
to
whatever
action
was
happening?
Much
like
a
diagnostics
channel
or
any
other
kind
of
hooks
would
be
it's
worth
taking
that
into
account
as
well.
I
think
just
whatever
happens
here.
E
We
probably
want
to
make
sure
that
it
is
not
too
impactful
on
performance
just
with
so
many
other
things
going
on.
At
the
same
time,.
F
G
G
New
to
this
arena,
but
are
people
wanting
these
to
stay
in
the
same
user
context
for
code
execution
for
all
these
hooks.
G
A
G
B
Yeah,
I
don't
think
I've
been
really
like.
I'm
one
of
the
original
culprits
of
doing
a
lot
of
monkey
patching
with
nyc
and
a
lot
of
the
istanbul
stuff
and
I've
been
kind
of.
I
haven't,
really
had
a
course
in
this
race
to
be
perfectly
honest,
because
I've
been
building
more
things
into
node,
which
I
think
has
been
working
well
like
like.
I
like.
B
The
coverage
is
now
done
as
part
of
a
node,
and
I
kind
of
it
was
a
pain
in
the
butt,
but
it
means
that
it's,
like
I
kind
of
know,
it's
going
to
work
and
it's
not
using
just
some
random
side
channel
monkey
patch,
which
is
nice.
So
I
don't
know.
I
don't
have
strong
opinions
about
about
what
the
needs
are
of
this
api,
but
I
have
been
finding
that
putting
work
into
having
actual
documented
approaches
for
doing
it
has
been
working.
Well.
So
that's
what
I
would
add.
B
G
F
My
experience
as
an
avm
vendor
is
that
apm
vendors
step
on
each
other
all
the
time
and
so
having
like
an
actual,
consistent
defined
interface.
That's
like
this
is
how
you
hook
into
stuff
safely
would
be
huge
benefits.
I
think
apms,
like
we
only
monks,
patch
things,
because
that's
the
only
option
we
have
if
we
had
an
easier
like
standard
way
of
doing
it.
We
would
just
use
that
right.
A
I
was
just
gonna
say
I
I
think
it's
worth
the
you
know
everybody
who's
got
a
who
does
have
a
horse
in
this
race
should
probably
like
spin
up
a
team
and
get
together
on
it
and
just
kind
of
because
yes,
there's
a
lot
of
cross-cutting
stuff.
There's
a
lot
of
different
things
happening
at
once
and
and
bradley's
right.
We,
you
know
it
would
behoove
node
to
try
to
have
a
have
a
strategy
instead
of
not.
B
B
A
And-
and
I
think
there
are
potentially
competing
needs,
essentially,
you
know
somebody
like,
like,
I
suppose,
myself
who's
working
in
the
testing
space.
A
We
we
want
to
be
able
to
mock
things
out
in
and
and
like
turn
things
off
and
tinker
with
stuff,
but
somebody
who's
in
in
security
may
might
want
to
stop
me
from
doing
that.
You
know
so
there
needs
to
be
hopefully
some
way
to
to
make
everybody
happy.
I
don't
know.
G
A
Yeah,
so
that
that
action
item
would
would
probably
just
would
be
for
those
those
interested
parties
to
get
together
and
and
reach
out
and
and
whatnot
and
try
to
start
discussions.
And
you
know
I
don't
know
if
I
don't
know
so,
there's
the
apms
there's.
A
You
know
there's
security
and
I
mean
maybe
it's
worth
you
know,
ben
or
I
or
somebody
with
with
interest
in
testing
and
and
that
sort
of
thing
to
come
in
and
say
well
just
to
make
sure
that
you
know
we
can
do
the
things
that
that
we
need
to
do
as
well,
but
maybe
that's
even
it
yeah,
but
it
yeah
it's
a
little
different.
So
it's
not
anyway
out
ben
or
I
maybe
ben.
A
I
don't
know
if
you
have
the
cycles,
but
if,
if
you
all
meet,
I
think
I
should
probably
join
up
and
and
just
kind
of
make
sure
that
we're
that
we're
not
stepping
on
on
on
the
needs
of
of
of
testing.
B
Yeah,
like
I
was
gonna,
say
I
was
trying
to
type
in
the
doc,
but
my
internet's
kind
of
been
janky,
but
I
was
gonna
say
like
won't.
We
get
folks
from
like.
Obviously
it
sounds
like
modules,
security
testing
and
the
other
one.
I
guess
is
the
folks
who
are
actually
interested
in
the
file
hooks
api
that
we're
talking
about,
let's
kind
of
get
someone
representing
those
needs
yeah,
maybe.
A
Certainly
has
an
interest,
I
don't
know
rory
if,
if,
if
npm
does
maybe
with
the
tink
stuff
or
what
but.
C
No
sorry,
I'm
just
kind
of
busy
here,
but
no
you're,
not
not
that.
I
know
off.
I
think
we're
just
kind
of
following
up
with
everything
that's
going
on,
but
I'm
not
really
aware
of
anything
stuff.
Yeah.
D
B
B
A
G
I
think
we
can
just
make
a
note
that
we
need
to
have
that
meeting.
I'm
sure
the
modules
working
group
has
its
hands
and
way
too
many
things
already.
I
think
discussions
would
likely
just
be
done
outside
of
that
meeting.
G
The
module
loader
already
has
a
large
number
of
constraints,
so
it
can't
really
be
as
flexible
as
other
things
might
be
able
to
be.
A
Okay,
so
as
long
as
you're
here
and
I'm
asking
about
this
so
ben-
and
I
wanted
to
talk
to
the
modules
group
about
something
we
brought
up
it's,
it
was
brought
up
quite
a
while
ago
about
like
access
to
the
cache
or
or
being
able
to
dump
dump
things
out
of
the
module
cache.
And
yes,
we
know
that's,
not
spec
compliant,
but
it's
also.
Cash
is
fine.
A
G
Bill
taylor's
posts
guilty
or
sorry
well,
this
is
on
the
agenda
later
can
are
we
going
in
order?
Are
we
skipping
around?
Is
that
on
this
agenda?.
A
It
is,
it
is
okay
yeah
we
will.
I
was
essentially
just
piggybacking
on.
You
know
the
module.
If
the
module
meeting
is
a
good
place
to
bring
that
up,
but
we
can,
we
can
follow
up
afterwards.
C
A
B
B
B
A
All
right,
okay,
so
nothing
else
there
sweet
all
right!
Next,
then,
is
this
chmod
r.
B
Star
rc,
on
the
call.
No,
I
think
this
is
interesting.
I'd
be
willing
to
like
help
darcy
get
his
sea
legs
and
the
note
if
he
wants
help
getting
c
legs
in
node.js
the.
I
think
isaac
brought
some
things
up
on
the
thread
a
few
weeks
ago,
which
was
basically
there's
some
real
security.
Like
there's
security
concerns
about
privilege,
escalation,
I
think,
was
the
issue
with
chmod.
B
I
didn't
fully
grok
them
yet,
but
I
don't
know
it
sounds
like
the
similar
to
rimraf,
where
there's
where
it's
actually
a
more
complicated
problem
than
it
looks
at
first
for
splash.
I
think
so.
Someone
needs
to
dig
in
and
someone
needs
to
own
and
dig
into
the
user
land
implementation
of
chmod-r
and
see
what
all
of
the
caveats
are,
and
specifically,
I
would
say,
with
an
eye
for
what
isaac's
point
about,
I
think
security
issues
with
it.
B
A
Okay,
are
there
any
action
items
here
I
mean
I
know.
Is
it
just
you
to
talk
to
darcy
or
something.
B
A
Okay,
okay,
to
move
on
all
right,
so
the
next
one
is
the
module
reloading,
the
module
graph
and
all
that
stuff.
So
it
it.
A
A
We
had
our
requirements
together
and
we
want
to
take
those
requirements
and
basically
go
to
the
modules
working
group
and
say
so.
This
is
what
we
think
like
these.
You
know
these
are
the
problems
that
we're
trying
to
solve,
and
so
how
can
we?
How
can
we
solve
them
right?
I
don't.
I
don't
know
anything
about
the
the
modules
implementation
at
all
and
so.
G
A
lot
of
the
stuff,
if
you
come
with
like
a
solution
already,
it's
probably
gonna
just
not
go
through
right.
It
just
gotta
come
with
the
use
cases.
One
thing
I
would
take
a
look
at
there
is
a
blog
post
by
gil
tayer.
I'm
gonna
put
it
in
the
notes.
G
I'm
gonna
put
it
in
the
chat
where
he's
done
mocking
with
loaders
and
he
does
do
reloading
in
the
same
thing
it
goes
and
explains
we
are
currently
going
to
be
working
towards
making
that
a
less
terrible
user
experience
for
somebody
writing.
Loaders,
however,
actually
doing
a
delete
in
the
module.
Cache
is.
G
Unlikely
even
v8's
internal
implementation
of
modules.
You
can't
actually
delete
a
module
until
a
global
is
gone.
They
just
it
is
not
encouraged
for
you
to
ever
try
to
delete
a
module
source
text.
B
G
Stuff,
like
that
does
occur,
guilter's
post
goes
into
great
detail
about
this.
The
particular
problem
that
we
still
have
is
there
is
not
a
good
communications
channel
between
generated
code,
which
is
a
string
and
the
loader
so
actually
sharing
references.
His
solution
for
now
is
to
use
a
global
and
we
are
trying
to
fix
that
problem.
G
A
And
so,
if
you
go
right
now,
and
just
just
just
just
for
my
understanding,
if
I
go
and
I'm
using
cjs
and
I
s
and
I
require
a
module
and
then
I
go
and
I
delete
it
from
the
cache
to
require
cache,
I
mean
that
works.
The
way
you'd
think
it
would
right.
First
for.
B
A
G
In
particular,
you
cannot
have
a
pending
module
in
cjs
because
it
is
a
blocking
operation
to
load
them
untrue.
For
yes,
modules
so
say
we
have
two
parallel
graphs:
a
and
b
and
they're
both
trying
to
load
the
module
through
and
one
deletes
foo.
The
other
can
have
a
reference
to
the
stale
module
job
to
load
foo,
but
in
general
that's
not
what
you
actually
want.
You
actually
want
to
load
a
new
job
after
foo
is
deleted.
G
G
G
A
G
I
would
say
it's
not
a
leak,
it
is
just
how
it
works.
It
is
by
design.
B
Okay,
I
think
some
of
these
are
some
of
the
to
me,
like
some
of
these
leaks
are
like
in
defense
of
what
bradley's
suggesting
like
like
it's.
It's
only
a
memory
leak
if
you're
adding
the
same
module,
10
000
times
but
like
if,
if
your
goal
is
to
just
replace
the
behavior
of
the
module
like
yeah,
you
have
two
copies
of
it,
but
you
know
it's
not
like
that's
growing
necessary
like
if
it
depends
on
your
implementation,.
G
A
G
D
A
Agree:
okay,
do
we
need
to
talk
any
more
about
this?
One.
A
All
right
next
is
support
for
hooking
and
spawn
and
spawn
sync
without
patching.
Does
anybody
have
anything
on
this?
One.
A
I
I
thought
this
was
the
no.
This
is
the
thing
where,
where
he
needed
to
fiddle
with
the
environment
right
cory,
you're
here
so
yes,.
H
I
am
yes,
the
original
purpose
is
to
basically
hook
the
whenever
child
process
spawns
a
new
process
for
the
sake
of
nyc.
The
way
that
I'm
using
it
is
that
I
manipulate
the
node
options,
object
to
inject
or
require
that
brings
in
the.
H
I'd
be
interested
to
see
what
comes
about
of
the
fs
hooks,
because
I'm
thinking
that
I'd
be
interested
in
seeing
the
api.
For
that.
The
current
setup
that
I
have
somewhat
emulates
an
event
emitter
in
user
space.
But
I'm
not
sure
that's
best,
because
really
I
don't
want
other
code
to
be
able
to
remove
the
hook.
H
And
the
bigger
deal
with
that
is,
I
don't
want
other
code
to
basically
remove
all
hooks
like
it
would
be
unlikely.
They
would
directly
remove
the
nyc
hook,
but
they
could
easily
remove
all
so
I'd
like
to
see
what
comes
up
of
the
fs
hooks
outside
the
eventimate
or
another
kind
of
style
I
was
thinking
of,
is,
I
think
it's
async
hooks
has
more
of
essentially,
you
call
an
api
and
red
just
register
your
hooks,
and
there
really
isn't
a
way
to
remove
that
hook
without
a
reference
to
it.
A
H
A
Where
are
we
now?
Oh,
am
I
yes,
okay,
a
better
way
to
detect
a
process
is
exiting.
I
I
feel
like
th.
This
was
on
me
to
do
something
and
I
didn't
again.
B
D
B
To
the
call,
the
basic
thing
is
that
if
you
want
to
actually
like,
if
you're
say,
you're
mocha-
and
you
want
to
write
one
file
when
moca
is
done,
writing
it's
running
its
test.
Suite
you're
end
up
end
up
in
this
world,
where
you
need
to
hook
into
process.exit,
but
also
any
of
the
terminal
spawns
that
you're.
Sorry,
any
of
the
terminal
signals
that
one
would
need
to
hook
into
because
those
aren't
going
to
emit
on
the
exit
event.
So
having
an
event
that
fires
uncatchable
exit
events
would
be
good
for
tooling.
A
Okay
yeah
anyway,
my
thing
we
can
move
on
unless
anybody
else
has
anything
they
want
to
say
about
that.
No
okay,
next
is
source
map.
He
looks
like
last
time
had
a
a
pull
request.
B
Yeah,
so
so,
first
source
maps
in
stack
traces
now
have
feature
parity
with
normal
stack
traces.
So
so
they
used
to
not
rewrite
the
they
used
to
not
rewrite
the
kind
of
snippet
of
code.
You
see
at
the
end
of
the
at
the
top
of
the
stack
trace.
It
would
be
like
snippet
of
code
of
where
your
error
happened,
then
stack
trace
and
that
snippet
of
code.
We
talked
about
how
it's
done
in
node
errors.cc,
and
it
was
a
little
kind
of
hard
to
monkey
patch.
B
I
have
I,
I
got
a
pr
landed
the
other
week
that
actually
applies
the
source
map
to
that
snippet
of
code.
So
you
end
up
with
the
original
source
in
that
snippet
of
code
and
then
the
stack
trace,
which
includes
the
original
source
plus
the
transpiled
source,
so
yeah.
So
it's
looking
pretty
good.
It
works.
Well,
that's
one
of
like
the
kind
of
the
long
hanging.
That's
one
of
the
known
things
that
I
I
hadn't
implemented
with
source
maps,
yet
that
I
was
excited
to
to
get
done.
A
Oh,
I
didn't
know
you
sent
it
and
you
got
merged
before
I
could
tear
it
apart.
So,
oh,
you
didn't
like.
F
D
B
A
Right,
okay
and
so
okay,
yeah,
that
no,
that
I
think
you're
right,
that's
the
one
I
needed
to
jump
in
on
and
that's
not.
B
I
continue
to
be
iffy
about
that
one
just
because
I
think
it
would
create.
I
think
people
would
shoot
themselves
on
the
foot
with
it
because,
because
of
the
mod,
because
of
the
fact
that
we
can't
clear
the
cache
the
module
cache
like
you
end
up
in
this
world,
where,
depending
on
where
you
turn
the
flag
on
you,
start
collecting
source
maps
only
after
you've
set
the
flag.
Like
I
don't
know,
we
can
make
the
pr.
B
I'm
kind
of
like
I
would,
I
feel,
like
I
wonder
if
it's
if
it's
like,
because
to
be
fair
right,
like
you,
only
have
to
spawn
with
the
flag
at
the
very
top
level
of
the
instrumenter.
It's
not
like
all
of
your
tests
have
to
be
like.
Mocha
can
then
run
all
of
its
tests,
not
in
sub
processes,
because
it's
on
now
you're
fine.
So
it's
it's
like
that
extra
200
milliseconds.
B
A
I
mean
if
we're
looking
at
mocha,
I
mean
mocha.
If
you
give
it
node
flags,
it
will
spawn
a
sub
process,
but
I
think
I
think
I
was
more
and
and
so
this
behavior
like
that's
not,
I
mean
that's,
not
really
an
issue
right.
Mocha
could
add
an
option
that
or
just
like
just
start
making
child
processes
by
default.
I
don't
know,
but
my
concern
was
like
okay.
Well,
other
tools,
you
know
you're.
A
This
is
if
they
want
to
use
this,
it's
going
to
demand
that
they
use
a
sub
process
too,
and
it's
just
like.
I
don't
know
it's
it's
future.
Future
tools
I
feel
like
shouldn't
have
to
need
to
do
that.
But
again
I
don't
know.
If
you
want
to
talk
more
about
it,
we
can.
We
can
talk,
you
know
offline
or
whatever.
B
Yeah
it
just
comes
in
this
like
valley
of
like
are
we
opening
ourselves
up
to
like?
Is
it
worth?
Is
the
benefit
to
tooling
developers
worth
the
bugs
we
potentially
get
open
for
the
next
few
years
of
people,
not
understanding
the
behavior
like
it's
such
a?
It
is
a
power
feature,
so
probably
it's
mostly
tooling
authors
setting
the
flag
anyways.
So
maybe
maybe
it's
not
going
to
create
a
burden
of
support.
A
B
One
last
thing
on
this
point
unrelated
I'm
thinking
of
removing
the
experimental
flag
from
source
maps
because
they've
been
in
the
wild
for
quite
a
few
months
and
a
few
node
versions.
We
don't
have
any
open
bugs.
I
was
I
was
just
going
to
open
a
pr
that
calls
specifically
the
stack
trace
is
not
experimental.
B
A
B
It's
definitely
getting
used
like
because
when
we,
when
we
turned
it
on
when
we
broke
express,
we
immediately
had
a
bunch
of
issues
open,
so
it
was
being
used
immediately
and
then,
like.
I
use
it
across
a
few
hundred
repositories
and
we've
had
it
turned
on
for
let's
say
six
months.
B
A
B
A
Okay,
well,
please
let
us
know
if
and
when
you
open
such
a
pr.
A
Just
like
cc,
node,
tooling
or
whatever
that's
good,
oh,
and
then
that
reminds
me
if
anybody
here
is
not
on
the
node,
tooling
team
and
wants
to
be,
and
you
will
get
more
github
notifications.
If
you
are
please
let
me
know
and
I'll
try
to
do
something
about
that.
Okay,
the
next
one,
then
is
argument
parsing.
I
I
don't
think
there's
anything
here.
A
That's
happened.
I
haven't
done
anything
with
that
ben.
Have
you
done
anything
with
it?
Roy,
no
okay!
I
think
I
think
I
can't
remember
what
we
needed
to
do.
Let
me
see
okay,
I
I
feel
like
we
need
to
just
like
probably
meet
again
right
and
and
kind
of
regroup
and
say:
okay,
where
are
we
with
this?
Is
it?
Is
it
just
time
to
send
a
pr
or
what
or
or
what
do
you
think,
yeah
or.
A
Okay,
I
mean.
C
A
Right,
I
might
have
some
cycles
opening
up
soon.
I'm
I'm
getting
close
to
the
end
of
the
thing
that
I'm
trying
to
do
in
mocha
and
so
yeah.
That's
just
been
taking
up
my
time,
but
let's
just
I
don't
know,
let's
just
follow
up
with
each
other
offline.
A
Okay,
so
roy
you
want
to
talk
about
your
npm
thing.
C
Yeah,
let
me
demo
this
real
quick,
because
we
have
the
we
have
an
rc
open
for
this.
I
have
even
a
plc
branch
sitting
there
on
npm,
but
it's
probably
broken.
I
was
just
reviving
it
right
now,
but
yeah
basically.
D
C
Having
a
kind
of
a
diff
tool
built
in
to
do
to
the
npm
cli,
so
kind.
C
Okay,
okay,
so
yeah,
but
basically
I'm
like
a
compulsive
git,
diff
user.
So,
like
I
find
myself
like
get
this
all
the
time,
and
I
would
love
to
have
a
way
to
kind
of
like
have
the
same
thing
but
against
like
packages
that
are
published
to
the
registry.
So
I'll
bring
this
over
to
you
guys,
because
I
know
it
might
be
relevant
for
tooling,
but
like
most
specially
like
package
authors,
gonna
be
quite
nice
but
yeah,
but
even
for
users
like
a
lot
of
times.
C
We
have
like
you,
know,
you're
running
npm,
outdated,
and
maybe
you
just
kind
of
want
to
know
what's
going
on
in
there
right.
So,
basically,
like
you
can
npm
div
and
I
can
say
like
yards,
so
you
can
point
to
one
package
and
have
like
a
diff
between
what
you
have
locally
and
what's
what
is
wanted
for
for
for
npm
updated
here
right.
But
I
see
it
being
useful
for
also
like
security
folks
like
when
doing
npm
audit
right.
C
C
Of
course,
it's
going
to
be
like
kind
of
brutal
in
frameworks
and
larger
stuff,
but
I
also
had
this
idea
of
like
maybe
for
something
larger,
we
kind
of
add
a
changelog
flag,
so
you
could
like
okay,
let
me
see
what
is
the
difference
between
two
versions
of
npm
with
like
they're
huge
right,
so
it's
only
going
to
filter
out
for
for
the
changelog
file,
so
you
can
get
that
right
away.
It
can
also
be
kind
of
convenient
for
for
updating
stuff,
but
also
for
package
authors.
C
So
right
now,
like
I'm
sitting
on
some
changes
here
on
my
on
my
repo
right.
So
this
this
ipt
is
a
small
package
that
is
published
to
npm.
So
I
could
also
like
npn
diff
and
just
get
like
the
difference
between
the
current
version
and
what
is
on
npm
and
the
nice
thing
is
like
it's
only
going
to
take
into
account
like
files
that
are
tracked
by
by
the
package
right.
C
So
you
can
see
like
my
test
file
that
has
changes
here
and
show
up
on
git
diff,
it's
not
showing
up
on
npm
div,
so
yeah
yeah.
We
already
had
some
feedback.
We
presented
this
in
the
open,
rc
call.
So,
like
would
be
nice.
People
want
to
be
like
have
more
options
from
from
get
div
like
maybe
bringing
over
some
options,
like
name
only.
So
people
can
do
more
coding
around
that,
but
yeah
it
would
be
nice
if
anyone
has
ideas
or
feelings
about
it.
C
A
C
A
It
makes
me
think:
well,
okay,
if
you
can
do
that
change
like
thing
I
mean,
is
it?
How
do
are
you
just
looking
for
a
file
called
changelog
or
history
or
what.
C
A
Awesome
anybody
have
anything
they
want
to
ask
or
say
about
npmdf.
B
H
Roy,
I
just
wanted
to
ask:
are
you
going
to
be
looking
at
any
kind
of
pager
like,
for
example,
to
be
able
to
wire
that,
through
less.
C
Yeah
yeah
yeah
yeah-
I
don't
know,
I
don't
know
if
yeah
hook,
that
up
through
config
or
something
but
right
now
we're
just
my
idea
with
the
plc
was
just
try
to
make
the
output
as
closer
as
possible
to
to
get
diff
output
so
that
people
can
like
hook
in
the
same
tool
they're
already
using
right.
A
That's
new
feedback
like
that
the
pager
environment
variable
respect
that
or
something
might
be
cool
anyway.
Sweet
ben
wanted
to
talk
about
his
interns.
B
Yeah,
well,
I
want
to
talk
about
the
project
which
is
flaky
tests
if
anyone's
contributing
to
node.js
there's
some
flaky
tests,
like
I
think,
they're
a
little
better
than
they
used
to
be,
but
there's
still,
I
notice
it
pretty
often
we're
doing
a
project
where
we
want
to
kind
of
collect
a
bunch
of
data
on
flaky,
test
behavior
and
see
if
we
can
get
good
about
kind
of
algorithmically
predict
predicting
which
tests
are
flaky
based
on
historical
data.
B
Why
this
is
tooling
adjacent
is,
is
I'd
like
it
to
work
for
pretty
much
any
test
framework
and,
like
the
main
need,
I
think,
is
that
we'll
we
will
need
to
be
able
to
output,
something
human
readable
and
also
probably
a
like
dot
tap
output
file.
That's
just
some
machine,
readable
form
of
the
tests.
B
It
would
be
cool
to
be
able
to
do
that
for
mocha
and
some
other
stuff,
so
not
directly.
I
guess
node
tooling
related,
but
kind
of
a
fun
tooling
thing
I'm
working
on
and
if
you
have
any
opinions
about
flaky
tests
or
flaky
tests
like
how
to
identify
them,
is
it
a
problem
you've
run
into
just?
Let
me
know
something:
I'm
gonna
be
working
on
over
throughout
the
summer.
A
Okay,
flaky
tests
all
right,
yeah,
I'm
definitely
interested
in
that.
Okay
we
have
like.
Does
anybody
want
to
talk
about
the
flaky
test
thing.
E
Well,
the
only
thing
I
would
say
is
I
find
they
always
fit
into
like
a
certain
number
of
different
patterns
that
almost
always
have
something
to
do
with
timing.
So
be
pretty
interesting,
if,
like
statistics
on
how
these
things
come
about,
like
specifically
like
how
how
the
root
causes
are
all
related
or
perhaps
in
some
cases
not
related
that
they'd
be
some
pretty
interesting
data
right.
B
I'm
curious
because
the
the
like
one
internet,
I'm
working
with,
comes
from
like
a
machine
learning
background,
so
it
seemed
like
let's
experiment
and
throw
this
into
a
model
and
see
what
comes
out
the
other
end.
So
I
don't
know
if
that
will
actually
be
the
best
approach,
but
I
think
it's
like
interesting
to
see
what
happens.
A
A
All
right
well,
so
we
got
like.
I
don't
know
three
minutes
or
something
but
two
minutes
so
I
just
wanted
to.
A
I
don't
I
mean
I
don't
think
we
need
to
set
this
up
for
next
next
meeting,
but
I
would
like
to
do
another
deep
dive
meeting
at
some
point
here
on
something
I
think
that
was.
I
can't
remember
what
we
did
on
that
one
time,
but
it
was
helpful,
and
so
we
would
dedicate
a
meeting
to
a
particular
like
one
thing
essentially
and
just
yeah
do
a
deep
dive,
and
so,
if
there's
something
you
think
that
would
be
beneficial.
A
I
I
think
what
I'll
just
do
is
I'll
open
an
issue
on
the
repo
and
if
you
have
an
idea
for
something
that
you
you
think
like
many
of
us
should,
should
come
and
and
put
our
heads
together
on.
Let's,
let's
do
it
but
yeah
I'll
be
I'll,
be
making
an
issue
and
then
just
comment
there.
I
suppose,
because
we
don't
really
have
enough
time
to
kick
around
what
that
thing
should
be
at.
I
don't
think
so.
A
All
right
all
right!
Well,
I
think
that's
about
it,
so
everybody
please
have
a
a
good
weekend.
Don't
don't
work
too
hard
stay
safe,
have
a.