►
From YouTube: Open RFC Meeting - Wednesday, July 8th 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
A
Essentially
the
items
that
are
on
there.
I'm
gonna
try
to
do
a
better
job
going
forward
next
week,
and
so
that
was
just
a
quick
update
there.
That
I'd
like
to
potentially
folk
folks
like
Wes,
who
isn't
on
this
call
today
as
I
know,
there's
been
an
effort
and
Tierney
I
think
has
also
helped
in
the
package
Jess
or
there's
a
new
create.
A
Agenda
script
that
they've
been
working
on
there
I
think
is
in
use
various
other
teams,
which
I
think
we
could
look
at
pulling
in
and
using
instead
of
the
manual
process
that
I've
been
taking
for
these
calls
so
again,
there's
hack
and
be
doc
and
I'll.
What
get
it
done
for
folks
that
are
just
joining
on
and
feel
free
to
add
yourselves
and
we'll
dive
in
to
the
agenda
before
that,
I
would
like
to
ask
if
there's
any
announcements
that
folks
would
like
to
bring
up.
A
A
Yeah
going
forward,
I'll
just
go
along
this
agenda.
The
first
issue
we
actually
have
here
is
issue
number
160,
so
the
poll
for
preference
on
filtering
workspaces
I
know
this
is
something
Roy
was
hoping
to
get
some
community
feedback
on.
Did
you
want
to
quickly
maybe
give
us
an
update
on
where
that's
at
and
what
you're
saying
all
right
sure.
B
B
B
A
A
B
A
So
we'll
leave
this
on
for
another
week
or
so
and
potentially
we
can
service
some
of
the
findings
from
that
discussion.
Then
next
week
may
be
awesome.
So
moving
on
RC
150,
add
file
pack
dependency
protocol,
I'm,
not
sure.
If
we
I
think
we're,
you
noted
we
didn't
poke
David
to
join
the
call
this
week,
yeah.
A
A
B
B
A
D
Yeah,
that's
fine,
you
can
leave
it.
Free
mixers
go
ahead,
saucy
cool
could
I.
Just
on
that.
One
just
say:
is
this:
what
I
think
it
is
a
way
of
because
I'm
very
concerned
about
my
behind
the
firewall
problems,
and
is
this
a
way
of
me
installing
stuff
in
so
that
I
don't
have
to
host
stuff
all
over
the
place
and
provide
environment
variables
and
get
it
to
point
all
over
the
place?
So
we
can
install
things
so
we
can
have
local
copies
of
stuff
in
a
folder
or
go
to
look
to
first.
C
C
What?
If
we
just
said
I
want
to
run,
you
know,
npm
install
file,
blah
blah
blah
rebuild
or
something,
and
that
would
tell
npm
they
go
ahead
and
run
all
the
prepare
scripts
and
relink
everything.
Dude
do
all
the
stuff
you
would
do,
but
still
have
it
be
assembling
another
option.
If,
if
that's
not,
you
know
if
I
miss
reading
kind
of
what
the
need
is
or
what
the
use
case
is.
C
Another
option
would
be
a
flag
to
say
when
you
encounter
a
file,
a
file
dependency
reference,
don't
create
a
symlink
pack,
the
foot
pack,
the
folder
and
then
unpack
it.
So
you
know
still
not
adding
a
new
protocol,
but
instead
just
adding
a
config
option.
That
would
say
this
is
how
you
handle
file
protocols
either
of
those
would
actually
be
somewhat
less
costly
in
terms
of
like
disruption
to
the
ecosystem
than
adding
a
new
protocol
and
not
super
hard
to
do.
I.
C
You
can
imagine
there
are
situations
where,
like
in
development
in
development,
I
want
to
create
assembly,
because
I'm
working
on
these
things
side
by
side
I
want
to
make
sure
they
work,
etc.
But
when
I,
when
I'm,
you
know
installing
in
production,
maybe
I
don't
want
those
symlinks
there
or
when
I'm
in
some
different
environment
and
a
docker
environment
or
something
I
want
to
just
create
that
you
know
pack
and
unpack
it.
C
So
you
can
sort
of
get
most
of
the
way
there
with
bundle
dependencies
and
then
packing
something
up
for
deployment
into
production,
but
a
lot
of
folks.
You
know
the
way
they
deploy
into
production
is
they
do
a
get
push
and
then
they
do
a
get
checkout
and
then
they
run
npm
install
locally.
So
it's
I
can
imagine
like
the
the
flag
to
pack
and
unpack
might
be
somewhat
useful
in
some
scenarios.
A
A
Was
essentially
the
champion
of
this
RC
and
I
know
there
was
a
little
bit
back
and
forth
with
Zoltan
of
PMPM
about
just
the
schema
getting
a
little
even
more
broadening
the
scope,
I
guess
for
yeah,
essentially,
nesting
types,
types
of
depths,
its
independence
ease
and
optional
dependencies.
I'm,
not
sure.
That's
discussion
that.
C
A
C
So
I
think
adding
adding
an
additional
layer
of
nesting
to
tell
the
type
of
overriding
overridden
dependency
is
I,
don't
prefer
it.
The
other
thing
is
I
actually
quite
liked.
The
idea
I
asked
I
was
I
thought
it
was
rather
cute
to
use
and
the
@
sign
instead
of
the
dot,
because
it
sort
of
reads
like
foo
at
2.3.4.
C
C
C
C
Like
X
overrides
Y,
but
only
when
it's
an
optional
dependency
of
X,
but
then
there's
something
else
within
X
that
has
a
regular
dependency
on
Y.
It's
like
it's
not
clear
whether
it
should
be
overwritten
or
not,
and
that
gets
into
some
pretty
sticky
territory,
whereas
just
saying
anything
down
this
branch
of
the
dependency
graph,
regardless
of
how
it's
being
pulled
in,
will
be
overridden.
C
B
C
C
Yeah,
what
we
did
go
through
several
several
use
cases
where
you,
where
you
would
want
to
use
it.
It's
tempting
to
look
at
this
and
say
well,
this
is
a
power
user
feature,
so
we
can
make
it
a
little
complicated
and
very
explicit,
and
it's
fine
because
nobody's
gonna
use
it
who's.
Not
you
know,
like
a
super-duper,
expert
and
I,
think
that's
actually
the
wrong
way
to
look
at
this,
because
what
this
actually
is.
Yes,
it
is
a
power
user
feature,
it's
also
an
escape
hatch
feature.
C
This
is
something
that's
going
to
be
used
by
somebody
who
has
exhausted
a
bunch
of
other
options
and
you
know
can't
kind
of
get
their
their
needs
met
in
the
like,
approved,
proper
ways,
and
this
is
they're
like
fine,
just
just
throw
an
override
in
there.
You
know
just
rim
it,
so
we
can
get
our
get
our
test
passing
or
get
everything
out.
A
C
A
B
C
C
C
We
wanted
no,
it
wouldn't
be.
It
would
not
be
easy
to
add
right
because
the
the
nature
of
the
the
way
that
this
sort
of
data
structure
is
it
doesn't
tell
you
what
kind
of
dependency
it
is.
It
just
has
a
version
selector
right,
how's,
the
left-hand
side
and
then
the
right
hands,
or
it
has
a
package
specifier
and
dependencies
misfires
the
left
hand,
side
and
then
the
right
hand
side
is
either
an
overwrite
object
or
a
string
version.
C
So
yeah
getting
getting
from
the
proposal
to
the
the
more
elaborate
like
dependency
type
filtering
kind
of
deal,
be
a
lot
harder,
but
I
I'm
really
struggle
to
come
up
with
a
situation
where
I
want
to
override
override
this
particular
thing,
but
only
when
it's
an
optional
dependency
and
not
when
it's
something
else,
and
it's
not
it's
again.
It's
really
not
obvious.
A
C
I
need
to
override
that
because
it's
in
the
dev
portion
of
the
tree
and
meaning
I
have
to
duplicate
it
or
because
it's
a
production
dependency
of
something
do
I,
not
override
it,
and
it
gets
more.
You
know,
then,
if
you
say
why
don't
override
it,
because
it's
nobody's
dev
dependency?
Okay,
what?
If
I
don't
have
a
production
dependency
on
B?
C
Now
B
is
a
dev
dependency
functionally,
because
it's
a
production,
dependency
of
a
dev
dependency
and
it's
just
it's
basically
taking
something
which
is
a
description
of
a
relationship
at
a
single
point
in
the
node
and
abstracting
it
out
to
how
we
select
a
section
of
the
tree.
So
it's
it's!
There's
kind
of
this
like
impedance
mismatch
in
the
semantics
there
I
don't
think
that
that's
a
good
idea
to
go
down
that
route.
C
B
Think
that
the
way
I
see
the
need
for
like
describing
other
types
of
dependencies
like
optional
or
down
would
be
more
useful.
If
this
was
like
something
you
could
share,
hey
you
know
could
have
to
be
publishing
to
a
package
and
like
taking
into
consideration,
but
we're
not
opening
that
Pandora's
box,
but
so
that
say,
like
I,
don't
think,
there's
much
value
in
having
the
tie,
because
it's
always
always
gonna
be
your
product
right.
A
C
C
A
126,
so
adding
type
information
to
package.json
in
the
registry,
I
know
orders
being
jumping
in
here
and
also
has
been
updating
this
RFC
for
a
bit.
I
think
this
is
on
the
registry
and
now
in
terms
of
us,
if
we
were
to
do
anything
like
add
a
new
field
to
the
document
or
the
Corgi
Docs
we'd
have
to
do
a
bit
of
work
to
those
end
points
and
also
whether
or
not
this
is
something
we
agree
upon.
I'm,
not
sure.
If
anybody's
looked
at
this
in
the
last
month
or
so
I.
F
Yeah
I
mean
I,
mean
thoughts
on
this
is
essentially
like
that
I
don't
want
it
limited
to
being
a
boolean
and
I,
don't
want
it
limited
to
being
just
relative
paths
but
like
beyond
that
beyond
that,
I,
don't
think
it's
it's
like
in
scope
for
this
meeting
right.
It's
like
separate,
tooling
kind
of
questions.
A
So
actually
we
can
potentially
I
mean
I
have
to
just
read
through
this
again
before
I.
Think
like
giving
like
a
thumbs
up.
I
think
everybody
here
should
probably
do
give
it
a
read
through
and
then
potentially,
if
we
have
consensus
or
how
we
can
get
consensus
is
kind
of
up
for
debate
to
land
and
then
backlog
it
in
registry
sides
backlog.
A
C
The
corgi
dog
to
the
dog
yeah,
we
we
it's
a
little
bit,
it's
a
bit
more
involved
to
go
through
an
ad
add
fields
to
the
documents
themselves
and
it
you
know
it
has
the
unfortunate
side
effect
of
like
invalidating
caches
and
various
other
things.
So
if
we,
if
we
do
do
that
it
it's
sort
of
more
prudent
to
do
so
very
slowly
right,
you
know
basically.
C
Right
so,
basically
like
walk
walk
the
registry
with
enough
of
a
timeout
between
between
hits
that
we
can
expect
it'll
take
a
you
know
a
month
to
go
through
the
whole
thing.
So
it's
just
sort
of
slowly,
trickling
out
with
the
new
data
updating
Corgi
Docs,
is,
is
much
simpler
and
I
guess
even
I
mean
even
the
pack
events.
If
we're
updating
those
it's
not
it's
not
so
bad.
It's
just.
It
takes
more
time
because
it's
more
work
but
I
guess
we
could
do
it
quickly.
It's
I
guess.
C
It's
what
NPM
actually
uses
when
it's
installing
things,
because
I,
don't
you
know
I,
don't
need
to
see
the
readme
in
order
to
know
what
your
dependencies
are
right,
I,
don't
need
to
see
your
the
list
of
maintainer
Xand,
the
description
and
all
that
other
junk
and
it
cuts
the
cuts,
the
the
size
over
the
wire
very
significantly
but
like
between
50
and
80
percent
gotcha,
depending
on
why?
How
much
metadata
is
enough.
E
C
You
need
to
install
it,
so
it's
it's
what
you
need
for
all
the
things
NPM
does
right
like
so
it's
it
also.
It
does
include
things
like
it.
It
shows
the
license,
and
you
know
the
the
bin
scripts
and
and
everything
so
that
any
any
operation
that
NPM
is
going
to
do
it
can
it
can
build
the
full
complete
tree
with
all
the
metadata
attracts
just
using
the
corrido.
So
that's
where.
A
B
A
C
So
it
has
shrink-wrap
is
another
one
where
we
just
like
I
know
that
there's
a
shrink
wrap
in
here
I'm
going
to
have
to
open
up
this
tarball
to
see
what
it
is,
if
I
mean
I'd
rather
not
add
a
boolean
right
cuz,
that's
just
like
it's
just
a
flag
that
says
you
have
to
do
more
work.
If
we
can,
we
can
short-circuit
that
step
and
include
the
type
info.
A
C
A
C
C
A
C
A
And
I
would
also
just
be
mindful
of
like
privileging
types,
then
do
we
start
to
like
privilege,
translate
transpilers
and
like
like
other
types
of
things
that
can
be
done
in
the
ecosystem
right
like
so,
if
we
add
a
types
information
that
do
that,
can
we
add
like?
What's
what
does
this
open
up?
I'm,
totally?
Okay,
with
doing
it
since
the
the
gussets
whim
is
so
large.
Now
the
touch
script
them
and
flow
I.
C
A
Yeah
I
say
we
mall
this
over
for
one
more
week
and
and
ideally
poke
ported
a
circle
back
and
and
I'm
gonna.
Do
my
due
diligence
here
and
actually
follow
up
in
a
sink
and
just
make
sure
I've
wrapped
my
my
head
around
this
as
well
and
yeah,
then
what
we
can
also
do
is
potentially
provide
like
a
next
steps.
A
So
if
this
does
land-
and
we
can
also
say
this-
is
what
you
can
expect
from
us
to
be
able
to
actually
land
the
support,
so
there
might
be
a
certain
period
of
time
where
we
have
to
the
backboard
it
might
take.
I,
don't
know
it's
I,
don't
know
if
it's
necessarily
a
month,
Isaac
but
I
know
we've
done
other
other
things.
A
lot
quicker.
A
It's
I
think
it's
a
couple
date.
It
like
it
would
take
maybe
48
hours,
maybe
yeah.
So
that's
my
rough
estimate,
yeah,
okay,
moving
on
then
to
PR
and
RC
117,
so
workspaces
running
commands.
So
this
is
kind
of
tied
to
the
pole
that
or
it
has
up
right
now,
going
into
detail
about
the
specific
commands
that
we
want
to
cue
up
and
be
workspace
aware,
which
would
potentially
visit
this
would
come
in
sort
of
a
point
release
after
we
land,
I'm,
pm7,
Roy
I'm,
not
sure
if
you
have
any
updates
here.
B
There
is
one
thing
actually
yeah
I
know.
Last
time
we
discussed
this
Jordan
suggested
adding
also
an
argument
in
the
CLI
for
providing
groups.
We
were
discussing
that
whole
story
behind
it
having
groups
of
different
workspaces,
you
can
work
with
and
having
that
like
behaving
like
Elias,
so
yeah
Jordan
suggested
having
also
a
command-line
argument
for
that.
So
when
I
was
in
the
process
of
like
documenting
that
from
that
wasn't
imaginary
man,
I
don't
have
from
the
previous
meeting.
B
I
actually
saw
one
of
the
comments
from
Daniel
Lerner,
and
one
of
the
things
he
actually
mentioned
in
the
beginning
of
the
dark
sea
is
how
how
bad
he
actually
thanked
his
API
with
that
desk.
Oh
yes,
like
just
like
trying
to
learn
from
past
mistakes
where
I'd
like
learn
from
their
experience.
So
that's
one
thing.
He
actually
suggests
this
not
to
do
so.
It's
kind
of
like
her
the
tricky
situation.
C
B
Kind
of
like
going
back
to
the
point
we're
trying
to
avoid,
but
maybe
Jordan
wants
to
speak
to
it
again
like
it
seems
to
be
also
like
quite
I,
need
to
have
the
possibility
of
declaring
groups
in
the
CLI
so
I
just
kind
of
stopped.
There
kind
of
asked
for
feedback
and
yeah.
That's
basically
where
it
stopped
lesson.
A
G
C
A
flag
yeah,
it
should
be
a
positional
argument.
I
mean
just
I
use
and
manage
a
lot
of
CLI
tools
and
it's
not
unreasonable
for
a
CLI
tool
to
use
a
flag
that
way,
but
in
NPM,
all
of
the
flags
are
are
config
config
options
which
can
also
live
in
a
config
file
or
in
the
environment
so
yeah
it
doesn't.
It
feels
like
it
should
be
more
of
a
first
class
thing.
Yeah.
A
C
Because
the
other
thing
is
we
don't,
we
are
not
sort
of
position
dependent
with
CLI
flags
that
get
passed
to
NPM.
So
if
you
do
npm
run
food,
XY
Z,
it
will
interpret
XYZ
as
an
argument
to
NPM
as
a
config
value
friend
yeah.
So
if
you
want
your
XYZ
to
be
passed
to
the
the
foo
script,
you
have
to
put
that
double
there
to
say.
No.
No.
This
is
a
positional
argument.
I
know
it
starts
with
a
just
ignoring
all.
A
C
B
B
F
C
So
I
I
would
I
kind
of
agree.
I
have
my
own
my
own
reservations
about
it,
which
I
think
are
I
mean
I
can't
speak
for
how
this
has
been
with
Lorna,
but
just
just
in
seeing
like
confusion
and
user
experience
and
my
own
kind
of
running
into
weird
issues
with
gloves
and
various
places.
A
glob
argument
really
needs
to
be
a
positional
argument,
because
the
show
will
expand
it
in
some
ways
that
are
sometimes
I'm
not
easy
to
predict
or
fail
to
expand
it
in
ways
that
are
not
easy
to
play.
C
So
if
you
look
at
like
how
Tappan
NYC
have
some
some
glob
arguments
that
are
config
Flags,
it's
it's
really
tricky
to
get
right.
I
think
the.
If,
if
you
have
a
glob
argument
as
a
way
to
spaz
in
a
number
of
positional
arguments
and
we're
saying
well
any
positional
argument
that
has
a
I'll
just
go
ahead
and
expand
it,
that's
fine
right,
because
then
the
shell
expands
it
or
you
expand
it.
It's
six
of
one
half
dozen
together,
but
if
you
have
like
work,
space
group
equals
core
equals
core
slash
star
there.
F
Flag,
what
are
those
cases
cuz
like
in
bash
at
least
write
a
star?
Will
there's
only
one
star
and
it'll
evaluate
to
the
first
thing
it
matches
so
yeah.
You
might
get
an
argument.
You
don't
expect.
If
you
don't
quote
it,
but
then
you
learn
that,
and
you
quote
it
right,
like
even
that's
the
same
same
problem
with
positional
arguments
right
like
if
I
pass,
foo,
slash
star,
it's
just
gonna
grab
the
first
thing
inside
foo.
Unless
I
go.
F
C
C
F
F
That
makes
sense,
and
that
may
be
what
Daniel
was
talking
about,
like
yeah
seems
likely
now
that
you've
explained
it
and
I
do
do
also
still
want
to
hear
if
it's
differing,
if
it's
that
or
something
else,
but
yeah.
If
it's
that
and
only
that,
then
it
seems
very
important
to
try
and
think
about
what
is
another
thing
that
is
there
another
way
to
without
requiring
someone
to
go
edit.
A
config
file,
urgh
anomaly
target
multiple
workspaces
as
part
of
running
another
command.
That
has
positional
arguments
right.
C
A
A
B
No
pull
request:
yeah,
just
I,
just
I
just
browse
through
it
quickly,
I
think
Isaac
provided
feedback
to
the
order
of
that
PR,
but
it
seemed
really
nice
how
simple
how
much
they
simplify
the
implementation,
like
just
the
core
of
the
idea
right
but
I
I
mean
I.
Think
it's
definitely
something
that
can
be
referred
to
when
all
of
this
RFC
sure.
A
F
Nice
I
mean
it
seems
like
they
say
in
use
case,
though
it
the
idea
is
essentially
here
is
I
want
to
be
able
to
say
these
audit
warnings
like
do
not
apply
to
me,
shut
up
about
them
and
any
mechanism
that
lets
me
shut
up
certain
on
it.
Warnings
I
think
solves
most
people's
use
case
in
this
thing
and
the
like
correct
in
my
opinion
and
bike
shed
comment
like
about
the
spelling
of
it.
That
I
think
made
right
like
like
I
agree
with
Isaacs
come
in
here,
but,
like
that's,
I,
think
an
implementation
detail.
F
C
F
A
So,
just
quickly,
if,
with
the
very
last
item
that
I
actually
added
here
just
before
we
started
the
call
I
asked
during
the
cloud
summit,
we've
opened
up
a
sort
of
a
new
team
which
I'm
not
sure
if
we're
gonna
be
able
to
use
completely.
Just
yet
I
have
to
get
some
sign-off
internally,
but
I'm,
hoping
that
we
can
start
to
privilege
some
folks
to
be
able
to
help
us.
Especially
with
this
call
specifically
maybe
identify
items.
A
A
Basically,
you
know
more,
like
official
capacity
would
be,
would
be
nice,
I,
think
and
would
I
think
a
couple
folks
have
reached
out
as
well
that
were
at
the
club.
Some,
and
so
with
that
in
mind,
I'll
definitely
be
poking
poking
y'all,
I'm,
Tierney
I
know
we
have
calls
separately
and
but
yeah
this.
This
idea
is
essentially
to
expand
and
broaden
sort
of
the
scope
and
of
the
team.
A
A
You
in
the
official
capacity-
so
this
is
something
I've
also
brought
with
ed,
so
who's
on
the
call
right
now
and
we'll
figure
out
how
to
a
reality
so
cool,
so
we're
essentially
that
time,
I
appreciate
everybody
jumping
on
today
and
again
we'll
be
circling
back
and
trying
to
get
into
a
regular
cadence
here,
weekly
on
Wednesdays
at
2:00
p.m.
Eastern
for
now,
ideally
we'll
be
looking
at
alternating.
It
calls
times
in
the
future
and
also
trying
to
be
better
at
doing
async
feedback
on
on
RFC's
going
forward.