►
From YouTube: Node.js Tooling Group Meeting 2021-04-30
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
Okay:
let's
get
started,
hey
everybody.
This
is
the
node.js
tooling
meeting
it's
friday
april,
30th
yeah,
let's
get
started
what's
what's
first
on
the
agenda
here,
I
guess:
does
anyone
have
any
announcements
or
anything
before
we
get.
B
A
Yeah
I
mean
I
can
think
of
one
thing,
that's
kind
of
related.
I
don't
know
if
we
should
talk
about
it.
B
Yeah,
are
we
talking
about
package
manager,
manager.
A
Yeah,
that
is
kind
of
related
yeah.
I
was
interested
in
the
outcome
of
that
vote,
so
they
decided
not
to
package
yarn
one
with
node,
but
they,
it
seems
like
there's
a
lot
of
support
to
include
core
pack.
It's
called
now,
which
would
provide
like
shims,
basically
for
installing
yarn
or
pnpm
or
npm
or
whatever
I
guess
npm
is
still
gonna,
be
bundled
anyways.
I
was
interested
in
the
outcome
of
that
decision.
I'm
happy
with
the
direction.
B
I'm
curious,
which,
if
you
I
don't
know,
maybe
it's
not
something
I
mean.
C
It's
more
on
the
technical
implementation
of
the
actual
tool
and
also
the
lack
of
definition
around
what
a
man
like
managed
packages
so
essentially
there
it
creates,
and
if
you've
played
with
it
a
bit,
it
actually
introduces
a
number
of
new
capabilities
that
actually
might
be
a
bit,
in
my
opinion,
harmful
to
those
communities
in
terms
of
switching
between
tooling,
especially
given
that
they've
actually
introduced
a
new
field
package
manager,
which
will
essentially
gate
and
is
pretty
anti-competitive.
In
my
opinion.
D
C
So
the
ownership
of
that
registry,
how
it
stays
up
to
date,
is
also
in
question.
So
I
think,
there's
a
number
of
questions
that
I
don't
think
they
answered
and
I
think
the
tsc
I'm
not
sure
why
you
know
we
we
for
the
record,
like
I
think,
a
lot
of
us
on
our
side
sort
of
stayed
out
of
a
lot
of
that
conversation,
but
I
still
have
quite
a
bit
of
feedback
to
give.
C
A
C
Out
a
hundred
percent,
we
had
a
binary
summit.
I
forget
when
it
feels
like
forever.
C
Like
guys,
comment
on
time
is
irrelevant
these
days,
it's
just
a
figment
of
our
imagination.
We
had
a
binary
summit
where
we
talked
about
tooling,
like
volta
and
and
nbm,
and
in
which
case
we
were
talking
about
how
people
might
customize
their
distributions
and
and
like
you
know,
swap
in
and
out
things
that
they
want
to
be
bundled
in
in
their
version
of
node,
and
this
is
a
subset
of
that.
This
is
only
scoped
like
this
tool
is
only
scoped
to
to
these
packages.
So
I
don't
know
if
this
gets
us
all.
C
I
I
I
don't
know
what
this
gets
us
since
it
sounds
like
we're.
Gonna
have
to
create
another
tool.
On
top
of
this,
to
manage
those
other
depths
that
are
bundled
in
node,
so
it's
it.
It
goes
against
sort
of
what
I
thought
the
outcome
was
of
that
binary
settlement
based
on
the
fact
that
it's
it's
yeah,
managing
a
subset
of
what
we
were
talking
about
and
then
also
I
feel
like
they.
C
There
was
a
whole
bunch
of
things
that
essentially
were
agreed
upon
to
by
saying
that
they
want
to
add
court
back
like
including
all
the
things
that
I
referenced
there
so
anyways,
not
that
I
dive
into
that
too
much,
but
I
I've
been
meaning
to
like
write
up
a
full
synopsis
of
that
and
and
tried
to
be,
as
obviously
as
as
mindful
of
the
position
to
make
sure
that,
like
it
doesn't
come
off
as
I
I
just
don't
know,
if
it's
a
great
thing
for
those
communities
to
be
honest,
like
especially
the
way
it's
shipped
with
the
jumper
binaries
like
those
are
very
confusing,
and
this
will
actually
break
npm
installs.
C
So
if
we
see
that
there's
a
binary
already
placed,
we
are
not
going
to
we're
not
going
to
try
to
override
it.
So
if
you
try
to
mpm
install
yarn
and
we
it's
already
been
placed
by
node,
we
no
longer
manage
crnpmpm.
So
that's
going
to
be
confusing
for
the
community.
That's
going
to
be
a
problem
for
the
community,
that's
going
to
create
some
churn
and
I
yeah
anyways.
Sorry.
B
B
C
B
B
A
Yeah,
I
mean,
I
think
it
does
need
to
be
approached
cautiously,
though,
for
sure,
okay,
let's,
I
guess,
move
on
to
the
agenda
actually.
First
item
on
the
agenda.
Speaking
of
things
that
need
to
be
approached
carefully
after
a
meeting
last
week,
I
created
an
issue
we
had
discussed.
A
The
idea
of
you
know
maybe
creating
an
eslint
plug-in
or
adding
to
the
nodes
plug-in
or
preset
to
flag
certain
things
like
you
know,
if
you're
importing,
like
rimraf
or
something
in
node
16,
you
know
just
to
highlight
that,
like
hey,
that's
actually
built
in,
you
probably
don't
need
that,
but
there
was
some
interesting
discussion
in
that
issue
primarily
from
jordan,
and
he
was
just
pointing
out
that,
like
yeah,
there
are
definitely
some
some
things
to
consider
in
doing
that
as
well.
A
Like,
for
example,
you
know
it
does
that,
does
that
de-incentivize
someone
to
keep
maintaining
you
know
a
package,
that's
been
pulled
into
core.
Is
that
the
intended
effect?
You
know
we
just
need
to
if
we
were
to
do
that,
consider
all
of
those
things
and
be
very
careful
about
it.
So
I'm
not
I'm
not
sure
if
it
is
something
we
should
do
or
not.
B
Yeah,
I
I
wonder,
and
and
this
is
part
of
the
reason
why
I
had
reached
out
to
kai.
So
I
don't
know
if
you
want
to
maybe
just
give
a
little
bit
more
context
and
we
can
kind
of
discuss
a
little
bit
further
or
yeah
or
whoever.
A
Sure
yeah
I
mean
the
general
idea
like,
as
I
kind
of
gave
in
that
one
example
is
like
we
pulled
a
couple
things
like
make:
derp
rimrath
we're
talking
about
one
of
the
recursive
copy
implementations.
B
Are
basically
sorry
to
interrupt?
I
was
just
gonna
elaborate,
like
these
are
packages
that
somebody's
already
built
that
provides
us
functionality,
we've
taken
that
functionality
brought
into
core
and
we
want
to
let
people
know
like
you,
don't
need
to
use
this
package
if
you
don't
want
to
because
it's
native
to
node.
A
Right
yeah-
and
this
is
something
we
talked
about
this-
I
think
actually
in
montreal
in
the
we
had
a
tooling,
you
know
roundtable
kind
of
meeting.
I
think
it
came
up
as
an
idea
there,
something
that's
been
on
the
back
of
my
mind
for
a
while.
A
Actually,
the
reason
that
I
brought
it
up
last
week
is
because
I
was
reading
a
book
like
a
new
book
about
node,
where
they
were
talking
about
node
15,
I
think,
was
referenced
and
in
one
of
the
examples
the
the
author
like
pulled
in
make
derp
to
recursively
create
a
directory.
A
A
Of
this,
so
yeah,
that's
kind
of
the
context
is
that
something
we
want
to
do.
Is
that
not
something
we
want
to
do?
It's
also
been
discussed
as
like.
Is
that
something
that
you
know
the
npm
cli
flags
when
you
install
one
of
those
packages
or
do
we
leave
it
up
to
the
package
author
to
add,
like
a
post,
install
notice
that
brings
that
up?
So
these
are
kind
of
all
the
things
we're
talking
about.
B
Yeah,
the
post
install
seems
to
make
sense
to
me,
like
a
natural,
you
know
and
and
most
friendly
to
maintainers
sort
of
approach.
C
Yeah
the
package
isn't
being
deprecated
and
they're,
not
changing
their
support
level
like
based
on
what
jordan
had
said
there,
like,
especially
like
we
don't
want
to
disincentivize
package
maintenance,
especially
if
it's
not
a
one-to-one
implementation
like
there
might
still
be
usefulness
in
a
package
and
like
yeah.
I
think
I
said
it
before
when
we
brought
up
last
week,
maybe
or
the
week
before,
that,
it's
just
we
want
to
be
mindful
that
we're
not
like.
C
There
is
any
like
hurt
feelings,
a
long
way
here
like
in
terms
of
like
we
pulled
this
in
and
now
we're
like
recommending.
Don't
use
that
like
that
package
like
it
seems
a
little
bit
odd
because,
like
these
two
things
should
be
distinct
and
different,
they
really
don't
have
that
much
of
a
connection
like
dude
like
like
we're
making
a
connection
between
them,
but
are
they
actually
a
one-to-one
mapping?
Like?
Is
the
package
the
exact
same
in
node
core?
I.
A
Think
in
some
cases,
yes
and
in
some
cases
no
so
yeah,
definitely
that's
a
consideration.
I
think
that
the
intention
like
from
my
perspective,
is
more
just
like
how
do
we
raise
awareness
that
these
things
are
now
available
and
don't
necessarily
require
installing
a
third-party
package
like
they're
in
the
docks
and
that's
great
but
sorry
kyrie?
You
know.
E
Say
something:
oh,
I
was
just
going
to
say
that
I
I
don't
think
that
eslint
like
the
linter
is
the
right
place
to
to
do
this.
At
least
you
know
as
an
official
contribution
from
from
node
itself
that
feels
a
little
bit
like
it'd
be
different
if
it
was
a
community
member.
Just
being
like.
E
Oh,
like
I'm,
going
to
add
this
tool
to,
you
know,
make
a
pr
to
mysticates
esl
plugin,
because
there
is
like
no
deprecated
something
or
a
rule
already
in
there
that
actually
flags,
deprecated,
syntax
for
or
deprecated
apis,
in
whatever
version
of
node
you're
using.
I
do
like
the
idea
of
the
posted
install
script
or
just
like
leaving
it
up
to
the
the
community
in
that
case,
but
also
totally
see
the
the
merit
of
trying
to
you
know,
increase
education
and
awareness.
E
I
just
don't
know
if
the
the
linting
steps
since
it's
you
know
hooked
into
ci
and
can
prevent,
builds,
and
you
know
everything
else.
I
don't
know
if
that's
the
place
to
do
that
personally,.
C
I
think
ben
noted
like
it,
would
be
amazing
that
lists
by
doing
it
through
eslint.
We
could
easily
create
a
path
for
you
to
upgrade
all
like
or
change.
Let's
say
your
entire
project
over
from
one.
C
You
know
from
that
specifically
including
the
package
to
utilizing
the
native
built-in
right
so
like
that
was
kind
of
like
one
benefit
in
going
this
red,
I
believe
and
then,
which
makes
sense,
but
I
do
like
I
do
kind
of
agree
that,
like
it
should
almost
be
like
I
don't
know,
I
don't
know
like
I
feel
like
the
maintainer
should
be
brought
along
this
journey
and
like
like.
C
Maybe
it's
up
to
them
to
like
push
you
to
do
that
or
like
we
somehow
get
buy-in
from
them
to
create
the
insulin
plug-in
specifically
for
that
package
right,
and
so
we
create
one
of
these
for
every
every
time
like
we
pull
in
something
like
mcderp
and
we're
like
hey,
can
we
reach
out
tell
the
maintainer
that
we're
also
considering
creating
like
a
eslant
plug-in,
that's
going
to
make
it
easy
for
people
to
transition
to
the
native
and
and
if
they're,
okay
with
that,
then
maybe
we
move
forward,
but
I
I
don't
think
we
should
move
forward
if,
like
somebody
feels
like,
like
you
know,.
A
Yeah,
but
I
was
brought
up
last
time
too
just
that
yeah
we
would
probably
want
to
get
buy-in
from
the
maintainer
first
before
doing
it,
but
at
that
point
then
just
make
it
a
post-install
script,
maybe
or
they
could
in
their
package.
We
have
tried
both.
C
I
think
we
said
both
right,
like
the
the
both
is
the
optimal
right,
so,
like
anybody
that
doesn't
know
about
it
would
get
that
that
message,
but
also
like
having
a
tool
that
helps
you
migrate
and
like
audit,
is
also
good
to
have.
C
A
A
Yeah,
I
guess
to
me,
as
a
user,
the
frustration
there
is
like
I.
I
would
like
to
know
these
things
when
I'm
writing
my
code
and
it's,
I
guess,
frustrating
that
maybe
it
would
be
not
an
inclusive
kind
of
list
of
of
things
that
were
now
available
to
me
in
the
platform,
but
I
get
that
it's
also
a
very
you
know
it's
a
tricky
issue
for
sure
yeah.
E
No
go
ahead:
okay,
you're
free,
I
was
just
gonna,
say,
there's
also
the
friction
of.
I
think
it
increases
friction
in
that.
If
you
know
the
maintainer
does
release
like
a
security
release
or
something
and
you
decide
to
use
it,
then
you
have
to.
There
has
to
be
some
way
to
let
the
rule
know
whether
that's
an
eslint
ignore
comment,
or
you
know
something
in
the
config
to
opt
out
of
that,
and
that
that
does
seem
like
a
pain.
I
don't
know,
there's
just
extra
extra
work
involved.
C
Yeah,
I
think
the
what
I
was
thinking
before
in
this-
and
I
just
thought
about
it
again-
is
that
it
sounds
like
the
problem
is
we
have
packages
that
are
named
the
same
thing
as
a
native
utility
right
as
a
native
module,
so
packages
in
the
ecosystem
that
are
going
to
be
named
the
same,
and
we
don't
have
like
reserved
like,
like
the
concern,
might
be
that
even
you
don't
know
that
you're
like
requiring
or
you're
trying
to
require,
let's
say
a
depth
like.
C
Let's
say
you
phantomly
installed
mcderp
somehow,
because
we've
hoisted
your
packages
and
now
you
try
to
require
it
and
it
was
a
top
level.
I
think
mcderp
is
under
fs
right
so,
but
for
other
instances
like
crypto
or
other
kind
of
modules
that
have
gotten
created
there
might
be,
it
might
be
confusing
to
the
ecosystem.
If
there's
two
things
like
the
native
module
and
then
the
ecosystem
module,
I
think
npm
is
oftentimes
actually
given
or
gifted
those
name
spaces
back
to
the
project.
To
ensure
that,
like
that
confusion,
sort
of
goes
away.
A
For
example,
for
example,
make
derp
is
part
of
the
fs
maker
command
with
the
recursive
option.
The
rimrap
is
similar,
so.
E
E
Of
an
educational
asmr
plug-in
like
on
each
release
that
could
that
could
help
you
upgrade.
I
do
think
that's
that's
a
cool
idea
to
explore.
A
C
I
mean
that
plug-in
is
opt-in
by
the
maintainer,
like
you
are
saying
like
whoever
is
adding
that
to
your
rule,
set
is
saying
if
somebody
tries
to-
or
I
see
that
that
you're
using
if
they're
like
like
and
we
are
using
this
node
version.
We
know
that
like
it
should
be
that's
wrong
right,
so
it's
kind
of
like
at
the
project
level
somebody's
making
that
decision
and
opting
in
if
that
tool
exists.
If
we
create
that.
A
A
Yeah
really
the
goal
that
I
had
in
mind
with
this
was
just
how
do
we?
How
do
we?
Let
people
know
that
these
new
things
are
available?
Anyways?
I
don't
know
if
we're
gonna
solve
that
today
we
there
was
some
interesting
discussion
on
that
issue
after
our
last
meeting.
So
definitely
you
know,
as
I
mentioned
in
the
issue
like
we're,
we're
definitely
gonna.
You
know,
discuss
this
a
lot
more
before
we
move
forward
with
anything
we're
not
just
planning
to
to
do
this
so
yeah.
A
I
don't
really
know
what
the
outcome
there
like.
I
I
I
don't
see
like
a
path
forward
right
away.
At
this
point,
I
think
we
would
need
to
consider
it
a
little
bit
more
so
yeah
unless
anyone
has
anything
else
they
want
to
bring
up
on
that
topic.
I
would
suggest
we
just
move
on
to
the
next
point.
A
Okay,
all
right.
Sorry,
there's
some
construction
noise
inside
my
window,
okay,
what
is
next
recursive
copy
is
next
on
the
list,
which
I
guess
is
me.
I
have
no
update
on
this.
I
haven't
had
a
chance
to
to
work
on
this
since
the
last
meeting.
A
A
So
yeah
no
update
there
for
me
next
on
the
agenda
is
a
better
way
to
detect
a
process
is
exiting
which
ben
was
had
volunteered
to
take
on
he's,
not
here.
So
I
guess
we'll
just
skip
over
that
for
today,
oh
and
then
I
guess
up
next
is
him
as
well
with
source
map
v3
support.
I
don't
think
there's
any.
I
don't
know
if
that
needs
to
still
be
on
the
agenda.
Does
it
we?
A
A
If
we
could,
you
know
if
they
could
move
forward
with
back
merging
that
with
that
test,
failing
that
was
kind
of
where,
where
that
one
stood,
I
guess
yeah
since
ben's,
not
here,
I
guess
we'll
just
skip
over
that
as
well.
I
am
happy
that
source
map
support
is
in
note.
16,
though.
A
It
was
sort
of
like
an
interleaved
source
map
would
show
you
like
here's
your
line
of
javascript
and
then
below
would
be
like
here's.
Your
line
of
typescript
and
the
whole
trace
was
sort
of
in
that
format,
which
I
think
doesn't
really
match
the
I
don't
know
if
there's
actually
a
spec
for
stack
traces,
it
seems
like
there's
some
work
around
building
one.
A
So
that's
kind
of
the
change
between
14
and
16
is
in
version
16,
you
just
get
the
typescript
or
whatever
it
might
be
stacktrace,
which
seems
like
it
would
be
easier
to
consume
by
other
tools
like
datadog
or
sentry
or
whatever
so
yeah
anyways,
I
guess,
is
any
other
topics
of
discussion
on
the
node
16
front
from
anyone.
C
No,
I
guess
oh
one
announcement
that
we
missed
that
may
have
already
been
said
in
other
places.
Like
end
of
life.
Note
10
today,
announcement
like
that's
nice
to
know
in
case
you're
like
have
to
go
check
your
engines
of
your
packages.
Maybe
you
want
to
upgrade,
may
cut
a
major
or
something
and
stay
up
to
date
and
save
yourself.
Some
somehow
we're.
A
A
I
know
we're
definitely
planning
to
drop
node
10
support
and
create
react
app
in
the
next
major
release.
So
the
12
and
above.
A
D
C
A
To
to
get
all
of
that
stuff
out
of
the
way
so
that
we
can
spend
the
rest
of
the
meeting
talking
about
argument,
parsing
so
yeah
joe
take
it
away.
B
Yeah
I
mean
I
don't
have
too
much
of
an
update.
It's
been
a
crazy
couple
of
weeks,
my
son's
birthday
and
a
bunch
of
other
things,
but
I
did
today
create
some
issues
that
you
know
were
kind
of
born
out
of
that
first,
pr,
which
I
dropped
into
the
chat.
B
So
you
know,
if
I
I
I
did
it
partly
because,
like
jordan,
jumped
in
and
had
a
couple
of
comments-
and
so
I
didn't
want
to
just
you
know-
make
assumptions
about
what
choices
we're
going
to
make.
I
thought
I
would
just
create
issues
for
some
of
them.
So
if
you
look
at
the
issues
in
the
parse
args
repo
I'll
look
here,
you
know
what
do
we
want
to
do
with
three
or
more
dashes?
B
I
know
in
the
faq
the
the
the
idea
was
that
you
would
just
strip
off
the
first
two
and
pass
back
whatever's
left,
but
I
thought
I'd
open
that
just
for
you
know,
discussion,
establish
error,
message,
approach
which
I'm
not
used
to
writing.
Tooling
libraries.
So
if
anybody
has
any
suggestions
on
what
we
want
to
do
with
with
that
or
I
can
just
you
know,
we
can
just
have
the
messages
in
there.
It's.
B
I
guess
it's
not
going
to
get
too
complex
here,
so
I
can
just
take
out
my
whoops
and
put
something
else
more
informative
in
there.
Bennett
also
mentioned
like
how
to
handle
other
environments,
like
electron
ben,
had
suggested
c8
for
code
coverage
preference.
B
A
B
Yep,
okay,
cool:
I
will
do
that.
I
will
make
a
comment
on
this
particular
pr
and
land
it,
and
then
we
can
just
start
kind
of
tackling
the
issues
and
you
know
if
you
want
to
jump
in
feel
free
to
to
do
whatever
and
or
if
you
want
to
pair.
You
know
I'm
open
to
whatever.
A
Yeah
I'd
love
to
start
kind
of
chipping
away
at
this,
so
I
think
I
think
we
maybe
need
to
to
make
it
clear
too.
That,
like
this,
is
like
very
much
work
in
progress
right
like
we
shouldn't
be,
you
know
for
pr's
and
things
like
that,
it
shouldn't
be,
like
you
know,
nitpicking
every
little
detail
and
whatever,
because
like
yeah,
this
is
like
very
very
work
in
progress,
but
I
do
think
I
think
you're
on
the
right
track
here,
capture
the
feedback.
A
We
definitely
don't
want
to
ignore
the
feedback
yeah
capture
it
move
on.
You
know
we'll
we'll
address
those
changes
in
a
future
pr
or
someone's
welcome
to
make
a
pr
of
their
own
to
address
it.
If
they
want.
E
Just
so
I
understand
is
this
working
on
a
new
api
for
argument,
passing
arguments
on
the
cli.
A
Yeah,
sorry
darcy,
no,
the
the
idea
is
that
we're
trying
to
get
some
argument,
parsing
capability
built
into
node
and
so
yeah
we're
basically
building
like
darcy's
at
the
polyfill
here
first,
so
we
can
start
to
experiment
with
it
and
it's
a
little
easier
to
work
here
than
in
the
main,
node.js
repo,
so
yeah.
We
want
to
kind
of
get
it
into
a
place
where
we're
happy
and
then
you
know
open
up
a
pr
in
the
main
repo.
B
B
Cool
and
I'm
gonna,
I'm
gonna
open
a
quick
pr2
to
the
readme.
Just
to
add,
like
a
you
know,
early
work
in
progress
flag
at
the
top
so
that
it's
clear.
C
C
I
think
and
it's
all
beyond
for
another
mirror
through,
but
I
I
know
that
he
had
had
some
work
and
a
pr
ready
with
a
bunch
of
that
done
already
and
wondering
if
that
could
just
go
move
forward
by
itself,
and
then
we
can
pull
that
out
of
this
because,
like
it
seems
like
something
else,
we
should
track
separately
of
the
parsers,
even
though
they
are
very
much
tied
together
and
like.
We
want
to
use
the
main
args
value
if
it
exists
and
that's
like
the
implementation.
B
What
you're
saying
kind
of
rings
a
bell,
but
it's
not
clear
to
me,
but
my
I
also
would
ask:
is
there
an
issue
related
to
this?
That
should
be
on
the
agenda
and
we
can
discuss
or
what.
C
C
C
It's
like
immediately
telling
you
to
like
slice
thing
up
this
up,
because
there's
extra
extra
information
there
you
don't
care
about,
so
it's
like
main
args
would
be
exactly
you
know
the
set
of
arguments
that
we
actually
care
about-
and
that
is,
I
think,
can
move
forward
independently
of
this
and
and
I,
as
far
as
I
knew
and
unfortunately
roy's
not
here
to
like
let
let
us
know
where
that
went.
I
think
he
already
had
the
work
done
to
actually
support
that.
C
B
C
That's
just
the
yeah,
that's
just
within
the
readme
itself.
We
have
basically
two
definitions
of
of
things.
We
would
introduce
with
this
work
so
like
util.parsecs,
should
actually
be
leveraging
what
main
arcs
if
it
lands.
So
we
I
think
it
should
independently
of
parsons.
B
Yeah
and
it's
interesting
because
we
have
you
know
one
of
the
issues
I
created.
Oh,
where
am
I
I'm
in
the
wrong
thing
here?
Is,
I
think
you
know
this
was
mentioned
ben
said:
how
do
we
handle
other
environments
like
electrons?
So
maybe
that's
related,
because
I
think
you
know
he
was
saying
that's
the
suggestion
that
roy
had
made
in
chris's
pr
so
real
quickly,
kai
some
context.
B
There
was
a
lot
of
thought
that
went
into
this
work
and
chris
hiller,
who
was
a
part
of
the
tooling
team,
did
a
bunch
of
work
with
a
pr
to
node,
and
there
was
a
lot
of
conversation
and
some
like
blocking
comments
and
like
a
ts,
vote
needed
and
then
chris
kind
of
just
walked
away
and,
and
we
kind
of
stepped
back
that
pr
was
closed.
B
I
think
it's
linked
to
in
the
in
the
in
the
readme,
but
what
I
was
going
to
say
is:
I
think
that
roy
commented
on
that
pr
with
an
example
of
what
he
was
doing,
and
I
use
that
in
my
this
initial
pr
so
anyway.
My
point
is,
I
created
an
issue
here
that
that
ben
mentioned
you
know,
maybe
other
environments
we
might
want
to
process
the
the
initial
kind
of
process.env
stuff
a
little
differently
in
case
there
are
different
environments.
B
So
maybe
that's
what
you're
saying
darcy
the
initial
kind
of
grab,
and
we
may
need
to
flesh
that
out
further
in
this
issue,
and
and
can
you
know
if
roy's
got
work
already
on
it?
That's
great.
C
Yeah,
just
the
tracking
issue
like
to
just
to
track
it
either.
Independently
of
this
would
probably
be
good,
because
I
think
that
yeah
like
roy,
could
potentially
kick
that
off
and
by
the
way
he
he'll
be
up
for
a
little
bit
next
week.
I
think
so.
You
won't
have
time,
I'm
sure,
to
work
on
anything
but
yeah.
It
would
be
good
just
to
independently
push
that
forward
and
then
focus
just
on
the
parsers
and
like
polyfill,
that
poly
film,
parsers
or
sorry
polyfill
main
args
into
the
the
consumer,
parsers
yeah,
implementations.
C
But
yeah
yeah,
but
I
think
that
that's
important.
We
don't
necessarily
need
to
land
main
arts,
but
I
feel
like
it's.
It
should
be
there.
It's
honestly,
one
of
those
things
that
I
I
think
is
just
like
extra
work
that
everybody
does
and
it
cleans
things
up
so
much,
and
then
I
think
that
the
parsers
work
obviously
is
is
gonna
like
unlock,
that
much
more
just
out
of
the
box
for
for
folks
that
are
building
like
command
line
tools,
so
yeah.
C
B
E
B
Cool
that
would
be
great.
I
mean
one
of
the
things
I'm
thinking
about
too.
That
I
think
would
be
helpful
for
this
work
and
might
be
a
good
like
you
know.
First
steps
or-
or
I
guess
would
just
be
helpful
to
move
things
along
is
like
the
test
cases.
B
You
know
if
we
just
started
adding
test
cases
and
code-
and
you
know
then
do
red
green
refactor
kind
of
stuff
could
probably
move
it
along
pretty
well
but
anyway,
if
anybody
wants
to
throw
something
at
this,
I'm
going
to
I'm
going
to
merge
this
pr,
you
know
feel
free
to
use
the
the
tooling
slack
to
you
know,
chime
in
if
anybody's
gonna
work
on
anything,
I'm
gonna
try
to
get
more
work
done
next
week
as
well,
and
we
can
just
you
know,
tag
team
up.
C
One
last
thing
on
that
before
I
run
because
I'm
already
late,
I
know
that
the
last
time
we
talked
about
this,
I
think
we
talked
a
lot
about
the
short
options
and
I
know
ben
opened
up
an
issue
about
that
and
making
the
case
for
us
supporting
that.
I
think
I
had
a
to
do
that.
C
I
never
followed
up
with
to
either
add
to
the
readme
or
sort
of
the
design
of
these
this
api
to
take
a
pass
at
like
what
that
would
look
like,
and
I
think
that
still
needs
to
be
done.
C
Based
on
the
fact
that
shorts
still
are
like
it's
confusing
and
the
fact
that
you're
able
to
define
at
least
the
way
that
api
is
documented
today,
they're,
like
a
short,
can
be
defined
as
multiple
characters,
and
that's
not
the
case
that
we
we
should
make
the
opinion
that
and
update
the
doc
to
say
that
a
short
op
is
always
a
single
character
and
that
it
it
gets
parsed
into
essentially
and
will
map
to
individual
characters.
And
so
it's
at
that
point.
C
I
think
I
have
to
write
the
doc
to
basically
say
that,
like
a
short
can
be
aliased
to
another
another
argument
so
or
another
option,
so
I
I
think
I
had
that
as
a
to-do.
So
I'll
definitely
take
a
pass
at
that.
When
I
get
some
time
here,
probably
in
the
next
week
or
two
great.
B
Yeah
that'd
be
awesome.
I
think
that
makes
sense.
I
think
short
ops
is
important
to
be
good
for
us
to
have.
C
And
that
shouldn't,
I
don't
think
that
affects
like
the
initial
work
as
well
joe,
because
I
don't
think
you
were
like
on
that.
Yet
so
it's
like
an
extra
it's
an
extra
option
to
essentially
change
the
the
returned
values
right,
so
cool,
okay,
gotta
drop,
though
this
is
great.
A
So
that
this
is
the
last
thing
on
the
agenda
so
do
either
of
you
have
anything
else.
You
want
to
add
on
this
topic.
B
No,
no,
I,
I
guess
I'll
just
say
kai.
I
don't
know
if
you're
in
the
the
tooling
slack
there's
a
whole
nother
slap,
you
sent
me
an
invite.
Okay
cool,
you
know
feel
free
to
join
the
tooling
channel,
and
if
anybody
is
gonna
tackle
something
it
might
not
be
bad
to
just
chime
in
there
sure.
So
we're
not
doing
the
same
thing
and
would
be
great.
You
know
to
them
the
more.
What
do
they
say?
Many
hands
make
light
work
or
something
so
that
sounds
good.
A
To
me,
if
you
emerge
this
pr
I'll
I'll,
take
a
look
at
this
this
weekend,
perfect,
I
will.
I
will
do
it
as
soon
as
we
hang
up
all
right
any
last
minute,
business
announcements,
anything
nope.
D
Thanks
for
including
me
and
this
and
inviting
me
appreciate
it,
yeah
thanks
you're
welcome
anytime,
yes,
happy
to
have
you.
A
All
right:
okay,
yeah,
let's
leave
it
at
that
then
have
a
good
weekend.
Everyone
cheers.