►
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
stupor,
so
here
we
are
no
just
two
and
group
meeting
august
8th
august
7th
2020..
I
was
on
vacation
for
the
last
meeting,
so
I
don't
really
know
what
happened,
but
I
heard
it
was
a
small
crowd.
Yeah
was
anybody
here
at
that
one?
It
was.
I
think
it
was
me
and
wes
and
ben.
B
Noteworthy,
I
don't
remember,
we
just
ran
through
all
the
issues
and
talked
about
stuff
that
we
don't
know
anything
about.
That
was.
C
A
Well,
let's,
let's
go
ahead
and
just
kind
of.
B
Remember
one
thing
that
we
did
talk
about.
We
talked
about
the
the
like
deep
dive
like
meeting
that
we
had
been
talking
about
doing
and
I
think
we
settled
on
a
topic
for
that
one.
I
think
it
was
like
the
recursive
file
system
stuff.
We
were
going
to
talk
about
so
I
think
the
action
item
from
that
is
we
should
we
just
need
to
like
book
like
decide
when
we're
going
to
do
that
and
yeah
get
it
booked.
A
A
Okay,
hi
ben
so
yeah.
So
let's
just
go
through
this
here,
so
config
files
in
project
group
directories
got
picked
up
somehow
yesterday,
apparently
by
hacker
news,
and
so
there
was
a
lot
of
traffic
on
that
issue.
A
So
you
know
the
the
comments
were
just
like
the
hacker
news
thread.
I
don't
know
if
you've
gotten
a
chance
to
look
at
it,
but
it
was
kind
of
what
you'd
expect
at
people
saying
we'll
stop
using
so
many
tools
and
it's
just
like
okay,
but
you
know
so
there's
all
these
people
in
this
github
issue.
A
A
fair
amount
of
them
aren't
helpful,
but
it
didn't
really
look
like
anybody
got
abusive
or
anything
which
is
nice,
but
there
were
a
lot
of
positive
reactions
to
the
issue
description,
so
I
think
we
and
it
was
pretty
popular
on
the
on
the
on
the
front
page
of
hacker
news
apparently,
and
so
I
think
we
we
kind
of
hit
a
nerve
with
that.
A
So
I
think
I
think
you
know
there
are
quite
a
few
people
like
who
hate
this
and
and
and
think
it's
like
a
real
problem
that
needs
to
be
solved.
You
know,
as
I
said
in
in
chat
earlier
today,
you
know
it
it's.
Certainly
it's
a
problem
and
people.
People
don't
like
the
way
things
are
whether
we
have
more
important
work
to
do
is.
Is
another
question
entirely,
but
I
think
in
general,
like
for
from
the
people
that
that
you
know,
came
in
from
social
media
and
whatnot,
they
seem
to
like
that.
C
I
brought
up
an
idea
in
the
slack
channel
a
little
bit
earlier
today.
I
don't
know
if
anybody
saw
it,
but.
C
C
B
C
C
If
you
think
that
is
what
we
should
go
for,
then
I
think
you
know
that
would
be
a
great
implementation
detail
of
said
package
which
just
gave
back
a
list
of
of
files,
but
I
think
that,
to
be
honest,
opinionated
is
a
little
bit
better
here,
because
if
we
can
get
opinionated-
and
we
can
just
say
almost
every
popular
tool
in
the
node
ecosystem
follows
this
exact
pattern
of
where
it
will
look,
then
I
think
we
get
a
lot
more
benefit
out
of
it.
B
One
thing
that
people
kind
of
brought
up
is
like
you
know:
yes,
lint
lets
you
pass
in
a
flag
to
point
to
your
config
file,
so
I
mean
maybe
even
just
kind
of
aiming
for
supporting
that
across
all
of
the
tools,
so
that
you
can
at
least
choose
to
put
your
files
in
some
subdirectory
and
then
point
them
at
it,
because
I
don't
think
everything
supports.
Even
that
so
I
mean
maybe
that's
a
realistic
starting
point.
B
A
Yeah,
I
mean
right
a
lot
of
tools.
I
mean
nokia
supports
that
you
know
config
file
location.
I
find
myself
just
not
using
it
because,
let's
just
use
the
defaults
because
that's
easy
so
one
way
to
go
about
it
more,
maybe
more
gradually
would
be
okay
for
the
the
libraries
or
projects
we
have.
We
can
start
using
the
new
config
new
config
directory
and
we
can
use
this
like
dash
c
flag
on
all
our
tools
and
we
can
put
everything
that
we
could
put
in
there.
A
Okay,
and
so
we
put
all
this
stuff
in
there
and
then
for
the
tools
that
we're
using
that
don't
support
an
alternate,
config
location.
We
go
to
those
tools
and
knock
on
the
door
and
say
hey
issue:
do
you
think
like
it
would
be
cool
if
we
added
a
thing
that
would
let
you
specify
a
you
know
a
particular
config
file,
location,
great,
and
so
I
mean
that's,
that's
one
way
to
do
it,
but
a
point
was
made.
I
don't
remember
where
you
know
it's.
A
I
think
in
the
issue
is
just
like
it's
it's
much
better
like
default
experience.
If,
if
you
don't
have
to
use
that
dash
c
flag,
but
it
it's
like
a
way
to
way
to
get
there
now,
you
know
if
we
find
that
every
everybody
who's
using
tool
x
is
using
the
c
flag
of
tool
x
or
a
sizable
portion.
Maybe
that
would
push
that
tool
in
the
direction
of
explicitly
supporting
that
location.
So
you
wouldn't
have
to
specify
you
know
where
it
lives,
so
so
it
would
start
looking
in
dot
config.
B
I
think
another
potentially
interesting
thing
about
doing.
That,
too,
is
maybe
that
would
like
if,
if
tools
started,
supporting
like
the
flag
or
whatever,
we
could
actually
start
like
like
searching
on
github
to
see
like
where
do
people
generally
put
this,
and
if
we
can
kind
of
get
some
numbers
where
it's
like?
Oh
there's,
a
consensus
that
people
seem
to
usually
put
it
in
like
a
dot,
config
file
or
directory.
B
Rather
that
might
it
might
give
us
some
some
information
to
go
on
and
then
also
just
I
just
quickly
googled
like
as
an
example
like
prettier,
does
not
let
you
specify
where
your
config
file
goes.
D
Does
moca
support
it
yeah
it
does.
I
feel
like
I
I
mean
this
is
kind
of
fresh
on
my
my
mind,
because
I'm
working
on
converting
yards
to
be
a
dual
module,
so
I've
added
like
several
more
new
config
files,
whereas
I
used
to
be
relatively
clean
in
that
directory
so
and
I
would
be
willing
to
experiment
with.
I
think
I
will
try
the
experiment
of
tossing
some
stuff
in
a
config
directory
as
long
as
there
are
enough
tools
that
accept
that
setting
that
it
actually
cleans
things
up
a
little
bit
yeah.
D
D
You
know
various
other
niceties
you
might
get
if
the
lender
finds
your
or
if
the
editor
finds
your
config
files.
So
this
is
the
advantage
civilization.
I
guess
it's
like
an
editor
could
be
looking
in
the
config
folder.
If
that's
where
people
started
putting
stuff,
but
I
could
start,
I
think,
because.
C
I
I
I
would
just
like
to
say
that
the
config
flag
is
already
provenly
good,
I'm
not
disagreeing
with
supporting
it.
I
think
we
should
support
it
in
all
the
tools,
but
I
think
that
that,
as
a
concept
is
not
really
super
like
exploratory
here,
I
I
mean
yes,
lin
supports
it
like
half
the
tools
I
use
already
support
it.
I
think
that's
just
a
proven
good
best
practice
for
a
clie.
C
I
would
like
to
figure
out.
I
think
this
issue
is
really
about
how
we
move
past,
putting
all
this
burden
on
the
user
and
move
it
into
some
either
standardization
or
a
burden
on
the
tools
themselves
to
support
it
because
like
if
they
have
to
pass
in
the
flag,
we're
just
all
we're
doing
is
shifting
it
from
being
a
file
in
their
thing
to
something
they
type
every
time
or
put
in
an
npm
script
like
to
me,
that's
not
a
huge
win.
Do
you
mind?
B
I'm
actually
curious
to
try.
This
now
like
see
like
ben,
brings
up
a
good
point
about
like
editors.
Looking
for,
like
you
know
your
eslint
rc
or
whatever
at
the
at
the
package,
I'm
actually
curious
to
try
a
project
moving
everything
that
I
possibly
can
into
a
different
directory
and
see
what
that
experience
is
like,
because
I'm
guessing
it's,
maybe
not
going
to
be
great.
D
C
So
if
we
want
to
look
for
precedence
and
the
rc
package
is
very
widely
used,
so
the
thing
that
I
linked
in
my
issue
in
the
slack
channel,
I
copied
straight
from
the
rc
package-
I
made
a
couple
of
small
changes
based
on
you
know.
The
fact
that
I
didn't
want,
like
I
was
trying
to
make
something
that
just
loaded
I
and
I's
not
tries
all
these
different
extensions
and
file
types,
but,
like
I
think,
just
by
looking
at
popular,
you
know
downloaded
npm
packages
for
config
loading.
C
That's
where
I
think
that
a
package
that
just
implements
the
new
lookup
algorithm
whatever
that
is
you
know,
and
then
we
just
go
to
them
and
say,
look
in
your
next
major
version.
Can
you
just
switch
to
this?
I
know
it
might
change
some
of
the
semantics,
but
it's
going
to
add
the
dot
config
directory
to
all
your
lookups
and
then
from
there.
It
should
be
just
a
matter
of
then
getting
projects
to
start.
Moving
to
this
pattern
like
to
me,
that
seems
like
a
pretty
straightforward.
C
B
C
Like,
but
this
is
why
I
was
saying
the
the
thing
that
caused
the
fragmentation
is
not
where
do
you
look,
they
all
support
the
same.
Damn
places
the
op
the
problem
and
the
cause
of
fragmentation
is:
how
do
you
load
them?
What
do
you
do
with
them
once
you
load
them,
so
all
these
packages,
like
rc
and
cosmic
config,
and
they
all
do
stuff
with
them
after
right,
but
they
all
look
in
mostly
the
same
places.
Obviously
slight
differences
across.
F
So
I
think
a
lot
of
so
let
me
just
quickly
address
the
thing
about
prettier.
I
think
the
reason
prettier
does
not
expose
a
flag.
Is
that
normally,
you
would
not
have
multiple
prettier
configurations
per
repository
right
so
for
things
like
semantic
release,
where
you're
loading
shared
configs
across
many
projects,
because
that's
what
you
do
for
something
like
eslint,
where
different
folders
might
have
different
settings.
Maybe
prettier
has
some
of
that
as
well,
but
something
like
I
I
don't
know
webpack
configurations
like
you're
bound
to
have
multiple
of
those.
F
I
I
also
think
that
trying
to
address
that
by
defining
an
algorithm
or
a
new
module
for
people
to
use
is
also
probably
going
to
have
slower
traction
than
simply
because
most
of
these
packages
are
already
loading
are
already
checking
multiple
locations.
They
would
probably
check
a
dot
something
dot,
something
rc
dot,
something
rc.json
something
something.config.js
or
right.
So
so
you
would
have
a
bunch
of
those.
So
then,
it's
just
a
matter
of
it's
already
an
array.
Ideally
maybe
it's
just
a
matter
of
pushing
an
extra.
C
I
have
read
the
source
of
a
bunch
of
these
very
recently
and
I
am
not
entirely
sure
it
is
that
easy.
I
agree.
It
would
be
hopeful
that
it
would
be
that
easy,
but
a
lot
of
them
do
some
stuff,
which
is
fine.
They
should
be
able
to
do
that
stuff.
That's
sort
of
more
wild
like
if
this
file
exists,
then
merge
it
with
that.
If
it
has
this
key,
then
instead
do
this
other
behavior
like
again
it's,
but
it's
all
about
what
they
do
with
the
files.
B
Maybe
maybe
it's
best
to
like
move
on
and
we
can
kind
of
continue
this
discussion.
Maybe
on
slack
come
up
with
a
plan
I
mean
ben.
You
mentioned
yeah.
You
are
doing
some
work
in
in
yards
right
now,
so
maybe
that's
a
good
guinea
pig.
C
And
one
last
point
on
that
when
you
move
them,
one
of
the
things
that
jordan
harbor
and
brought
up
was
that
does
it
apply
to
the
directory
as
if
it
was
a
nested
config
or
not.
So
make
sure
you
test
out
those
particular
behaviors,
because
that's
the
thing
where
I
think
they
will
all
be
broken
from
having
read
emotions
of
the
source
code,
I
think
they're
all
going
to
break.
F
Just
this
very
small
request,
I'm
probably
not
on
the
channel
and
I'm
not
sure
if
I
want
to
join
the
channel
because
yeah
there's
should
we
create
a
new
issue
to
get
away
from
the
hackiness
thread
specifically
to
solve
the
overarching
problems.
G
I
I
actually
had
even
the
broader
suggestion-
maybe
this
discussion
all
together,
especially
given
the
argument
from
west
that
maybe
this
is
like
education
with
other
package
maintainers.
Maybe
this
issue
should
be
moving
entirely
to
the
package
maintenance
working
group,
given
that
it
might
become
more
of
a
hands-on.
B
C
I
don't
know
if
it's
the
right
answer
right.
I
think
I
think
the
job
of
the
package
maintenance
working
group
is
to
help
evangelize
once
this
group
and
all
of
the
tools
have
made
a
general
direction,
maybe
not
decision
but
guidance.
You
know,
like
the
package
means
working
group's
best
quality
is
that
we
can
go
to
all
these
people
and
say
like
let's
collaborate
on
getting
this
effort
done
and,
and
you
know
and
whatnot,
but
like
this
particular
issue,
I
don't
think
we
even
have
a.
What
are
we
even
recommending
decision
yet.
A
All
right
so
yeah,
let's
let's
move
on
for
now,
so
the
next
one
is
recur.
Recursive
file
system
operation.
So
this
seems
to
me,
like
it's
kind
of
the
the
larger
discussion
around
you
know
what
apis
are
we
looking
at
that
that
we
might
want
to
change
and
then
what
should
our
strategy
be?
A
For
for
how
those
api
should
look-
and
you
know,
as
ian
said
earlier
in
the
meeting-
that's
a
good
topic
for
a
deep
dive
session
and
unless
anybody's
got
something
like
burning
that
they
want
to
say
about
this.
A
I
think
maybe
we
we
could
move
on
and
and
come
just
come
back
to
it
during
the
deep
dive.
A
All
right
ffi,
as
I
recall
this
is
brian's
thing.
Is
there
anything
on
that
that
that
we'd
like
to
talk
about.
E
There's
there's
basically
nothing
new
at
this
point,
just
I
guess
a
small
update
here
is
that
gus
kaplan
is
working
on
the
fast
api
calls
api
in
v8
and
that
should
hopefully
end
up
being
more
friendly
to
the
kind
of
stuff
that
we
want
to
do
here.
So
yeah,
that's
kind
of
it.
At
this
point.
A
A
A
All
right
sweet
so
we'll
do
that
and
that's
that's
on
me
to
schedule
it
recommendation
for
tooling
config
file,
location
format.
This
should
be
removed
from
agenda.
I
think
that
is
that's
kind
of
like
out
of
scope.
The
way
it
was
presented
so
next
one,
the
chmod
r.
B
A
I
I
mean
I
was
under
the
impression
that
that
darcy
had
intended
to
to
do
this,
and
it
was
also
under
the
impression
that
somebody
was
going
to
work
with
him
on
it.
Maybe
roy,
I
don't
know.
G
G
Quick
session
with
versus
at
some
point.
D
A
Okay,
all
right,
yes,
a
module
reloading
in
module
graph.
I
I
I
think
we
still
need
to
like
get
into
a
modules
meeting.
Is
that
right,
ben
for
this
thing
and
just
kind
of
crash
it
and
be
like
we
need
this
thing
or.
D
Yeah,
I
was,
I
was
saying
the
last
meeting
basically
like
I'd
like
us
to.
I
would
like
us
to
pick
a
specific
problem.
I
would
even
maybe
potentially
before
we
crashed
a
meeting,
pick
a
specific
problem
and
see
where
we
hit
a
wall,
so
we
come
in
and
say:
look
we
tried
to
do
this
and
it
doesn't
work.
How
do
we
make
this
work
and
I
think
the
problem
that's
most
compelling
is
maybe
proxy
choir.
D
A
Right
so,
if
you're
unfamiliar
with
it's,
what
it
is,
it's
it's
module
level
mocking.
So
you
know
you
might
use
a
a
program
or
a
little
library
with
stubs
and
spies,
or
a
test
run
with
stubs
and
spies,
and
you
might
look
at
an
object
and
you
might
stuff
about
a
function
and
that's
all
cool
and
good.
A
But
when
you
do
stuff
like
that
it,
it
will
potentially
do
unintended
things
like,
for
example,
if
you
want
to
stub
like
process.stdout.right
or
something
like
that,
that's
going
to
have
probably
far
wide-ranging
effects
other
than
your
particular
unit
test,
and
so,
instead
of
this
using
a
rewire
mock
or
a
proxy
choir
type
library,
you
swap
out
the
entire
like
module.
A
So
I
guess
that
doesn't
work
for
process,
because
that's
a
global
but
like
if
you
wanted
to
stub
like
fs,
wright
or
something
you
would
you
would
stub
out
fs.
You
would
give
it
like
a
phony
write
implementation,
and
maybe
you
would
use
a
stub
for
that
implementation.
A
But
it's
just
it's
swapping
out
entire
modules
for
other
ones
and
there's
lots
of
different
ways.
You
can
do
it.
You
can
make
it
so
only
your
test
case
that
that
wants
this
file,
only
your
test
case
that
that
loads,
a
module
and
that
module
wants
to
file
and
they
only
get
the
fake
file,
but
any
other
part
of
your
system
that
might
be
loaded
at
the
same
time
gets
the
real
one.
And
so
you
can.
You
can
kind
of
like
limit
things.
You
can
stub
modules
and
and
pass
everything
through.
A
So
you
only
you
have
like
the
real
module
but
you're
just
just
stubbing
out
like
one
part
of
it
or
you
have
stuff
like
checking
to
see
if
you're,
using
a
module,
like,
I
said,
like
enforcing
isolation,
so
you
can
say:
okay,
we
are
going
to
only
use
this
one
module
and
if
our
module
uses
anything
else,
that's
outside
of
like
this
white
list
anywhere
down
the
line,
then
you
can
break
the
test,
and
so
you
can
enforce
isolation
that
way
where
everything
must
be
mocked.
A
But
it's
like
all
these
things.
You
can't
do
any
of
these
things
like,
because
you
can't
you
can't
like
easily
reload
a
a
module.
You
can't
knock
it
out
or
require
cash.
You
can't
cause,
you
know,
require
file
to
actually
load
the
file
again
and
and
return
that
module
a
different,
a
different
object.
A
So
that's
what
you
can't
do
and
I
think
that's
a
good,
a
good
use
case
and,
like
I
know,
there's
like
a
hack
around
this
that
gill,
I
can't
remember
his
name
gil.
I
should
know
his
name
he's
a
maintainer,
but
he
he
published
like
a
blog
post
with
a
hacker
on
this,
where
you
can
actually
pull
this
off.
It's
like
it's
a
nasty
nasty
hack
but
like
how?
A
How
do
we
like
stop
people
from
having
to
go
to
these
lengths
and
and
then
there's
also
the
other,
the
other
point
of
well,
even
if
you
do,
are
we
able
to
reload
a
module
you
you're
just
going
to
leak
memory
because
there's
no
way
in
v8
to
actually
like
discard
a
module.
A
So
I
mean
that's
another
can
of
worms,
but
we
should
start
with
just
kind
of
making
it.
So
it's
not
not
such
a
headache
to
implement.
D
I,
I
think,
that's
perfect.
I
think
if
that
blog
post
already
exists,
I
didn't
know
about
that.
Then
that
would
be
like
a
good
like
really
understand
that
fully
and
then
come
and
say
like
look
at
these,
like
you
said,
look
at
these
links,
we're
going.
Is
there
a
way
we
can
make
this
easier?
I
think
that's
a
worthwhile
conversation.
A
Yeah
guilt
guilt,
I
don't
know,
pronounced
it's
tr
t
t-a-y-a-r
and
he's
got
a
blog,
I'm
not
sure
where
that
that
particular
post
is
linked,
but
I've
seen
it
maybe
even
in
the
issue
somewhere
but
okay.
So
I
think
yeah
going
with
that
to
the
modules
team
might
might
be
good.
I'm
I'm
wary
of
of
just
posting
an
issue
with
that,
but
you
still
want
to
just
do
the
meeting
then.
D
A
Okay,
so
can
we
like
offline,
let's
find
a
meeting,
we
can
both
attend
all
right.
Okay,
does
anybody
have
anything
else?
They
want
to
say
about
this
stuff.
A
All
right
next
one
is
support
for
hooking
spawn
and
spawn
sync
without
patching.
A
I
mean
I
know
some
of
us
are
like
stephen
who's
here,
sometimes
is
involved
in
that
discussion.
I
don't.
I
don't
have
any
visibility
into
it
right
now,
I
haven't
been
paying
any
attention
to
what
they're
doing
over
there.
Brian
do
you
know
anything
about
this.
E
D
One
action
item
we
had
from
the
last
meeting
was
that
we
should
make
sure
we've
talked
to
stephen
bellinger
to
so
that
they
know
that
like
spawning
is
one
of
the
things
we'd
like
to
be
able
to
be
able
to
do
with
these
ultimate
mega
hooks,
because
it
might
be
that
his
use
cases
are
different
than
our
use
cases.
So
just
make
sure
we
communicate
that.
A
Okay,
yeah,
I
think
he
probably
does
but
yeah
we
should
make
sure.
Okay
next
is
the
good
old.
A
better
way
to
detect
a
process
is
exiting
again.
I
feel
like
this
is
the
same
thing
essentially,
and
I
remember
at
some
point
corey
said
he
was
he
had
something
that
was
working
for
now,
so
I
think
it
wasn't.
D
E
D
I
think
it
is
important,
and
maybe
we
can
there's
like
some
really
weird
code
in
the
node.js
codebase
for
test
coverage,
which
works,
but
it's
kind
of
we've
created
an
exception
for
it
with
hooking
into
exit,
and
it
would
be
nice
if,
instead
of
there
being
a
weird
exception
for
coverage,
that
any
tooling
could
do
something
similar.
But
maybe
we
can,
if
that's
covered
by
a
hook,
then
maybe
we
could
switch
out
the
hack
we
have
for
coverage
for
a
hook
as
well
or
something.
You
know
what
I
mean
yeah
so,
but
I
don't
know.
B
So
there
was
something
we
talked
about
in
the
last
meeting
ben
was
actually
saying
we
should
maybe
remove
that
from
the
agenda,
but
I
did
bring
up
one
point
I
was
hoping
brian
would
be
their
last
meeting,
but
he's
here
now.
So
this
is
something
I'm
very
interested
in
at
work.
We
use
typescript.
B
We
also
use
datadog
for
all
of
our.
You
know,
traces,
logging
type
stuff,
and
so
that's
somewhere,
where
we
like
very
much.
You
know
we
get
stack
traces
they're,
the
compiled
javascript
stack
trace,
which
is
not
very
useful,
so
I'm
very
much
interested
in
enabling
this
feature.
B
In
that
context,
the
the
possible
issue
that
I
brought
up,
though,
is
like
the
format
that
ben
kind
of
used
for
the
stack
trace.
Is
it
interleaves
lines
of
like
your
javascript
and
your
typescript
in
the
stack
trace?
So
I'm
not
certain
if,
like
other
tools
out
there
like
datadog
or
sentry,
or
whatever
other
kinds
of
tools
like
that,
are
actually
going.
E
E
B
Yeah,
I
think,
like
some
tools,
let
you
upload
your
source
maps
to
go
along
with
the
code,
which
is
fine,
although
having
to
do
that
in
all
of
your
tools
and
adding
that
like
build
step,
whatever
is
kind
of
annoying,
so
the
built-in
source
map
support
is
really
interesting
in
that
context,
but
yeah
it's
just
the
way
that
it
actually
formats
the
stack
trace
where
it's
like
here's,
the
line
of
javascript
here's,
the
line
of
typescript,
here's
the
next
line
of
javascript,
here's
the
next
line
of
typescript,
I'm
not
sure
if
that
is
going
to
be
supported
properly
in
in
certain
tools.
D
B
D
D
I
never
added
up
in
the
last
meeting
like
there
is,
I
know,
tc39
is
trying
to
standardize
on
the
stack
trace,
parameter
on
errors.
I
believe-
and
I
think,
like
part
of
the
problem
is
there's
no,
that's
not
a
standard
property.
How
you
do
stack
traces
like
like
v8.
Does
it,
but
it's
not
really
standardized.
D
So
there's
not
really
like
a
definition
of
this
is
what
an
error
message
should
look.
As
far
as
I
understand,
there's
not
really.
A
definition
of
this
is
how
an
error
message
should
be
printed
such
that
the
parser
can
then
print.
The
error
message
like
a
lot
of
it
is
just
people
have
tended
to
follow
certain
conventions
yeah,
I
don't
know
like
like.
D
I
guess
I
guess
the
point
I'm
making
is
that
it
would
be
neat
if,
if,
if
we
actually
did
reach
a
kind
of
consensus
on
what
an
error
message
should
look
like
and
then
maybe
we
could
shift
nodes
approach
to
doing
the
stack
traces
to
match
whatever
that
consensus
is
yeah,
the
error
message
is
basically
interleaves.
It
basically
shows
right
now
for
human
readability,
brian.
It
basically
shows
like
the
the
original
call
site
and
then
the
sorry.
D
It
shows
the
re
the
call
site
in
context
of
where
the
error
happened
in
javascript
and
then
the
original
call
site
with
respect
to
the
typescript
file
or
with
respect
to
the
jsx
file
or
whatever.
So
you
basically
have
this
stack,
that's,
but
it
does
it
in
a
kind
of
a
human
readable
way
where
we
like
error,
then
one
line
below
it,
I'm
putting
it
in
chat,
it'll,
be
like
okay,
here's
the
error.
In
its
other
context
and
the.
G
D
Is
literally
there
yeah,
but
I
don't
know
like
to
your
point,
though,
like
you
would
definitely
need,
like
you
still
didn't,
need
to
have
either
the
source
maps
living
beside
the
stuff
or
inline
in
in
the
file.
So
you
don't
you
don't
necessarily
like
you
still
are
uploading
additional
data
right.
So.
B
Yeah,
I
mean,
I
guess
in
our
case
it's
we're
building
the
code
into
like
a
docker
container,
so
it's
very
easy
to
just
add
the
like
typescript
flag,
to
also
build
the
source
maps
there,
whereas,
like
with
sentry,
for
example,
we
have
a
whole
other
like
build
step
in
ci
that
has
to
find
the
source
maps
upload
them
to
sentry.
Do
a
bunch
of
other
work
to
associate
it
with
the
release
and
everything.
B
I'm
here
cool
yeah
that
was
kind
of
why
yeah
I
was
hoping
to
talk
to
you
about
it.
I
will
yeah
try
just
enabling
it
and
see
what
happens.
I
actually
did
a
couple
weeks
ago,
but
it's
our
setup
is
a
little
bit
complicated,
and
so
I
wasn't.
I
wasn't
actually
getting
stack
traces
that
I
wanted,
but
I'll
give
it
another.
Try.
D
You
might
find
you
don't
get
anything
just
because,
well,
I
know
express
well,
it
might
work
with
express
actually.
But
but
if
something
overrides
the
stack
trace
generation
step,
it
can
cause
issues
for
you.
So
you
might
find
some
of
your
telemetry
libraries
have
like
overwritten
the
stack
trace
generation
method,
which
means
that
actually
you
don't
even
get
the
original
stack,
trace,
anyways
yeah,
so
so
try
it
and
see.
If
you
can,
if
you're,
if
the
area,
if
you're
missing
it
in
the
stack
trace
that
might
be
what's
happening,.
C
If
I
recall
correctly,
that
wasn't
just
an
express
issue
that
was
just
a
doug
maintained
module
outside
of
express
right.
We
should,
if
we
want
to
direct
people
that
wasn't
it
the
debug
module.
A
D
C
We
have
a
couple
folks
involved
in
that
as
well.
One
thing
I
think
that
is
interesting,
though,
is
that
just
standardizing
stack
traces
doesn't
really
help
when
you
have
transpilers
in
the
mix
anyway.
I
don't
want
to
go
off
on
that
topic
too
much
right.
But
if
you're
trying
to
show
like
the
topic
here
was,
it
shows
the
js
line
and
the
ts
line,
and
then
the
js
line
it
feels
like
well
you're,
never
going
to
that's,
never
going
to
fit
in
a
jazz
specification
for
tc39.
D
E
Oh
sorry,
there
certainly
could
be
room
for
extensibility
right
and
that
might
sort
of
answer.
D
Well,
yeah
yeah,
I
mean
this
is
kind
of
what
I
advocated
when
I
was
doing.
The
work
on
stack
traces
in
the
first
place
was
like
this
is
really
common
in
the
web
and
node
and
probably
like
any
other
javascript
runtime
that
transpilation's
common.
So
it's
very
common
that
your
stack
trace
is
going
to
have
a
call
site
and
then
an
original
call
site
so
having
that
built
in
would
be
good
like
and
that's
not
node.
You
need
that's,
not
typescript
unique.
That's
just
bundlers
typescript.
C
A
Okay,
so
right,
let's
move
on
argument
parsing
what
so
at
open
js,
collab
summit
or
something
or
the
opengs
world.
You
know
I
gave
this
talk
on
mocha
and
then
that
talk
on
mocha
I
had
a
very
like
dead,
simple
implementation
of
of
what
that
arc.
Parser
would
look
like
ben.
I
I
feel,
like
the
last
thing
that
we
said
on
this,
was
that
we
should
send
a
pr
at
this
point.
Is
that
true,
okay.
D
Yeah,
I
agree
with
that
and
I
think,
like
I'm,
really
excited
with
this,
because
I
think
the
most
excited
the
most
exciting
thing
on
our
potential
things
we
think
are
cool.
Is
the
like
python
style
running
like
rimrock,
for
running
mkdurr
as
a
command
line
flag
through
node,
which
I
think
needs
the
argument
parser.
A
We
need
to
send
a
pr,
I'm
probably
gonna,
be
so
if
you've
heard
me
blathering
on
slack,
I'm
working
on
trying
to
like
moco's
watching
files,
and
it
wants
to
know
exactly
which
test
files
to
rerun
if
a
file
changes
which
is
kind
of
yeah
and
anyway,
I'm
working
on
that,
and
so
it's
going
to
be
like
at
least
another
week,
probably
until
I
get
to
an
mvp
there,
at
which
point
I
could
probably
send
a
pr
to
do
this
for
the
yard
parsing,
unless
you
think
you
could
get
to
it
sooner
then,.
D
I
think
it's
just
really
important
to
make
sure
the
tone
is
like
this
is
a
tool
we
potentially
even
this
is
a
tool
we
potentially
even
want
to
expose
some
command
line,
oriented
stuff
in
node
itself
and
that
and
the
c-based
argument
parser
is
difficult
to
use.
This
is
not
us
saying
how
all
argument
parsers
should
work
in
the
community,
nor
is
it
us
trying
to
replace
all
argument.
Parsers,
I
think,
is.
I
think
we
need
to
be
very
careful
that
that's
how
we
frame
this
and
that's,
I
think,
an
accurate.
D
A
D
More
pressing
I've
been
doing
this
work,
or
I
think
I
mentioned
it
in
chat.
Maybe
I've
been
doing
some
work,
trying
to
target
esm
and
cjs
at
the
same
time,
using
roll
up
and
typescript,
it's
been,
it's
felt
a
little
bit
like
uncharted
territory,
and
I
was
wondering
if,
if
folks
have
had
what
other
people's
experiences
have
been
in
this
does
anyone
else
want
to
look
at
my
pr,
basically,
is
what
I'm
asking
and
see
how?
D
Maybe
it
will
be
interesting.
A
few
people,
and
maybe
you'll,
have
some
different
directions
for
how
maybe
I
should
approach
things
because
I'm
like
I
know,
yarg's
is
used
by
tons
and
tons
of
people.
So
it's
all
well
and
good
to
try
to
do
an
experiment
like
this,
but
I
want
to
be
really
careful
not
to
break
too
much
of
the
community
when
I
actually
start
shipping
it.
D
I
was
talking
about
michael
rogers
about
this,
and
he
and
like
as
soon
as
you're,
targeting
esm,
you
can
actually
publish
to
both
packet
register
package
registries,
so
I
thought
I'll
try
it.
The
actual
more
difficult
thing
is
targeting
cjs
at
the
same
time,
because
you
end
up
having
these
conditional
exports
and
you
end
up
kind
of
doubling
your
bundle
size,
because
you
have
now
cgs
code
and
esm
code
in
your
in
your
code
base
which
are
incompatible.
So
you
know
it's
been
kind
of
a
wild
ride.
D
I
love
if
anyone
else
has
run
into
this
I'd
love
feedback,
but
I'm
hoping
within
I
mean
I'm
hoping
to
have
a
build
of
vpr.
That
would
be
able
to
target
esm,
maybe
by
the
end
of
the
weekend,
like,
I
think,
I'm
kind
of
on
the
path
to
the
refactor.
C
I
have
a
question
because
this
is
something
I've
been
looking
at
lately,
because
we've
talked
a
bunch
about
moving
express
modules
into
scopes
and
one
of
the
big
setbacks.
I
say
setbacks.
It's
not
really
that
difficult,
but
like
we.
We
think
we
need
to
slowly
migrate
people
right
and
to
do
that,
we
would
need
to
probably
dual
publish
I'm
wondering
if
we
had
a
good
set
of
tooling
for
dual
publishing.
Would
this
get
rid
of
a
lot
of
these
dual
module
problems
like?
C
That
would
enable
this
and
it
could
enable
it
for
both
these
kind
of
dual
module
purposes,
but
also
for
just
like
literally
the
fact
that
we
want
to
migrate
like
the
babel
migration,
which
is
just
super
painful
for
everybody,
which
was,
oh
sorry,
babel,
six
or
whatever
change
every
single
import
across
your
entire
project.
C
Right
if
it
was
just
like,
oh
well,
babel
six
is
dual
published,
one
under
the
at
babel
scope
and
one
under
the
existing,
but
breaking
change
and
we're
gonna
deprecate
the
old
one
and
move
to
the
new
one
like
that
would
have
eased
that
transition.
If
we
had
some
tooling
in
that
space,
it
might
solve
both
of
these
problems.
All
at
once
do
you
feel
like
that
would
be
a
good
direction.
D
I
think
I've
definitely
thought
about
this,
and
I
mean
this
is
longer
than
a
two-minute
discussion,
so
we
should
bring
it
to
chat
or
but
no
this
has
crossed
my
mind.
I
was
I'd
also
even
thought
of
like
what,
if
you
had
an
mpm
disk
tag
for
esm
and
an
mpm
disk
for
cjs
and
like
you,
could
literally
install
and
they
just
had
different
suffixes
on
the
the
version
number
or
something
like
so
no,
I
don't
think
it's
out
of
left
field
at
all.
D
Like
it
crossed
my
mind,
I
was
gonna,
see
what
I
could
get
yards
bundle
size
down
to
like
if
I
can
still
be
in
within
10
or
20
percent
of
the
current
size
and
dual
and
b
dual
mode.
Maybe
that's
an
okay
route
to
go,
but
if
it's
like
doubling
the
package
size,
maybe
it
does
make
sense
to
publish
it
to
two
different
places.
So
I
don't
know.
I
think
it's
a
good
conversation
to
have.
C
E
C
Would
be
a
really
cool
conversation
as
an
npm
rfc,
also
for
what
it's
worth.
I
just
built
this
tool
internally
because
we're
migrating
a
bunch
of
scopes
internally,
so
I
have
a
thing
that
accepts
dis
tag,
registry
version
and
package
name
and
then
we'll
create
a
branch
and
publish
multiple
versions,
and
it's
just
like
one
command.
So
if,
if
you
all
think
that's
something
that
would
be
worth
working
on
in
open
source
land,
I'd
I'd
be
happy
to
figure
out
how
to
extract
what
I
have
internally.
C
G
G
So
yeah
with
that
ben
sure,
don't
I
just
have
one
last
announcement.
G
Actually,
we
are
going
to
be
releasing
the
beta
version
for
v7
next
week,
so
we
haven't
made
an
announcement
yet
so,
but
you
can
right
now
you
can
npm.
I
dash
g
npm
at
next
seven
and
then
you're
gonna
get
the
current
like
better
version
already
so
yeah,
especially
this
group.
If
you
can
try
it
in
your
project
and
like
send
some
feedback,
especially
if
there's
something
like
terribly
broken,
it'd
be
nice
to
know
before
the
announcement
on
monday.