►
From YouTube: Node.js User Feedback - Public Session - Node.js Tooling
Description
A
Great
all
right,
hi,
everybody
welcome
to
the
second
public
user
feedback
session.
Our
first
was
on
benchmarking,
and
this
time
we
have
a
collection
of
folks
throughout
the
know:
Jess
user,
tooling
community.
So
you
know
very,
very
interesting,
bringing
together
a
very
interesting
group
of
folks
end
users
of
node
in
a
way,
but
you
know
very
much.
A
You
know
share
some
experiences
and
somebody
built
some
connective
tissue
back
to
the
the
node.js
project,
so
I
want
to
get
get
into
everybody's
introduction
and
before
I
you
know
go
around
I'd
like
to
give
the
floor
to
Chris
teller
maintainer
of
MOCA,
who
it
was
kind
of
the
the
starting
spark
for
for
this
group.
So
Chris,
you
know
we
we
got
together
at
IBM
index
here
in
San
Francisco
and
had
a
nice
conversation
about.
You
know
how
you
know.
Just
tooling
folks
would
like
to
get
more
involved
in
no
just
project.
B
Yeah
so
I
came
to
Dan
and
you
know
I
I
had
kind
of
noticed
over
the
years
that
you
know
most
of
the
people
working
on
core
were
really
focused
on
on
deploying
node.
As
a
you
know,
a
server
or
a
micro
service
or
people
really
focused,
and
so
sorry
I'm
getting
some
echo
the
anyway.
So
I
came
to
Dan
with
this
and
I
was
like
you
know
there,
there's
not
a
whole
lot
of
I,
guess,
representation
more
more
or
less
from
people
who
consume
node.
B
You
know
either
as
users
or
maintainer
Zoar
creators
of
command-line,
tooling
and
there's
just
a
ton
of
command
line
too
four-note
people
are
writing
more
and
more
tools
every
day
in
node,
and
you
know
it's
the
the
the
the
challenges
that
we
face
are
vastly
different
from
trying
to
you
know
basically
scale
node,
a
or
or
you
know,
a
lot
of
the
times-
we're
not
as
worried
about
performance
and
that
sort
of
thing,
and
so
we
are,
our
concerns-
have
often
more
to
do
with
user
experience.
Maybe
so
that's
just
kind
of
the
idea.
B
I
had
I
thought
that
maybe
it
would
be
a
great
idea
for
some
people
to
come
together
and
and
try
to
increase
lines
of
communication
between
the
people
using
node
for
tooling
and
in
core.
You
know
it's
nowadays.
The
the
whole
web
is
built
on
on
node.js,
command-line,
tooling.
You
know
everybody's
using
Babel
or
webpack
or
whatever
so
yeah.
That
was
just
kind
of
the
idea,
and
so
here
we
are.
A
Great
well
thanks,
Kristin,
and
really
appreciate
you
putting
the
legwork
to
bring
everybody
together
really
excited
to
do
this,
and
you
know
just
for
those
who
are
joining
or
turning
into
user
feedback.
It
will
exist
under
the
charter
of
the
community
committee
in
the
notice
project,
and
you
know,
as
a
team,
we
get
together
bi-weekly.
This
is
our
team
meeting
session
and
you
know
pump
once
a
month
is
how
we
I
was
lined
up.
A
We
have
we've
kind
of
made
a
commitment
to
doing
it
once
a
quarter,
but
you
know
once
every
a
couple
months
we
get
together
and
we
have
public
sessions
that
bring
together
folks
from
from
all
across
the
the
node
project.
So
let
me
introduce
folks
I'm
Dan
Shaw
I'm,
the
champion
side
of
the
community
committee
for
the
user
feedback
initiative.
I'm
a
calm,
calm,
member
and
I
am
a
member
of
the
nascent
mentorship
group.
I'm
gonna
go
around
my
screen,
so
I
don't
know
if
anyone
can
sort
of
predict
who's.
C
D
E
A
F
G
A
H
I
J
I
guess
I
guess
accurately:
I'm
Ben,
Newman
I
work
on
the
meteor
Jas,
open
source
framework
lead
developer
for
that
and
I
guess
the
Greek
was
experiencing
that
we
we
do
with
note.
Is
we
ship
a
specific
version
of
node
with
each
release
of
meteor?
So
you
don't
bring
your
own
node,
you
sort
of
get
it
from
your
version
of
meteor
way.
J
J
G
A
K
A
K
A
A
A
C
A
Great
just
just
so
we're
all
clear
and
I'm
not
skipping
over
anybody
Oh
morning
Lee.
So
let's
go
into
our
first
question,
which
is
describe
how
your
no
just
tooling
leverages.
Nodejs
I'm
gonna
draw
this
into
our
chat,
so
everyone
can
see
this
as
we
go
around.
You
know
fairly
later,
group
and
I
think
there's
no
better
place
to
start
with
no
jest
tooling.
We
didn't
start
with
the
MPM,
so
Rebecca
do
you
want
to
start
with
this
question
sure.
D
D
They
are
consuming
nodejs
tools
to
build
web
sites,
and
so
there
they
are
primarily
consumers
of
the
tooling
that
the
people
here
are
making
more
than
they
are
authors
of
tooling,
but
like
their
experience,
if
no
js'
is,
is
deeply
rooted
in
how
the
tooling
works
and
then
of
course,
yeah
in
Pam
itself
is,
is
where
I
spend
my
time.
I
also,
you
know,
like
all
of
my
command
line
stuff.
A
A
E
Sure
so
my
experience
has
been
very
similar
to
Rebecca's
what
what
she
mentioned.
What
you
mentioned
so
yeah,
like
all
of
my
tooling,
is,
is
in
node
and
it's
primarily
to
build
websites,
but
at
PayPal
we
also
have
a
fair
amount
of
tooling
for
building
and
packaging
up
our
node
servers
as
well
and
so
yeah.
But
there's
it's
yeah,
it's
it's
all
in
node,
Oh
in
JavaScript,
just
just
like
Rebecca
said,
despite
it,
maybe
not
being
the
best
tool
for
the
job.
E
Technically,
the
the
benefits
of
just
having
a
single
language
for
everything
are
just
like,
so
huge
being
able
to
have
contributors
who
may
not
be
super
experienced
in
tooling
in
general.
They
can
contribute
because
they
know
JavaScript,
oh
yeah,
most
and
most
of
our
tooling
is
in
the
form
of
C
lies
as
well.
So
that's
that's
about
it.
The.
G
E
E
Not
quite
we
do
have
like
our
pipeline
for
building
our
apses.
We
have
this
node
thing
on
Jenkins
that
builds
out
the
whole
thing,
and
then
we
have
this
Java
thing
that
packages
are
all
up
into
a
manifest
file,
and
then
that
goes
up
to
our
servers,
which
will
deploy
things
and
and
on
that
side
it's
all
node
little.
H
Everything
we
do
now
runs
a
node
right,
so
we
have
a
open
source
test
runner,
but
we
build
on
all
three
platforms
using
node.
So,
like
Rebecca
said,
we
I
don't
want
to
install
pearl
I,
don't
wanna
rely
on
scripts.
It's
all
shell
GS,
just
give
me
doctor
container
with
node
and
the
rest
will
be
the
same.
H
We
have
sass
as
well,
so
all
runs
node
node
scripts,
deploy
everything
person.
Everything
I
would
say
our
biggest
challenge
right
now
with
no
GS,
it's
with
slight
differences
in
how
it
the
tools
are
no
treats,
like
you,
know,
child
processes
and
direct
streams
right
and
windows
versus
a
4
up,
arrests
right.
So
what
was
the
biggest
pain
point?
But
we
are.
We
are
cable
that
we
can
live
with
that
compared
to
other
systems.
A
I
No
I
do
not
get
anything,
so
thank
you.
So
at
Intel
we
really
don't
have
anything
to
lean
as
far
as
leveraging
nodejs
as
I
said,
we
kind
of
focus
only
on
the
performance
side
of
node.
No
just
one
time
we
do
have
our
own
intensive,
a
tune,
analyzer
tool
which
to
again
measure
the
performance
and
track
the
hotspots
in
the
inner
application.
I
But
we
do
we
did
develop
this
workload,
which
we
contributed,
not
just
benchmarking
and
we
use
all
the
NPM
standard
packages,
the
mangoes
and
that
kind
of
tooling
we
have-
or
we
have
used
so
far,
but
we
don't
have
any
expertise
in
you
know,
like
all
others,
to
develop
any
new
tools
or
use
node.js.
Some
some.
A
A
I
So
we
have
contributed
so
general
Java
applications
in
a
browser
we
can
definitely
user
can
use
between
directly.
But
now
that
we
have
the
weird
support
we
can
leverage
into
nodejs.
So
you
run
node.js
regularly
and
you
run
v2
from
command
line
or
is
a
C
program
on
Linux
and
it
catches
all
the
hardware
counter
data
and
kind
of
gives
you
my
micro
or
credential
level
information
about
the
hotspots
in
your
application.
I
For
example,
if
you
are
we,
if
your
applications
too
big,
it
can
tell
you,
there
are
100
or
50%
I
cache
misses
or
you
have
a
lot
of
front-end
bound
issue.
You
generating
lot
of
coal
for
a
particular
application
and
all
those
things
which
normally
you
don't
get.
You
do
get
that
from
perf
in
a
way,
but
you
don't
get
from
the
higher-level
tools,
but
that's
the
low
level
data
you
get
from
video
freedom.
A
J
And
you
know
it's
like
a
relatively
small
team
of
people
working
on
it.
That's
that's
very
important
for
velocity,
but
it
also
means,
as
soon
as
the
version
of
node,
that
we're
using
has
a
particular
like
cool
new
feature
like
the
inspector
in
late
versions
of
node
7,
node
8.
We
can
just
ship
that,
as
like
a
standard
experience,
you
know
we
don't
have
to
have
like
a
degraded
version
of
it
in
you
know,
if
you're
using
an
older
version
of
node,
because
we
can
just
make
that
assumption.
J
So
that's
been
really
nice
and
one
way
that
we've
made
that
work
for
our
users
is
that
you
can
Meteor
node
and
then
node
arguments
and
it
just
like
defers
to
exactly
the
version
of
node
that
you're
using
for
the
current
app
meteor
app
that
you're
working
on.
We
do
the
same
thing
for
NPM
and
MPX
and
even
yarn.
So
that
is
just
very
easy
to
use
exactly
the
same
versions
that
meteor
ships
with
and
also.
H
J
J
C
I
have
a
question
on
that.
Do
you
so
what's
the
upgrade
path
like?
How
do
you
kind
of
eventually
move
from
LTS
LTS
and
like
when
10
cut
becomes
LTS?
Do
you'd
like?
Is
that
gonna
be
an
easy
transition
for
you
or
is
there
anything
that's
kind
of
a
barrier
on
that
node
side
kind
of
C
is
like
holding
you
back
yeah.
J
So
far
as
we've
made
like
comparatively
huge
leaps,
it's
actually
been
fairly
straight
forward,
at
least
from
the
perspective
of
the
end
user,
because
we're
able
to
just
like
take
a
meteor
app
that
was
at
the
previous
version
that
was
working
and
see
what
happens
when
we
try
running
meteor
update
to
get
to
the
new
version
and
just
like
repeatedly
examining
what
breaks.
When
you
try
to
do
that.
Inviting
people
to
you
know
let
us
test
their
actual
apps
and
having
a
few
internal
apps
of
our
own,
like
the
the
galaxy
hosting
service
means.
J
We
can
just
really
like
smooth
that
that
update
experience
and
what
do
they
like
internal
changes,
end
up.
Looking
like
you
know,
we
we
go
through
the
the
list
of
breaking
changes.
We,
you
know
updated
buffer
new
buffer
to
buffer
from
in
a
lot
of
cases,
but
for
the
most
part,
although
we
point
people
to
those
those
lists
we
we
haven't
had
to
like
hold
people's
hands
to
update
that
kind
of
stuff
in
their
own
apps,
though,
we
certainly
have
to
pay
attention
to
it
in,
like
the
implementation
of
the
command
line
tool.
A
J
We
would
push
people
rather
than
trying
to
pretend
that
like
node,
doesn't
exist
and-
and
for
us
that's
been
really
important
because
it
it
means
that
people
know
they
can,
for
the
most
part,
just
like
drop
an
existing
node
projects
like
into
a
subdirectory
of
a
meteor
app,
and
it
should
just
work,
that's
an
expectation
we
want
them
to
have,
and
vice
versa,
so
like
if
they
decide
to
move
off
of
meteor.
For
whatever
reason
you
know
the
the
code
they've
written.
A
A
Saw
and
I
wanna
thank
Shawn
and
Gus
and
Kelly
for
all
joining
I'm
gonna
go
ahead
and
let
the
folks
that
are
the
joint
on
time.
You
know,
go
through
the
current
topic,
which
is
describing
how
your
tool
leverages,
know
Jess
and
then
at
the
end
of
that
I'll.
Let
you
nourish
yourselves,
and
this
is
our
first
topic
so
it'd
be
great
times
it's
for
you
to
jump
in
I.
M
B
Hi
yeah,
so
yeah
mocha
is
a
testing
framework
for
JavaScript
and
so
yeah.
It
probably
should
be
written
in
JavaScript.
To
straight.
That's,
that's
about
all
I
know.
You
know
it's
it's
gonna.
It's
got,
it's
no
js'
launcher
for
testing
node
and
you
can
use
it
in
the
browser.
But
you
know
that's
that's
about
the
size
of
it
in
in
my
own,
you
know:
work
outside
of
mocha.
B
You
know,
I've
looked
at
doing
things
like
using
node
to
you
know,
create
like
a
bundlers
for
deploying
code
to
various
server
list
frameworks
and
things
like
that,
and
so
that's
basically
just
just
how
I
use
it
but
yeah.
It's
of
course
there's
there's
a
ton
of
stuff
going
on
at
IBM.
That
I
don't
really
know
too
much
about
you,
know,
there's
loopback
and
and
and
that
team
writing
their
tools
there
so
but
yeah,
but
that's
about
all.
Yet
it's
just
but.
N
Leche
uses
node
lo
dashes
is
started
out
as
D,
which
means
it
works
in
the
browser.
I
mean
it
worked
in
Adobe
Illustrator,
it
works
RINO,
it
did
all
kinds
of
stuff,
but,
as
time
has
gone
on,
we've
used
node
more
and
more
to
generate
various
builds
of
Allah.
So
low
is
now
built
with
node
and
I'm
specializing
more
for
just
just
modern
environments
and
ekam
script
modules.
So
it's
going
to
be
leveraging
those
things
that
are
that
are
in
node
I'm,
also
working
on
a
module
loader,
which
is
all
mode.
N
It's
it's
it's
adding
es
syntax
to
node.
So
that's
that's
getting
into
module,
loader,
algorithms,
all
the
resolution
stuff
under
the
hood
tying
into
experimental
things
like
VM
module.
All
of
that
kind
of
stuff,
so
I've
been
becoming
more
active
in
the
node
issue.
Tracker
because
of
that,
like
fix
bugs
on
various
flags
and
features
to
kind
of
unblock
or
ease
the
path.
There
I
also
work
at
Microsoft,
and
we
are
our
big
consumers
of
node
part
of
the
the
node
foundation.
N
Doing
the
N
API
work,
chakra
node,
all
that
stuff,
so
lots
and
lots
of
node
consumption.
Here
but
it's
Microsoft
is
kind
of
like
multiple
companies
in
one
I
mean
every
every
team
is,
is
their
own
thing,
but
it's
just
like
any
other
application
development
thing
I
mean
it's
all
consuming
node
for
you
can't.
You
know,
create
a
modern
web
application
without
using
node
in
the
tools
around
node.
To
do
that.
N
N
Low
five
will
use
the
ESM
loader,
there's
a
there's,
a
build
of
low.
Now
that
is
written
entirely
in
ESM
and
that's
low,
yes,
so
yeah.
So
the
next
major
version
will
be
all
yes,
yes,
em
and
then
we'll
require
build
tools
or
bundlers
for
consumption.
Outside
of
that
I'm
dropping
our
CLI
tool.
We
used
to
have
a
tool
that
would
create
custom
builds,
and
now
that
you
know
web
pack
is
a
thing.
A
O
Sure
can
you
hear
me
first
of
all,
yes,
so
I
work
on
ember
CLI,
and
so
that
is
the
build
tool
for
ever
j/s
projects
and
we
use
well.
We
chose
a
while
ago
I
a
underlying
build
system
called
broccoli.
Jas
I
would
say
that
we're
probably
the
only
user
of
it
right
now
and
then
we
compile
down
to
AMD
for
the
browser,
and
that
is
also
a
fairly
legacy
concern
that
has
hasn't
changed
over
the
years.
O
D
O
Say
I
guess
to
some
of
the
the
ways
or
/
issues
were
using
node
with
so
our
broccoli
build
system
does
a
lot
of
file
system
thrashing,
and
that
is
very
concerning
once
you
get
to
a
Windows
system.
So
we
we
have
lots
of
time
spent
improving
our
symlinks
and
you
know
improving
our
documentation
as
far
as
how
Windows
users
can
get
around
their
Simulink
blocks
on
their
systems.
So
that's
something
we
deal
with
a
lot.
O
D
O
O
O
G
O
O
C
G
C
Okay,
I
I'm
super
interested
in
this
bit
and
I
did
I'm.
Actually
a
few
people
who
have
jumped
in
to
this
discussion
have
asked
me
about
this
privately
and
how
old
I
handles
like
node,
LTS
stuff
I,
have
questions
about
that,
but
I
I
do
want
to
make
sure
I
with
the
other
user
feedback
members
we've
come
through
one
question
over
42
minutes
in
should
we?
What
what's
the
plan.
L
C
A
I
think
that's
a
good
point
and
you
know
I
I
think
there's
an
interesting
topic
area
emerging
around
LTS,
an
opportunity
to
come
back
and
further
discussion
around
that.
So,
let's,
let's
just
make
note
of
that-
and
you
know
see
that
as
an
opportunity
to
come
right
on
and
Rebecca
I'd
love
to
get
you
your
input.
A
Integrator
of
that
distribution,
interesting
so
last
but
not
least,
gus-gus
yeah!
Thank
you
for
joining
I,
don't
know
if
your
tooling
or
nodejs
from
the
invites.
So
please
please
excuse
my
ignorance
if
you'd
like
to
introduce
yourself
and
describe
how
your
your
tooling
leverages
know:
Jess,
that's
great.
If
you're
a
node
contributor
and
just
joining
us,
please
just
introduce
yourself
hi.
P
Yeah
I'm
just
kind
of
here,
I
well
I'm,
yeah
I'm,
not
I,
don't
have
any
tooling
I'm
just
kind
of
joining
in
to
kind
of
take
its
effect
on
this,
based
on
we've
been
looking
at
tooling
a
lot
in
the
node
modules
group
and
I
just
kind
of
wanted
to
see
what
you
know.
Tooling.
Authors
were
doing
to
kind
of
get
a
better
to
understand.
They're,
perfect.
A
Thank
you
for
joining
us
and
before
you
join
that
I
kind
of
filtered
out
some
of
the
folks
that
are
here
from
the
node
project
here
to
listen
and
I
will
include
you
in
that
group
of
folks
as
I
go
around
and
ask
folks
questions
thanks,
guys,
all
right,
so
I
want
to
focus
on
the
negative.
We
have
a
you
know
a
few
questions.
What's
working?
A
What's
not
working,
you
know
to
give
everybody
the
you
know
appropriate
forum
to
you
know
to
say
their
piece
and
you
know
to
really
focus
the
you
know
open
forum,
discussion,
yeah
I'd
like
to
hear
while
we're
gathered
together
and
we
have
the
ear
of
the
knowjust
project.
What's
not
working
with
the
you
know,
Jess
tooling,
ecosystem.
Where
were
our
pain
points,
so
we
can
begin
identifying
them
and
addressing
that
and
let
me
go
ahead
and
drop
this
into.
A
N
There's
also
things
that
are
really
handy,
that
are
pseudo
private
and
that
have
not
made
their
way
to
being
public.
Yet,
and
part
of
me
feels
like
the
the
culture
in
node
is:
if
I
bring
it
up,
there's
a
chance,
they'll
go!
Oh,
we
should
actually
lock
that
down
more
and
then
take
away
the
handy
feature,
instead
of
exposing
that
handy
feature
in
a
consumable
way.
N
I
would
actually
like
to
expand
some
of
those
too
so
I
did
that
the
the
the
thing
coming
from
the
outside
is
that
that
I
think,
if
we're
going
to
focus
on
negatives,
is
I,
think
that
there's
a
there's
a
an
attitude
and
node
core
that
user
land
is
less
than
and
I
I
wish.
That
was
was
different,
there's
a
lot
of
times
where
they'll
see
a
user
land
solution
as
as
not
even
viable
and
as
someone
that
that
you
know
basically
works
in
user
land.
N
It's
it's
kind
of
a
it's
disappointing
that
a
lot
of
times
in
order
to
get
nodes
attention,
you
have
to
mention
the
word
fork
or
or
they're
they're,
just
they're
deaf
to
it,
and
so
that's
I
would
really
like
to
for
user
land
and
ecosystem
things
to
be
recognized
as
important
without
the
ecosystem.
Node,
as
it
is
today
would
not
have
not
exist
just.
G
N
More
for
things
like
so,
if
there
is
solutions-
or
there
is
implementations
of
things
that
that
starting
out
in
user
land
is
is,
should
be
seen
as
a
as
an
okay
or
acceptable
thing.
A
lot
of
times,
they'll
say
things
like,
for
example,
or
we're
debating
about
fetch
and
then
looking
at
no
to
fetch,
which
is
an
external
package
and
how
that
relates
to
to
note
or
I
think
that
no,
it
should
be
open
to
pulling
in
packages,
or
at
least
looking
at
how
external
packages
equal
to
81
for
a
lot
of
times.
N
There's
basically
a
mindset.
It
has
to
be
native.
Only
it
can't
exist
through
something
other
than
being
sucks
or
C++
and
I
think
that,
especially
for
things
that
are
experimental
or
work-in-progress
user,
land,
implementations
or
JavaScript.
Realm
implementations
should
be
seen
as
as
okay
and
as
an
option
for
for
new
features.
A
D
No
one
wanted
to
tackle
that,
because
it's
an
immense
and
difficult
problem,
some
level
of
document
that
we
we
don't
even
have
documentation
and
like
what
errors
you
can
get
from
different
commands.
It's
like
it
might
throw
something.
If
it
went
wrong,
what
will
it
throw?
Try
it
out
and
find
out
see
if
it
breaks.
D
So
that
that
that's
that
you
know
when
we
were
first
talking
about
doing
this
meeting,
that
was
the
thing
that
was
most.
That
immediately
came
to
my
mind.
There
have
been
you
know:
it's
like.
Historically,
we've
had
some
other
things
around
how
Clyde
tools
you
know
hi
tool
UX,
is
all
through
stdio
and
you
know
we
had
like
had
a
lot
of
stdio
juggling
I.
Think
that's
solid
now,
so
I
don't
expect
to
have
that
in
the
future,
but
that
was
an
interesting.
D
That
was
certainly
an
interesting
experience
like
when
note
changed
some
settings
and
it
had
this
whole
cascading
effect
that
ultimately
resulted
in
stuff
behaving
strange
on
Linux
installations.
The
later
on-
and
you
know
more
broadly
and
I-
don't
know
like
that.
That
comes
down
to
a
corset
like
that
one,
it's
like
would
any
of
us
pointed
that
out
there's
a
problem
if
we
had
seen
it
in
advance
and
I,
don't
know
if
that's
true,
but
it
is
like
that
that
is
the
place
where,
as
a
chi
developer,
I
have
to
be
like.
D
A
Yeah
and
if
so
tolling
folks
turn
into
you
know,
node
is
extremely
active
in
terms
of
its
contributor
base.
Not
the
same
with
libuv
is
very,
very
small
group
of
folks
working
on
that.
So
you
know
call
to
action
a
great
opportunity
to
go
work
on
a
really
low
level
event
stuff
across
all
platforms,
but
you
know
there's
definitely
you
you
were
seeing
you
know,
repercussions
of
you
know
very
small
team
there.
Okay,
so
attorney
wants
to
direct
a
question
to
everybody
that
we're
going
to
respond
to
in
the
issue.
Issue
number
45.
C
C
G
A
Great
yeah,
so
please
post
that
issue,
and
you
know
this.
This
group
is
designed
for
you
know
what
jdd
mentioned
in
terms
of
providing
that
venue.
You
know
for
the
initial
discussion,
but
we're
not
necessarily
the
end-all,
be-all
and
I'd
like
to
see
you
know
this
potentially
grow
into
a
more
active
group.
That's
focused
on
this
and
you
know
we'll
continue.
Our
journey
of
I
am
providing
the
public
forum,
so
Kelly
isn't
working
with
the
node.js
ecosystem
for
the
Ember
team.
A
B
That
directed
at
me,
yes,
okay,
you
know
so
my
frustrations
with
with
just
just
from
a
technical
standpoint.
Are
you
know
again
cross-platform
issues,
it's
you
just
like,
for
example,
FS
not
watch
just
has
so
many
problems
and
it's
I,
don't
think.
There's
really
any
champion
there
further
stopwatch.
Nobody
wants
to
try
to
figure
it
out
and
well,
it's
probably
because
it's
really
hard
right,
but
yeah.
You
know
why
are
there
things
like?
Why
do
we
need
cross
spawn?
B
Why
do
we
need
cross
in
why
you
know
why
do
we
need
something
built
on
top
of
FS
watch
to
make
it
useful?
Why
do
we
need
graceful
FS?
All
these
all
these
things
that
it
seemed
to
me
that
you
know
that's
that's
kind
of
that's
just
kind
of
where
I'm
going
with
it.
It's
just
it's
just
these
cross-platform
gotchas
and
compatibility
is
in
just
kind
of
neglected
areas
of
notes,
core
core
base,
great.
A
G
Ask
just
one
question
very
quickly:
do
you
think
this
is
unique
to
tooling
the
cross-platform
concerns,
because
it's
sort
of
the
first
life
I've
heard
from
like
the
end
users
weren't
mentioning
it
specifically
so
I'm
just
wondering.
Do
you
think
there's
something
special
about
the
tooling
or
it's
just
that
its
first
first
people
that
to
say
it
so
that
we've
heard
it.
B
A
C
E
Yeah
awesome
I'm
so
glad
that
Christopher
mentioned
the
cross-platform
stuff.
That's
been
a
huge
pain
for
me.
I
know
gleb
mentioned
in
the
comments
in
our
chat
here.
It's
that's
thumbs
up
from
him,
too
I
I
would
say,
that's
the
been
the
biggest
challenge,
especially
in
in
my
open-source
tooling
efforts
from
like
people
using
the
tooling
as
well
as
contributing
to
it.
It's
been
just
a
huge
pain,
so
yeah.
H
E
Rim
raff
to
that
yeah,
a
bunch
bunch
of
modules
that
I
wish
didn't
exist,
but,
like
that
said,
we
were
gonna
talk
a
little
bit
about
what
is
working
in
the
node
ecosystem
and
and
I.
Think
that's
one
thing
that
is
working
is
that
these
these
solutions
do
exist.
They
may
be,
you
might
consider
them
workarounds,
but
the
fact
that
they
exist
makes
it
like
a
lot
easier
than
it.
Then
it
was
a
couple
years
ago
before
they
existed.
So
that's
that's
one
of
the
reasons
why
we
prefer
to
use
node
for
our
tooling.
E
It's
just
that
lots
and
lots
of
problems
have
been
solved.
It's
easy
easy
to
build
these,
these
kinds
of
tools.
So
yeah.
Let
me
just
make
sure
oh
yeah.
Another
thing
that
hasn't
been
mentioned
is
debugging
and
could
still
use
some
work.
I
I
mean
the
debugging
tools
already
like
with
the
inspector
flag
and
everything
like
that's
awesome.
It's
really
really
good
I
I.
Think
mostly.
The
debugging
story
is
an
education
problem,
both
from
the
perspective
of
using
tools
that
hook
into
the
debugging.
E
Utilities
that
no
it
provides,
as
well
as
just
people,
understanding
that
the
node
modules
directory
is
just
like
there's
just
a
bunch
of
JavaScript
in
there,
so
you
can
actually
like
console.log
and
do
whatever
else
you
want
to
in
there.
So
I
don't
know
what
the
node
project
can
do
from
an
education
standpoint,
but
as
a
maintainer
of
open-source
software,
if
people
just
understood
a
little
bit
better
how
to
debug
things,
I
would
get
a
lot
fewer
issues
both
of
my
tooling,
as
well
as
my
like
other
runtime
related
modules
too.
G
I
would
suggest
if
there's
like
a
particular
use
case,
you
post
an
issue
in
the
Diagnostics
working
group,
because
I
know
there's
some
work
there
to
try
and
capture
the
like
that
the
use
cases
and
if
it's
like
a
unique
debugging
use
case
firm
for
module
tooling.
It
would
be
good
to
have
that
captured
there
and
then
considered
as
part
of
the
documentation
that
people
are
working
on
yeah.
E
That's
that's
fair,
I.
Think
a
lot
of
people
don't
know
that
you
can
run
like
if
you're
doing
es
lint.
For
example,
you
can
run
node
dot,
slash,
node
modules,
dot
bin
es
lint
and
then
inspect
like
if
people
just
understood
that
they
could
do
something
like
that,
it
would
make
a
big
difference,
and
so
maybe
there's
something
that
we
can
do
there
to
facilitate
that
kind
of
education.
Yeah.
G
Like
there
was
already
an
effort,
not
not
making
a
huge
amount
of
progress
just
to
the
people's
time,
to
document
the
tools
and
how
to
use
them.
So
if
you
know,
for
example,
you
know
exactly
how
you
want
people
in
debugging,
you
wrote
something
up
that
explained
that
we
can
probably
get
that
on
the
node.js
org
website
and
from
there
it
can
be.
You
know
we
can
publicize
it
through
tweets.
Whatever
else.
Oh
I.
C
E
A
H
C
J
You
can
kind
of
think
of
it
as
a
single
weight,
but
the
await
can
appear
anywhere
as
long
as
there's
an
async
function
on
the
call
stack
not
just
in
the
body
of
the
the
function
and
the
reason
this
is
such
a
an
issue
for
us
is
implementing
that
at
the
v8
level
has
some
pretty
gnarly
implications.
Basically,
these
fibers
look
a
lot
like
threads
to
v8
and
v8.
G
J
Is
the
one
thing
that
keeps
me
up
at
night
yeah,
it's
a
big
example
in
my
mind,
I,
don't
know
we
we
had
another
bug
related
to
that,
like
we
wouldn't
have
had
this
problem
if
we
weren't
using
fibers
that
resulted
in
segmentation
faults
in
node
810,
and
we
did
a
big
bisect
and
figured
out
that
again
it
was
a
v8
back
port
that
could
have
been
done
differently
and
I.
Don't
know
it
just
just
very
recently.
This
isn't
a
huge
B
to
have
a
version
of
node
with
meteor.
J
We
can
also
ship
a
custom
version
of
node
if
we
have
to
so.
Of
course,
there
was
a
security
update
for
node,
811
and
out
of
conservatism.
That
didn't
include.
You
know
the
fix
for
this
problem,
so
we're
looking
at
a
situation
where
we
can't
actually
update
to
a
node
at
11
for
the
secure
the
updates
right
now
until
8:11
to
comes
out.
J
G
J
A
So
Ben
it
sounds
like
there
would
be.
You
know,
a
great
opportunity
to
get
deeper
involved
in
the
VM
working
group.
You
know
that
is
the
the
group
we've
shipped
NEPA
API
there,
but
that
is
the
group
that
you
know
tends
to
focus
on
stability
there
and
we've
worked
very
hard
to
build
out
an
API
which
is
an
ABI
stable.
A
You
know
representation
of
what
node
expects.
So
by
expressing
you
know,
meteors
needs
in
that
ABI
stable
layer
that
node
uses,
rather
than
you
know,
which
is
the
contract
that
we
use
and
v8
uses
to
say.
You
know
if
we've
broken
anything,
so
you
know
tuning
into
that
and
participating
in.
You
know
that
work.
It
seems
like
a
good
area
to
get
involved
because
you
know
as
a
project
we
very
much
you
know
pulled
back
away
from
that.
You
know
not
having
any
sort
of
expression
and
just
using
internals.
A
C
G
I
mean
so
far
that
that
other
channel
is
I
mean
it's
just
sort
of
an
ad
hoc
when
used
I
like
Dan's
suggestion
that
you
know,
if
you
looked
at
any
pie
and
said
these
are
the
things
we
still
can't
do
using
that
that
would
at
least
give
you
know,
we
can't
implement
everything
there,
but
that
would
give
us
some
good
information
to
say
these.
This
is
another.
G
I
A
C
C
We
are
actively
trying
to
make
the
channels
between
the
kind
of
user,
land,
ecosystem
and
node
core,
and
they
do
project
more
open
and
tear
down
barriers
between
that
I've
heard
from
you
know,
quite
a
few
people
that
there's
perceived
barriers
and
so
I'm
personally
try
to
strip
those
down
as
much
as
possible
and
I
know.
You
know
others
of
the
project
are
as
well.
C
C
Don't
require
them,
but
you
know,
even
if
you
just
want
to
reach
out
to
someone
on
Twitter
or
you
know,
via
DM
or
via
email,
or
you
know,
vomit
in
an
issue.
We're
always
gonna
be
happy
to
help,
and
at
least
try
that
you
know
try
to
find
common
ground
and
you
know
make
it
a
more
open
space,
so
yeah
feel
free
to
reach
out
to
people,
and
you
know
we
are
happy
to
write,
assist
thanks.
G
I
think,
just
echoing
you
know,
we
want
to
you,
know,
Forge
the
connections
and
get
the
right
groups
of
people
together
to
work
on
the
particular
issues.
I
think
this
was
a
good
sort
of
introduction
to
what
people
are
working
on.
I.
Think,
in
my
mind,
I
see
next
steps
is
to
try
and
figure
out
some
like
concrete
things
that
we
want
to
move
forward.
So,
for
example,
you
know
I
heard
things
like
platform
support.
G
G
Can
we
work
for
them
to
have
issues
because
I
think
it's
a
matter
of
you
know
sometimes
finding
the
right
group
of
people
to
have
the
discussion
with,
and
you
know,
and
if
there
isn't
one
seeing
if
we
can
get
a
group
of
people
who
are
interested
in
sort
of
having
that
discussion,
as
you
know,
provided
you
know
you
guys?
Are
you
have
time
to
participate?
I
think
we'll
find
other
people
who
have
time
to
participate
as
well,
and
you
know
sort
of
bit
by
bit
hopefully
make
progress
in
the
right
direction.
G
So
I
think
you
know,
hopefully
in
the
issue
we
can
figure
out
what
those
know
step.
Next
steps
are
I'll
also
say
if
you
know,
if
any
of
you
have
some
specific
things,
you
want
to
try
and
move
forward
earlier
than
you
know
that
that
discussion
may
take
place,
feel
free
to
reach
out
to
myself
and
I'm
sure
Tierney
would
say
the
same
thing
and
we'll
figure
out.
You
know
what
kind
of
next
steps
we
could
start
in
in
advance.
Okay,.
A
A
I
want
to
make
sure
we
we
go
ahead
and
grab
some
of
the
comments
that
folks
made
there
and
put
them
in
the
minutes,
because
you
know
things
like
a
perm
and
FS
watch
and
stuff
like
that.
Yeah
I
want
to
make
sure
that
those
are
captured
in
the
minute.
So
when
all
the
node
collaborators
go
back
and
look
at
those
issues,
we
can
see
the
record
of
it.
So
thanks
again,
everybody
for
taking
the
time
today
and
joining
us
for
this
public
users
feedback
session
on
know
just
tooling
thanks
again,
Lex.