►
From YouTube: Open RFC Meeting - Wednesday, November 3rd 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run 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
I
believe
we're
live
on
youtube
thanks
everybody
for
joining
another
mpm
open
rfc
meeting
today's
date
is
wednesday
november
3rd,
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
number.
A
Issue
number
487
for
folks
that
have
just
joined
the
call
I'll
copy
and
paste
the
meeting
notes
again
for
you.
One
last
time
feel
free
to
add
yourselves
as
attendees
as
usual.
We
ask
people
to
please,
please
be
polite
and,
as
others
are
speaking,
please
raise
your
hand
and
I'll
call
on
you
and
try
to
be
cordial.
A
Please
abide
by
the
code
of
conduct
that
we
have
there
linked
and
all
calls
and
all
communications
on
the
npmrc's
repo
are
governed
and
under
that
code
of
conduct
we
encourage
you
to
read
it
and
tldr
is
please
be
respectful
to
each
other,
and
we
have
a
short
list
an
agenda
today,
but
want
to
give
the
floor
for
anybody
if
they
have
announcements
they
want
to
share.
A
If
nobody
has
any
announcements,
we
can
dive
right
into
the
first
item
that
we
had
here,
which
is
issue
or
sorry.
Rfc
number
481
running
prepare
scripts
for
link,
bundled
tips.
I
know
matt
you've
been
joining
last
and
keeping
track
of
this
for
the
last
few
sessions.
Is
there
any
update
here
in
this
pr.
B
B
A
B
Guess
it's
just
the
implementation
section
that
I
need
help
with.
I
was
briefly
talking
to
mike.
I
want
to
say
who
who
has
like
collaborator
rights
on
this
fork,
but
I
haven't
heard
from
them
since
the
last
last
meeting,
so
I'm
not
really
sure
how
else
to
kind
of
like
reach
out
about
that
or
what
kind
of
implementation
details
I
should
get
into
on
this
rfc.
A
I
can
I
can
get
you
access
to
my
car.
I
can
make
a
connection
there.
Can
you
maybe
in
chat,
just
share
your
email,
the
best
email
to
get
in
contact
with
you,
mike's,
actually
a
local
here
and
and
good
friend
of
ours,
and
I
can
I
can
get
you
in
touch,
so
you
have
another
way
of
collaborating.
Hopefully,.
C
A
He
was
very
interested
in
trying
to
help
with
the
implementation,
so
sweet
so
I'll.
Take
that
as
an
action
on
my
side
to
follow
up
and
make
sure
you
get
connected
and
make
some
traction
happen,
there
was
there
any
other
actions
that
other
folks
were
owning.
If
you
can
remind
me
matt
other
than
you
helping
write
this
rc,
I
guess.
B
Yeah
I
mean
there's,
the
original
rrfc
was
kind
of
split
into
three
steps,
land
and
pack
list,
which
I
think
happened
in
in
npm
eight
and
an
rfc
about
workspace
layout,
which
I
think
jordan
was
gonna.
Work
on.
Maybe.
A
Awesome
any
other
notes,
then
here
matt
anything
else.
You
want
to
bring
up.
B
A
Okay,
don't
worry
so
we
can
respond
async
to
that
comment
for
sure
cool
anything
else
on
in
this
area
like
I
know,
you
said
that
we
landed.
Do
you
know
which
version
we
actually
landed,
that
support
matt
for
the.
B
I
I
think
it's
in
8.1,
but
I
was
I
yeah.
I
looked
into
it
a
little
bit
while
I
was
working
on
the
rfc
and
I
think
I
was
maybe
still
missing
a
step
or
something
like
that
and
actually
trying
to
kind
of
manually
force
this
to
happen,
and
it's
been
a
week
or
or
more
since
I've
had
a
chance
to
really
like
dig
into
it.
So
I'm
not
sure
where
I
left
that.
A
Okay,
let's
know
if
that,
like,
I
think
we
provide
some
kind
of
hack.
You
work
around
right
now,
if
that's
not
working,
maybe
feel
free
to
ping
us
in
whether,
like
the
slack
channels,
I'm
not
sure
if
you
are
part
of
either
the
openjs
foundation,
slack
channel
or
there's
also
the
node,
tooling
slack
channel
that
we
usually
or
slack
orgs,
sorry
that
our
team
is
usually
in,
but
there's
there's
ways
to
get
a
hold
of
of
us.
Also
through,
like
slack
or
so.
B
Yeah,
that
would
be
great,
is
there
like,
I
guess
I
haven't
seen
a
slack
org
like
join
link
or
whatever
it's
called.
A
I
can
send
you
some
references
when
I
make
the
connection
with
mike
as
well
for
for
you,
after
the
call
so
I'll.
Take
that
as
an
action
to
get
you
access
to
those
it'd
be
great
to
to
have
a
a
channel
for
us
to
chat
in
npm
has
slack
channels
within
those
orgs.
So
there's
about
two
or
three
of
them
that
are
run
by
the
different
communities
that
we
we
try
to
follow
along
and
use
as
back
channels
for
for
communication
and
tierney
just
shared
the
openjs
foundations.
A
Invite
link,
I
think,
they're
right
there
in
chat.
So.
A
No
worries:
I
appreciate
the
heads
up
cool
moving
along
the
next
two
items
that
we
had
are,
I
believe
connected.
I
know,
vince
billy
and
isaac
have
been
working
together
a
little
bit.
A
C
Yeah,
so
the
basic
idea
of
the
the
rfc
that
I
wrote
is
it's
it's
pretty
light
it
probably
doesn't.
It
doesn't
go
as
far
as
I
think,
jordan's
kind
of
vision
for
this,
which
I
think
is
also
worth
worth,
writing
up,
and
maybe
we
decide
to
land
or
implement
or
accept
one
and
then
do
the
other
as
an
extension
of
it
or
just
take
his
instead
of
it.
C
I
don't
know
really
what
the
best
path
forward
is
there,
but
I
figured
just
like
let's
just
write
up
the
thing
that
is,
that
would
actually
be
kind
of
a
step
in
the
right
direction
and
what
came
out
of
kind
of
the
discussion
of
the
implementation
of
isolated
mode
that
vincent
and
I
were
looking
at
essentially
the
the
thing
that
this
does
is,
it
would
say,
don't
hoist
anything
other
than
pure
depths
up
above
the
workspace
project,
bound
the
workspace
boundary
itself.
C
So
if
you
have
a
dev
dependency,
regular,
dependent
dependency
or
optional
dependency,
it
would
it
would
never
hoist
to
the
root
right.
C
Then
that
will
always
be
resolved
to
the
sibling
workspace
rather
than
fetching
from
the
registry
and
third,
if
you
have
a
peer
dependency
from
a
workspace
that
will
always
be
hoisted
to
the
root
and
shared
among
all
workspaces,
which
is
the
way
it
currently
works
today.
So
the
only
change
that
this
would
introduce
that
would
be
any
non-pure
dependencies
will
never
be
hoisted
above
the
workspace
to
the
root
and
two
any
dependencies
on
a
sibling.
C
Workspace
would
be
resolved
to
that
sibling
workspace
rather
than
fetching
from
the
registry,
and
that
that
would
address
a
couple
of
problems
that
we're
seeing
in
how
peer
sets
kind
of
can
end
up
being
split
apart
in
order
to
to
resolve
things
in
a
way
that
is
a
little
leads
to
some
confusing
scenarios,
particularly
among
with
the
use
of
webpack
and
webpack
cli
and
some
other
some
other
cases,
without
going
all
the
way
to
isolated
mode
style
resolution
the
I
say
that
jordan's
hand
is
up.
C
D
C
D
Boundary,
so
I
think
this
is
a
strict
improvement
over
the
current
default.
So
I'm
happy
to
see
that
change
made.
It
is
definitely
not
sufficient
for
what
I
need
for
my
alternate
layout.
I
like,
I
still
think
we
end
up
we'll
end
up
needing
three
layout
modes
default,
isolated
and
then
the
middle
one
shared
or
something
and
but
but
this
this
change
will
make
the
d
the
delta
between
shared
and
default
smaller,
and,
I
think
it'll
like
it
will.
D
Break
in
dev,
rather
than
production
right
exactly
so
yeah
it
hopefully
will
not
break
anyone
unhappily,
but
the
basically
the
point
that
the
major
difference
between
what
the
shared
mode
and
what
you're
suggesting
is
that
a
pure
dependency
of
a
child
workspace
in
shared
mode
would
not
automatically
get
hoisted
to
the
root
and
become
available
to
everything
else
and
in
particular
what
this
would
enable
is
for
one.
Child
workspace
to
peer
depend
on
react,
17
and
another
one
to
peer
depend
on
react,
18
and
actually
to
have
two
depend
on
react.
D
C
D
A
fifth
package
that
had
no
peer
dependency
on
react
or
dependency
of
any
kind
would
not
be
able
to
require
react
because
it
wouldn't
be
available
in
its
node
modules
graph.
So
obviously
this
is
still
you
know.
I
still
need
to
write
up
this
rfc,
but,
like
that's
to
me,
that's
the
big
high
level
difference.
C
Yeah
so
then
go
ahead,
so
the
the
use
case-
that's
maybe
worth
zooming
into
here-
is
in-
and
this
is
this
gets
tricky,
because
right
now,
there's
no
way
to
kind
of
explicitly
declare
this
and
so
we're
we're
we're
having
we're
forced
to
kind
of
guess
what
users
are
intending
based
on
kind
of
what
the
current
behavior
is,
and
that
is
always
a
little
bit
perilous
to
do.
C
But
that
being
said
today,
if
I
have
a
collection
of
workspaces
within
one
project
and
they
have
some
pure
dependencies
and
con
and
in
common
one
thing-
that's
sort
of
a
a
very
common.
It's
certainly
not
universal,
but
a
very
common
use
case
is
I'm
developing
a
bunch
of
software
that
is
intended
to
kind
of
all
work
together
right.
It's
all
part
of
a
thing.
C
We
have
one
mono
repo
for
our
entire
company
and
some
of
these
things
work
together
and
some
of
them
don't
so
that's
kind
of
more
where,
where
you're
coming
at
it
from
and
and
I
think
that
they're
both
valid
use
cases,
and
so
the
challenge
is
like
how
to
identify
that,
because
if,
if
it's
a
case
where
you
know,
for
example,
I
have
let's
say
I
wanted
to
take
all
of
the
all
of
the
sub
modules
of
the
npm
cli
and
put
them
in
one
workspace.
C
C
That's
going
to
break
like
when
you
try
to
install
amb
together,
it's
going
to
break
and
they're
in
the
same
project,
they're
co,
their
sibling
workspaces.
So
like
I
want
to
know
that
it's
going
to
break,
I
want
to
see
it
break
because
otherwise
it's
going
to
break
when
people
try
to
install
it.
The,
however,
on
the
other
side,
if
it's
like
well,
I
have
like
you
know
four
different
sort
of
sets
of
things
to
work
on
react
15
through
18.,
and
I
want
to
develop
them
all
within
the
same
workspaces
project.
C
In
that
case,
I'm
not
going
to
use
all
of
these
things
together.
At
the
same
time,
I'm
going
to
kind
of
use
some
subset
of
them.
So
then
the
question
is
like:
how
do
we
kind
of
identify
what
those
what
those
bubbles
are
or
like
what
those
like
boundaries
are?
When
I
initially
took
a
pass
at
this
rc,
I
had
something
like
that
in
mind
and
and
went
down
a
little
bit
of
a
a
rabbit
hole
of
like
how
to
sort
of
specify
in
the
root
like
workspaces
declaration.
C
Now
like
these
three
workspaces
share
things.
Those
two
share
things
together
and
it
got
really
hairy
and
I
just
was
like
okay,
we
like
there's
a
problem
here,
let's
just
like,
take
the
shortest
path
about
solving
the
problem,
which
doesn't
actually
require
any
kind
of
additional
configuration,
and
I
think
the
challenge
that
we're
going
to
find
and
the
bike
shed
that
we're
going
to
we're
going
to
find
ourselves
running
into
with
your
with
your
dream.
Is
that
either
either
we
say?
C
Look
if
you
want
to
use
all
these
things
together,
they
just
you've
got
to
make
them,
have
compatible
peer
depths
period
and
we're
not
going
to
highlight
that
for
you
right
we're
not
going
to
tell
you
when
that's
not
the
case
or
b,
you
have
to
somehow
identify
explicitly
like
at
the
root
level.
C
C
Right
right,
it's
there
there
is
so
what's
also
interesting.
Is
there
there
is
a?
We
might
be
able
to
solve
this
in
a
in
a
pretty
lightweight
way.
D
C
C
So
maybe
that's
not
as
lightweight
as
I
had
initially
hoped,
but
I
could
that
could
be
just
another
sort
of
way
to
approach
that
bike
shed
but
yeah.
If,
if
we,
it
does
get
a
little
a
little
bit
complicated
if
we're
going
to
use
the
stated
pure
dependencies
as
the
way
to
define
those
those
bubbles
or
those
groups,
because
essentially
then
we're
in
a
in
a
state
where
we're
like.
C
I
have
you
know,
let's
say
I
have.
I
have
10
different
workspaces
and
I
need
to
figure
out.
You
know
what
is
the?
What
is
the
maximal
amount
of
overlap
that
I
can
get
and
now
we're
getting
into
like
heuristics
and
those
bubbles
might
sort
themselves
out
in
surprising
ways
or
ways
that
are
hard
to
kind
of
guess.
D
I
mean,
and
the
way
that
I
deal
with
this
in
enzyme
is
basically
that
I
I
have
a
bunch
of
overly
complicated
scripts,
so
I
pick
a
react
version
and
based
on
which
version
I
pick
it
selects
the
appropriate
things
to
sim
link
in
the
appropriate
places
and
it
sort
of
ignores
the
other
ones,
and
that
way
I
can
run
the
entire
repo,
but
but
it's
only
actually
running
the
subset
that
are
compatible
with
my
quote.
Current
react
version,
and
so
I
don't
know
if
that's
here
or
not.
C
You
can
also
do
this
by
checking
out
different
versions
of
react
into
your
project
and
then
having
a
dev
dependency
on
react
file,
colon
dot,
dot,
slash,
react,
13
or
whatever
react
16.
I
don't
know
what
react
versions
are
apparently,
but
the
the
kind
of
the
dev
dependency
escape
hatch
is
still
a
possibility
for
for
explicitly
managing
peer
dependencies,
because
the
dev
depth
will
kind
of
clobber
the
pure
depth
when
you're
in
development.
D
I
mean
maybe
yeah
we
it's
something
we
can
explore
right
and
all
in
every
package
that
I
have
declared
appeared
at
period
that
I
I
copy,
the
identical
pure
depth
range
into
the
dev
depth,
so
that
ci
can
install
it
in
all
the
appropriate
version
configurations
so
and
that
I've
been
saying
that
that's
the
best
practice
for
half
a
decade
is
that
everything
that's
appeared.
App
should
be
listed
as
an
identical
dev
dev
the
tooling
doesn't
require
that,
but
like
it
would
be
really
nice.
If
that
didn't
become
invalidated.
C
Yeah,
the
the
flip
side.
There
is,
if
you
declare
every
like,
if
all
of
your
workspaces
declare
all
of
their
pure
depths
as
devteps
you're,
never
going
to
have
any
resolve
problem,
which
is
nice,
but
it's
also
sort
of
a
downside.
If
those
z-resolve
prop
errors
are
are
doing.
Some
work
for
you
right
are
trying
to
kind
of
show
you
that
things
won't
be
compatible
in
production.
D
D
A
So
what
are
the
next
steps
in
terms
of
this
isaac?
Are?
How
close
do
we
have
to
change
this
rfc,
based
on
some
of
the
use
cases
that
were
brought
up
in
the
484
pure
depth
installation,
or
do
we
have
to
like
ratify
changes
to
an
existing
implemented
rfc
for,
like
the
changing
the
default
behavior
for
pure
depth
resolution.
C
I
think
we
might
want
to
you
know,
make
a
make
a
new
rfc
that
is
just
and
jordan
if
this
is
a
step
if
this
default,
if
this
proposed
default
that
I
put
in
in
this
rfc
we're
discussing,
gets
you
closer
to
your
goal,
it
might
be
worthwhile
to
just
write
a
like
another
rfc,
that's
like
building
on
top
of
it
right.
So,
in
addition
to
blah,
also
add
these
steps
and
right
then
we
can
kind
of
evaluate
like
does
it
still
solve
all
of
the
all
of
the
problems
that
we
hope
to.
C
C
Well,
I
mean
the
implementation
of
it
is,
is
literally
like
four
lines,
so
I'm
tempted
to
you
know
the
sooner
we
can
get
it
ratified
like
than
the
soonest
the
sooner
we
can
actually
do
it.
The
change
in
in
arborist
is
is
really
really
tiny.
D
I
mean
the
reason
I'm
asking
is
because,
even
though
it
seems
to
me
like
it's
a
a
complete
step
towards
what
I
want
and
like
a
nice
subset
of
what
I
want
right,
the
way
to
be
sure
would
be
to
write
out
a
full
rfc
as
a
delta
on
this.
For
from
what
I
want,
and
then
we
can
like
explore
all
of
those
and
then
but
like
that,
would
require
you
delaying
a
few
weeks
on
this
yeah.
I
don't
know
if
that's
worth
it
or
not,.
C
A
A
C
The
way
that
we
kind
of
where
we
kind
of
landed
with
isolated
mode,
too,
is-
and
this
is
just
to
to
agree
with
you
and
add
some
technical
details
to
that.
C
The
way
we
landed
with
isolated
mode
is
that
it's
a
a
deterministic
transform
of
any
arbitrary
tree
into
its
sort
of
isolated
counterpart,
with
the
only
difference
being
increased
deduplication
and
the
inability
to
load
any
any
modules
that
you
don't
have
an
explicit
dependency
on,
but
any
tree
that
we
end
up
generating
in
terms
of
like
anything
that
is
shared,
will
still
be
shared.
C
Anything
that
is,
you
know,
all
the
versions
that
you
were
previously
resolving
to
you're
still
going
to
resolve
to,
except
for
things
that
you
don't
have
an
explicit
dependency
on
which
will
be
unavailable
unless
they're
at
top
level
depth
and
except
for
the
fact
that
the
pads
will
be.
You
know
these,
like
weird
hash
paths,.
D
I
have
a
possibly
related
question,
I
believe
pnpm
and
yarn
pnp
use
if
something
is
present
as
an
optional
pure
depth,
but
not
a
regular,
pure
depth
such
that
older
clients,
don't
see
it
at
all
and
newer
clients
only
see
it
as
optional
does
npm
do
something
with
that,
or
is
that
a
yarn
and
pnpm
specific
or
maybe
even
yarn,
specific
behavior.
C
So
I
don't
know
what
yarn
does
exactly
with.
I
don't
want
to
comment
on
what
yarn
or
pm
do
with
optional
pure
depth,
but
what
npm
does
with
optional
peer
depths?
Is
we
we
ve?
We
ensure
that
if
the
version
exists,
if
the
version
is
resolvable,
it
has
to
be
a
valid
a
valid
match
for
the
for
the
stated
dependency
range
right.
C
D
Okay,
and
so
the
reason
that
that's
relevant
is
that
I've
been
told
on
one
of
my
packages,
where
someone's
trying
to
make
that
change,
that
that
is
an
escape
hatch
for
pnp,
at
least
where.
If
you
do
that,
then
yarn
will
make
it
available
to
require
from
that
project.
Even
though
there's
no
version
constraint
applied
and.
C
So
it's
like
make
the
link
for
me,
even
though
I
wow
that's
a
weird.
C
I
mean
it's:
it's
worth
cons,
it's
not
a
big
change
from
what
we
already
have
specified
under
isolated
mode,
but
the
yeah
we're
not
going
to
install
it
by
default.
But
it's
like
sort
of
like
if
it's
a
if
it's
listed
in
pure
depth,
meta
then
go
ahead
and
make
it
available
like.
C
If
it
would
have
been
if
it
would
have
been
reachable
by
that
tree,
so
essentially
for
essentially
the
way
that
the
transform
works
is
we
go
through
each
node?
We
say
what
are
the
edges
out
from
that
node?
We
we
create
a
hash
based
on
the
hashes
of
all
those
things
and
the
the
integrity
of
the
of
the
node
and
those
things
that
it
has.
A
dependency
on
that
has
an
edge
out
on
are
sim
linked
in
to
be
made
available
to
it.
C
So
we
could
say
that
if
any
of
its
you
know
non-pure
depth
things
in
peer
dependencies
meta
was
reachable
in
the
original
hoisted
tree,
then
the
version
that
it
would
reach
and
find
and
resolve
to
will
also
be
linked
in
and
included
in
that
set,
I'm
not
sure
off
the
top
of
my
head.
What
kind
of
implications
that
would
have,
but
essentially
it
would
be
just
another
thing
kind
of
added
to
that
set,
so
it
doesn't
seem
like
it's
going
to
be.
C
It
would
be
a
huge
lift,
so
really
we
would
have
to
see
kind
of
how,
how
widespread
and
how
essential
is
that
particular
escape
hatch,
or
does
it
make
sense
to
have
something
a
little
bit
more
explicit,
something
that
looks
less
like
a
mistake.
D
Right
I
mean
my
my
understanding
is
that
yarn
has
hard-coded
a
pop,
a
bunch
of
popular
packages
in
this
fashion,
to
like
make
things
available
to
them.
That
aren't
explicitly
depend
on,
but
that
this
is
the
thing
that
they
suggest
packages
do.
So
we
also.
C
D
C
C
D
I'm
pointing
out
that
it
seems
to
be
an
escape
hatch
for
this
sort
of
thing,
and
if
it's
something
that
we
would
need
around
changing
how
hoisting
works
in
workspaces,
then
I
I
just
wanted
to
bring
it
up
in
case
like
I
like.
I
don't
want
it
to
end
up.
I
want
us
to
end
up
leaving
space
for
design
space
for
it.
If
that's
a
thing
we
might
need,
even
though
I'm
not
necessarily
advocating
for
it,
because
it
seems
weird.
A
So
I
think
the
key
is
like:
let's
write
down
the
use
case
right
like
and
then
what
are
the
mechanisms
in
which
we
can
we
have
available
to
us
today
or
don't
and
how
would
like
what
we
propose
solve
for
that
use
case
all
right.
So
it's
just
like
simply,
let's,
let's
figure
out
what
like
use
case,
you
are,
and
unpmp
and
pmpm
have
like
supported,
or
why
they've
done
that
and
then
propose
it
and
just
be
like
how
do
we
work
backwards
from
supporting
that?
Or
do
we
even
have
that
problem
right.
A
If
not
jordan,
it
sounds
like
there's
a
you
know,
a
big
ask
here
for
from
you
to
to
try
to
like
build
upon
this
or
show,
like
you
said,
the
delta,
between
what
you
want
to
write
so
yeah,
so
I'll
leave
it
as
that.
That
being
the
major
action
item
here
cool,
I
added
this
last
agenda
item
on
here
I
think
caleb
I
saw
you
joined
and
you
also
had
this
rc,
which
I
didn't
add
to
the
agenda
initially
but
tucked
on
here.
A
I'm
not
sure
if
you
want
to
speak
to
it,
but
it's
number
486
resolving
registry
overrides
not
sure,
if
you're
available
to
to
speak
to
this
but
feel
free.
If
you
want.
E
The
the
gist
is
that
at
my
workplace
we
build
packages
using
different
custom
registries,
and
currently
we
have
to
modify
the
package
lock
by
removing
the
resolved
key
to
allow
us
to
change
the
registry.
The
default
registry
registry
in
pmjs.org
is
a
magic
value
that
always
means
the
current
registry.
So
if
you
have
a
lock
file
that
uses
the
default
registry,
you
can
switch
to
a
custom
registry,
but
if
you
already
have
a
lock
file
with
a
custom
registry,
you
can't
switch
to
another
registry.
E
A
A
E
That
bug
is
just
marked
as
triage.
Okay,.
A
Awesome,
we'll
probably
leave
this
on
the
agenda
unless
folks
have
any
comments
right
now,
initially
looking
through
this
probably
leave
you
on
the
agenda
for
next
week
as
well,
unless
we
can
respond
it
asynchronously
yeah.
This
is
definitely
something
we
want
to
want
to
fix
for
you
all.
If
it's
like
breaking
breaking
anything
for
you.