►
From YouTube: Open RFC Meeting - Wednesday, June 17th 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
Awesome
and
we're
live
on
YouTube.
Thank
you.
Everybody
again
for
joining
another
open,
RFC
call
and
apologize
for
your
getting
a
few
minutes
getting
started
a
few
minutes
late.
Today's
date
is
June
17th,
Wednesday,
June,
17th
and
just
for
a
quick
update.
This
is
usually
the
time
slot
for
the
RC
deep
dive,
which
is
my
I,
think,
a
meeting
invite
isn't
standardized
yet
across
the
two
alternating
call
times
so
apologize
for
folks
that
had
some
confusion.
A
A
The
gist
here
is
that
we
would
really
like
folks
to
be
mindful,
and
if
you
want
to
be
show
you
your
opinion,
please
raise
your
hand
and
just
be
kind
and
thoughtful
to
folks
when
they're
speaking
desired.
Outcomes
of
this
call
is
essentially
to
help
move
forward.
Rcs
give
the
community
an
extra
channel
and
a
means
of
communicating
with
the
MPM
team,
and,
ideally
you
know,
make
some
progress
and
discuss
items
that
are
important,
including
the
RFC's
themselves.
A
We
have
a
smaller
agenda,
but
I
want
to
also
quickly
acknowledge
some
new
folks
that
have
actually
sort
of
joined
the
ranks
I
wanted
to
maybe
give
miles
who
most
folks
I
think
know
on
this
call
opportunity
to
say,
hi
and
maybe
explain
a
bit
about
some
changes
that
he's
had
in
his
personal
life,
and
maybe
why
he's
joining
today.
I'm
in
this
call,
you
I
do
a
quick
introduction
in
the
mouth
yeah.
B
I
selfishly
also
have
you
know,
like
my
own
legs,
small
product
things,
I'd
love
to
see
happen
like
better
support
for
package
exports
and
stuff,
like
that,
but
I'm
sure
my
bias
will
will
show
pretty
quickly.
I'll
also
be
working
across
a
variety
of
other
products
from
github,
including
you
know,
like
actions
and
packages,
maybe
pages,
like
kind
of
anything
that
has
to
do
with
the
end-to-end
experience
for
a
developer
sitting
down
and
getting
productive
with
github
I'm
still
going
to
be
active
in
node
and
open
j/s
in
tc39.
B
So
you
know
if
you
have
any
direct
feedback
to
give
me
about
the
way
that
I'm
engaging,
because
it's
a
new
spaces
that
I'm
working
in
you
know.
Please
feel
free
to
bring
that
to
me.
I
recognized
a
number
of
people
on
this
call.
We
already
know
a
way
to
get
a
hold
of
you
privately,
but
you
know
most
of
my
information
is
available
on
either.
You
know
my
Twitter,
where
my
DMS
are
up
in
or
if
you
go
to
my
website
and
use
Kluth,
just
a
tiny
bit.
B
A
Know
we're
excited
to
be
doing,
and
it's
great
to
see
you
on
these
calls
now
so
yeah,
it's
it's
exciting,
so
I
would
another
quick
claps,
claps
and
chat
another
quick
announcement
or
update
for
folks
I
know
this
has
come
up
quickly.
The
open
jazz
club
summit
and
the
open
Jas
world
is
it's
happening
next
week.
I
know
a
number
of
folks
here
also
are
in
the
various
and
nodejs
working
groups.
I
know:
there's
a
package
maintenance
working
group
session,
which
I
think
Wes
will
be
there.
I
will
be
there
for
sure.
A
I
know
that
their
mouths
is
actually
running.
Also
I
think
you're
doing
a
talk.
Next
week,
I'm
gonna
try
to
be
running
a
workshop
for
essentially
a
broad
broad
scope,
contributing
to
NPM
session.
So
there's
there's
a
number
of,
and
actually
next
week,
I
think
we'll
probably
be
skipping.
This
call
in
lieu
of
doing
essentially
a
open
Jes
that
coordinates
what
collapse
on
it.
So
the
agenda
I
think
is
still
being
I'm,
not
sure
if
it's
completely
finalized
I
know
that
Joey
had
posted
a
PR
for
for
that.
A
That
draft,
but
I
think
it's
it's
almost
almost
completely
solid
in
in
concrete
right
now,
so
I'll
make
sure
to
post
that
or
add
this
to
the
meeting
notes,
if
possible.
Just
so
everybody
knows
where,
where
we'll
be
next
week
and
and
the
different
touch
points
will
have
I'm
pretty
excited,
you
know
this.
It's
unfortunate
that
we
can't
be
together
and
and
in
the
same
space
together
to
collaborate,
as
is
often
the
case
to
hopefully
change
up
the
way
that
we
interact,
because
we're
are
a
virtual,
pretty
much
90%
of
time
with
each
other.
A
A
What
I'll
do
and
take
as
a
an
action
item,
is
to
add
that
to
our
public
events,
calendar,
which
is
already,
if
folks,
have
already
been
using
that
and
we'll
try
to
keep
that
up
to
date.
For
now
in
the
long
term,
that
may
not
be
the
source
of
truth
going
forward,
as
I
mentioned,
that
being
at
a
call
like
I
know,
it's
been
tough
and
a
bit
confusing
to
figure
out
which
link
to
jump
on
and
there's
been.
A
D
I
think
that
some
people
already
found
this
I
mean
not
useful
right
now,
because
they
cannot
use
it
like
that,
like
it
is,
but
I
think
a
lot
of
people
have
has
a
struggle
and
even
with
workspaces
from
other
solutions
that
they
have
probably
tried,
have
faced
this
problem,
where
you
want
to
maybe
focus
with
just
one
part
of
your
workspace,
and
you
still
have
to
do
a
lot
of
work
installing
all
dependencies
for
everything
so
yeah.
We
think
we
should
maybe
discuss
this
now
when
we
start
pressure.
A
I
appreciate
you
jumping
on
I
know.
We
talked
to
you
last
minute
there,
so
so
yeah.
So
the
again
the
agenda
is
listed
in
the
hack
MD
file
feel
free
again,
if
you
have
an
add
yourself
to
the
attendees,
you
can
do
that
there,
the
first
item
and
just
want
to
give
folks
time
Before
we
jump
in
it.
Was
there
any
other
announcements,
No,
okay,
well,
jumping
into
the
first
item,
PR
number
150,
essentially
yeah
David.
D
Sure
so
this
comes
as
a
as
an
idea
when
we
are
working
with
large
repositories
which
are
usually
managed
by
work
spaces,
either
Garan
workspaces,
lerna
or
any
other
kind
of
workspace
tool.
Usually
we
have
to
download
all
the
dependencies.
Never
it
doesn't
mind
if
we
just
want
to
work
with
just
one
packet
or
a
couple
of
packets
which
are
actually
linked,
which
means
that
we
have
to
spend
a
lot
of
time
installing
in
one
of
our
cases
we
have
mono
repo,
which
is
using
like
26
or
something
that
packages
which
are
in
a
workspace.
D
So
there's
not
a
lot
of
dependencies
when
we
want
to
work
with
it.
So,
if
I
will
like
to
focus
only
on
a
specific
package,
I
will
I
will
rather
just
rebuild
or
install
all
the
dependencies
that
are
actually
linked
to
my
package.
This
is
one
of
the
things
that
probably
can
be
achieved
with
just
linking
the
packages
with
the
existing
file
protocol.
But
the
thing
is,
we
are
missing
a
couple
of
a
couple
of
issues
that
we
have.
One
is
dependency
hoisting,
sometimes
with
the
actual
file
protocol.
D
Hoisting
of
dependencies
is
not
trigger
correctly,
like,
for
instance,
within
one
of
the
examples
I
created.
We
have
a
dependency
on
one
package,
which
is
like
a
common
set
of
building
tools
which
includes
typescript.
So
when
we
install
the
dependencies
by
just
normal,
linking
the
typical
dependency
is
in
the
node
modules
of
that
package,
but
it's
not
hoisted
to
the
top
package,
which
will
be
normally
done
if
it
was
just
a
dependency
which
is
coming
from
NPM
right.
D
That's
one
of
the
problems
and
the
other
problem
is
we
actually
want
to
build,
and
if
we
have
any
distributable
in
the
in
those
packages
right,
we
don't
want
to
first
install
link
and
then
go
through
each
and
every
one
of
those
packages
building
the
JavaScript
or
typescript
or
whatever.
So
we
can
later
start
using
the
the
different
the
route
package
so
as
to
say
so.
D
Having
these
four
links,
linkle
packages
within
our
working
directory
or
our
workspace
is
the
behavior
that
we
will
expect
to
be
having,
and
the
problem
is
that
if
we
just
go
through
each
of
the
packages
and
turbo
and
then
link
it's
much
more
costly
than
if
we
it
automated
in
a
way,
this
file,
plus
back,
is
trying
to
aim
for
that.
So
whenever
you
depend
on
any
other
pockets
in
your
local,
and
you
want
to
do
some
process
to
build
it,
then
you
are
able
to
trigger
the
pack.
D
A
D
Are
not
solving
it?
We
are
relying
on
the
workspace
tools
that
we
have.
So
if
we
are
working
with
yarn,
this
means
we
have
to
do
all
the
installs
and
run
the
build
scripts
through
all
the
worker
spaces
that
actually
have
builder
script
and
it
takes
a
while-
and
sometimes
we
just
don't
want
this
or
if
so,
if
a
developer
is
working
with
a
man
or
a
boy
in
his
local
machine,
they
need
to
go
through
all
these
installing
of
dependencies
building
of
dependencies
when
maybe
they
just
need
very
minimal
subset.
C
D
E
Don't
think
so,
I
think
it's
just
doing
the
linking
I,
it's
been
a
while
so
I
wouldn't
take
that
as
a
definitive
answer
but
I
when
we
used
lerna
on
one
of
the
projects
I
worked
on.
Maybe
a
year
ago
we
ended
up
having
to
write
a
script
that
just
went
through
and
did
all
the
pre
builds.
So
so
I
was
gonna.
Ask
I,
feel
the
pain
of
this,
but
I
hesitate
to
think
the
solution
should
be
a
new
protocol.
I'm
not
saying
I
disagree
with
that
I.
Just
we've
already
got
workspaces
being
worked
on.
E
We
were
going
to
say
that,
but
workspaces
are
in
the
works
and
what
would
be
the
difference
that
adding
a
protocol
here?
What
would
be
the
bigwig?
What
is
it
just
running
the
scripts
there
because
then
it
seems
like
we
could
just
add
a
workspace
pre-pack
or
you
know,
whatever
a
command
that
does
the
behavior
we
want,
without
necessarily
having
to
introduce
a
new
protocol
to
get
the
same
end
result
right.
Yeah,.
D
And
that's
actually
one
of
the
questions
that
I
had.
If
you
are
going
to
work
with
workspaces,
will
you
be
able
to
like
focus
and
maybe
say:
okay
I
want
to
work
with
this
workspace
and
it's
dependencies,
so
you
don't
have
to
install
all
the
dependencies
of
all
the
workspaces.
If
we
could
do
this,
I'm
not
sure
if
we
could
also
maybe
run
a
script
which
is
built
focused
only
on
the
root
package
plus
its
dependencies,
but
then
it
will
solve
this
problem
at
all.
D
So
we
don't
think
we
will
need
a
new
protocol,
but
I
think
that's,
even
if
you
don't
want
to
use
workspaces.
Maybe
you
have
a
very
small
project
that
really
don't
feel
like
managing
before
spaces
I.
Don't
know
we
already
have
the
file
protocol.
If
this
file
protocol
is
just
doing
the
linking,
maybe
it's
not
so
useful
for
you
so
I
think
it
could
be
maybe
even
an
improvement
on
top
of
the
file
of
the
existing
file
protocol.
So.
E
Actually
found
the
file
protocol
since
it
changed
behavior
to
be
almost
useless
like
agree,
I,
never
use
it.
I
used
to
have
I
had
my
whole
last
company.
Our
entire
setup
was
based
on
on
file
protocol
things
and
like
as
soon
as
you
all
change
that
it
broke
it
and
we
I
think
I
well
to
come
back
left
a
couple
a
long
time
ago.
So
you
know
who
knows
but
not
having
a
replacement
that
actually
copies
the
files
over,
as
has
been,
you
know
unfortunate
to
me.
A
Which
might
be
David's
notes
there
and
then
in
terms
of
how
we
would
be
implementing
something
like
NPM
pack
and
for
the
workspace
aware,
I'm,
fairly
positive.
We
will
be
running
lifestyle
event,
our
lifecycle
events
appropriately,
so
I've
learned
it
today
isn't.
That
is
something
that
you
know
like
for
each
one
of
these
items
that
I
think
you're
trying
to
solve
for
David
I
think
that
we
might
have
existing
conversations
going
on
to
try
solve,
for
and
and
maybe
where
you
can
speak
to
the
at
least
the
workspace
as
effectively
sure.
C
Yeah
yeah,
it's
one
of
the
conversations
we're
gonna
have
today
about
the
running,
the
sub
commands
and
yeah,
but
important
part
of
the
proposal
having
the
ability
to
scooter
or
a
specific
workspace,
or
you
can
also
define
groups
of
workplaces.
Hey
order,
everyone
No
so
just
to
wrap
up
like
I,
also
checked
the
learner.
I've
been
thinking
a
lot
in
the
work
of
workspace.
It's
also
consulting
their
dog,
so
I
had
these
at
times
and
as
a
part
of
the
bootstrap
phase,
they
also
run
like
pre
publishing
and
prepare
my
scripts,
so
yeah
not
packed.
C
D
C
D
C
That
this
kind
of
behavior
like,
if
not
entirely
like
just
satisfied
by
the
workspaces
futuring
running
sub,
commands
like
it
would
be
nice
to
also
try
out
with
external
tooling
from
from
the
community,
so
that
we
can
like
actually
like
feedback
before
really
going
for
something
less
fundamental.
Like
of
a
change
like
a
protocol.
A
C
E
E
You
know
as
if
you,
if
you
go
and
we're
going
to
go
and
publish
it,
you'd
get
you'd,
be
able
to
test
that
which
is
caught.
People
off
guard,
especially
lately,
I
think
which
might
lead
into
some
of
the
like
exports
and
write.
Wasn't
there
a
big
thing
recently
that
broke
because
somebody
published
with
the
bad?
C
B
I
think
speaking,
really
quickly
less
to
what
you
were
talking
about
there.
This
is
a
little
tangential,
so
we
don't
need
to
dig
in,
but
something
I'm
interested
in
exploring
as
well
is
like
what
kind
of
pre
published
validations
might
be
able
to
be
done
on
both
the
client
and
the
server.
The
is
promised.
Failure,
for
example,
would
not
have
been
able
to
be
published
if
there
was
like
a
validation
of
the
exports
map.
B
There's
also
like
a
historic
bug
that
I
love
and
then
in
particular,
sub
stack
used
to
get
hit
by
all
the
time
because
of
like
race
conditions
in
the
CLI
client.
That
only
were
observable
on
like
a
really
really
old
PC
that
he
used
to
publish
from
we're
like
periodically
index.jsp
just
not
end
up
in
the
tarball.
B
Now,
I'm
not
saying
that
this
is
happening
anymore,
but,
like
I,
think
that
there
are
some
really
basic
validations
that
can
be
done,
such
as
like
what
does
main
point
to
does
that
file
exists
in
the
tarball
like,
even
just
that
has
like
a
published
validation
is
like
one
of
those
things
that
could
probably
stop
a
whole
slew
of
different
publication
errors
that
I've
seen
kind
of
be
very
disruptive
to
the
ecosystem.
Before
so.
A
One
quick
note
on
that
and
then
David
I
see
you
have
your
hand
up
and
I
know
that
NPM
doctor
was
supposed
to
and
I'm
not
sure
how
many
people
actually
use
that,
but
was
supposed
to
help
with,
like
you
know,
I
think
help
with
running
a
whole
bunch
of
tests
against
your
environment
and
your
package,
so
I'm
not
sure.
If
that's
like,
we
can
extend
upon
that
and
or
like
you're
saying
miles
like
add
it
add
sanity
level
validation
to
the
pack
they
would
like.
Would
you
like
that?
Yes,.
D
Sure
I
wanted
to
go
back
one
moment
to
what
was
mentioned
about
changing
the
behavior,
where
we,
instead
of
linking,
we
just
copied
the
files
over
to
the
actual
tree
of
knowledge
that
we
would
have
and
I
think
I'm.
Speaking
on
behalf
of
Isaac's,
he
mentioned
that
we
should
probably
just
do
this
one
so
one
when
we
installed
the
first
time
we
just
copy
all
the
files
over
to
the
to
the
tree.
But
what
if
we
want
to
rebuild
it,
we
do
we
have
to
do
maybe
some
kind
of
switch.
D
E
I
this
was
the
workflow
we
basically
used
when
we
were
relying
on
these
file.
Protocols
work
sorry
I'm
outside
that
was
a
taco
truck
anyway.
So
so
we
had
a,
we
had.
A
separate
link,
I
think
was
using
back
in
the
day.
I
think
it
was
called
NPM
link
local
if
I
remember
correctly,
and
then
it
would
replace
all
of
the
file
dependencies
with
links
when
we
were
working
on
them
and
I
think
we
had
like
a
special
filter
that
we
could
link.
E
We
use
the
same
package,
but
it
would
only
link,
though
the
ones
you
were
working
on
at
the
time.
It
wasn't
not
a
great
developer
experience,
but
it
sense
the
way
we
had
it
structured
you
weren't
regularly
or
you
weren't
always
it
was
maybe
50
50
when
you
were
working
on
application
logic
versus
common
library
logic,
so
so
at
least
50%
of
the
time
the
developers
on
that
team
were
just
running.
E
You
know
the
normal
NPM
install
and
then
never
touching
any
of
the
workspace
dependencies,
and
so
it
works
really
well
in
that
regard,
for
them
to
just
when
they
knew
that
they
were
gonna,
be
working
on
a
on
one
of
the
dependencies.
They
would
just
link
it
in
you
know
independently,
so
that
sort
of
would
solve
that
right,
because
you'd
have
the
the
behavior
that
you
want
when
you're
not
weren't
working
on
them,
which
is
give
me
the
full
tree
right
and
D
duped
and
hoisted
and
everything.
A
Okay,
is
this
just
to
be
my
fault
I'm
here
and
I've
folks
have
noticed
I've,
actually
added,
we
added,
or
does
our
see
you
next
and
to
make
sure
it
doesn't
go
last
as
being
tradition.
Unfortunately,
is
there
any
initial
next
steps
that
we
can
provide,
or
maybe
give
some
more
context
around?
The
other
I
know
we're
going
to
talk
about
sub
commands
here
as
well,
but
in
terms
of
like
adding
some
feedback
to
this?
Yes,
regarding
I.
C
Saw
I
just
also
comment
in
the
Reno
issue:
it's
not
linked
back
to
the
RFC
important
lately.
So
took
me
a
while
to
read
those
but
yeah
he's
particularly
interested
in
like
having
this
outside
of
workspaces
right,
like
I
mentioned,
like
we've
been
doing,
is
lower
ourselves.
All
this
time
right
is
as
a
reliable
way
to
test
a
package
before
publishing
so
yeah.
It
seems
that
there's
there
is
appetite
from
eyes
excited
to
actually
explore
a
protocol
kind
of
thing,
so
it
would
be
awesome
to
collect
feedback
on
the
RFC
itself.
Yeah.
C
A
D
A
Problem,
so
our
next
item
on
the
agenda
is
126,
so
just
out
of
this
again
adding
file
types
to
package.json
in
the
registry
order,
I
apologize
that
we
haven't
been
able
to
give
you
enough
time.
So
hopefully,
now
is
good,
and
would
you
like
to
give
us
a
quick
update
on
on
the
RC
and
maybe
some
of
the
work
that
you've
been
doing
ASA
good.
F
If
it's
all
done
on
the
registry,
which
was
not
a
goal
of
mine,
my
goal
is
to
try
and
do
it
all
myself
so
and
it
would
just
just
get
done
so
that
that
actually
just
put
a
little
bit
of
a
question
back
on
this,
it
would
have
to
go
on
someone's
end
on
some
of
MPM
teams
roadmap,
basically
to
get
it
done,
but
so
I
would
say
it
as
it
is
now
it's
non-controversial
and
basically
ready
to
go,
but
now
it
requires
actually
game-pod.
So
it's
roadmap,
because
I
don't
know.
A
A
Shape
like
that
is,
is,
is
on
the
registry
team,
usually
to
to
write
the
the
code
to
actually
ensure
that
something
gets
like
essentially
privileged
and
because,
as
you
know,
there's
lots
of
things
in
folks
package
JSON
so
and
we
don't
map
everything
once
one
and
and
there's
also
a
a
more
slimmed
down
version
of
documents
called
Cordy,
Corgi
Docs,
you
know
so
like
little
dogs,
Corgi
dogs,
very
cute.
That
also
would
go
into
that.
A
So
just
we
can
I
think
like
this
as
a
registry
or
put
a
label
on
registry,
ideally
get
somebody
from
that
side,
I'm,
gonna,
guess
Edie,
Thompson
who's
being
also
starting
to
join.
These
calls
is
the
new
product
manager,
as
well
for
for
MPM
from
github
might
be
good
to
just
have
him
join
and
that
conversation
and
get
sign-off
and
make
sure
that
we
can
get
backlogged
and
then
give
you
maybe
a
time
line.
A
G
I'm
just
looking
through
the
RFC
for
the
type
stuff,
and
so
something
that
I
would
say
that
I
consider
a
mistake
from
early
nowadays
is
treating
paths
and
package.json
that
start
with
letters
as
being
relative
to
the
package
route,
and
we
corrected
that
for
the
exports
field,
for
example.
So
you
have
to
use
dot.
Slash,
there's
two
reasons
for
that.
One
is
that
it
makes
it
unambiguous
by
requiring
that
start
with
a
dot.
G
So
one
of
the
things
I
thought
we
talked
about
was
being
able
to
say
that
my
package
has
types
and
its
types
are
in
a
different
package,
and
that
might
be
my
corporate
mega
types
package
or
that
might
be
a
definitely
typed
package
or
whatever,
but
so,
like
the
current
RFC
PR,
it
looks
like
it
just
has
a
single
path
that
doesn't
start
with
a
dot
and
doesn't
and
thus
precludes
it
being
a
different
package.
Identifier,
yeah.
F
E
E
E
Exclusions,
amazing,
look
at
Texas
right
that
only
that
excludes
you
to
definitely
type,
though
right.
So
if
we
wanted
to
like
Jordan,
was
saying
provide
a
at
Corp
mega
types
right
which
had
all
of
our
you
know
our
custom
things,
and
maybe
it
includes
some
open
source
ones
that
were
missing
types
that
we.
We
don't
support
that
today,
yeah.
F
A
G
Backlog
and
to
be
clear,
I
wasn't
trying
to
say,
I
think
that
the
feature
should
wait
on
supporting
a
pair
identifier,
pointing
to
a
package.
I
was
saying
that
if
you
restrict
the
design
space
to
only
supporting
starts
with
a
dot
slash,
then
you
leave
that
open
for
a
future
RFC,
and
you
can
unblock
your
common
case
of
a
relative
file
in
the
package.
That's
that's
up
to
y'all
to
figure
out
what's
the
best
path
but
like
I,
haven't
ero
concerns
about
you
know
doing
it
in
multiple
steps.
A
A
So
the
next
item
in
the
agenda
is
our
C
number
129.
This
is
the
overrides,
are
C
I
notice
and
just
for
to
be
mindful
I
see
that
Sultan
of
PMPM
made
some
comments
in
the
RFC
itself
a
couple
days
ago
and
Isaac's
actually
on
vacation
at
the
moment,
so
it's
reasonable
that
he
isn't
jumping
on
the
call
today
but
notice
there
was
some
updates
there,
just
basically
around
the
sheep
and
potentially
changing
the
design.
Did
anybody
on
the
call
have
a
chance
to
look
at
those
comments
want
to
add
anything.
A
E
A
E
A
E
Been
messing
around
with
some
of
this
stuff
and
I've
actually
found
some
cases
where
I
get
some
pretty
unexpected
behaviors
if
I'm
putting
things
in
weird
places.
So
if
you
have
something
in
like
prod
and
dev
and
they
specify
different
versions,
there's
different
behavior
than
if
you
have
it
with
here
and,
like
you
know,
I
I
haven't
written
out
test
cases
for
everything
yet,
but
it
might
be
worth
discussing
what
the
use
cases
are
for
supporting
the
same
depth
in
multiple
blocks.
E
Anyway,
there
are
certain
ones
that
are
really
good
and
I'm,
not
saying
there
aren't
but
I'm
just
saying:
there's
some
that
don't
make
any
sense
and
almost
I
can't
imagine
them
ever
making
sense
right
like
you,
you
just
and
they
don't
even
resolve
the
tree,
doesn't
respond,
respect
it
right.
So
if
you
put
lodash
in
prod
depths
at
one
dot,
oh
and
low
in
dev
depp's
into
tato,
like
you
can't
unless
you
aliased
it,
you
can't
install
that
anyway.
E
So
like,
what's
the
point
in
supporting
that,
so
if
we
can
figure
out
which
which
combinations
actually
make
sense,
then
it
might
give
a
little
bit
of
illumination
on
what
we
would
want
to
support
it
overrides
there
because
again,
optional
and
dependencies
doesn't
make
sense
and
that's
his
example
right
like
if
you
put
it
as
dependencies,
it's
good,
it's
not
optional
anymore.
It's
it's
a
dependency
right.
C
Yeah
Wes,
if
you
want
to
look
back
I,
think
it's
a
fair
to
just
leave
this
RC
open
for
a
while
and
collect
more
feedback.
I
know
that
there's
this
ongoing
discussion
between
as
a
consultant
there
already
so
I
think
it's
fair
to
maybe
yes,
I
think.
G
A
Okay,
this
is
it
feels
like
the
alias
all
over
again.
Okay
I
think
just
allow
Isaac
and
his
hoping
to
jump
on
the
call,
probably
also
to
bring
this
up
if
folks
feel
like
they
want
to
add
any
comments
to
the
RC
itself.
Again,
that
was
1:29
I'm,
definitely
jump
in
there.
If
you
have
thoughts
just
to
be
mindful
of
time,
we
have
about
13
minutes
left
and
only
about
three
items
left.
So
if
we
can
try
to
spend,
you
know
three
to
four
minutes
max
on
each
the
next
three.
That
would
be
great.
A
Oh
yeah
right
did
you
just
pull
one
out
or
did
I
just
do
that
yeah
yeah?
What
the
types
again?
Sorry,
okay,
okay
great!
So
we
only
have
two
left
and
so
the
next
item
in
our
agenda
when
some
RC
and
p.m.
workspaces
running.
Why
did
you
want
to
give
a
quick
update
on
where
you're
at
with
that,
in
the
updates
you
made
since
last
week,
yeah.
C
I
guess
the
update
the
action
item
we
had
was
to
create
a
poll
right,
so
I
went
ahead
and
created.
So
maybe
we
want
to
just
take
the
time
to
advertise
it
a
little
bit
more,
but
it's
basically
to
collect
this
casual,
collect
community
feel
like
sentiment
on
what
spell
they
want
to
filter
out
workspaces
and
when
running
sub
comments
in
them
and.
D
A
A
A
C
C
Basically
the
ability
of
like
globby
wait
along
with
the
flag
and
yeah
I
haven't,
replied
yeah
but
I'd
like
to
discuss,
because
that's
the
other
aspect
of
the
RFC
providing
a
way
to
basically
create,
like
groups
or
alliance
of
of
a
set
of
workspaces
that
you
can
kind
of
predefined.
So,
instead
of
using
blobs,
you
would
point
to
these
Alliance
to
these
groups
and
you
would
invoke
the
flag
with
those.
Is
that,
but.
A
G
You
know
every
time
react
adds
a
new
minor
like
this.
There
has
to
be
globs
somewhere
and
it
seems
like
in
general.
I
kind
of
it's
always
always
feels
friction,
friction
II
and
weird,
when
something
that's
supported
in
config
isn't
supported
in
a
CLI
argument
and
vice-versa
I,
don't
think
NPM
is
axiom
of
their
always.
The
same
necessarily
has
to
apply,
but
in
general,
like
it's
nice
when
there's
parody,
so
it
seems.
G
C
G
Have
it
and
I
would
expect
the
the
group
definition
to
be
the
same
schema
as
the
filter
flag?
In
other
words,
a
group
is
a
predefined
filter,
a
filter
is
you
know,
and
then,
and
then
there,
the
relationship
between
those
things
is
clear
and
and
like
it's
it's.
It
would
feel
less
to
understand
to
me
and
to
educate
as
well,
because,
like
it's
just
whatever
you're
running
on
the
command
line
with
filter,
oh
you're
typing
that
a
lot
make
it
a
group,
and
then
you
don't
have
to
type
it
as
much.
C
And
I
think
I
think
having
them
as
a
group
that,
like
usually
at
least
from
my
experience
when
you
have
a
you,
know,
collaborative
workspaces,
you're
working
with
other
people,
you
want
to
share
it.
It's
kind
of
like
you're,
always
good,
like
most
of
the
time
you're
going
to
be
running
these
the
same
set
of
workspaces,
it's
like
to
have
them
in
the
package
Jason
and
as
a
way
to
share
with
the
rest
of
the
team.
Well,.
G
That's
why
that
the
parody
is
nice
between
I,
do
I've
been
using
npx
on
the
command
line
now
I
want
other
people
to
be
able
to
use
the
same
command
now.
I
take
the
part
after
npx
and
that's
an
NPM
run
script
right,
like
it's
nice
that
there's
a
parody
there
yeah.
This
would
be
nice
to
have
it
between
groups
and
filters.
A
C
We
have
yeah,
we
haven't
heard
back
from
CBE
right.
He
mentioned
he
would
like
to
still
be
engaged,
that
I
mean
they're
real
right
at
RFC
or
even
like
writing
a
new
one
right.
Seeing
that
such
a
dated
one
and
we
discuss
it
like
fundamental
changes
in
it,
so
we
kind
of
let
it
open
to
him
like
if
he
wants
to
just
update
this
one
and
we
can
like
kind
of
follow
along
or
if
he
wants
to
kind
of
actually
write
a
new
one
to
exclude
all
the
mention
is
to
interactivity.
C
E
Just
gonna
add
I'm
working
in
a
similar
space
right
now.
Internally,
my
hope
is
to
build
something
that
we
think
is
open.
Source
of
all
seems
to
be
now
so,
if
you're
putting
this
I
would
much
rather
use
your
stuff,
then
build
my
own,
but
it
so
it's
out.
Does
it
sound
like
that
would
be.
You
know
NPM,
eight
anyway
or
like
what's
the
story?
E
D
A
Because
overrides
and
any
audit
resolution
type
like
anything
that
would
change
those
either
some
commands
or
the
installation
process
we
have
to
be
mindful,
but
I
mean
this
is
something
we're
talking
about
internally
and
now
also
with
miles
coming
on
board
with
dub,
where
we're
a
lot
more
mindful
and
need
to
be
a
lot
more
mindful
with
sort
of
our
our
window
here
for
getting
at
least
seven
into
the
next
or
being
way
more
mindful
about
just.
You
know
how
were
versioning
in
general,
so
I'm
personally,
personally,
not.
A
A
C
A
C
A
Think
you
well,
it
would
change
essentially
what
resolutions
would
get
you
get
noisy
on
install.
So
if
you
had
a
I
think
now
again,
this
is
where
I
think
we
can
probably
move
this
discussion
till
later
day,
because,
right
now
the
RFC
is
still
tied
to
the
interactive
piece.
Along
with,
like
this
schema
itself,
whereas,
like
we've,
asked
I
think
for
those
to
be
split
up
so
that
we
can
look
at
just
what
it
would
mean
to
support
like
a
resolutions
JSON
or
yeah
like
a
resolve
that
JSON
or
audit
resolved
JSON
file.
A
C
Is
an
incremental
thing
because
it
depends,
it
relies
on
you
having
this
new
file
with
which
would
be
out
of
Chase
and
that's
definitely
like
up
to
by
chatting,
but
it
needs
to
have
that
file.
Declare
and
like
an
in
an
incremental
version
of
this.
You
know
you
could
read
from
it
and
filter
out
audit
results
based
on
that.
But
if
you
don't
have
this
file,
if
you're
not
using
it,
it
is
I
think
if.
A
A
He,
if
you
were
using
that
today
and
then
just
in
a
minor
version-
and
you
were
using
in
a
different
way
than
is
the
intention
of
how
we're
going
to
support
it
and
then
something
breaks
or
something
changes
about
NPM
install.
Because
of
that
and
we
didn't
ship
it
in
a
major
would
be
probably
the
reason
why
we
might
want
to
consider
it
to
be
an
PMA
yeah.
C
E
E
E
Why
I
think
that's
a
little
bit
short-sighted,
which
you
know
it's
one
minute
left
so
I
I,
don't
want
to
stand
on
a
pedestal
and
take
the
end.
So
if
the
conversation
picks
back
up
again-
and
it
looks
like
they're
going
to
champion
it-
then
I'll
happily
come
in
and
try
to
share
my
my
feedback,
but
it's
a
long
conversation
already
and
and
if
it's
not
doesn't
move
forward
recently,
I
didn't
want
to
make
comments
that
weren't
super
valuable
to
them.
Appreciate.
A
A
I'm
just
a
quick
note:
there,
though,
I
think
that
CB
actually
did
do
or
create
some
tooling
around
this,
and
so,
if
you're
looking
at
just
want
to
make
sure
you
don't
like
recreate
the
wheel
or
or
if
we,
if
there
is
a
way
to
get
time
with
you
to
pick
this
up,
that'd
be
great
if
it
makes
sense.
That's.
E
G
Apologize
yeah
and
I
actually
have
to
drop
two,
but
it's
a
tiny
PR.
So
the
summary
is
that
adding
the
exports
field
is
a
breaking
change,
so
unless
you're
like
really
verbose
and
careful-
and
you
can
always
expand
it
so,
like
my
advice,
would
be
to
add,
the
P
essentially
add
my
PR
to
see
700
and
then,
if
you
find
that
there's
more
things
you
need
to
expose,
you
can
very
easily
you
know
as
a
patch
or
a
minor
expose
them
later,
but
you
can't
tighten
it
back
later.
So.
A
It'll
be
a
good
item,
we're
not
under
tight
pressure
to
ship
the
beta
for
some
just
yet,
but
we
let's
definitely
give
that
up
for
discussions
next
week,
actually
so
cool.
Okay,
thanks,
awesome,
I
appreciate
everybody
jumping
on
today,
and
hopefully
I'll
see
y'all
at
Summit
and
over
Jeff's
world
next
week.
Sorry,
everyone.