►
From YouTube: Open RFC Meeting - Wednesday, April 16th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live
on
YouTube
again.
This
is
the
open
RC
call
for
Wednesday
April,
the
15th
I'm,
your
host
RC
Clark.
The
meeting
notes,
link
I,
just
pasted.
It
in
chat
feel
free
to
add
yourselves
to
the
attendees
list.
Let
me
know
if
you
can
edit
that,
as
usual,
we'll
be
following
the
agenda:
that's
posted
in
the
MPM,
slash
RFC's
repo,
and
just
be
mindful
of
the
code
of
conduct
that
these
meetings
are
all
held
with
and
as
well
as
any
conversations
between
your
seated
meetings.
A
We
just
enter
and
want
to
make
sure
people
are
being
mindful
and
thoughtful
as
people
speak,
please
raise
your
hands
when
you'd
like
to
contribute
today,
I'm
gonna
be
trying
to
take
notes.
As
our
resident
note
taker.
Claudia
I
can't
make
it
today,
so
I'll
try
to
do
my
best
there
as
well.
These
calls
just
to
reiterate
sort
of
the
desired
outcomes
of
this,
and
the
intentions
of
these
calls
is
to
get
closer
to
the
community
and
hopefully
move
our
series
forward
or
conversations
forward.
A
We
run
these
bi-weekly
with
a
alternating
bi-weekly
call
for
deep
dives.
So
we'll
try
to
pick
a
session
or
topic
that
we'd
like
to
go
a
little
bit
further
in
depth
next
week
by
the
end
of
our
discussion
here
today
and
appreciate
everybody
jumping
on
today.
Again,
the
agenda
should
be
in
there
in
that
meeting
notes
dock
and
before
we
jump
into
the
items
that
were
listed.
Does
anybody
have
any
announcements
they'd
like
to
go.
A
B
A
C
A
I've
heard
this
numerous
times
from
the
community
that
there's
a
want
and
a
need
for
us
to
be
exposing
that
information
in
a
meaningful
way,
not
also
on
the
website,
even
to
split
up
dependents,
information
from
also
like
having
deaf
dependencies
as
a
thing.
That's
specifically
there.
So
we
we
have
an
internal
issue
backlog
to
do
that,
work,
which
would
also
require
essentially
having
that
API
exists,
which
I
we
don't
think
it
does
today.
So
it
would
make
sense
that
once
it
does
exist,
but
we
would
potentially
expose
that
publicly
I
think
Glenn.
A
C
So
we
will
understand
the
whys
and
wherefores
as
we
begin
to
carry
out
maintenance.
You
know
in
a
more
serious
fashion,
we'll
find
where
our
modules-
and
we
will
have
we'll-
have
a
good
idea
who
liked
the
one
or
two
most
dependent
people
our
army,
but
we
soon
get
to
realize
that
there
are
a
whole
slew
of
people
that
we
might
wish
to
inform
or
even
test
against,
and
it
is.
C
It
is
really
for
tooling
and
for
maintenance
that
I
come
to
this
from,
but
I
can
see
that
we
would
have
a
need,
a
greater
need
anyway,
but
to
be
able
to
give
people
a
heads
up,
but
hey
breaking
change
coming.
You
are
the
top
ten
people
you're
important
to
ecosystem,
that's
kind
of
what
we
want:
a
sort
of
a
community
way
of
being
able
to
find
out
who
we
we
will
impact,
as
these
very
important
packages
get
handed
off
between
sort
of,
let's
say,
intergenerational
maintained.
As
now.
C
It's
not
doesn't
like
a
human
generation,
but
may
last
three
or
four
years
of
one
person
thing
and
then
life
changes
might
happen.
They
may
have
children,
they
may
they,
may
it
go
into
management
and
have
it
have
teams
to
manage
it
changes
and
it's
that
that
we
wish
to
help
with.
As
you
know,
packages
get
passed,
but
they
still
but
remain
incredibly
widely
used.
A
A
To
expose
this
data,
I
would
say
like
end
of
year,
like
the
like,
q4
is
probably
like
for
earliest
I
would
say,
but
again,
I
can't
really
give
any
promises
about
when,
like
we'd,
be
able
to
support
this
I
know
that,
like
there's
user
land
tooling,
that
some
people
have
tried
to
to
create
utilizing
the
existing,
if
you
guys
to
try
to
like
circus
this
bubble
of
this
information,
so
which
I
know
is
tedious
to
maintain
so
be
great.
If
it
was
something
that
we
could
support,
natively
I'm,
going
forward
songs.
C
So
I
have
one
of
request
in
interim
if
it
said
q4
time
thing
and
we're
grateful
fan.
If
any
support
we
get
it
would
it
be
possible
for
community
members
to
actually
say
this
particular
one
we
are
worried
about.
We
are
making
a
breaking
change.
Could
you
just
tell
us,
but
even
before
you
get
an
API,
you
could
run
it
internally.
I
know
that's
extra,
because
I
think
we
have
one
or
two
things.
We
are
concerned
about
changing
and
I'm.
Looking
at
the
Express
team,
I've
been
looking
at
it.
C
The
Express
session,
module
and
I
know
it's
not
huge
where
it's
11
million
dollars
a
week
with
its
key
and
hey
I
can
guess
the
top
surf
you
ready
and
then
it
just
sort
of
tells
or
themes
of
various
flavors,
a
sequel
and
I
really
couldn't
pick
one
from
the
other.
That's
thumb
I'm,
surprised
about.
You
know
that
so
few
stars,
but
that
that
might
be
a
help.
If
we
could
just
have
you
know
this
one
who
are
the
people
just
one
or
two
any
entry
in
time,
but
Solan
is
the
endgame
I.
Don't.
D
I,
don't
want
to
unmute
for
too
long,
so
I
think
a
neighbor
has
got
some
long
thing
going
on,
but
somebody
on
Twitter
just
last
week
posted
something
about
doing
like
a
big
query.
Analysis
of
they
had
pulled
I
think
the
entire
set
of
github
repositories
and
used
that
to
then
analyze
and
compact.
Just
anyway
approaches
aside
I
think
there
are
some
ways
that
if
there
was
some
money
put
behind
it,
you
could
do
the
analysis
you're
talking
about
without
NPM
necessarily
needing
to
expose
this
API.
D
C
E
F
F
Glen
to
your
point
about
you
know,
is
it
possible,
for
you
know,
someone
within
open
Jas
or
some
other
kind
of
some
of
these
other
major
projects
to
just
reach
out
to
us
and
ask
a
question
like
we're
happy
to
help?
If
we
can,
you
know
within
the
limits
of
reasonable
time
investment,
but
the
the
what
I
think
there's
actually
some
some
push
for
here,
which
we've
also
discussed
internally.
You
know
again
in
that
kind
of
q5
planning
timeframe,
is
actually
having
a
proper
graph
DB
type
implementation
for
registry
dependencies.
F
What
that
would
also
allow
us
to
do
is
a
lot
more
interesting
stuff
on
the
security
side.
So,
for
example,
it's
it's
a
little
bit
hairy
right
now
that
you
know
you've
seen
this
whole
issue
with
minima
stand.
How
I'm
ik
d'oeuvre
depends
on
it
and
everything
depends
on
mcdr
pand.
Then
it's
very
difficult
to
sort
of
unravel
on
the
client
side
or
even
within
the
within
the
audit
API
endpoint.
F
What
exactly
needs
to
be
done
in
order
to
fix
your
problem,
even
though
to
a
human?
It
looks
very
obvious,
so
we're
doing
some
improvements
on
that
in
NPM
b7,
but
a
proper
database
would
allow
us
to
do
a
lot
of
interesting
things.
You
know
above
and
beyond,
just
a
dependents
API
and
would
be
much
more
much
easier
to
get
those
kinds
of
answers
much
more
quickly
than
you
know,
than
just
looking
at
the
like
replicating
the
couchdb
and
kind
of
building
it
up
for
each
individual
ad
hoc
use
case.
A
F
Well,
I
think
you
know
there's
a
bigger
conversation
here,
maybe
about
like
how
we
handle
RFC's
that
come
into
the
NPM
RFC's
repo
that
are
not
about
the
CLI,
because
it's
you
know,
I
kind
of
don't
have
the
key
people
to
to
weigh
in
on
a
dependence
API
right.
It's
it's
a
it's
more
a
back-end
issue
and-
and
this
is
kind
of
tends
to
be
more
focused
on
CLI-
and
you
know,
of
course
understand
that
line
being
somewhat
blurry
from
outside
of
this
particular
organization.
F
G
E
F
F
That
actually
got
a
lot
harder,
the
reason
being
that
we're
not
really
using
couch
TV
as
the
database
of
record
for
almost
anything.
Nowadays,
we
use
it
as
a
almost
more
almost
like
a
glorified
of
sub
type
of
thing
that
has
really
good
pure
replication
just
to
store
the
packing
and
metadata
itself,
but
all
of
the
all
of
the
views
have
been
ripped
out
of
it.
So
the
way
couch
CB
generates
its
its
Map
Reduce
fuses.
F
Every
time,
there's
a
write
to
the
database,
it
reevaluate
Sall
of
the
views
that
that
document
was
was
a
part
of,
and
so
this
is
really
good
and
lets
you
kind
of
like
pre
pre
generate
so
that
you
can
fetch
this
data
very
very
quickly.
But
the
downside
is
every
write
was
getting.
You
know,
kind
of
we
hit
this.
This
hockey
stick
point
where
every
write
was
getting
increasingly
more
and
more
costly
in
order
to
make
because
it
had
to
read.
F
A
Yeah
and
maybe
to
speak
to
the
first
part,
there
Isaac
and
I
know
that
we
have
a
registry
label,
but
we
I
know
that
there
was
discussions
previously
as
well
about
potentially
having
registry
specific
RFC's
created
or
like
like
trying
to
create
that
distinction,
so
something
actionable,
maybe
there's
is
for
now
at
least
ensuring
that
we've
labeled
any
RFC
that's
coming
in
that
has
registry
related
topics
to
it.
I
know
that,
although
we
might
say
that
you
know,
this
is
definitely
something
that
we
all
agree
to
terms
of
a
design
of
api's
etc.
A
It's
definitely
something
that
we're
gonna
have
to
we've
always
said
it's
a
champion
again
internally,
and
what
we
could
do
or
try
to
do
going
forward
is
once
something
has
been
added
with
that
label
or
labels
being
added
to
an
RFC
like
that
or
discussion
like
that.
We
try
to
bring
to
these
calls
specifically
folks
that
would
essentially
greenlight
at
the
implementation
details
from
the
registry
side.
F
I
mean
you
know
the
I
I,
don't
and
I
don't
want
to
come
across
as,
like
you
know,
blaming
the
user
on
this,
like
I.
I,
totally
understand
that,
like
sometimes
the
distinction
is
very
while
it
seems
obvious
to
me
it's
it's.
It
cannot
be
obvious
to
to
users
who
don't
you
know
kind
of
understand
all
of
the
finer
points
of
like
what's
a
registry
issue
or
what's
the
CLI
issue,
and
so
having
one
kind
of
bucket
where
users
can
throw
their
ideas
is
really
really
valuable
and
then
we
should
just
kind
of
sort
them.
A
Templates
are
our
friends
here
so
I'll.
Take.
That
way
is
something
that
I
can
I
can
try
to
champion
and
make
sure
that
we're
driving
discussions
in
the
right
direction
and
then
also
have
mechanisms
to
ensure
they
don't
get
lost
and
that
people
feel
like
they
understand
like
how
to
contribute
these
ideas
and
that
they're
actually
gonna
get
you
know
championed
or
like
action
Don
properly
I.
F
D
A
F
The
the
the
registry
portion
of
that
thing
would
be
discussed
in
that
call.
I
still
think
this
is
a
good
place
to
kind
of
start.
A
lot
of
that
stuff
and
just
identify
like
here
is
a
registry
dependency
that
this
CLI
feature
has
you
know,
and
these
these
things
might
range
from
like.
Well,
it's
it's
actually
trivial
I
can
just
kind
of
wait
into
that
coat.
That
code
Basin
send
a
PR
to
that
team.
All
the
way
up
to
like
this
requires
a
complete.
F
We
can
do
just
in
the
CLI
itself,
so
I
think
I
think
what
we
have
now
is
a
good
start,
but
we
just
need
a
better
forum
for
kind
of
identifying
like
this
right.
Here
is
a
purely
registry
thing
and
like
there's,
no
way
that
there's
no
way
the
CLI
can
give
you
a
dependents
API
right,
like
that's
gotta,
be
a
server-side
piece.
F
A
Just
be
mindful
of
time,
because
I
know
we
have
a
pre-launch
agenda,
I'd
like
to
try
to
get
through.
So
if
we
want
to,
let's
follow
up
here
with
some
actions
on
the
a
stroll
this
year
itself
at
that
label
and
then
at
the
broader
sort
of
a
conversation
about
how
we
distinguish
between
CLI
versus
registry,
related
content
or
suggestions
should
be,
should
probably
better
document
that
somehow
so
cool
so
moving
on
issue
or
item
three
issue
number
one,
one,
five
iso
add
a
top-level
bin
dependencies,
the
package.json
I
know
this
is.
A
F
A
F
A
Good
we're
a
little
bit
more
cheaply
for
sure
okay.
So,
since
we're
there
isn't
much
to
discuss
there,
I
want
to
get
into
the
two
items.
Number
four
and
five
are
c1,
one
for
and
RCA
103
expanded
list
of,
ignore
files
and
add
NPM
workspaces.
These
are
both
I
think
owned
by
Roy.
If
you
want
to
maybe
speak
to
them
quickly
and
just
maybe
give
a
status
update
on
both
yeah.
H
A
A
A
A
I
think,
based
on
our
conversation,
two
weeks
back,
it
was
just
essentially
pare
down
the
list,
make
sure
it's
not
something
that
might
be
disruptive
to
folks
that
are
already
thrown
in
those
files
that
we
we
don't
want
to
over
yeah
over
flag
things
that
people
are
actually
using
passing
around
editor
config
and
packages
might
be
a
thing
that
the
user
land
actually
does.
So
could
you
give
a
quick
update,
then
ROI
on
the
workspaces
RC
and
maybe
give
some
insight
into
the
work
that
you've
been
doing
recently.
H
F
H
Okay,
I'm
good
yeah
and
then
the
progress
side
of
things
right
now,
yeah
we
have
more.
We
have
made
progress
with
the
implementation,
so
we
put
together
this
list
of
projects
using
workspaces
that
we're
going
through
yeah
I
got
something
back
from
West
Jordan
on
that.
Thank
you
so
yeah,
but
right
now
is
still
development
phase.
I
guess
yeah.
A
So
if
anybody
knows
on
this
call
of
really
popular
projects
that
are
using
workspaces
today
with
learning
on
yarn,
it
might
be
good
to
surface
those
to
us
just
to
make
sure
that
you
know
people
can
adopt
NPM
workspaces
full
wholesale.
Once
that's
ready
to
go
so
yep
awesome
so
moving
on.
Then
there
is
here
our
number
92,
so
the
rc4
stage
workflows
are
the
staging
stage
publishes,
which
I
know
we
did
a
deep
dive
call
on
about
a
month.
Back
now
time
flies
I'm,
not
sure.
F
F
A
Think
the
one
key
out
of
the
conversation
also
was
I,
think
we're
gonna
transfer,
I,
guess,
like
the
ownership
of
that
IRC
or
like
stewardship,
maybe
from
Daniel,
just
I
know
he's
sort
of
switched
positions
now
and
company
so
may
not
have
the
same
time
and
resources
to
update
that
moving
forward.
So,
whether
that's
myself
or
are
you
Isaac
or
whoever,
and
we
should
make
sure
that
there's
somebody
like
keep
an
eye
on
that
and
just
update
the
language
based
on
discussions.
A
That's
another
one
where
we
should
definitely
flag
is,
depending
on
the
registry
implementation
right,
so
yeah
I'll
be
heavy
dependency,
which
I
think
it
already
is
labeled
properly,
but
yeah.
Certain
design
implementation
details
should
be
probably
distinguished
cool.
Moving
on
item
number,
seven
issue
56
feature
essentially
create
RFC
or
create
the
RC
for
yarn
like
resolutions.
So
last
week,
if
folks
are
weren't
aware,
we
did
again
at
deep
dive
last
Wednesday
on
resolutions
and
actually
sort
of
mocked
out
or
stuff
they're
sort
of
schema.
A
That
seems
to
make
a
lot
of
sense
and
actually
made
things
look
a
little
bit
less
hairy,
at
least
from
our
end.
I
know
that
you
know
we
didn't
want
to
take
the
exact
same
approach
that
yarn
has
gone
with
so
creating
like
a
DSL
and
so
I'm,
not
sure
Isaac.
Do
you
want
to
speak
to
the
new
RC
that
you've
created,
which
is
also
on
this
agenda?
Essentially
in
response
to
that
call'
yeah.
F
So
I
think
that
the
the
net
here
is
that
I
have
some
more
work
to
do
and
I
appreciate
been
discussing
in
slack
with
Wes
and
turny
siren
and
Jordan,
and
a
few
others.
So
I
think
that
the
where
we've
gotten
to
I
think
is
good
and
I'm.
Gonna
have
a
lot
more
examples
and
use
cases
to
put
in
that.
It's
going
to
be
a
very
long.
Rfc
with
you
know,
sort
of
getting
not
close
to.
F
It
will
be
a
an
actual
spec
for
how
the
feature
ought
to
work
and
because
it
it
is
such
a
fiddly
kind
of
a
flat,
gunny
type
feature.
I'd
I
want
to
get
as
much
documentation
as
possible
about
how
it
works
and
and
how
it
handles
all
the
different
edge
cases
that
we
kind
of
exhaustively
can
go
through
before
we
commit
to
it
with
an
implementation,
and
you
know
main.
G
Thing
that
might
be
really
nice
to
address
those
concerns
and
help
end
games,
implementation
and
help
me
is,
if
you
had
a
separable
test
suite
that
I
could
plug
in
resolved
to
so
that
I
can
make
sure
that
resolve
can
support,
like
so
I
can
implement
this
support
in
resolve
and
make
sure
that
it
is
actually
working
that
way.
I
don't
have
to
write
my
own
test
cases
yeah.
G
It
would
be
really
great
overall
to
have
an
NPM
test
suite
where
I
can
say
like
I'm
gonna
test
this
tool,
and
here
is
how
you
run
the
install
command
and
here's
how
you
run
the
uninstall
command
and
here's
how
you
run.
You
know,
here's
how
you
do,
resolution
and
stuff
like
that.
You
know
I
know
that's
a
very
broad,
large
ask
but
like
yeah.
F
F
F
What
the
build
ideal
tree
test,
an
arborist
are
so
they're
they're,
easily
portable,
but
not
exactly
as
portable
as
your
as
you're
talking
about
not
not
that
easily
another
another
possibility
is
something
somewhat
similar
to
the
the
tests
in
semver,
where
which
are
reused
by
a
lot
of
other.
You
know
several
other
December
implementations
where
we
have
a
you
know.
F
A
list
of
here
are
all
of
the
vert
here's
a
laundry
list
of
dependency
ranges
of
various
types
and
then
here's
what
they
should
parse
to
in
terms
of
the
actual
comparators
or
here's
a
you
know.
Given
this
range,
this
version
should
satisfy
this
version
should
not
satisfy,
and
you
know
I
know
like
the
December,
crate
and
Konan
and
a
few
other
projects
use
those.
F
A
F
And
just
just
to
be
clear:
we're
not
planning
on
supporting
yarn
style
resolutions
per
site.
We're
where
we
landed
was
we're
gonna,
do
a
new
thing
called
overrides
and
that's
what
this
RFC
is
to
discuss
in
and
in
part
of
this
we
also
are
unaccepting
the
or
rejecting
the
the
previously
accepted
RFC
called
package
overrides,
because
it's
it
turns
out
that
that's
not
actually
a
good
enough
solution.
D
D
Other
purpose,
which
I've
made
the
case
a
couple
of
times.
I
wanted
to
do
and
I
ended
up
doing,
but
it
was,
it
was
more
difficult
than
I
would
say
is
good,
so
I
think
this
kind
of
case
would
be
a
really
great
way
to
sort
of
challenge
the
design
of
arborist
so
that
maybe
we
could
at
some
point
start
pulling
out
test
cases
and
make
them.
D
You
know
something
you
could
run
against,
maybe
not
other
implementations
that
install
packages,
but
maybe
there's
other
implementations
that
rely
on
having
an
understanding
of
how
overrides
works,
because
you're
gonna
do
some
particular
automation
around
it
right,
and
if
you
had
that
as
sort
of
a
piece
you
could
pull
out,
it
would
make
doing
that
extra
tooling.
A
lot
easier,
I
think
yeah.
F
F
Also
we
just
you
know
we
kind
of
while
things
are
in
flux
and
and
while
we're
working
on
it,
it
is
a
lot
easier
to
just
kind
of
keep
it
all
together
wheel.
You
know,
if
you,
if
you,
if
you
crack
open
the
repo
like
as
you've,
seen
like
build
ideal
tree,
is
pretty
separable
from
RIA
and
actual
tree
and
virtual
tree,
and
all
these
all
the
other
kind
of
major
parts
of
it
and
the
node
and
edge
classes
are
also
pretty
independent.
F
D
A
The
bridge
yep
awesome
so
that
sort
of
touches
on
obviously
the
eighth
item
there,
which
is
the
FO
RFC
itself.
So
if
there's
any
other,
you
know,
discussion
be
had
feel
free
to
add
comments
in
the
RFC
itself.
In
terms
of
the
actual
issue
for
your
resolutions,
I
know
that
there's
actually
been
a
little
bit
discussion.
While
we've
been
on
this
call
and
while
has
chimed
in
actually
on
that
and
potentially
I
guess,
we
can
close
out
the
issue.
A
Yeah
well,
it
seems
like
some
just
you
know:
there's
a
couple
people
responding
so
that
that
thread
right
now,
so
yep
cool
yeah.
So
let's
move
on
then
to
PR
one-to-one
or
121,
the
rc4
add
the
link
version
comment
since
accident
version,
I
haven't
had
enough
time
to
really
look
at
this.
These
last
two
have
been
created
just
recently.
These
last
two
are
sees
I'm,
not
sure.
If
other
folks
have
had
a
chance
to
look
at
this.
F
F
A
G
G
D
Okay,
I
had
read
this
a
bit
ago,
but
then
I
didn't
respond
because
it
was
one
of
these
ones
where
I'm
like
wow
I,
don't
really
know
how
to
feel
about
this.
Having
said
that
and
thought
about
it,
and
it
coming
back
up
again,
I
think
this
is
at
least
two
things.
So
this
comment
thing
is
like
sort
of
unrelated
yeah.
B
D
F
H
D
F
Mean
it's
it's
pushing
for
global
dependencies.
It's
not
gonna
work.
If
you
have
multiple
projects
with
different
link,
you
know
link
specs
sort
of
attached
and
I'm,
not
sure
that
there
are
very
many
cases
where
you
where
you
necessarily
want
a
global
link
rather
than
assembling
to
some
specific
target.
H
Yeah,
this
discussion
might
be
coming
from
the
same
place
or
a
similar
place
from
the
been
dependencies
one
like
similar
kind
of
pain
point
people
want
to
address,
but
like
they're
proposing
solutions
but
like
maybe
we
should
think
more
about
the
problem
itself
and
yeah,
because
I
feel
like
there's
similar
things
to
the
independence
is
like
exposing
like
this.
This
come
on
the
global
dependencies
that
they
use
all
the
time
they
don't
want
it
to
leave
in
their
projects,
etc.
D
D
Can
I,
since
you
brought
that
up
can
I
have
another?
It
would
be
nice
to
paying
the
authors
of
the
rfcs,
along
with
the
meeting
creation,
so
I
I
have
just
recently
been
looking
at
automated
meeting
creation,
stuff
and
I
had
thinking
about
actually
adding
that
to
my
little
default
meeting
creator
thing
and
since
you
brought
it
up,
I
think
it
would
because
this
is
the
second
one
even
on
this
call
where
the
the
author
is
not
present
and
I
think
would
be
very
helpful
with
we
tried
to
at.
F
A
I'll
admit,
though,
that's
on
me
to
do
a
better
job.
We
have
some
automation
for
these
calls.
I
know.
Just
before
the
new
year
we
had
the
agenda
being
created
automatically.
Unfortunately,
a
lot
of
that
pinging
generation.
These
calls
themselves.
So
it's
a
lot
of
manual
work
right
now.
You
know
we
we
serve
bootstrap
the
madhawk,
which
means
that
the
you
know
this
is
not
the
first
time
we've
actually
talked
about
making
improvements
to
that
so
Wes.
A
If
you
end
up,
you
know
fully
realizing
some
of
that
tooling
we'd
love
to
steal
that,
because
it's
not
a
we're,
not
unique
position
here.
I
know
that
is.
D
D
A
D
D
A
Absolutely
love
that
right
now,
actually,
the
generation
for
our
this
agenda
and
and
some
of
the
automation
still
lives
in
a
open
source
project
called
status
board,
which
you
may
or
may
not
also
know
so,
there's
a
bunch
of
scripts
in
there
that
generate
different
things
for
this
team,
and
so
the
agenda
is
actually
in
there.
So
you
could
go
steal.
Whatever
logic
lives
there
today,
I
have
to
manually
run
the
NPM
scripts.
A
So
the
give
action
somehow
is
failing,
but
yeah
it's
it's
good
thing
to
note
and
definitely
something
that
we
need
to
do
for
the
deep
dives.
Those
are
a
bit
more
manual
where
I
often
have
pings
some
of
the
folks
that
have
been
most
loud
in
different
discussions
to
hopefully
bring
them
to
those
deep
dive
discussions.
So
I'm
not
sure
how
we
can
automate
that
so
much
as
there's
a
bit
of
manual
work
about
which
topic
we're
gonna
be
discussing,
but
the
definitely
the
agenda
creation
can
ping.
A
The
authors
of
those
those
RFC's
are
the
issues
for
sure
awesome,
okay,
so
moving
on
then
I
do
want
to
leave
a
little
bit
of
time
at
the
end
of
this
call
to
discuss,
maybe
what
that
topic
will
be
for
their
next
week's
deep
dive.
So
the
last
item
on
here
the
last
are
see
actually
that
we
have
identified
is
adding
types.
So
our
CR
and
pull
pull
request,
number
1
to
6
or
126
would
be
adding
type
or
type
information
it's
at
the
Packman
I
know.
This
is
something
that
I've
been
poked
about.
A
D
D
because
like
why
would
they
support
my
offshoot
type?
You
know
definition,
language
or
flow
I,
don't
know,
maybe
flow,
even
just
flow,
have
a
type
separate
type
definition
either
way.
If
we
did
typescript
support
in
this
way,
I
think
we
would
have
to
make
sure
we
consider
how
other
ecosystems
would
would
be
either
disproportionately
or
disadvantaged
by
that
choice.
Right.
B
F
At
like
the
you
know,
looking
at
the
the
lifecycle
of
JavaScript
frameworks,
they
they
tend
to
rise
and
fall
with
the
you
know
with
the
years
and
it's
a
it's
a
pretty
safe
bet
that
react
will
be
around
in
you
know,
or
typescript
will
be
around
in
another
three
to
five
years.
It's
it's
a
much
less
safe
bet
that
it'll
still
be
around
in
the
next.
You
know
five
to
ten
years
there
or
without
you
know
or
that'll,
be
it's
a
safer
bet,
that'll
be
superseded
by
something
else.
F
They
kind
of
rise
up
and
they
reach
some
steady-state
and
then
and
then
dwindle
or
trickle
off,
like
handlebars
and
jQuery
are
still
very,
very
widely
used,
but
they're
not
growing
like
they
used
to
be
so
I
hear
you
on
the
the
privileges
you
know,
sort
of
privileged
in
typescript
per
se.
I
think
it
might
be
a
mistake,
and
you
know
it
may
be.
F
It
may
end
up
being
a
wart
that
we
come
to
regret,
especially
if,
if
typescript
eventually
changes
the
way
that
they
do
type
inference
or
type
information-
and
there
are
other
typing
systems
I
know,
Hagel
is
one
that
I
was
actually
looking
at
recently.
That's
pretty
cool
but
and
also
uses
the
same
type
type
definitions
that
typescript
does
just
kind
of
to
to
piggyback
on
the
on
that
community's
popularity.
F
One
one
thing
about
this
RFC
in
particular
I
mean
there's,
there's
nothing
stopping
you
from
doing
this
today,
right
you
can,
you
can
just
sort
of
put
it
in
your
package.
Json
and
it'll
show
up
in
the
PACU
MIT
like
it's.
It's
actually
that
simple.
It
won't
show
up
in
the
minified
vacuum
in
unless
we
do
a
little
bit
of
extra
work.
But
if
people
start
using
using
that
stuff
pretty
widely
like,
then
of
course
we
would.
F
We
would
add
that
to
the
to
the
minified
packing
mint,
if
there
was
some
reason
to
add
tree
generation
or
search
time,
getting
it
into
the
actual
website.
Again
is
more
of
like
a
product
feature
request,
you
know
and
and
the
the
argument
for
doing
that
is
well
all
of
these
packets
Jason's
that
have
been
published
already
have
type
information
kind
of
bundled
into
them.
F
G
A
F
So
I
think
really
the
I'm
not
sure
what
the
ask
is
here
as
far
as
what
the
CLI
does.
You
know,
if
you
I
think
the
ask
here
is
like
infer
that
there
is
a
typing
file
when
we're
publishing
and
you
know,
if
you
see
like
index
DTS,
then
we
automatically
adds
something.
Some
acumen
when
we
probably
Alec,
has
type
script
definition.
A
G
That's
not
even
the
same
file
name
like
it's
not
always
gonna
be
food
is,
and
food
ETS,
like
often
you'll,
have
one
big
mega
DTS
file
for
the
entire
project
and
a
bunch
of
scattered
files
that
are
transpiler
outputs,
so,
like
I,
really
think
that
the
the
Taipings
field
and
I'm
not
advocating
for
it
I
agree
with
West's
concerns
about
over
privileges.
Things
like
that,
but
I
really
think
the
type
of
like
exposing
the
Taipings
field
is
probably
the
most
straightforward
solution.
G
F
I'm
not
I
mean
I'm,
just
not
sure
why
we
would
need
it
at
package
resolution
time,
which
is
what
the
the
Corgi
doc
is
for,
exposing
it
on
the
website.
I
mean
yeah
totally
fine
with
that,
but
I
think
also
we
I'm
trying
to
shy
away
from
adding
a
lot
of
extra
fields
to
the
package.json
file
that
we
read
and
publish.
So
from
that
point
of
view,
III
would
almost
say
like:
let's
just
not
do
it
like,
if
you
want
to
put
it.
G
F
Yes,
not
the
pack
of
it.
The
packing
mint
is
okay,
the
the
full
okay,
so
packing
mint
is
actually
a
vague
term.
The
full
metadata
pack
you
mint
is
everything.
It
includes
the
description
it
includes
the
author
name,
it
includes
a
bunch
of
you
know
junk
that
you
don't
need
when
you're
just
installing
a
package.
The
Corgi
dock
is
the
minified
packing
mint,
which
only
has
the
dependencies,
and
you
know
the
bin
scripts
and
the
things
that
we
kind
of
need
to
like
consider.
While
building
the
tree
does
the
full
packing
mint.
F
F
D
H
There's
one
point:
we're
missing
from
the
RFC:
I
was
just
going
over
it.
Well,
we
discussed
and
the
implementation
section
there
they
do
mention
that
they
would
like
to
to
the
CLI
to
be
checking
for
the
existence
of
the
type
definition
like
the
definition
files
and
then
possibly,
if
they're,
not
there
right,
so
that
that's
a
change,
we're
COI.
F
F
C
F
There
are
bin
scripts,
then
we
we
make
sure
that
they're
included
in
the
in
the
the
PACU
the
package
artifact.
We
could
do
the
same
with
a
typing's
file.
Description
like
I,
don't
feel
like
that's
sort
of
it's
probably
widely
enough
used.
That
that
feature
is
fine.
You
know
we
do
similarly
with,
like
I
think
we
do
a
similar
thing
with
a
note
chip
file
and
a
couple
of
other
things
that
are
probably
less
widely
used
than
typescript
definitions.
F
But
all
that
being
said
like
again,
assuming
that
you
are
not
excluding
the
thing
from
your
package
in
some
way,
then
it
will
be
included,
and
you
can
put
this
filename
in
your
package.
Json
today,
like
show
me,
show
me
people
using
that
and
show
me
a
way
that
I
can
make
their
life
a
little
easier
and
I'll
probably
do
it.
But
if
it's,
if
it's
a
lot
of
kind
of
net
new
work
or
or
changes
to
how
we
do
tree
resolution,
then
that
starts
to
peel.
That's
what
makes
it
a
lot
more
costly,
yeah.
A
Just
to
be
mindful
we're
at
time
about
a
one
minute
over
actually
I
want
to
propose
the
the
question
and
and
appreciate
the
discussion
here.
I
think
there's
more
conversation
be
had
about
this
RC
actually
and
I
see
itself
and
just
a
saw,
so
he
asked
more
more
thoroughly
and
what
we
would
need
to
do
to
support
that.
F
C
A
A
Effort
appreciate
that
that's
great,
hopefully,
we'll
have
Claudia
back
on
by
next
week
to
help
with
that.
I
know
she's
being
doing
a
great
job
there.
So
again,
I
appreciate
it
really
jumping
on
for
the
RCA
call
today
and
again,
hopefully
keep
having
discussions
in
the
issues
and
pr's
themselves
and
I'll
see
you
next
week,
yeah
cool,
oh
my.