►
From YouTube: Node.js Tooling Group Meeting - 2020-10-16
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
great
welcome
to
the
node.js
tooling
meeting
for
october
16th,
so
yeah,
since
it's
just
the
three
of
us
here,
we'll
maybe
just
move
kind
of
quickly
through
the
agenda.
There's
probably
some
things
on
this
list
that
none
of
us
know
much
about,
so
we
could
probably
just
skip
those.
I
guess
the
first
thing
on
the
agenda
is
the
recursive
file
system
operations.
A
A
So
I
think
we're
going
to
try
and
do
something
there.
The
week
of
the
26th.
B
And
can
we
can
you
really
quickly
just
go
through
because
I
was
trying
to
follow
a
bunch
of
the
issues
but
which
ones
landed
and
went
out
in
this
recent
one
and
which
ones
are
still
pending,
because
there's
like
three
or
four
different
stages
of
this
and
I
I
I
was
trying
to
follow
along.
But
I
I
think
I
just
didn't
get
the
full
context.
A
A
A
So
it's
and
that's
in
node
15.,
so
so
the
the
stuff
that
I
was
just
talking
about,
the
the
new
rm
command
is
in
the
latest
version
of
node
14
and
then
starting.
The
first
version
of
node
15
is
gonna.
Have
that
deprecation
warning
and
that
it
yeah
just
it
just
prints
the
deprecation
warning.
A
If
you
use
any
of
those
flags
until
you,
you
know,
use
this
new
rm
method
instead
and
then
you
know,
the
plan
is
maybe
eventually
we're
gonna
like
kill
that
functionality
altogether,
but
maybe
not,
we
might
just
it
might
be
too
widely
used
by
people
to
fully
kill
it
off.
So
we're
kind
of
going
to
have
to
see
but
yeah.
I
think
I
think.
B
We
did
that,
have
we
looked
at
so
so
I
I
know
personally
myself
and
most
things
that
I've
seen
aren't
using
it
directly
they're
using
it
through
some
of
the
more
popular
fs
extension
modules.
B
Have
we
looked
at
what
it
would
take
to
get
those
following
suit
yet
because
so
I'm
saying
like
like,
for
example,
like
fs
extra
fx
or
sorry
fs
extra
fs,
what's
the
other
one,
there's
like
three
or
four
that
are
like
pretty
popular
that
just
basically
wrap
and
provide
some
of
this
functionality
before
it
originally
landed?
B
That
might
make
it
easier.
Just
if
we
get
those
ones
migrated
over
the
the
actual
like
long
tail
stuff
might
become
a
lot
easier
to
reason
about.
A
Yeah
I
mean
that
that
makes
sense
to
me
just
taking
some
notes
here.
Some
libraries
are
using
the
old
or
are
using
fs.render.
A
B
B
A
A
B
All
over
the
place
so
I'll
I'll
I'll
see
if
I
can
submit
a
pr
yeah.
I.
A
A
Okay,
I
don't
think
there's
anything
else.
We
did
the
deep
dive
on
the
recursive
stuff.
You
know,
yeah,
I
think
copy
dur
is
going
to
be
the
next
sort
of
step
there.
So
I
don't.
I
don't
really
think,
there's
much
else
to
talk
about
on
that
front.
Hopefully,
hopefully
my
next
meeting,
we
can
have
like
at
least
a
rough
rfc
together
and
then
we
can,
you
know,
maybe
discuss
that.
A
Okay,
what
else
do
we
have
here?
Foreign
function
interface?
I
don't
really
know
anything
about
this.
One
all
right.
I
think
we'll
just
skip
that
one
for
now
deep
dive
meeting
pearls.
Actually
I
closed
this
issue.
I
closed
a
few.
It
was
one
of
the
things
we
talked
about
last
time
was
just
kind
of
like
combing
through
some
of
our
our
issues.
So
I
closed
a
few
that
were
like
done
or
like
definitely
not
going
to
be
done.
A
So
I
think
we
already
started
talking
about
like
another
deep
dive.
We
were
thinking
like
esm.
I
think,
or
maybe
the
road
map
would
be
a
good
topic,
but
we
don't
need
to
figure
that
out
right
now,
so
yeah
next
is
chmod-r.
C
Darcy
sent
a
message
to
the
meeting
issue
that
that
he
wasn't
gonna
be
able
to
make,
or
he
would
at
least
be
late.
A
A
A
I
think
we
were
talking
lasso,
maybe
trying
to
discuss
with
some
other
people.
I
don't
remember
who,
though
so
we'll
skip,
that
for
now
hooking
spawn
and
spawn
sync.
I
also
don't
know
anything
about
that
or
a
better
way
to
detect
the
process
is
exiting
source
maps
are
on
here.
That's
that's
ben's
thing,
the
last
one
though
argument
parsing.
We
could
potentially
discuss
that
just
prior
to
the
meeting
starting
joe-
and
I
were
talking
about
that
as
well-
he's
planning
to
pick
up
the
work
that
chris
initially
started.
A
Like
do
you
want
it
to
throw
or
not,
I
think,
was
the
the
contention.
It's.
B
Just
amazing
to
me
that
that
like,
if
that's
going
to
be
the
thing
that
blocks
it
like
yeah,
just
come
on
like
let's
just
push
this
through,
so
the
two
proposals
that
I've
read-
and
maybe
this
maybe
there's
more,
but
the
only
ones
I
know
of
are
one
is
popular
like
an
errors
key
and
then
not
throw,
and
then
the
other
one
is
throw.
B
Is
there
any
good
like?
Did
somebody
break
down
the
the
big
like,
like
a
point-by-point
breakdown
of
like
what
the
different
points
are
on
the
different
sides
of
this.
A
We
actually,
I
think
we
got
pretty
in-depth
on
that
in
the
last
meeting.
I'm
just
going
to
see
if
I
can
find
the
notes.
B
I'm
just
wondering,
because
my
my
reasoning
here
is
why
I'm
asking
that
is
it.
It
feels
like
if
we,
if
we
get
down
to
one
issue
like
that,
and
people
can't
reach
a
consensus,
but
have
like
good
points.
Then
it
seems
like
we
need
to
just
be
really
aggressively
going
after
the
tsc
being
involved.
Yeah
because,
like
it
doesn't
really
matter
like
we
get
either
way,
is
fine
and
people
will
just
adapt.
You
know
and
it'd
be,
and
it
was
really
unfortunate
to
see
chris
step
back
after
that
being
contentious
when
it's
like.
A
No,
I
agree,
I
think
we
there
was
also
some.
I
think
roy
brought
up
last
time
that
we
could
like
just
do
something
with
like
friendly,
useful
error
messages
as
well,
rather
than
just
throwing
like
a
stack
trace.
You
know
it
could.
We
could
just
have
like
generic.
Like
you
know,
whatever
the
name
of
the
the
flag
is
like.
A
Oh,
this
flag
is
required,
or
this
has
to
be
a
boolean
or
a
string
or
whatever,
and
then
let
people
override
them
if
they
want,
and
that
seems
like
a
pretty
good
like
out
of
the
box
experience
to
me
but
yeah.
I
do
agree
with
you
like,
and
then
we
did.
A
We
ended
up
doing
this
with
the
renderer
thing
like
we,
just
people
couldn't
really
decide,
so
we
brought
it
up
with
the
tsc,
they
decided
on
a
plan
and
we
did
it
so
I
agree
we
should,
I
think,
maybe
try
to
put
forward
a
solution
that
we
like
but
yeah.
If,
if
there's
too
much
contention
around
it,
then
let's
just
yeah,
take
it
to
the
tsc,
have
them
decide
and
get
it
done.
B
Yeah
yeah,
I'm
I'm
I'm
not
super
strongly
opinionated
here.
What
is
what
does
jargs
do
because
I'm
not
actually
sure
I've
ever
encountered
the
case
where
it
it
errored
on
parse
it
it
does.
The
error.
B
A
I
don't
know
that's
good.
I.
B
Didn't
either
way,
I
think,
following
community
precedence
is
actually
the
most
valuable
there
right.
It's
not
necessarily
that
it's
the
most
correct
it's
just.
If
that's
what
people
are
mostly
used
to,
then
it
seems
like
that's.
The
safer
bet.
A
Yeah
I
mean
I
would
agree
with
that.
The
only
the
only
thing
that
I
like
really
don't
want
to
see
is
like
throwing
an
exception
with
a
big
stack
trace
like
that.
That,
I
think,
is
just
like
not
the
right
answer,
anything
other
than
that
I'm
I
can
live
with.
B
Yeah
again,
like
I
said,
I'm
not
super
opinionated,
so
I
I
was
actually
surprised
that
it
got
as
contentious
as
it
did.
I
feel
like
I
actually
feel
like
wrapping
user
input.
Parsing
with
a
try.
Catch
is
actually
also
a
fine,
because
I
think
I
mean
that's
what
we
have
to
do
on
web
servers
and
it's
you
know,
I
mean
I'd,
say
pretty
normal.
B
So
again
I
like
I
said
I
I
would
go
either
way,
but
I
think
that
the
main
point
that
I
wanted
to
bring
up
was
just
if
people
can't
agree.
We
should
just
be
just
stopping
the
conversation
and
going
straight
to
the
tsc.
A
Yeah
and
like
I
said,
we
saw
that
that
worked
well
with
the
rainbow
stuff,
so
I
definitely
agree
I
put
that
down
in
the
notes.
Is
there
anything
else
on
the
argument
parsing
front
that
we
want
to
talk
about.
A
A
Yeah,
okay,
that
sounds
good.
I
will
just
make
a
note
of
that
as.
A
A
Yeah,
okay,
that's
great
and
I
mean
yeah
you
can
always
if
you
have
any
questions
or
whatever,
like
just
you
know,
there's
the
slack
channel.
Otherwise
we
can
discuss
at
the
next
meeting
as
well.
C
Cool
yeah
and
roy
offered
to
help
as
well
so
once
I
kind
of
get
up
to
speed
and
have
the
code
pull
down
I'll,
take
a
look
at
it
and
reach
out.
A
Yeah,
it
was,
it
was
him
and
ben
and
chris,
that
kind
of
did
like
the
bulk
of
the
work
on
like
coming.
A
And
stuff
like
that,
so
yeah,
right
or
ben
would
be
good
to
talk
to
cool
okay.
Is
there
anything
else
that
you
guys
want
to
talk
about
while
we're
here,
because
that
was
that
was
it
for
the
agenda.
B
Since
nobody
from
npm
is
here,
we
should
we
should
just
mention
npm
seven.
The
main
line
is
out.
They've
already
even
got
their
first
patch,
so
you
know
never,
never
trust
a
a
dot
0.0
how
quickly
they-
and
I
don't
know
what
the
the
patch
fixed,
but
I've
been
I've
been
using
the
betas
for
probably
about
two
weeks
now.
B
A
Cool
yeah
I've
been
trying
the
betas
as
well.
I
actually
missed
the
announcement
of
of
like
v7
on
like
monday
or
whatever
it
was,
let's
see
until
a
couple
days
later,
but
yeah
it's
exciting
stuff.
Now
I
just
need
them
to
add
that
resolutions,
field
and
yeah.
B
A
B
The
two
that
I'm
really
excited
for
from
you
know
work
perspective
are
the
combination
of
overrides
and
parent
package.
Json.
Have
you
followed
that
discussion?
Yet
no
there's
a
proposal
that
has
been,
I
think,
accepted,
or
at
least
it's
it's
like
pretty
clear
that
it's
going
to
be
accepted
for
specifying
a
parent
package,
jason
from
which
you
will
inherit.
B
So
the
the
thing
I'm
really
excited
for
is
at
work
is
centrally
managed
overrides,
so
the
idea
would
be
we
as
a
central
team,
can
publish
a
single
list
of
like
these
are
our
supported
platform
versions,
and
we
could
just
do
like
star,
you
know
or
well
probably
we
won't
do
star
but
like
for
for
some
of
the
ones
where
there's
a
lot
of
like
a
lot
of
transitive
alignment
required.
B
So
things
like
react
or
things
like
grpc,
you
know
where,
like
you,
might
publish
a
platform
of
like
of
components
or
or
in
grpc
land
like
you
have
a
client,
and
it
relies
on
like
this
huge
tree
of
transitives,
and
if
you
have
two
clients
in
the
same
tree
like
how
do
you
mesh
them
and
then
having
the
ability
to
push
that
from
a
central
location
and
not
have
every
single
project
have
to
like,
go
and
roll
out
these
huge
updates
and
keep
up
to
date,
all
the
time
is
going
to
be
really
nice.
A
That
that
does
sound,
really
nice.
The
big
use
case
for
us
with
resolutions
is
graphql.
If
you
use
different
versions
of
graphql
in
your
project
or
across
projects,
the
horrible
things
happen
it'll.
A
Actually,
if
it's
in
the
same
project,
it
will
like
refuse
to
compile
your
code,
won't
even
run,
so
that's
where
we
use
it
a
lot
but
yeah
being
able
to,
and
that's
in
like
that
codes
in,
like
every
project
so
being
able
to
like
centrally
say
like
these,
are
all
the
versions
of
graphql
or
pin
2
and
like
apollo
packages
or
whatever
that'd
be
awesome.
A
B
B
There's
there's
just
a
bunch
of
edge
cases
in
that
with
that
one
that
make
it
a
little
bit
less
clear,
whereas
the
overrides
is
like
which
everybody
just
needs
everybody's
needed
that
that's.
Why
so
many
people
use
yarn
like
you
know.
A
B
A
Well
that
so
that's
the
thing
too,
is
it's
like
it's.
Actually,
it's
as
much
or
more
work
for
us
to
upgrade
from
yard
1
to
yarn
2
and
from
yarn
to
npm,
so
we
might
as
well
seriously
consider
both
of
them
now
so
yeah
we
haven't,
we
haven't
like
fully
decided
yet,
but
yeah
kind
of
both
options
are
on
the
table,
which
is
nice.
It's
good
to
have
some
choice.
B
B
My
worry
is
that
we're
going
to
just
reintroduce
another
huge
fracture,
like
we've
had
in
the
past,
with
yarn,
supporting
these
features
in
npm
not
and
get
back
to
a
place
where
it
becomes
you,
you
get
locked
in
super
strongly
to
one
or
the
other,
which
is
what
yarn
two
really
does
like
you
know,
once
you
go
the
yarn
two
route,
you're
pretty
well
locked
in
there.
B
Without
you
know,
I
mean
I
guess
you
can
mic,
you
can
always
migrate,
but
like
making
the
changes
that
are
required
to
support
pnp
like
it's
enough
that
I
think
it's
going
to
be
a
barrier.
I'd
really
like
to
see
more
collaboration
there-
and
I
know
the
the
p
p
p,
p
m
e
p.
A
M
m
e
m
m:
I'm
like
I
knew
it
was.
It
got
a
new
name
though,
because
that
wasn't
available
on
npm.
I
think
it's
called
core
pack
now.
B
B
It's
just
that
it's
codified
in
the
package
json,
which,
in
theory
for
previous
yarn
projects,
you
could
just
delete
the
yarn
lock
and
then
reinstall
with
with
npm
as
long
as
you
weren't,
using
the
couple
of
features
that
yarn
had
and
you'd
be
able
to
be
at
least
a
little
bit
portable,
and
I
think
now,
you're
gonna
get
even
more
entrenched
ecosystems
where
they're
like
no.
No
we're
not
you
know,
we've
got
it
in
here
and
you
can't
even
install
this
without
yarn
or
enpm.
A
But
internships,
the
flip
side
is,
though,
if
they
make
that
easier
to
install
those
tools
and
I'm
hoping
we
can
get
something
kind
of
like
like
nvm
ask
where,
like
you
like
cd
into
like
a
project
directory
and
it
just
it
just
automatically
picks
up
like
okay,
you
need
this
version
of
node,
this
version
of
yarn
or
npm
or
whatever,
and
just
like
does
it
for
you
behind
the
scenes.
I
think
that
would
be
pretty
nice
and
then
you
can
use
whatever
you
want
across
different
projects.
B
It
kind
of
does
that
in
that
you'd
hook
the
same
kind
of
thing
up.
I
assume
you
use
something
like
durian
v
or
you
know
to
do
that.
Cd-Ing
thing.
If
you
do
the
same
thing
with
core
pack,
I
think
you
just
say
like
core
pack
install
and
then
it
will
do
whatever
your
package.
Json
says,
which
is
good,
but
you
still
have
to
know
what
to
what
binary
to
execute
right,
which
is
the
difference
between
node
with
nvm,
you
just
say
node
and
it's
a
node
version.
B
Which
like
and
that's
where,
maybe
you
could
have?
Maybe
you
could
switch
everybody
just
to
say
core
pack
and
then
core
pack
would
delegate
out,
but
then
you
have
to
deal
with
the
differences
between
the
package
managers
right,
as
I
said,
I
don't.
I
don't
think
it's
actually
making
anything
meaningfully
different
than
it
is
today.
It's
just
making
it
like
two
steps
easier
right
because
it's
codified
in
the
package.json,
so
you
can
go,
look
it
up
and
it's
bundled
by
default.
So
which
is
great.
A
Kind
of
works,
no,
I'm
not
like
opposed
to
it.
Certainly,
like
I
think,
yeah
it's
it's
a
convenience
thing
happy
that
it's
there
I
guess
for
yeah
like
I
said
it
makes
a
little
easier
if
you
do
want
to
use
something
other
than
npm
makes
the
levels
the
playing
field
a
little
bit
where
you
know
before
npm
was
the
only
thing
that
shipped
with
node.
I.
B
I
see
I'm
I
push
back
on
that.
Don't
get
me
wrong.
I
think
we
need
to
remove
the
entrenched.
You
know
the
preference
we
give
to
npm,
but
I
don't
think
we're
actually
making
it.
I
don't
think
we're
leveling
the
playing
field.
Npm
is
now
owned
by
github
like
you're,
not
leveling,
the
playing
field.
Yarn
is
still
a
single
maintainer.
Pnpm
is
still
a
single
maintainer.
There's
no
leveling
happening
here.
B
Leveling
would
be
as
if
we
took
a
lot
of
the
work
that
those
three
package
managers
are
doing
and
made
that
a
feature
of
node
and
then
all
they
would
have
to
maintain
is
the
little
differences
they
wanted
on
top
of
it
right
or
like
to
me
that
is
leveling.
The
playing
field
having
some
core
package
manager
features
built
into
the
platform
like
go,
has
done
not
to
say
that
that's
like
we
should
go
at
the
same
direction
they
did
but
like
that
makes
it
actually
a
loving
level
playing
field.
B
What
we
have
today
is
just
like:
well,
we
couldn't
figure
out
how
to
really
do
it
right.
So
we
just
like
ship
stubs
for
yarn
and
pnvm,
and
it's
like
still
not
you
know
and
github
still
owns
the
registry
like
until
we
fix
that
I
say
fix
it
until
until
that
changes.
There's
no
leveling
of
the
playing
field
like
by.
C
B
A
C
By
the
way,
I
I
thought
I'd
just
add
to
I
put
it
in
the
meeting
notes,
but
darcy
responded
to
a
message
about
that.
One
issue:
nothing
has
happened,
there
he's
pretty
overloaded
at
work
and
I
would
be
happy
if
somebody
else
wanted
to
pick
it
up.
That's
the
shmod-r.
A
Yeah
all
right
well,
we'll
put
it
on
the
list
of
recursive,
stuff
and
yeah.
If
anyone
wants
to
pick
it
up,
it's
great
but
yeah,
I
think
like
for
me
my
my
focus
is
going
to
be
on
the
copy
durer
one.
I
think
that's
like
higher
higher
impact,
so
I'm
going
to
try
and
tackle
that
first,
but
eventually
we
will
get
to
all
of
these.
Hopefully
yep
sounds
good,
hey.
I
guess
another
thing
that
I
kind
of
wanted
to
that's
been
on
my
mind.
A
I
don't
know
if
you
guys
know
anything
about
this,
though,
is
the
promise
api
in
fs.
A
I
I've
tried
to
use
it
a
few
times
and
like
for
some
reason,
like
more
than
half
of
the
file
system.
Operations
are
not
in
there
like
it's
only
like
a
tiny
subset
of
them,
and
I
don't
really
know
why
I
assume
there's
some
kind
of
reason
just
seems
weird
to
me
that,
like
like
it,
I
don't
know
it's
hard
to
use
because
not
everything
is
there
and
then
it
also
more
and
more.
These
days
seems
weird
that
it's
not
like
the
default.
A
You
have
to
use
like
fs.promises
whatever.
So
that
maybe
falls
a
little
bit
outside
of
this
group,
because
I
know
there's
an
fs
group,
but
yeah
I
mean
I
would
really
love
from
a
tooling
perspective.
I
would
love
for
that
to
be
better.
B
So
I
think,
there's
a
few
problems
right
that
with
it
being
the
default,
depending
on
what
you're
doing
like
if
you're
trying
to
do
a
high
performance
web
server,
that
also
has
like
some
file
serving
you
definitely
don't
want
to
be
doing
the
promise
apis
right.
You
want
to
be
using
the
streaming
apis
because
they're
going
to
be
able
to
stream
directly
to
the
socket
right,
and
then
you
don't
have
the
like
memory,
overhead
of
loading,
a
massive
video
file.
B
C
Yeah,
but
I
think
that
that
was
sort
of
a
decision
that
was
made
a
while
ago,
and
I
think
a
lot
of
those
that
are,
you
know,
updated
quote
unquote
to
use
promises.
That's
like
the
pattern
that
was
decided-
and
I
I
looked
at
this
a
while
ago
and
was
looking
at
doing
more
of
the
promise
api
work
but
yeah.
So
I
don't
know,
I
think,
that's
kind
of
the
pattern
that
folks
landed
on.
A
A
You
know
where,
where
maybe
that
should
be
the
default
version
like
it
just
seems
very
weird
to
me
that
you
know
the
default
like
if
you,
if
you're,
not
adding
sync
onto
the
end
of
the
method
or
whatever
the
default
behavior
is
callbacks.
A
B
Yeah,
I
would
be
on
that.
One
thing:
one
thing
that
might
be
interesting
to
propose
is
to
do
sort
of
a
layered
api,
so
we're
talking
about
this
in
the
web
server
frameworks
team
about
how
we
can
both
satisfy
the
performance
requirements,
and
you
know
the
when
you're
a
power
user.
You
might
expect
something
a
little
bit
lower
level
and
you
might
need
that
for
a
certain
reason,
balance
that
and
then
balance
that,
with
the
end
user
use
case
where
oftentimes
an
end
user
is
just
like.
I
don't
want
any
of
that.
B
B
So
I
wonder
if
there's
maybe
a
way
where
we
could
maybe
pull
out
the
fs
and
have
like
fs
promise,
or
you
know,
maybe
something
as
a
se
as
a
separate
top-level
module
that
actually
layers
that
imports
the
underlying
fs
or
something.
You
know.
I
mean
like
like
how
we're
trying
to
think
about
the
layering.
A
Right
because
yeah,
I
do
agree
that,
like
I
think
the
the
promise-based
versions
of
this
stuff
is
what
most
end
users
probably
do
want.
You
know,
especially
from
a
tooling
perspective
like
if
I'm
just
like,
if
I'm
writing
a
script
or
something
like
that,
I'm
gonna
just
end
up
using
the
sync
version
of
something,
probably
because
it's
easier
than
importing
the
promise
based
version
and
maybe
for
a
cli
using
those
sync
operations
is
fine,
but
definitely
not
in
in
really
anything
else.
B
I
mean
even
then
it
depends
because
a
lot
of
libraries
I
write
which
expose
clis
are
also
used
in
contexts
where
they're
imported
right.
So
like
we
have
some
security
libraries
at
work
where
they're
they.
The
underlying
implementation,
is
used
both
in
the
cli
and
in
web
servers,
and
so
you
just
can't
use
the
sync
file
apis
in
that
case,
but
you
do
want
to
use
the
promise
apis
like
you
know,
because
it's
a
it's
an
end
user
thing.
B
They're,
not
you
know
it's
not
like
a
they're
writing
a
high
performance
file,
server,
they're,
writing
like
one
file
and
then
reading
the
same
file
right
and
like
in
that
case,
you
definitely
are
going
to
use
a
promise
api
and
it
does
seem
like
that.
We're
making
those
people
jump
through
hoops
right
unnecessarily,
yeah
yeah,
that's
kind
of
like
anything.
B
The
recursive
operations,
but
like
really
the
only
reason
I
use
fs
extras,
because
I'm
writing
and
reading
json
files
all
the
time-
and
I
don't
want
to
it's
just
easier
to
you-
know
import
that
it
already
does
the
promise
it
only
imports
the
promises,
api
from
core
and
then
re-exports
it
so
everything's
already
promises.
B
C
A
A
B
A
C
I
was
going
to
say
if
you
wanted
to
start
tracking
some
of
that
stuff
and
we
could
create
an
issue.
I
could
start
looking
at
it
once
I
get
through
these
couple.
Other
things.
It
was
something
I've
kind
of
looked
at
in
the
past.
A
Yeah-
it's
probably
it's
probably
worth
I
can.
I
can
create
an
issue
in
the
tooling
repo
for
it
just
so
we
can
keep
track
of
it
and
it'll
end
up
on
the
agenda
next
time
and
whatever
and
then
yeah
we
I
mean
we
might
as
well
start
start
discussing
that
too.
I'm
definitely
interested
in
improving
the
situation.
A
A
It
hasn't
changed
in
quite
a
while
yeah
and
like,
as
far
as
I
know,
anything
that
takes
a
call
back.
You
should
be
able
to
turn
into
a
promise-based
version,
so
I'm
not
sure
why
they
stopped
short
on
a
bunch
of
them.
Yeah
yeah
all
right,
well,
yeah
I'll
I'll,
make
a
quick
issue
after
this,
so
that
we
get
that
on
the
agenda
for
next
time
and
we
can
keep
discussing
sounds
good
yeah.
I
mean
that
that's
you
know
everything
we
had
on
the
agenda.