►
From YouTube: Node.js Tooling Group Meeting
Description
A
Alright,
okay,
so
to
Lee
meeting
here
we
are
November
15th
2019
and
today
we
are
see
here.
Is
this
I'm
gonna
paste
this
in
the
chat?
The
link
to
the
minutes
document?
I
would
really
appreciate
it
if
somebody
would
take
minutes
if,
if
you're
not
gonna,
be
talking
because
it's
hard
to
take
minutes
and
talk
at
the
same
time
anyway,
so
it's
November
15th
and
today
we
are
not
going
to
talk
about
anything
except
the
open,
JSF
summit
agenda.
So
the
idea
is
so.
A
To
recap
the
the
thing
is:
we're
going
to
have
a
like
a
collaboration
session,
which
is
essentially
a
fancy
word
for
a
meeting
at
the
opening
of
JSF
collab
summit,
which
would
be
on
I
think
the
13th
and
14th
of
December
in
Montreal,
which
is
right
after
the
node
+,
je
s
interactive
conference.
So
we're
gonna
have
this
meeting
I,
don't
know
when
they're
still
hammering
out
the
schedule,
but
because
we
get
a
or
at
least
last
time
we
did
this.
A
We
got
quite
quite
a
few
people
who
don't
normally
participate,
have
had
interest
in
in
this
session.
So
I
expect
that
to
happen
again
and
we
should
tailor
our
you
know
our
agenda
accordingly.
I
did
reach
out
to
the
collab
summit.
Organizers
and
I
was
like
hey
what
about
a
longer
time
like
2
hours
or
more,
and
they
said
they
hadn't
figured
out
the
schedule
and
somebody
said
I
think
a
day
or
two
though
they're
working
on
it,
but
there
was
nothing
to
suggest
that
we
couldn't
do
something
like
that.
A
A
The
I
know
that
it's
been
requested
not
just
by
us
or
somebody
I
can't
remember
who,
but
but
people
want
to
be
able
to
either
you
know
Cory
that
brought
it
up,
but
like
record
the
meeting
or
you
have
video
conferencing
or
streaming
or
something
because
not
everybody
can
be
there
and
it
would
be
great
to
get
people
involved.
You
can't
be
there
so
I
mention
it.
I,
don't
know.
I
I,
don't
have
high
hopes,
but
yeah
that
would
be
nice,
wouldn't
it
so
yeah.
B
A
Also
in
their
Court,
so
we're
just
kind
of
waiting
to
hear
back
about
the
about
the
schedule,
but
I
think
it's
probably
okay
to
proceed
as
if
we're
going
to
have
a
longer
session
and
and
try
to
go
that
route,
we
can
always.
You
know,
pull
stuff
out,
I
suppose
if,
if
we
can't
have
a
longer
session
but
I
mean
I,
I,
guess
I
I,
don't
think
it's
gonna
be
a
big
issue.
So
that
said,
with
the
logistics
and
stuff.
What
should
we
talk
about
at
the
summit?
I.
A
A
And
I
thought
I
asked
him
if
he
had
any
suggestions.
You
know
I
can't
figure
out
where
he
said
that.
Where
did
he
say
that,
oh
here
it
is
three
days
sugars.
So,
let's
see
he
says,
okay,
here
we
go
I.
He
says
I'm
on
board
with
the
idea
the
float
around
about
having
first
quarter
the
session,
be
a
recap
of
what
we
did
and
then
the
ongoing
so
I
don't
know
what
we've
accomplished
and
then
it's
the
ongoing
agenda
items.
A
You
already
have
lined
up
our
parser
exit
signal
and
then
maybe
the
last
square,
the
session
on
board
new
ideas
from
intending
folks
just
kind
of
open
the
floor
and
say:
hey:
do
you
have
any
ideas
about
this
hi
I'm,
not
sure
who
Mel
is,
but
you
are
here.
I
will
push
this
button,
hello,
Mel,
anyhow
yeah.
So
what
do
we
think
of
Ruiz
idea
where
we
kind.
A
A
So
I
also
I
also
like
Rees
idea,
but
I
kind
of
think
we
should
maybe
do
it
in
a
different
order.
So
you
know
people
who
are
just
kind
of
coming
to
check
it
out
and
see
what
it's
all
about
might
have
something
in
mind
that
they
want
to
bring
up
and
and
might
not
be
super
interested
in
in
you
know,
kind
of
going
deep
into
a
topic.
They
don't
have
necessarily
any
interest
in
and
so
other
than
kind
of
this.
You
know
past
this
introduction
to
the
group.
This
is
what
we're
up.
A
C
Yeah
I,
don't
know
where
this
fits
in
the
agenda,
but
one
thing
I
think
would
be
interesting
to
keep
pushing
at
would
be
kind
of
what
our
relationship
is
with
the
tactical
steering
committee
and
kind
of
what
kind
of
continue
to
try
to
define
the
type
of
work
the
tooling
group
does
in
the
abstract.
Even
I,
don't
know
if
we
how
much
we
want
a
time
box
that,
but
maybe
that's
just
part
of
an
introduction
about
what
the
heck
the
tooling
group
is
I
feel
like.
C
C
C
Yeah,
we're
basically
like
I
mean
by
the
way
I
understand
like
there's
two
things
you
can
be.
It
can
be
a
working
group
and
we're
like
what
are
we
technically
Chris
I
thought
our
working
groups,
more
official
right,
yeah.
A
C
A
There's
just
so
many
like
so
any
like
any
given
feature
or
change.
Node
could
have
some
impact
on
what
we're
doing,
and
so
it's
not
always
straightforward
like
when
we
should
be
looped
in
because
there's
just
so
many
like
cross-cutting,
cross-cutting
issues
and
so
I,
don't
think.
There's
like
really
a
clear
I,
don't
know
subset
of
oh.
This
is
clearly
a
thule
issue.
I
mean.
Maybe
we
could
work
to
define
those
things
more
closely
like
if
it
has
something
to
do
with
I,
don't
know,
shebang,
parsing
or
something
to
do
with
with
I.
A
D
Yeah
I,
just
wanna
meant
I,
don't
only
understand,
you
know
the
nodejs
chartering,
but
if
I'm
understanding
correctly
to
be
chartered
we'd
effectively
own
parts
of
subsystems,
I
think
defining.
That
would
be
difficult
because,
just
looking
at
what
we've
done,
I
mean
we've
added:
stuffed
the
FS
module,
we're
looking
into
adding
stuff
to
process
and
child
process.
D
C
C
A
I
don't
know
I
feel
like
there's
like
there's
like
the
Charter.
That
says
this
is
what
the
group
the
working
group
is
responsible
for,
and
the
TSC
in
their
Charter
says
they're,
giving
this
thing
into
that
group.
If
the
TSC
wants
to
override
them,
they
have
to
go
back
and
change
their
own
charter.
You
know
name
it
something
like
that.
You
know.
So
it's
all
and.
C
C
Something
worth
oculi:
maybe
we
should
invite
someone
from
the
TSC
to
say
what
they'd
like
it
would
being
tried.
Maybe
we
can
get
someone
to
come
from,
closely-related
working
group
say
come
to
the
meeting
or
someone
from
the
TSC
come
to
the
meeting
and
I'm
sure
we'll
have
somebody
from
the
TLC
there
yeah,
and
this
may
be
make
sure
that
we
agree,
maybe
make
sure
there's
alignment
and
what
we
all
think
we're
trying
to
do.
C
I
think
we've
got
enough
like
rogue
stuff.
Now
that
were
that
people
are
like
deferring
to
us
on
some
stuff,
which
is
great
they're
like
oh,
you
should
talk
to
the
tooling
working
group
about.
Are
you
working
good?
You
should
talk
to
the
tooling
group
about
that
I
think
you've
said:
that's
come
up
a
few
times
in
threads
yeah.
A
A
Then
I
mean
yeah,
so
what
I
would
like
is
just
kind
of
let's
open
it
up.
Hey
who
wants
to
talk
about
what
you
know.
We
have
some
ideas
we
can
talk
about,
but
if
you
have
any
burning
questions
or
suggestions
or
something
that
you
want
to
get
out
in
front
of
people
and
let's,
let's
let's
talk
about
it,
let's
discuss
I,
don't
know
if
that's
I,
don't
know
how
productive
that's
gonna
be
because
you
know
last
time,
there's
like
20
people
or
25
people,
I
mean
it's
not
like.
A
You
can
yeah
any,
but
I.
B
C
Tech
folks
joined
the
meeting
like
there's
a
few
definitions
of
tooling,
like
some
people,
think
of
it
purely
as
like
babble
and
and
the
the
ability
to
you
know
transpile
and
shim
code.
That's
what
I
think
that's
a
lot
of
what
people
in
the
tc39
9
see
tooling
is,
and
we
see
it
more
like
we're
a
bunch
of
people
from
mocha
and
NYC
and
like
create
react
app
like
I,
think
we
see
tooling
slightly
different,
where
it's
I
don't
know
still
transformations
involved.
But
it's
a
difficult
thing
to
fully
define
I.
C
C
A
C
That's
closer
to
by
definition,
which
means
maybe
we're
like
explicitly
not
code
transportation
like
that's
something,
but
that's
something
that
concerns
language
makers
more
or
tc39
more
because
they
need
the
shim
stuff.
But
it's
not
so
much
a
command-line
thing
somewhere
of
a
language
feature
thing.
Yeah,.
A
You
know
that's
a
really
good
point
and
I
think
yeah
people
are
kind
of
maybe
confused
about
that
and
say
you
know
we
want
to
talk
about
talk
about
translation
and
stuff,
and
you
know
it's
it's
that's
like
language
language
stuff,
and
you
doesn't
really.
You
know
unless
node
starts
doing
that,
for
whatever
you
know
it
doesn't
it
doesn't
have
anything
to
do
with
node
yeah.
A
D
Not
I
somewhat
agree
with
hands
view
on
the
idea
that
this
is
about
development
tools.
One
thing
I'd
say
about
the
transformation:
I
think
that
the
actual
translation
is
out
of
scope
for
us,
but,
for
example,
one
of
the
things
that
I'm
planning
on
working
on
is
enabling
the
es
module
loader
to
basically
do
source
transformations.
D
C
That
seems
like
a
recent
listing,
like
I,
feel
like
well
we'll
to
facilitate
some
of
the
types
of
tooling
we're
trying
to
build.
Maybe
we
go
a
little
outside
of
you
know
the
scope
of
just
a
command-line
tool,
but
that's
our
bread
and
butter.
Maybe
one
second
I
was
gonna,
say
I
was
gonna,
say
something
similar
Cory.
D
D
C
A
A
Boy:
okay,
well
yeah,
let's
maybe
yeah.
Let's
talk
about
that
more!
Let's
talk
about
the
TSE
stuff
and
then
and
then
maybe
somebody
I
don't
know,
send
a
pull
request
to
the
readme
or
something
that
I
mean
hash
it
out
there
and
then
and
and
then
talk
about
it
at
the
next
meeting
about
like,
let's
clearly
define
this
or
scope
as
as
well
as
we
can
yeah
as.
C
C
A
C
No
I,
don't
think
I
think
we
need
to
have
like
I
think
we
should
plan
the
structure.
Add
a
little
bit
better
than
that.
Like
maybe
like
one
thing
we
could
do,
is
you
could
even
have
people
put
up
some
ideas
with
sticky
notes
and
then
pick
three
common
ones
or
something
like
I've?
Seen
that
approach
to
running
a
meeting
work
very
well
yeah
use
something
like
that
like
we
can
do
sticky
notes
and
say,
like
okay,
we
have
20
people
in
the
room.
We
all
want
to
talk
to
a
bunch
of
stuff.
C
C
You
what
I've
seen
work
really
well,
we
did
this
recently
for
actually
a
summit.
We
did
with
my
team
and
we
did
it
at
NPM
a
few
times.
You
have
people
write
down
some
stuff,
then
you
group
it
together
and
a
lot
of
time.
You'll
start
to
get
some
grouping
so,
like
you
know
it
will
turn
out.
Five
people
in
the
room
want
to
talk
about,
see,
lies
and,
and
three
people
want
to
talk
about.
C
I,
don't
know
new
file
system
functions
or
something,
and
then
we
can
do
a
little
bit
of
grouping
and
it
might
shake
out
that
it's
obvious,
like
a
ton
of
people,
want
to
talk
about
CLI,
stuff
or
a
ton
of
people
want
to
talk
about
adding
a
few
new
methods
to
the
FS
and
then
I
think
that
could
help
structure
the
meeting
a
little
more
than
just
a
free-for-all.
Conversation
I
think
would
be
worthwhile
like,
especially
if
we
have
like
to
our
like.
It
really
depends
on
the
length
of
the
meeting.
I.
Think
I.
C
C
We
should
really
have
a
goal
of
the
meeting
which
is
like
what
do
we
want
like
if
great,
if
we
get
20
people
in
there,
what's
the
what
what
action
items
do
we
want
people
to
take
away
and
like
even
having
a
couple
more
people
on
this
call
I
think
would
help
because
we've
actually
coordinated
work
on
this
call
before
and
and
gotten
some
pull
requests
and
to
note
through
conversations
in
this
meeting
so
I
think.
Maybe
our
action
item
is
just
you
join
the
call
and
help
us
start
to
build
some
of
this
stuff.
A
A
C
C
B
Speaking
of
that
actually
I
was
that
react
cough
a
couple
weeks
ago
and
I
had
a
couple
interesting
conversations
with
some
people.
There
I
talked
to
Jason
Laster
who's.
He
he
works
at
Mozilla,
I.
Think
he's
like
in
charge
of
the
Firefox
dev
tools,
so
he
was
really
interested.
Something
we've
had
on
the
agenda
for
a
while
is
that,
like
compiling
scale,
I
type
tools
to
like
a
self-contained
binary-
and
he
was
really
interested
in
that
for
the
build
process
for
Firefox
dev
tools.
B
I
guess
they
run
like
a
separate
instance
of
Babel
on
each
subdirectory
I'm,
not
sure
why,
but
the
like
boot
time,
for
that
is
actually
like
the
biggest
time
consuming
thing
in
their
build
process.
So
he
was
really
interested
in
that
and
then
I
actually
talked
to
who
works
at
site?
Who
were
some
XJS,
but
we
were.
B
We
were
actually
talking
about,
I
mean
they
built
lots
of
CLI
tools
and
we
were
talking
about
and
I've
been
trying
out
recently
their
tool
NCC
that
compiles
it
basically
like
compiles
the
dependencies
from
your
project
into
like
a
single
javascript
file.
So,
for
example,
like
you're
running
a
tool
with
MDX,
it'll,
download
and
boot
like
ten
times
faster,
doesn't
have
to
download
any
of
the
other
dependencies.
B
C
100%
agree
like
I
think:
that's.
This
topics
come
up
a
few
times
and
we've
had
the
conversation
with
Joey
about
how
it
would
technically
be
possible.
The
bundles
node
binaries
more
easily
with
CLI,
but
it
kind
of
you
know
it's
definitely
a
bigger
technical
challenge
than
some
of
the
things
we've
taken
on
I
think
which
has
mostly
been
API
additions,
but
I
mean
like
I,
think
that
should
be
in
the
scope
of
things
we
think
about,
like
how
amazing
would
it
be
if
you
could
ship
NYC
as
a
standalone?
B
And
actually
is
I
had
a
a
tool
like
that
of
PKG,
and
they
kind
of
moved
away
from
that
and
I'd
be
curious
to
know
why,
like,
for
example,
NCC
now
it
doesn't
it's
not
a
binary
that
bundles
node
with
it,
it
just
compiles
your
node
project
into
a
single
javascript
file,
but
I
actually
did
go
down
that
road.
At
one
point,
yeah
I'd
be
curious
to
know.
I.
C
Was
talking
to
I
was
talking
to
a
start-up
at
github
universe
yesterday,
who
writes
some
developer
tooling,
that
I
use
and
they
were
saying,
like
they're
rating,
that
I've
been
for
five
different
languages
because
they
support
you
know
node
Ruby,
like
five
other
languages
and
they're
actually
really
interested
right
now
and
finding
a
way
to
package
package.
A
binary
that
could
be
used
like
cross
language
like
Ruby,
would
use
a
node
would
use
it.
Python
would
use
it,
but
they
would
really
like
to
do
the
development
in
nodejs.
B
C
B
Mean
like
for
me,
like
I've,
started
using
NCC
recently,
and
it's
amazing,
like
it
speeds
up
your
your
CLI
tools
like
dramatically
so
I
mean
I,
think
even
just
that
is
kind
of
a
win
there.
If
we're
talking
about
writing
CLI
tools,
they
should
be
you
know
as
fast
and
responsive
as
possible.
In
my
opinion,
anyways.
You
know
it.
C
Makes
sense,
I,
don't
know,
I
think
I
think
that
that
could
it
could
be
an
interesting
goal
for
2020
that,
like
between
the
other
work
we
do.
Maybe
we
do
try
to
take
on
a
bigger
task,
like
start
to
think
about
the
bundling
problem,
because
I
mean
that
would
be
huge
fruit
and
just
know
just
as
a
technology
right
well,.
B
C
We
can
set
a
bigger
goal
in
this
meeting
and
say,
like
we
have
all
these
smaller
things.
We
want
to
get
done,
laying
some
floor
requests,
but
2020
we
do
in
each
meeting.
We
want
to
spend
a
bit
of
time
talking
about
bundling
or
something
like.
Maybe
that's
our
big
goal
for
the
big
big
audacious
goal.
I
mean.
D
Thing
I
just
want
to
mention
about
that
on
the
distribution
side,
like
say
at
least
in
Fedora,
I
can't
speak
about
Ubuntu
or
the
Debian
side,
but
I
know
with
fedora
they're
generally
frown
upon
bundle.
Dependencies,
so
I
know
contradicts
the
idea
of
being
able
to
basically
put
everything
together
in
one
thing:
I
think
it
would
be
nice,
though,
to
look
at
you
know.
Basically,
is
it
possible
to
do
that
at
the
per
package
granularity
so
in
other
words,
instead
of
like
NYC?
D
You
know,
and
a
lot
of
that
is
maybe
you
know
a
hundred
things
from
lodash
a
couple
hundred
things
from
babel.
It
would
be
nice
if
that
were
instead.
Just
you
know
the
few
dozen
packages
being
loaded,
I,
don't
know
if
that's
compatible
with
what
we're
talking
about,
but
I
just
wanted
to
mention
that
it.
Basically,
if,
if
everybody
starts
bundling
their
CLI,
you
know
everything
into
their
Co
lies,
then
I
can
see
that
becoming
kind
of
a
roadblock
to
getting
those
tools
like
distributed
as
part
of
Linux
distributions.
I.
C
A
Okay,
so
so,
then,
as
far
as
like
the
order
in
which
we
do
things
yeah,
we
know
we
want
to
start
with
the
recap,
and
this
is
the
scope:
do
we
want
to
move
into
focus
discussions
that
we
choose,
or
do
you
want
to
do?
The
sticky
note
exercise
right
after
that,
I
think.
C
May
be
doing
the
sticky
note
like
do
we
have
we
have
a
couple
open
conversations
like
the
I'd
say
the
biggest
open
conversation
we
have
is
probably
the
command-line
pricing
right
now
and
I
think
there
are
some
there's
some
like.
We
know
that
Windows
isn't
working
out
well
for
RIM
RAF,
for
instance,
like
we
get
lasers,
there's
some
random
things
like
that.
We
could
talk
to
you,
but
almost
would
rather
go
into
the
focus
discussion,
I,
think,
cuz,
I
think
we
could.
C
C
C
Because
I
think
like
we
could
probably
leave
20
minutes
for
how
to
get
involved
at
the
end,
though,
then,
because
we
could
simply
I
would
say
that
the
fixing
up
Windows
tests
is
a
great
way
to
get
involved,
joining
the
meetings
a
great
way
to
get
involved
like
we
don't
really
have
to
harp
on
that
stuff.
Early
on
in
the
meeting
I.
C
Don't
I
think
probably
40
minutes
would
go
pretty
fast
with
the
sticky
note
exercise
like
leave,
10
minutes
to
figure
out
the
sticky
notes,
and
then
you
know
45
minutes
to
discuss
at
all.
You
look
you're
pretty
that's
for
an
hour
right
there
and
I
guess
if
we
do
like
three
topics,
maybe
you
can
say
15
minutes
of
topic
or
something.
C
C
A
A
A
C
C
It
might
be
nice
that
we
don't
have
in
the
agenda
which,
like
it
might
be.
Maybe
we
do
this
and
then
maybe
we
just
do
this
in
our
bi-weekly
or
semi
weekly
meeting
afterwards,
we
try
to
set
a
little
bit
of
a
roadmap
based
on
the
outcome
of
this
meeting.
Maybe
not
try
to
do
that
as
part
of
this
meeting,
because
so
I
mean
the
takeaway
might
be
like.
C
C
C
A
I
mean
yeah,
we
need
yeah
for
that
particular
thing
sure,
but
we
need
somebody
who's
who
you
know
is
actually
using
this
stuff
correct.
Who
needs
to
do
it?
It's
and
right
now,
I
mean
I,
don't
need
to
do
bundling
I
mean
I
could
conceivably
make
that
part
of
my.
You
know
yearly
goals
or
something
like,
but
you
know
there's
other
things
that
that
I
care
about
because
of
my
job
or
whatever.
C
Else
exactly
what
just
like
yeah
and
I
mean
that's
working
well
for
that
working
so
far
like
we
all
want
file
system
operation,
so
we've
all
contributed
a
little
bit
to
that
kind
of
stuff
and
Cory's
working
more
on
the
SM
stuff
because
he
needs
some
fixes
for
NYC
and
I
for
some
reason,
care
about
test
coverage.
I,
don't
know
why
I.
A
Think
maybe
we
need
to
make
it
clear
to
you
know
people
like
you
know
the
only
way
that
any
of
this
stuff
is
going
to
get
done
is,
if
is,
if
you
know
you
participate,
because
this
is
not.
You
know
we're
not
here
to
necessarily
serve
you.
You
know
we
want
to
make
it
better,
but
we're
we're
trying
to
you
know
come
together
on
on.
A
C
A
A
C
A
C
C
C
You're
at
the
okay
I'm
965
yeah,
so
this
is
running
on
our
build
infrastructure,
so
this
is
like
super
close
to
actually
being
something
you
can
do
nightly
sure.
So
this
is
our
nightly
build
as
it
stands
right
now.
This
is
the
build
that
just
came
in
off
of
one
of
our
windows:
build
servers,
who's,
our
Google,
but
no
js'
project.
You
know
if
the
nodejs
project,
so
it's
like
ours,
our
Jenkins
servers.
C
The
tests
are
running
on
our
our
Linux
on
our
collection,
our
cluster
of
servers
that
we
have
for
node.js
on
Jenkins.
But
as
it
stands
today
we
don't
get
Windows
coverage
because
we
only
have
a
Linux
system
running
I'm
testing
out
code
caballo
for
the
node.js
project,
because
it
actually
allows
you
to
take
coverage
from
multiple
systems
and
merge
it
together.
So
we
can
actually
have
a
Linux
build
and
a
Windows
build
and
a
mobile
build
or
something
all
running,
conjunction
and
then
code.
C
Cough
will
actually
pull
all
three
together
into
one
cohesive
report
so
that
out
the
other
end
will
actually
have
all
the
Linux
lines
of
code
showing
coverage
and
all
the
windows
covered
lines
of
code
showing
coverage.
So
our
nightly
report
will
start
to
get
on
coverage
that
node.js
org
will
probably
be
for
Center
to
higher
and
more
indicative
of
actual
work.
People
could
do
because
today,
when
you
start
to
dig
into
these
reports,
you
actually
often
find
lines
like
this
that
it's
actually
just
that
we're
not
currently
able
to
track
it.
D
D
C
Basically,
we're
basically
adding
a
new
node
to
Jenkins
that
is
doing
Windows
coverage
and
then
I'm
proposing
we
use
code
cough
do
because
it
has
this
merge
functionality,
which
is
we
shouldn't
build
ourselves,
probably
like
we
could
do
it.
It's
just
like
we
threw
quarry
and
my
like
Istanbul
stuff
can
do
it,
but
we
have
to
like
I,
don't
know
like
copy
the
file
to
some
remote
server
somewhere
from
each
of
the
builds
and
then
do
it
ourselves
where
we
merge
all
the
reports.
D
I,
don't
think
it
can
be
done
without
a
service,
because
I
mean
basically
right.
You
have
tests
that
run
on
Linux
and
tests
that
run
on
Windows.
Those
are
two
separate
virtual
machines,
so
basically
there
is
no
master
process
that
can
say:
hey
here's,
the
results
you
know
from
Windows
in
this
directory.
The
results
from
Linux
here
I
mean
if
we
had
that
we
can
definitely
merge
those
you
know
just
by.
A
C
Yet
but
I've
been
talking,
a
few
people
we've
been
having
to
work
through
the
build
working
group.
To
do
any
of
this,
like
I,
had
to
get
access
to
I
have
access
to
just
the
coverage,
build
servers
right
now,
because
you
can
Jenkins,
you
can
actually
give
limited
access
to
machines,
so
I
have
access
to
a
new
whatnot,
not
yet
used
Windows
built
server,
and
then
the
old
Linux
build
server
and
we're
gonna
start
kind
of
trying
to
combine
the
two
anybody.
C
Over
there
at
Google,
I
think
there's
a
chance.
I
continue
getting
more
involved,
so
I
know,
yeah
I
think
we're
a
little
short-handed
on
build
right.
I
mean
there's,
not
I'm,
not
talking
about
Google
I'm.
Talking
about
like
on
the
node.js
project,
I
think
it's
been
hard
to
keep
build,
staffed,
I
believe,
yes,.
C
D
C
C
D
Environment
variables
is
actually
all
that's
being
altered.
The
the
master
commit
of
the
demo
repository
I
created
actually
straight
passes,
an
env
object
to
the
callback
hooks
and
then
from
there.
For
example,
you
could
do
you
know
E&B
dot,
NYC
config
equals
whatever
or
you
could
do.
Env
dot,
node,
preload
plus
equals
well
you'd
have
to
make
sure
that
yeah
anyways
you
could
either
set
or
append
variables
or
you
could
even
delete
variables.
D
D
A
separate
poll
request,
which
kind
of
provides
an
object
to
the
hooks
which
include
the
env,
but
also
let
you
know
like
you
know
this-
is
the
file
that's
being
executed.
These
are
the
args
none
of
the
other
stuff
is.
It
is
editable.
So,
basically,
with
the
exception
of
the
env,
it's
a
read-only
object.
C
C
Just
to
start
the
conversation,
maybe
even
because
it's
probably
not
a
huge
amount
of
work,
but
what
I
was
gonna
say
is
would
be
need
to
retire
the
special
snowflake
logic
we
have
for
for
the
built-in
v8
coverage,
because
it's
an
environment
variable
if
you
need,
if
we
could
instead
use
the
same
mechanism
that
userland
tooling,
can
use
to
set
to
set
the
environment
variables
as
well.
Correct.
D
And
obviously,
for
the
purpose
of
my
kind
of
user
space
module,
it
has
its
own.
You
know
add
this
event.
Remove
this
event.
It
kind
of
replicates
the
add
and
remove
listener
functions
of
the
event
module,
but
without
accepting
the
parameter
for
the
event
name,
one
thing
I
was
kind
of
thinking
about
is:
maybe
this
could
work
as
simply
a
spawn
event
on
the
process
object.
D
You
know
so
process
got
on
spawn
and
you
have
a
function
which
can
alter
the
environment
or
in
the
case
of
test
like
with
standard
version,
it
could
hook
the
process
spawn
to
basically
monitor
you
know
for
testing
purposes,
hey,
we
did
actually
execute.
You
know
the
get
command
and
you
know
do
what
was
supposed
to
be
done.
You
know,
so
there
are
use
cases
where
you
wouldn't
ask
we
had
it
anything
that
makes.
C
Sense
to
me
I
think
this
would
be
I
like
that
this
could
get
rid
of
like
the
weird
snowflake
stuff.
We
have
four
notes
coverage
too.
So
that's
great.
Let's
just
make
it
an
agenda
item
for
the
next
conversation,
but
I
would
recommend
maybe
making
a
candidate.
Plural
is
just
like,
because
I
find
that
works
really
well.
I
know
it
like,
especially
if
it's
a
feature
that's
less
than
a
few
hundred
lines
of
code.
C
A
C
C
You
only
have
one
minute
left,
so
you
try,
put
a
pin
in
it.
Yeah
so
excited
to
see
folks
I
guess
we
start
one
more
meeting
before
Montreal
all
right
yeah.
So
we
do
have
one
meeting
from
Montreal
and
was
it
I
think
we're
just
going
to
do
a
more
normal
one
so
seems
like
we
have
a
pretty
good
agenda
roughed
out
here.
Maybe
we
can
turn
the
notes
from
today
into
the
proposed
agenda.
Just
tend
to
throw
that
up
on
an
issue
or
something
it
speaks
or
leave
comments
on
it.
Yeah.