►
From YouTube: Node.js Tooling Group Meeting
Description
A
There's
a
big
there's,
a
loading
bar
okay.
This
looks
good.
Okay,
we
are
live
on
YouTube.
This
is
meeting
of
the
nodejs,
a
big
original
learning
bar
okay.
This
looks
good.
Okay,
we
are
live
there.
We
go
real
live
on
YouTube.
This
is
a
meeting
of
the
node.js
tooling
group
join
with
me
is
Roy
Chris
at
Christopher
Cory
MSO.
Hailed,
who
is
that
on
that
line?
I
don't
know
if
I
know
your
first
name.
C
So
yeah
last
last
time,
I
was
you
know
at
that
conference
and
basically
did
like
I
had
no
marbles,
and
everything
was
messed
up
in
the
hotel
room
and
all
this
stuff.
So
anyway,
two
weeks
ago,
I
released
the
tool
I've
been
working
on
for
the
past
I,
don't
know
five
months
or
so,
which
is
a
mostly
command-line
tool
to
work
with
diagnostic
reports
and
node,
and
so
diagnostic
reports
is
an
experimental
feature.
It
was
a
tad
pretty
recently,
but
what
it
does
is,
is
it
you?
C
It
causes
node
to
dump
a
large
JSON
file
full
of
information
which
is
useful
for
debugging
and
figuring
out.
What's
going
on
with
the
process
anyway,
I've
been
working
on
this
tool
that
ingests
this
JSON
report
and
then
outputs
other
information.
So,
for
example,
it
works
a
little
bit
like
yes,
lint,
where
there
are
heuristics
that
it
will
run
against
the
report
and
from
that
it
will
say
things
like.
C
Oh,
hey,
look
at
this
weird
thing
that
could
be
a
problem
and
it
kind
of
does
some
analysis
of
this
JSON
file
for
you,
in
addition
to
that,
it
will
redact
secrets
from
from
the
environment,
because
that
report
JSON
has
the
entire
environment,
and
you
don't
want
to
expose
your
your
API
keys
or
what-have-you.
So
it
will
redact
secrets,
it
will
convert
to
other
formats
and
you
can
actually,
you
can
kind
of
diff
to
reports
side
by
side
in
a
in
a
kind
of
purpose-built
way
which
eliminates
noise
and
nonsense.
C
I
Oh
there
is
the
lovely
site
that
I
built
with
IBM's
has
this
like
design
system
and
they
have
a
Gatsby
theme
and
so
I
learned
Gatsby
to
make
the
site
in
any
way.
But
that's
what
I've
been
working
on
almost
exclusively
for
the
past
like
five
months,
and
so
it
felt
good
get
something
out
there
and
it
is
a
tool
and
it
has
to
do
with
nodejs.
So
there
it
is
awesome.
C
A
C
A
little
bit
I
mean
it
can't
tell
you
what
line
of
code
is
leaking
right,
but
it
can
provide
information
about
memory,
usage
and
memory
usage
over
time
it
will.
The
diagnostic
report
can
be
triggered,
unlike
an
uncaught
exception,
and
so
it'll
help
you
figure
out
why
your
process
died.
It
will
report
on
a
fatal
which
could
be
an
out
of
memory,
and
you
may
get
more
information
there,
but
it's
still
a
kit.
I
can't
tell
you
where
your
leaking
memory
it
can.
It
can
only
tell
you,
like
the
straw
that
broke
the
camel's
back.
C
It
will
tell
you,
you
know
what
what
line
the
process
ran
out
of
memory
on
right,
so
yeah
and
and
so
there's
there's
heuristics
that
I
built
in
and
of
course
there,
because
it's
like
yes,
when
it's
like
customizable
configurable,
you
can
write
your
own
heuristics.
If
there's
something
weird
and
yeah,
that's
can
the
idea
cool.
C
I
mean
first
just
start
playing
with
diagnostic
reports.
It's
as
I
said
it's
new.
It's
experiencing
experimental
API,
but
yeah.
It's
it's.
It's
definitely
useful,
especially
if
you
like
have
a
process
in
production
that
you
can't
just
like
attach
a
debugger
to
you
can
you
can
trigger.
You
can
manually
trigger
a
report
just
by
sending
a
signal
to
the
process
so
yeah.
There
are
lots
of
different
use
cases
for
it,
but
yeah.
B
E
It
hasn't
been
merged
yeah,
but
we
are
aiming
to
release
it
next
week
next
week,
release
so
basically
the
maintainer
czar
going
to
be
able
to
add
a
funding
objet
pointing
to
you
URL,
and
it
can
be
like
a
patron
open,
collective,
whatever
they
want
bread
and
P
and
o'clock.
The
CLI
provide
way
for
consumers
to
lilius
other
info
visit,
one
of
them
and
basically
take
some
action.
A
C
A
A
D
E
A
D
A
C
C
I
mean
I
think
it's
we
could.
We
could
start
thinking
about
that
so
like
what
would
be
a
good
format
for
that
meeting,
you
know
I
expect
there'd
be
quite
probably
quite
a
few
people
in
it
and
lots
of
people
that
don't
usually
participate,
and
so
maybe
we
should
write
up
like
a
short
short
agenda
of
like
I,
don't
know
intro
to
tooling
group,
and
this
is
what
we
do,
and
this
is
how
you
can
get
involved
and
then
I
don't
know.
I
don't
know.
So,
let's
think
about
that
when.
A
Gonna
say,
like
I,
think
we've
actually
had
a
few
successes
now,
which
is
great
Brian
English
added
the
stat
on
listing
two
directories:
that's
a
great
win
for
tooling.
We
have
mcdr
recursive,
we
have
coverage,
we
have
rim,
ref
now
is
landed
and
we're
actually
starting
use
rim
ref
in
some
of
node
core
test
libraries
so
like
nodes
using
cream
ref,
which
is
great
well
they're
trying
to
but
the
windows
tests
aren't
working.
So
we
should
maybe
talk
about
that
today.
Actually.
A
Long
story
short
I
think
we
kind
of
need
to
open
with
maybe
talking
about
some
of
the
things
we
have
done
and
white
and
and
how
the
working
group
has
been
a
bit
of
a
success
so
far,
I
think
more
so
than
the
first
meeting,
because
I
think
the
first
meeting
we
had.
We
basically
had
only
done
maybe
one
of
these
action
items
and
we've
done
a
couple
more
since
then,
so
it's
kind
of
starting
to
show
how
they
working
group
is
creating
value.
A
That's
a
guide,
be
mean,
maybe
pull
the
room
and
see,
like
maybe
I
guess,
maybe
like.
We
also
represent
a
bunch
of
tools
for
the
community
like
NPM
NYC
mocha
I
can
maybe
give
some
background
about
like
tooling,
outside
of
node
core
and
our
interest
in
that,
and
then
the
relationship
between
that
and
node
core
I
think
there's
some
value
there
as
well.
I.
A
C
A
You
might
be
interesting
to
try
to
do
like
a
two
hour,
one
and
but
then
like
time
box
on
the
stuff,
so
like
still
allow
for
some
of
the
off,
like
I,
don't
wanna,
say
I'm
topic,
but
still
allow
for
some
of
the
heated
deep
conversations
where
we
argue
about
whether
rim
rafts
should
be
in
court,
but
maybe
time
blocks
them
to
like
30
minutes
or
something
so
that
we
can
also
have
a
few
more
structured
conversations.
So
just
realizing
things.
Yes,.
A
E
Of
that
yeah
and
I
think
one
more
thing
that
we
could
count
on
the
agenda
is
like
opening
for
four
new
participants
to
bring
new
ideas.
I
think
that's
was
something
really
cool
in
the
cooler
last
time
I've
been
in
one
of
these
I
think
it
was
the
first
meeting
from
the
room,
but
there
was
a
ton
of
new
ideas.
Think
that
sound
chill
ideas
so.
A
It
sounds
like
maybe
like,
let's
just
maybe
even
have
a
meeting
outside
of
this
one
and
actually
treat
this
a
little
bit
more,
like
a
talk
where
we
have
a
structure
like
let's
plan
the
structure
out
of
it
between
a
few
of
us
and
like
just
really
have
a
plan,
you
don't
have
to
figure
it
out
on
this
call,
but
let's
not
fly
by
the
seat
of
our
pants.
This
time,
yeah
good
good,
go
home
and.
C
A
E
A
A
Don't
I
think
a
lot
of
the
contention
around
this.
This
feature
idea
was
on
the
ability
to
detect
an
async,
exiting
and
I
think
would
be
a
huge
benefit
if
we
just
kind
of
tried
to
have
a
exit
event
that
always
fires
on
exit,
but
it
doesn't
work
in
a
sync
I
think
that
would
still
be
an
improvement.
Maybe
we
should
doesn't
seem
like
we
have
too
much
controversy
around
implementing
that.
D
A
D
A
That
I
like
that,
and
it
sounds
good
we
should
loop
I,
feel
like
Joey-
would
like
it
really
knows
that
either
Anna
or
Joey
really
know
this
part
of
the
system
well
and
could
probably
help
us
implement
it
in
like
30
minutes
if
they
were
bought
into
it,
because
Joey's
been
moving
around
all
the
exit
logic
around
test
coverage
in
to
see,
and
she
knows
that
area
really
well
so
I
feel
like.
We
basically
already
do
this
for
test
coverage.
D
So
is
there
actually
a
way
to
detect
if
an
event
exists,
or
would
we
have
to
do
version
based
detection
like
assuming
that
a
terminate
event
is
added
to
the
process
object?
How
do
we
feature
detect
that
would
we
just
have
to
check
the
nodejs
version
like
to
decide
if
we
have
to
fall
back
on
signal
exit.
A
A
How
do
you
think
that
would
Cory
I
guess
maybe
you're
one
of
the
main
stakeholders
of
this?
Do
you
think
that
having
consuming
you
could
detect
the
feature?
Do
you
think
that
having
this
terminate
that
would
fire
on
any
fatal
determination
of
execution
in
your
program
would
be
helpful
for
some
of
the
stuff
you
do
with
NYC.
D
Yes,
I
I
think
it
would
be.
It
would
be
better
for
us
to
essentially
hook
terminate
event
rather
than
like
signal
exit
hooks.
The
a
couple
of
signal
handlers,
in
addition
to
the
normal
process
exit
event
and
one
of
the
things
I'd
like
to
see,
is
basically
for
NYC
to
avoid
manipulating
the
like
the
state
of
the
application,
the
environment
and
I
think
that
hooking
signal
handlers
is
sad.
D
A
D
A
A
Look
enjoy
you
move
some
of
it
into
C++,
but
there's
yeah
exactly
right,
we're
we're.
Eight
coverage
should
happen
for
all
normal
and
fail
exit
cases
and
no
Jess,
and
we
have
unit
tests
around
it.
So,
there's
probably
you
could
look
at
exactly
where
the
coverage
gets
written
and
that
would
be
a
good
place
to
add
the
event
and
I
can
I
would
help
with
code
review
like
this
I
think
this
feature
it'd
be
great.
I'd,
happily
help
with
code
review
and
at
least
make
sure
Joey
reads
it
or
Anna.
A
So
if
sourcemap
v3
3v3
supported
node,
one
update
is
it
did
one
person
came
in
from
the
community
from
express
and
there's
a
common
plugin
and
express
that
was
overriding
like
undocumented
shim.
You
could
do
to
rewrite
stack
coverage,
so
there's
some
discussion
happening
around.
Should
we
still
run
that
shim
and
not
try
to
take
over
the
stack
trace,
even
if
you've
provided
an
able
source
of
maps.
True
so
that's
been,
one
topic.
A
A
A
So
I
there's.
I
basically
have
an
issue
open
that
has
a
bunch
of
deltas.
That
would
be
great
places
for
people
to
start
working
on
the
code
base.
So
if
anyone
has
any
mentors
that
would
like
that
they
are
working
with
or
would
like
to
get
some
contributions
and
to
node.js
themselves,
I
would
love
to
help
you
and
some
issues
related
to
source
maps.
I
know
Ian
said
he
was
a.
It
was
interested
he's
not
on
the
call
today,
but
I
think
just
an
open
call
for
help.
I'd
love
to
make
that
feature
more
polished.
A
That
includes
making
it
work
nicely
with
things
like
Express
and
old
plugins
and
the
most
fun
biggest
Delta
to
work
on,
probably,
is
that
it
doesn't
point
to
the
right
line
of
code
that
failed.
It
only
rewrites.
The
stack
trace
so
it'd
be
kind
of
neat.
If
you
could
actually
point
to
the
both
your
source
in
the
transpiled
source,
when
the
exception
throws
that
be
a
fun
thing
to
look
on
you're.
B
A
The
other
one
is
two
nine,
eight
six
five.
If
you
just
check
a
bunch
of
checkboxes
which
work
we
could
be
doing
around
source
map,
oh
and
I
think
I
snuck
in
one
thing
related
to
coverage
too.
That
was
driving
me
nuts,
so
it
ignore
the
coverage
you
want.
If
you
don't
feel
like
working
on
coverage,
I.
B
A
D
D
D
A
Really
torn
on
this
feature
like
like
we
use
in
all
of
our
Canonical's
example
of
samples
we
put
across
hundreds
of
libraries
on
the
client
libraries
team,
I
work
on
at
Google.
We
have
you
know
it
starts
with
processed
sliced,
blah
blah
blah,
and
it's
like
a
little
confusing
if
you're
newish
to
programming
you're
like
what
the
heck
is
happening
here.
Why
am
I
slicing
this
I
see
I,
see
the
value
of
Maine
rx
I'm,
also
like
super
on
the
fence
of
like
it's.
A
Such
a
simple
thing
is
just
doing
slice
for
you
like
I'd,
rather
have
something
like
minimis
EndNote,
I,
think,
which
we've
talked
a
ton
about,
so
it's
like
I
guess
if
I
can't
have
something
closer
to
minimis.
This
is
better
than
kick
in
the
head,
but
I'm
like
I,
don't
know
I'm
wondering
if
there's
like
some
middle
ground,
like
we
could
figure
out,
but
obviously
I
haven't
put
a
ton
of
thought
into
it.
Yet
and
I
apologize
yeah.
E
I'm
totally,
okay,
on
just
like
having
a
sitting
on
that
for
a
while,
like
you
can
get
her
more
feedback,
especially
maybe
after
the
summit.
That
can
be
like
one
big
topic
of
the
conversation
to
summit,
and
we
can
use
that
as
an
example
of
like
what
has
been
proposed.
Like
one
direction,
we
can
take
and
see
like
if
you
can
actually
get
some
real
consensus
on
the
way
moving
forward
and.
B
E
A
For
a
thing
like
it
felt
like
like,
if
you
were
at
our
last
conversation,
we
had
in
person
at
in
Berlin,
I
think
there
it
felt
like
we
would
never
land
rim
Raph,
because
it
was
so
controversial,
and
then
that
landed
in
like
three
days
like
what
oh
yeah
there's
like
a
couple
of
months
of
noodling
around
on
it,
and
then
someone
was
like
I'm
just
gonna.
Do
it
like
this
and
then
suddenly
they
had
four
approvals
and
they'd
landed.
A
D
Honestly,
I
think
that
that's
not
really
the
comparison
doesn't
really
line
up
because
rim
raft,
basically
it
does
X
and
X-
is
very
well
defined,
and
there
really
isn't
any
controversy
about
the
speck
of
X
in
the
case
of
command-line
parsing,
there's
quite
a
few
conflicting
opinions
on
what
exactly
that
should
accomplish
and
how
it
should
work
and
I'm
not
sure
how
that
can
really
be
yeah.
A
D
A
A
But
the
windows
tests
had
failed
for
no
DJ,
it's
Jess
itself
when
they
tried
to
move
some
of
the
code
to
rim
Rev,
so
I
think
we
should
investigate
this
and
maybe
maybe
adding
some
more
tests
to
rim
raft
or
something
we
should
have
on
our
minds
as
something
our
working
group
takes
on
or
tries
to
encourage,
because
it's
I
mean
one
of
the
reasons
I
was
really
excited
about.
The
rim.
Ref
part
was
that
it
would
make
test
cleaner
and
nodejs,
which
make
derby
cursive
certainly
did
so
for
not
able
to
use
it
ourselves.
A
Then
it
might
as
well
not
be
there.
So
we
should
fix
it.
Yeah,
it's
just
two
cents,
so
maybe
that's
another
thing
that
having
our
minds.
If
we
know
anyone
like
if
anyone's
doing
the
mentorship
program
still
or
knows
anyone
who's
looking
to
get
their
first
few
country
contributions
into
nodejs
ID,
a
good
unit
of
work
as
well.
A
Saying
we
should
look
guys
we
should.
Maybe
an
action
item
is
just
we
reach
out
to
rich
and
say:
have
you
opened
an
issue
for
this
like
which
tests
failed,
specifically
just
just
figure
it
out
as
exactly
the
sorts
of
issues
we
expect
to
fail,
which
is
like
I,
think
a
race
condition
in
Windows,
not
deleting
the
files
fast
enough,
so
Rim,
Ralph
kind
of
bails.
A
D
D
In
the
new
version
of
NYC
were
moving
away
from
spawn
wrap,
which
basically
created
a
shell
script,
that
injected
options
into
the
nodejs
process
and
basically
replaced
the
program.
You
are
running
the
new
versions,
kill
users
spawn
spawn
sync
refining,
but
at
this
point
all
it
does
is
manipulate
the
environment
prior
to
executing
a
new
process,
I'm
wondering
if
that's
something
that
could
potentially
get
into
nodejs.
D
Obviously
there's
kind
of
like
a
security
concern
there.
You
know,
because
some
arbitrary
library
would
basically
be
able
to
say
hey.
You
know
we're
adding
this
to
the
environment,
the
sub
process
and
well,
in
the
case
of
the
way
nodejs
works.
It's
actually
saying
you
know
this
module
should
automatically
be.
You
know,
preloaded
into
every
sub
process,
so
I
could
see
the
nodejs
core
having
security
concerns
there.
A
D
Well,
sticky,
environment
wouldn't
necessarily
do
the
trick
because
in
some
cases
like
with
NYC,
it
needs
to
set
the
note
underscore
options.
So
specifically,
it
needs
to
insert
you
know
the
dash
dash
requires
option.
So
simply
for
us
to
simply
say
this
is
the
sticky
note
options
wouldn't
work?
We
need
to
hook
a
function.
That
would
say
okay.
This
is
what
the
process
is
trying
to
spawn
with.
So
we
need
to
insert
this
into
note.
I.
A
D
E
D
One
of
the
things
that
like,
for
example,
with
NYC,
if
somebody
basically
runs
a
sub
process
where
they
say
you
know
environment,
is
this
one
variable
that
clears
out
all
other
variables.
I
see.
Okay,
I,
see
you're,
saying
this,
usually
or
also
in
the
case
where
something
like.
If
somebody's
testing
code
and
let's
say
they
just
set
node
options
well
from
their
coverage
from
that
sub
process,
just
doesn't
exist.
A
A
A
We've
have
a
sticky
environment
variable
which
is
just
node
V
8
coverage
environment
variable,
but
I
would
rather
that
we
were
using
some
sanctioned
API
for
doing
that,
because
then
it's
more
generic,
so
I'd
like
to
just
it
seems
elegant.
It
allows
us
to
get
rid
of
a
special
case.
We
have
for
one
of
our
features,
a
node
which
I
like
and
makes
it
something
that
the
community
can
actually
use.
So
I
mean
I,
don't
know
would
be
interesting.
It's
at
least
starting
worth
starting
a
conversation
with
some
security
minded.