►
From YouTube: Open RFC Meeting - Wednesday, Nov 18th 2020
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
This
is
probably
not
related
to
rfc,
but
it
would
be
helpful
on
the
cli
repo.
If
there
was
some
list
I
could
refer
to
of
like
appropriate
reasons
and
methods
of
closing
issues,
because
there's
a
large
chunk
of
them
where
I
feel
like
I
could
close
them,
but
I
don't
want
to
like
overstep
or
like
piss
anyone
off
sure.
B
So
sorry,
jordan,
like
I
just
went,
live
there,
so
just
I
apologize
that
was
like
in
the
midst
of
that
question,
not
actually
private.
It's
just
irrelevant
to
sure
sure
so
I'll
say
that
we
are
live
on
youtube,
so
welcome
to
another
openrc
call
jordan
to
you
to
your
questions
just
there
in
terms
of
it's
sort
of
a
meta
question
around
trashing
of
issues.
I
think
we
can
create
some
docs
for
that
or
or
you
know
we
can
work.
B
We
can
take
that
discussion
offline
in
one
of
the
slack
channels
to
talk
about
how
to
do
that,
appreciate
and
acknowledge
that
you've
been
helping
out
with
us
on
that
and
have
been
for
a
long
time.
Helping
to
to
you
know,
address
feedback
from
the
community.
It's
been
a
big
help,
so
want
to
actually
give
a
shout
out
to
you
for
for
doing
that
with
us.
C
I
think
I
think
it's
actually,
it
might
be
actually
less
off
topic
than
you
think
we
you
know
I
I
don't.
I
don't
think
that
it's
it's
it's
sort
of
an
odd
fit
to
write
an
rfc
about
how
we
close
issues.
C
I
don't
think
that's
the
right
approach
there,
but
it
would
be
good
to
have
a
maybe
create
a
dock
within
npm
somewhere,
you
know
could
even
be
in,
like
I
don't
know,
if
there's
some
special
github
place
for
like
where
we
put
issues
you
know
it
could
be
in
like
the
issue
templates
that
says
like
hey
these,
are
you
know,
here's
a
link
to
the
wiki
page
that
says
when
you're,
you
know
why
this
will
be
closed
so
that
people
get
that
kind
of
notice
right
when
they
start
and-
and
we
can
refer
to
it-
and
you
know-
let's,
let's
write
up
a
draft
of
that
and
then
even
like
discuss
it
here.
C
So
it's
just
done.
You
know.
Really.
This
is
kind
of
our
our
like
community,
visible
discussion
platform
forum
for
talking
to
y'all
so
might
be
good
to
have
a
have
it
on
our
rfc
agenda.
Even
though
it's
not
actually
an
rfc,
if
anybody
doesn't
think
that's
too
weird.
D
Yeah
I
like
that,
do
you
actually
have
like
an
fhq,
because
I
think
that
typescript
has
like
an
fhq
that
says
something
like
commonly
asked
questions
like
we're
not
going
to
do
this
because,
like
we
don't
think
it's
a
right
fit.
So
that
might
be
something
you
would
want
to
refer
to
there
as
well.
B
Yeah,
so
I
actually
started
a
personal
faq,
which
I
thought
I
might
actually
bring
over
at
some
point,
because
I
have
a
whole
bunch
of
like
mtm
specific
frequently
asked
questions
and
I
was
actually
using
it
myself,
as
I
was
trashing,
some
of
our
other
yeah
other
docs
or
other
sort
of
issues
that
we
have.
So
I
just
copy
and
paste
it
there
in
chat
yeah.
That's
a
good
idea
question
also
to
to
consider
happening
in
either
the
cly
or
here
in
the
in
the
rc
process.
B
B
Or
how
do
I,
how
do
I
get
good
feedback?
How
to
give
or
write
a
good
rfc?
All
those
types
of
things
are,
you
know,
good
questions
and
good
things
that
we
should
ask
ourselves
and
then
also
document
awesome
appreciate
the
link
to
the
typescripts.
B
So
again,
I
know
we
got
kicked
off
to
a
little
bit
differently
today.
Just
wanted
to
quickly
note
if
you
haven't
already
feel
free
to
add
yourself
to
the
meeting
note
stock,
that
I've
shared
there.
It's
a
hack,
md
doc,
we'll
be
following
along
the
agenda
that
was
created
in
issue
290
in
the
mpm
rc's
repo
and
just
wanted
to
also
go
over
the
fact
that
these
calls
and
and
all
communications
and
in
the
rc's
repo,
and
also
throughout
all
the
the
entire
project.
B
All
the
interactions
are
covered
under
a
code
of
conduct
and
we
just
want
to
acknowledge
that
people
be
mindful
and
respectful
when
and
speaking
to
each
other
and
also
just
being
thoughtful
when
others
are
speaking
on.
These
calls.
Please
try
to
raise
your
hands
if
you
have
something
to
add
and
I'll
I'll
do
my
best
to
stay
on
top
and
make
sure
that
folks
folks
have
time
to
give
feedback.
B
If
there's
nothing,
I
know
that
roy
has
been
doing
a
couple
interviews.
Potentially
he'll
have
more
info
on
where
those
are
going
to
live.
I
think,
speaking
about
the
work
we've
been
doing
in
the
clay
and
talking
about
npm
seven.
B
If,
if
you
haven't
seen
you
know,
we've,
you
know
released
another
version
as
of
yesterday,
so
the
npm
012
should
be
out
in
the
wild,
so
a
new
release
has
appeared
and
feel
free
to
go
grab
it
in
the
usual
ways-
and
I
guess
also
just
to
to
note-
and
let
folks
know
that
we
are
shipping-
you
know
one
to
two
releases
on
average
a
week
so
tuesdays
and
fridays
seem
to
be
the
cadence
at
this
point,
and
hopefully
you're
you're,
staying
up
to
date
with
us
and
and
appreciate
the
feedback
we've
been
getting.
B
So
if
there's
nothing
else
for
for
folks,
I'd
like
to
dive
into
the
agenda
and
the
first
issue
being
issue
287,
which
is
an
rr
fc
for
adding
no
hoist
or
the
no
hoist
config,
which
is
a
feature
that
yarn
v1
has
supported,
and
it's
specifically
around
workspaces,
I'm
not
sure
roy
or
jordan
did
you
want
to
maybe
also
flush
out
the
details
of
this.
A
Actually,
I
think
that
should
be
the
only
in
default
behavior,
ideally,
and
it's
late
for
the
too
late
for
that,
of
course,
but
I
think
that
the
hoist
behavior
the
default
behavior
means
that
in
the
root.
A
So
let
me
rephrase
the
way
that
sort
of
the
model
pnp
is
chosen
is
that
nothing
is
requirable.
Unless
that
projects
package
json
mentions
it,
there's
a
lot
of
reasons
why
that
breaks
things
in
the
ecosystem,
but
conceptually
that
is
the
right
model.
A
In
other
words,
I
shouldn't
really
be
able
to
require
something
that
my
own
package.json
doesn't
contain
in
an
ideal
world,
and
this
can
cause
issues
where
sub-projects
that
can
be
deployed
or
published
separately
and
like
independently
of
a
monorepo
can
at
test
time
and
a
development
time
have
access
to
a
dependency
that
is
available
in
the
root
that
they
should
not
have
access
to.
A
In
other
words
like,
I
would
almost
rather
have
there
be
a
separate
folder
called
like
monorepo
modules
or
something
for,
because
that's
a
terrible
name.
That's
why
I
picked
it
for
now
that
had
all
the
hoisted
things
so
that
the
roots
node
modules
only
either
like
only
contain
the
things
that
were
in
the
root
package.
A
Json,
the
the
value
of
no
hoist,
is
to
piecemeal,
provide
that
behavior
one
dependency
at
a
time
and
what
that
ends
up
being
is
a
bug
farm
as
people
discover.
Oh,
I
need
to
put
react
in
there.
I
need
to
put
some
other
pure
depth
or
some
other
core
package
in
there
and
and
it's
sort
of
it's
kind
of
a
whack-a-mole
thing
where
things
break,
and
then
they
figure
out
that
noho's
can
fix
it.
A
I
feel
like
a
much
better
version,
would
be
a
mode
that
which
obviously
couldn't
be
the
default
at
this
point,
but
but
that
a
mode
that
would
never
hoist
and
just
kind
of
implicitly
no
hoisted
everything
so
that
each
sub
project
and
the
root
had
to
explicitly
put
the
right
stuff
in
its
package.
Json
yeah.
B
C
Yeah,
so
regarding,
like
pnpm,
we're
essentially
talking
about
unlisted
dependencies
and
hoisting
there,
I
I
want
to
just
kind
of
make
sure
that
we
draw
a
really
clear
line
between
what
we're
talking
about
here
versus
the
problem
of
unlisted
dependencies.
What
we're
talking
about
here
is
hoisting
in
the
workspace
context.
Specifically,
so
I
have
a
workspace
with
several
packages
and
all
of
their
dependencies
get
hoisted
up
to
the
top
there's.
C
There
are
pros
and
cons
regarding
correctness
and
and
kind
of
strictness
and
enforcement
with
hoisting
versus
no
hoisting,
especially
regarding
pure
depths.
It's
very
easy
in
a
workspace
context.
If
we
don't
hoist
peer
dependencies,
it's
very
easy
to
end
up
in
a
situation
where
I
have
two
packages
that
I'm
intending
to
be
using
together,
but
they
actually
cannot
be
installed
together
because
they
have
conflicting
peer
dependencies,
and
so
you
know
you
can
you
can
see
this
happen?
C
If
you
have
like,
I
have
packages
x
and
y,
and
you
know
x
depends
on
some
react.
Goober
that
depends
on
that.
Pure
depends
on
react,
16.8,
and
I
have
something
else
in
y.
That
depends
on
a
different
react.
Goober.
That
pure
depends
on
react.
Six,
you
know
greater
than
16.11..
C
If
I
try
and
install
those
two
things
together,
I'm
it's
going
to
fail,
but
the
workspace.
If
we're
not
hoisting
those
peer
depths,
then
the
workspace
will
appear
to
work.
Fine-
and
you
know
you'll
just
have
two
copies
of
react
because
it'll
be
installed
as
if
it
was
a
regular
depth
since
we're
not
hoisting
things
out
of
those
workspaces.
C
If
we
do
hoist
things
by
default,
then
what
that
means
at
least
the
current
default
behavior,
is
that
any
module
that
has
a
you
know,
file
system
parent
within
the
project
will
get
its
peer
dependencies
loaded
at
that
level,
instead
of
as
a
child
folder
and
so
as
a
result,
if
you
have
conflicting
peer
dapps
within
your
workspace
projects,
they're
going
to
actually
conflict
and
surface
that
to
you
right
away,
which
is
again
like
not
every
workspace.
Is
this
way
it's
it's.
You
can
imagine
a
workspace
that
has
multiple
different
applications.
C
You
know
like
I
have
a
web
application
and
a
claw
application.
It's
fine
if
they
have
those
two
have
conflicting
pure
dependencies,
because
they're
completely
separate
products
and
they
are
effectively
separate
projects.
They're,
not
modules
intended
to
be
used
together.
So
it
gets
kind
of
interesting.
I
think
we're
going
to
have
to
have
some
kind
of
config
here
to
tell
it
what
to
do
in.
In
terms
of
you
know,
and
I'm
I'd
be
fine
having
a
you
know
true
and
false
as
options
for
your
okay.
C
F
B
Can
I
reply
yeah
one
sec?
Let
me
interject
as
well
join
before
before
you
go,
so
we
had
had
this
discussion
a
bit
and
I
had
given
some
feedback
internally
about
this
specifically
and
for
me,
I
feel
like
there
are
a
couple
ways
that
we
achieve
different
strategies.
What
I
would
call
different
strategies
for
resolving
your
depth
depths
today
and
that
you
know
you
can
utilize
the
flag
like
legacy.
B
Bundling
you
can
utilize
the
flag.
Well,
not
like.
B
What's
the
other
one
legacy
bundling
and
global
style,
global
dash
style
are
two
what
I
consider
to
be
like
two
sides
to
the
same
coin,
which
is
like
a
a
resolution
strategy
and
like
what
I
had
proposed
internally
was
the
idea
that
by
default,
let's
say
today
if
we
were
to
create
a
new
config
for
how
to
modify
or
change
like
this
behavior
of
whether
to
hoist
or
not
hoist,
I
imagine
it
could
be
under
some
kind
of
like
style
or
strategy
config,
which
then
the
default
would
be
hoist.
B
There
would
be
an
option
for
noise
and
there
could
be
an
option
for
global
and
then
there
could
potentially
be
future.
You
know
styles,
you
know
added
to
that.
That
was
my
again.
I'm
just
interjecting,
with
like
my
personal,
like
under,
like
thoughts
on
this
but
feel
free
to
respond.
A
A
You
want,
definitely
want
peer
to
apps
shared,
but
you
never
want
them
hoisted
in
a
repo
where
you
have
totally
disparate
projects,
you
don't
ever
want
a
vertical
conflict
between
those
projects,
but
so
the
example
I
have
is
is
enzyme.
Enzyme
has
like
eight
or
ten
sub
packages.
It's
currently
a
learner
project,
and
that
includes
enzyme,
react,
adapter,
13,
14,
15,
15,
4,
16,
1
and
so
forth.
There's
like
seven
or
eight.
They
all
have
conflicting
peer
depth
requirements
with
each
other
by.
C
A
However,
what
I
wha,
so
what
I
currently
have
to
do
is
a
bunch
of
hijinks
to
rejigger
all
the
dependencies
in
the
repo
to
use
a
specific
react
version
so
that
the
main
enzyme
thing
which
allows
every
react
version
more
or
less
essentially
like
I
I'm
saying
I
want
to
use
enzyme
with
this
adapter
and
then
the
reacts
that
come
with
it
and
then
there's
a
like
adapter
utils
package
that
they
all
share
and
that
you
know
so
so
there's
it
it's
very
complex
and
I
don't
expect
that
any
feature
would
just
cater
directly
to
this
use
case.
A
But
what
it
means
is
is
what
I
think
again
is
is
desired
here.
Is
that
anything
that
is
a
workspace
project
or
a
peer
dep
should
be
put
in
a
special
place?
That's
not
node
modules
and
there
those
should
be
all
treated
as
singletons,
and
then
everything
else
should
just
be
normal
as
if
it
wasn't
in
a
workspace,
and
at
that
point
you
have
all
the
shapes.
When
you
say.
C
As
if
they're,
not
in
a
workspace,
you
mean
they
get
their
dependencies
installed
under
their
node
modules,
yep.
A
Older
okay,
exactly
right
and
in
that
version
the
like,
then
you
have
all
the
behavior
you
want,
which
is
that
all
of
your
in
repo
projects
are
correctly
locally
linked
and
shared
right.
So,
as
you
make
your
changes,
you
know
everything
sees
them
and
all
of
their
common
peer
dependencies
are
shared
as
they
should
be,
and
obviously
transitive
peer
dependencies
would
have
to
be
also
you'd
have
to
figure
something
out
there.
A
But
so,
in
the
case
of
react
right,
everything
in
your
workspace
would
would
share
the
same
version,
the
same
copy
of
react,
but
they
wouldn't
like
there
wouldn't
be
any
risk
of
implicitly
implicitly
sharing
a
dependency
where
one
of
them
has
low
dash
and
therefore
the
other
one
doesn't
have
low
dash
but
still
gets
to
require
it.
A
And
I
know
this
is
a
different
paradigm
than
node
modules,
but,
like
I,
I
really
think
that
that's
the
semantic
that's
desired
and
that
I
think
it
occurred
to
me
during
when
everyone
was
talking
that
I
think
that's.
Why
hoist
and
no
hoist
both
have
always
feeled
weird
and
like
you're,
totally
right
that
just
hoisting
will
break
pure
depth
stuff.
So
that's
also
not
what
we
want
or
sorry
just
just
never
hoisting
will
break
pure
depth
stuff.
So
that's
definitely
not
the
the
path
we
want
to
go.
A
The
current
path
has
other
breakages,
so
like
yeah,
yeah.
C
So
again,
just
to
tease
apart
so
first
of
all,
I
think
enzyme
is
actually
I
you
know,
I'm
it
wouldn't
be
the
first
time
I
just
randomly
catered
to
your
whims.
They're,
usually
good,
so
I'm
not
not
complaining,
but
I
think
that
you,
you
bring
up
an
interesting
point
which
is
like
what
enzyme
is
doing
is
unusual
and
it's
not
the
normal
way
that
people
use
react
within
a
workspace
right.
The
normal
way
you
use
reaction.
C
Workspace
is,
I
want
exactly
one
react
and
I
want
to
make
sure
that
all
of
these
packages
work
together.
That's
why
I'm
using
a
workspace.
So
if
they
don't
work
together
because
they
have
conflicting
rehab
depths,
that's
a
problem.
I
want
to
surface
that
right
away
now,
then
you
have
something
like
enzyme
or
just
a
case
where
I
want.
Instead,
my
I
want
to
have
one
repo,
which
is
everything
my
company
does,
and
those
are
five
different
websites,
and
you
know
two
of
them
are
on
an
outdated
version
of
react
and
that
should
be
fine.
C
C
Example
sure
so
in
that
case-
and
you
know,
and
then
that
case
kind
of
is,
is
the
the
extreme
example
of
that
is
something
like
enzyme,
where
you
have
a
bunch
of
adapters
that
that
are
conflicting
by
design.
So
if,
if
we
make
it
work
for
enzyme,
I
think
we
make
it
work
for
the
you
know
somewhat
more
tame
like
react.
Web
versus
react
native
type
of
case,
and
then
the
task
is
like:
how
do
we
def?
C
How
do
we
design
a
config
so
that
the
complicated
thing
is
possible
and
set
the
defaults
so
that
the
common
case
is
easy
as
like
the
normal
thing
that
happens?
So
that's
like
the
first
point.
The
second
point-
and
this
should
really
be
you
know-
its
own
discussion-
is
just
like
what
to
do
about
unlisted
devs.
So
workspaces
certainly
make
unlisted
depths
or
they
they
appear
to
make
unlisted
depths
a
bigger
problem.
C
But
I
don't
think
they
actually
do,
because,
if
you're
using
those,
if
you're
using
all
of
those
packages
together,
like
I'm
installing,
you
know
five
different
low
dash
things
that
are
all
kind
of
being
developed
within
a
workspace.
And
so
you
know
to
ensure
that
they
don't
don't
like
break
each
other's
tests
or
whatever.
C
Well,
if
one
of
those
things
is
using
an
unlisted
depth,
if
it
works
in
the
workspace,
it's
going
to
work
in
my
project
as
well.
For
the
same
reason,
so
I
think
the
unlisted
depth
issue
is.
It
should
really
be
its
own
thing,
and
my
my
preference
would
be
that
if
it
works
in
if
it
works
in
a
normal
npm
install,
it
should
probably
work
in
a
workspace
as
well.
A
Yeah
and
I'm
not
trying
to
suggest
that
it
would
be
appropriate
or
correct
or
good
in
any
way
to
go
to
that
strict
level
that
pnp
has
done.
I
think
that
I'm
tr
I
do
differentiate
between
hoisted
transitive
dependencies
of
the
current
graph
and
things
hoisted
across.
You
know
workspace
boundaries,
and
the
latter
is
the
one
I'm
concerned
about
here.
C
C
Everything
within
the
like
adapters,
slash,
star,
glob
set
of
packages
should
not
ever
have
their
depths
hoisted
and
and
then
what
you,
then.
It
will
never
be
a
problem
right,
we'll
just
treat
those
as
a
top
level
install
target
and
never
go
above
it
kind
of
global
style
they,
and
then
it's
kind
of
on
you
to
make
sure
that,
like
if
there's
peer
dapps,
they
don't
conflict
or
anything
like
that
and
have
your
own
test
for
that.
A
But
they
still
have
to
be
shared.
So
in
that
use
case,
how
like
like,
even
if
I'm
saying,
even
if
every
every
sub
package
is
correctly
defined
in
terms
of
their
manifest
right,
they
they
still
need
to
share
common
peer
debts.
Even
when
I'm
not
hoisting
them
like,
so
that
there
have.
A
There
always
will
have
to
be
a
way
to
share
those,
and
hoisting
is
the
trivial
way
and
the
like
way
that
leverages,
how
node
modules
already
works,
but
the
way
that
the
way
that
I,
that
people,
that
people
with
inordinate
perseverance
figure
it
out
for
npm
linking
use
cases
is
by
linking
the
peer
depths
through
the
global
and
that's
their
sharing
mechanism.
And
I
don't
think
that
workspaces
should
leverage
that
for
its
sharing
mechanism.
But
I
think
it
illustrates
the
need
and
use
case
of
having
a
a
non-local
sharing
mechanism.
C
So
how
would
we,
how
would
we,
how
would
that
even
make
sense,
though,
if
you
have
a
you
know,
enzyme
react.
Adapter,
15
and
enzyme
react.
Adapter
16.,
one
of
them
has
appeared
up
on
react.
16
one
has
appeared
up
on
react,
15.
like
they
can't.
A
Share
it,
they
can't
share
the
same
wrap,
but
let's
say
we
have
four
packages:
two
that
appeared
up
on
16
and
two
that
peered
up
on
15..
They
should
have
one
copy
of
16
and
one
copy
of
15.,
and
that
should
be
somewhat
automatic.
I
shouldn't
have
to
as
long
as
I've
set
up
my
peer
debts
correctly.
I
shouldn't
have
to
do
anything
to
make
that
happen.
D
Damn
it
so
I'm
a
bit
concerned
about
the
unlisted
packages
like,
I
think
it
would
be
kind
of
cool
to
just
tell
npm
to
not
hoist
anything
because
otherwise
it
just
becomes
a
little
bit
of
like
magic
like.
Where
is
this
package
even
coming
from?
D
So
maybe
an
idea
would
be
to
keep
it
in
like
the
package
json
and
still
like
just
install
it
into
like
the
parent
node
modules
folder,
so
that
it's
only
there
like
once,
but
still
like.
If
you
look
into
the
package
json,
it's
it's
there
for
the
project
because,
like
what
we
have
is
actually
git
sub
modules.
D
So
you
could
build
every
package
without
the
accompanying
workspace,
which
I
think
is
very
useful.
B
Yeah,
so
I
think
isaac
just
noted,
like
the
legacy
bundling
flag,
does
allow
for
things
to
be
placed
like
in
place
for
your
depths
to
be
resolved
in
place,
and
this
is
kind
of
it
goes
back
to,
and
I
want
to
quickly
go
back
to
the
actual
rrfc,
which
is
actually.
B
I
want
to
be
mindful
that
the
the
reason
why
this
discussion
kicked
off
just
because
they
were
hoping
that
we
would
adopt
a
strategy
similar
to
yarn
v1,
and
I
just
want
to
because
I've
heard
it
a
couple
times.
I
don't
think
that
there's
consensus
here
and-
and
I
think
we
might
not
actually
all
agree-
that
we
don't
actually
like
the
style
of
that
api
and
the
way
that
they've
like
no
voice
is,
I
think,
we're
talking
about
it
in
different
ways
like
we're
talking
about
as
potentially
a
config
flag
on
its
own.
B
That
might
be
like
used
with
install
in
this
case
they're.
Talking
about
it
being
like
a
map
to
certain
packages
that
you
like,
like
to
jordan's
point
at
the
very
onset
of
all
this.
I
don't
think
we
want
to
like
there's
going
to
be
a
lot
of
churn
in
terms
of
like
adding
to
that
list.
That's
set
if
we
implement
the
exact,
like
the
exact
same
no
hoist
api
in
your
package
json
and
the
way
that
they
did
it
in
your
b1.
I
don't
think
that's
what
we
want
to
support.
B
F
B
B
Bundling
is
config,
and
I
think
that
those
both
are
under
utilized
today,
potentially
because
of
their
names,
because
people
don't
understand
what
they
do
and
then
I
also
think
that
they
would
help
resolve
some
of
the
these
issues
for
for
for
folks,
and
we
could
point
to
them
if
we
changed,
you
know
we
did
this
with
omit.
So
in
mpm7
you
know
we
basically
introduced
omit,
which
is
what
production
and
dev
development
like
actually
mapped
to,
which
is
like
omit
production
is
actually
dev
and
omit.
B
Dev
is
actually
production,
the
production
flags.
So
I
could
imagine
that
we
could
map
the
legacy
bundling
and
legacy
bundling
and
global
style
to
a
new
strategy
config
that
then,
could
be
by
default
today.
Whatever
you
want
to
call
that,
what
we're
doing
today,
whether
it
is
as
as
join,
says
incorrectly
named
hoisting,
we
could
call
it
something
else.
B
Whatever
that
default
behavior
is,
and
then
we
could
say,
the
upstate
would
be
to
no
hoist
or
to
in
place
or
whatever
you
would
like
to
to
to
call
sort
of
the
opposite
of
that
behavior
and,
I
think,
there's
a
third
behavior,
potentially
whatever.
That
is
that
we
do
for
globals
and
potentially
there's
more
behaviors,
more
strategies
that
that
exist,
but
I
think
that
that
what
we're
talking
about
is
a
little
bit
different
than
what
this
original
rfc
is.
I
think
we
all
agree
that
we
don't
want
to
support.
B
I
think
we
want
to
solve
the
real
problem,
the
root
problem,
but
I
don't
think
that
the
supporting
no
voice
the
way
it
was
in
yarn
b1
is
the
way
go
ahead.
Roy,
I
see
your
hands
up.
A
Yeah
I
mean
I,
I
didn't
actually
have
my
hand
up,
but
I
always
have
something.
So
I
I
think
that
if
there's
a
if
what,
if
your
strategy
darcy,
is
something
that
is
going
to
take
a
long
time
or
have
to
wait
till
a
major
bump,
then
it's
probably
worth
doing
something
in
the
interim
to
somehow
address
this
point
and
no
voice
does
do
that.
A
F
Two
points
two
points
not
sure
how
well
legacy
bundling
is
working
with
workspaces.
I
do
believe
I
tried
it
out
and
I
found
some
bugs
in
there,
but
imagine
the
bugs
we
can
solve
it
like
not
a
problem
if
legacy
building
is
meant
to
work
and
it
should
work.
But
yes,
like
no
highs.
There
is
also
one
point
to
consider
which
is
compatibility
right
with
the
things
that
are
out
there.
B
I
think
again,
so
your
your
that
that
implied,
I
think
we
have
to
go
back
to
the
two
use
cases
which
I
think
isaac
stated,
and
you
know,
there's
two
sort
of
like
reasons
why
people
are
using
workspaces
is
one
to
try
to
manage
projects
that
should
be
sharing
a
whole
bunch
of
common
packages
and
dependence
dependencies
and
then
there's
the
other
use
cases
where,
like
I,
I
just
want
to
manage
the
project
like
my
projects
that
like
share,
potentially
maybe
they
share
like
scripts
like
run
scripts
like
potentially,
I
want
to
build
all
these
things
at
the
same
time,
but
one's
a
distinct
app
compared
to
the
other
one,
and
they
don't
what
you
don't
want
to
share.
A
Let
me
rephrase
if
at
any
time
you
have
two
projects
that
you've
linked
together
right,
either
using
npm
link
which
we're
not
trying
to
solve
right
now
or
two
workspace
projects,
and
they
have
common
peer
depths.
Those
must
always
be
shared.
Otherwise
it
will
everything
will
break
period.
So
if,
if
legacy.
A
B
F
There
is
one
thing
I
remember:
I
just
remember
the
thing
I
wanted
to
mention
because
from
when
jordan
was
saying
it
first
time
it
made
me
think
of
because
jordan
was
saying:
oh
yeah,
maybe
peer
dabs
and
workspaces
like
they
can
live
in
a
different
place
right,
and
that
made
me
think
of
the
virtual
route
of
arborist,
and
maybe
these
things
can
like
be
tied
together
and
made
it
work
ways
like.
F
Maybe
it's
a
worth
exploring
avenue
of
thought
there,
because
I
do
know
in
arborists
like
we
do
have
a
virtual
route
but
which
we
only
use
for
the
purpose
of
resolving
the
dependency
tree
today,
but
maybe
it
can
become
a
real
place,
not
so
virtual
anymore
yeah.
I
mean.
C
Down
that
road
leads
pnpm,
which
is
a
you
know,
we
don't
have
to
mimic
everything,
pmp
does,
but
there's
it
it
would
be
a.
It
would
be,
basically
that
shared
location
right.
C
We
would
just
put
it
in
node,
module,
npm
and
there'd
be
a
you
know,
a
react,
slash,
16,
slash,
node
module,
slash
react
and
you
would
sim
link
it
in
and
we
would
just
simply
get
in
the
same
version
to
everything
when
we
it
basically
could
basically
be
a
separate
refining
strategy
so
that,
if
we,
you
know
anytime,
there's
something
that
resolves
to
this
particular
version.
C
We
create
a
sim
link
rather
than
unpacking
it,
the
the
then
the
other
tricky
thing
is,
like
you
know,
doing
our
load
actual
where
we,
you
know,
read
it
that
way
like
if
we're
gonna
do
that
going
all
the
way
is
not
much
harder
than
doing
something.
Fancy
and
special.
Just
for
workspaces
like
we
can
keep
building
the
ideal
tree
exactly
as
we
are
today
and
sort
of
managing
the
tree
of
nodes
and
then
just
change
how
we
reify
it
and
how
we
load
the
actual
tree.
C
In
order
to
to
understand
like
using
this
kind
of
shared
special
location,
it
would
make
npm
7
a
lot
faster
like
it
would
give
us
a
hook
to
to
make
unlisted
depths.
You
know
something
we
could
be
very,
very
strict
about,
like
pnpm
is,
or
you
know,
maybe
make
that
an
opt-in,
and
by
default
we
just
link
everything
as
high
up
as
we
possibly
can
like.
There's
there's
a
ton
of
ways
we
can.
C
We
can
handle
and
address
this,
but
I
I
think
if
the
goal
is
like
being
in
100
correct
with
unlisted
dependencies
like
any
anything
we
do
for
workspaces,
we
are
also
going
to
just
have
to
do
for
a
big
project.
A
I
think
that
that
work
that
linked
projects,
whether
it's
npm
link
or
workspaces,
is
where
this
comes
up
and
it
comes
up
sharing
of
pure
depth
comes
up
for
both
the
unintentional
access
to
dependencies
comes
up
in
workspaces,
and
I
think
the
latter
is
is
far
more
bug
prone
than
the
other,
which
is
just
highly
inconvenient,
and
annoying
it'd
be
great
to
fix
both,
but,
like
though
I
I
just
I
don't
care
about,
like
being
able
to
directly
require
a
transitive
dependency.
That's
unlisted
that
that's
fine!
C
Well
right,
so
anything
that
is
anything
that's
a
problem
for
workspaces
is
also
a
problem
for
a
project
that
just
depends
on
file
colon
dot,
slash
packages
right
and
the
the
unlisted
depths
issue.
Well,
while
it
is
a
problem
in
the
general
case,
it
is
arguably
a
problem
that
is
made
worse
by
workspaces,
because
now
you
have
a
situation
where
there
is
a
node
modules,
folder,
where
I
can
view
where
I
can
require
a
transitive
dependency
of
a
project
I'm
not
used
with.
C
So,
if
I
you
know,
if
a
and
b,
if
a
has
appeared
up
on
b
and
a
does
require
c,
which
is
one
of
b's
dependencies
like
you
know
what
that's
probably
fine
like
it's
gonna
work
most
of
the
time
anyway,
the
the
issue
is
like
a
and
b
are
completely
unrelated
and
maybe
even
can't
work
together
and
yet
are
depending
on
each
other's
meta
dependencies,
and
then
that's
where
you
get
into
trouble.
C
B
Exactly
I
appreciate
that
so
feel
free
to
add
any
comments
back
there.
I
think
we're
kind
of
all
agreed
that,
though
it
seems
like
we
don't
probably
want
to
move
forward
with
this
specific
discussion,
but
yeah
we'll
set
up
a
deep
dive,
further
rrc.
B
But
not
the
api
as
intended
by
the
as
the
original
comment.
Okay,
moving
on
to
item
two,
the
279
rfc
a
proper
rfc,
the
default
command
isaac.
Would
you
like
to
discuss
this
a
bit.
C
Yeah,
so
the
issue
here
is-
and
I
am
I
just
I
know
I
wrote
the
rfc,
but
I'm
kind
of
I
have
some.
I
have
some
very
pointed
comments
for
it
for
myself
and
for
the
version
of
me
that
wrote
this
rfc
and
I
you
know
wouldn't
say
I
object
to
it
entirely,
but
it's
definitely
got
some
issues.
C
The
the
idea
is,
you
know
we
frequently
get
asked
for
if
I
run
npm
build
and
I
have
a
scripts
entry
in
my
package.json
with
the
title
build
with
the
the
key
builds
then
npm
build
should
run
that
this
is
the
default
behavior
in
yarn
v1
and
I
think
also
yarn
v2
people
really
like
it
who
use
it.
I'm
told-
and
I
got
to
thinking
like
you
know-
we've
we've
sort
of
refactored
and
cleaned
up
a
lot
of
the
the
flow
of
logic
within
the
core
npm
object.
C
C
It
will
fall
back
and
run
npm
help,
and
so
this
is
like
what
this
this
is
kind
of
the
the
the
fallback
where
we're
like
and
then,
if
there's
no
health
entry
for
built
it'll
run
the
help
search
command,
which
searches
all
of
our
all
of
our
help
docs
and
gives
you
a
list
of
like
hey
like
these
are
the
search
terms.
You
know
these
are
the
search
entries
that
have
that
term
in
them
and
if
that
has
exactly
one
result,
it'll
just
run
that
help
topic
so
effectively.
C
We
have,
like
a
you,
know,
unique
this
kind
of
interesting
search
behavior,
where,
if
I
run
npm
package.json
or
if
I
run
npm
package,
lock
json,
it
will
show
me
the
help
dock
about
the
thing
that
I
that
I
tried
to
do.
It's
pretty
nice
default
behavior.
I
think,
but
there's
no
reason
why
help
necessarily
has
to
be
the
thing
that
we
run
by
default.
C
If
you
give
me
a
command
that
isn't
known,
that
could
very
easily
be
a
config
that
you
can
set
the
default
command
and
then
any
everybody
who
wants
to
run
npm,
npm
eslint
instead
of
npm
run
eslint,
will
have
that
and
it'll
just
work,
so
some
alternatives
brought
up
in
the
rfc.
C
Well,
if
the
only
oh
so
then
also,
I
was
thinking
you
know,
making
exec
the
default
behavior.
Now
that
npx
is
just
a
wrapper
around
running
npm
exec.
C
If
I
make
np,
if
I
make
exact
the
default
behavior
well,
then
I
can
run
npm
rim,
raph
fubar,
and
I
don't
even
have
to
use
npx
with
its
subtly
different
command,
parsing
logic
or
whatever
so
yeah.
So
I
kind
of
got
to
thinking
like
what,
if
we
did
make
this
something
that
a
user
could
configure,
the
one
alternative
is
like.
Well,
you
know
one
one
objection
is
like
99
of
the
people
who
change
this
setting
will
be
changing
it
to
run
script,
so
why
don't
we
just
make
npm
help
build?
C
If
you
have
a
script
named
build,
it
could
just
tell
you:
hey,
you
have
to
run
npm
run,
build
if
that's
what
you're
trying
to
do
the
other.
The
other
argument
against
it,
which
I
think
is
a
little
bit
like
we
should
do
that
anyway,
but
the
other
argument
against
it,
which
I
think
is
a
little
more
compelling-
is
we're
going
to
have
some
situation
where
somebody
runs
a
thing
and
it
doesn't
work
and
they're
confused
about
why?
C
So
yeah
and
we
should
probably
also
make
run
script
like
if
you
run,
run
script
as
the
default
command.
It
should
fall
back
to
help
if
there's
no
script
by
that
name.
There's
a
couple
things
here
for
sure
yeah,
so
like
there's
other
ways
that
we
could
just
make
it
nicer
and
not
have
a
default
command,
but
it
wouldn't
be
hard
to
do,
and
I
could
certainly
see
some
some
people
benefiting
from
it.
D
Well,
I
I'm
kinda
split
about
this,
I'm
so
what
I
usually
do
is
like
I
try
to
run
a
script
and
then
it
doesn't
run
the
script
because
I
forgot
the
run
and
I
would
really
welcome
it
if
npm
would
just
look
through
the
scripts
and
just
run
the
script
or
yeah
and
I
think
yeah.
I
think
I
would
welcome
that.
D
D
I
don't
know
just
my
two
cents,
I
mean
obviously
like
npm,
like
a
short
for
npm
exec
and
then
like
some
death
dependency
that
I
have
installed
will
also
be
nice,
but
I
don't
know
my
my
first
and
my
first
use
case
would
be
just
to
run
the
script
just
because
I
forgot
about
the
run,
and
that
happens
to
me.
D
I
don't
know
three
times
a
day.
I
don't
know
just
because
I'm
in
a
hurry,
so
I
would
welcome
that.
I
would
not
know
if
I
would
especially
configure
it,
though
I
appreciate
the
feedback.
That's
good.
A
But
that
said,
I
feel
like
features
like
this
are
an
attractive
nuisance,
they're
things
that
everyone
says
that
people
tend
to
to
think
they
want,
because
they're,
shiny
and
they're
convenient
and
like
the
analogy
that
it
reminds
me
of,
is
making
usernames
be
top
level
urls
on
your
website
like
twitter
or
npmjs.com,
and
as
soon
as
you
do
that
you've
immediately
screwed
yourself
for
any
future
top
level
changes
you
want
to
do.
You
have
to
make
for
twitter,
they
had
to
make
certain
usernames
yeah,
but
that's
free
that
redirects.
A
So
for
twitter
you
had
they
had
to
make
certain
usernames
illegal
so
that
they
could
have
a
url
right.
They
had
to
take
the
at
I
username
from
somebody
so
that
they
could
put
all
their
tweets
under
slash.
I
slash
stuff,
like
that's
really
disruptive
and
that
I'm
sure
some
user
was
not
happy
about
that
but
like
and
I'm
sure
npm
had
similar
issues
where
npmjs.com
something
is
expected
to
be
a
package
name
or
maybe
a
username
or
maybe
a
top-level
page
and
like
these
keep
happening.
A
This
this
feels
like
that
to
me,
like
yarn.
Adding
this
feature
to
me
is
has
always
been
a
mistake.
I
think,
because
it
means
yeah
you
screw
up.
You
know
you
get
to
type
a
little
less,
and
maybe
you
it
guesses
right
for
you
more.
You
know
more
often
than
you
do,
but
I
think
that
sometimes
verbosity
is
okay.
I
think
that
sometimes
running
into
friction,
and
especially
when
the
error
messages
are
helpful
and
having
it
tell
you
like,
hey
you
like,
like,
if
I
type
git
and
some
command,
and
I
misspell
it.
A
A
Like
the
number
of
times,
I've
misspelled,
master
or
something
is,
has
decreased
dramatically
over
the
years
like
I,
I
don't
check
out
hamster
anymore
right,
but
and-
and
I
so
I
think
that
there
is.
There
is
some
value
in
in
having
the
friction
and
not
gently
nudging
people
towards
the
muscle
memory.
They
need
yeah
like
it's.
It's
not
like,
like
any
of
us,
have
have
veto
power.
Necessarily,
but
so
like
I
wouldn't,
even
if
I
did
this,
isn't
something
I
would
veto
it's
just.
I
feel
like
it's
an
attractive
nuisance.
B
So
I
have
one
quick
thing
to
add
and
then
it
looks
like
christian.
You
still
have
your
hand
up,
so
I'm
I'll
call
on
you
in
a
second
here
for
me
like,
and
maybe
this
question
to
everybody
like
it
does
sound
like
they're
and
we've
I've.
B
I've
addressed
this
already
a
couple
times
in
the
last
couple
of
months,
because
some
feedback
was
given
to
us
about
making
this
the
default
behavior
and
fallback,
but
could
would
a
new
bin
like
npr
help
solve
this
like
if,
if
the,
if
truly
like
people,
are
saying
it's,
it's
a
nuisance,
to
write
the
sub
command
run
and
I'm
constantly
forgetting
it?
B
Could
we
train
people
to
be
like
hey,
there's
a
new
bin
npr
and
now
you
can
like
we
will
all
this
will
be
the
default
behavior
of
that
and
I
unfortunately
the
only
problem
I
have
with
that,
and
I'm
gonna,
like
you
know
be
my
own
devil's
advocate
here-
is
that
there's
already
existing
like
npm
run.
All
I
think
bleed.
I
believe,
ships
npr
as
a
bin,
and
so
like
the
only
thing
is.
B
We
won't
want
to
be
mindful
that
you
know
there's
already
user
land
tooling
out
there
that
exists,
so
yeah
that
would
be
my
suggestion
is,
is
like
we
know
that
this
is
a
problem.
Christian
has
said
you
know
he
does
this
three
times
a
day.
We
know
other
people.
Do
this
a
lot
we've
been
asked
for
this
support
for
a
long
time.
We
don't
think
it's
the
right
thing
to
create
magic.
B
That
falls
back
and
then
create
make
it
harder
for
us
to
inform
people
when
we
have
new
sub
commands
and
create
like
a
a
black
list
of
of
space,
that
we
can
no
longer
like
evolve
npm
itself,
and
this
might
help
with
that
by
by
saying
the
default
behavior
at
npr
is
npm
ron
x,
question
feel
free
to
go
and
then
tyranny.
I
see.
D
D
And
this
is
kind
of
creating
some
confusion
here,
something
I
like
your
suggestion,
darcy,
however,
what
I'm
also
thinking
about?
Maybe
you
could
do
like
a
prompt
like
hey.
This
is
npm,
I'm
smart
here
you
have
a
script.
Do
you
want
to
run
this
and
you
can
just
I
don't
know
press
enter
or
something
and
it
does
it
and
it
like
shows
a
warning
like
this
might
not
happen
in
the
future
when
we
decide
to
implement
npm
watchers,
okay,
because
this
as
jordan
said,
might
always
happen.
B
Tuning
did
you
have
something
added
then
roy.
I
know
your
hands
up
as
well.
G
I
I
kind
of
I
took
my
hand
down
just
because
I
realized
like
I
caught.
I
had
to
differ.
Second,
I
had
half
the
conversation
and,
as
he
talked
more,
I
realized
there
was
bits
I
was
missing,
so
I
I
I'll
dip
for
that
question
that
I
was
to
have.
F
Sure
yeah,
no,
I
just
you
were
mentioning
the
band
solution,
different
bin
and
also
a
package
ecosystem
right.
So
maybe
maybe
should
I
just
move
on
to
mtl.
B
I
mean
truly
truly
what
you're
talking
about
is
we?
If
we
did
support
npr,
then
we
could
just
shell
out
to
ntl,
so
I
mean
it
could
become
a
dependency
of
the
client.
If
we
really
want
that,
for
everybody
that
doesn't
know
right,
yeah
supports
a
a
tool
that
helps
you
run
your
run
scripts
and
helps
them
easily
be
discoverable.
B
B
B
So
if
we
can,
can
we
move
on
to
the
next
rfc
or
rfc
275
isaac?
This
is
the
registry
protocol.
B
C
I
have
not
yet
created
a
corresponding
rfc
for
this,
but
I
have
been
kind
of
discussing
it
with
some
folks
on
on
slack
and
kind
of
playing
with
some
ideas,
and
I
think
the
comments
in
there
are
close
enough
to
an
rfc
for
us
to
discuss
it.
C
Essentially,
what
this
would
be
doing
is
taking
the
the
behavior
that
we
currently
have
for
alias
specs,
where
we
do
npm
colon
and
then
some
kind
of
name
at
version
specifier
and
expanding
that
to
say
registry
colon,
full
registry,
url,
pound,
sign,
name
it
version,
and
that
would
be
kind
of
the
the
canonical
full
form
of
an
alias
specifier.
C
This
would
also
allow
people
that
to
do
some
really
interesting
stuff,
where,
like
that
previously
discussed
thing
that
had
some
some
security
unfortunate
security
implications
around
setting
a
registry
just
for
a
given
package
or
for
a
specific
package
name.
We
could
do
that
much
more
easily
by
just
saying
hey
if
you
want
this
package
name
to
be
on
that
registry.
C
Okay,
here's
how
you
define
that
and
it'll
always
fetch
from
that
registry.
The
the
other
nice
thing
that
this
would
allow
us
to
do
is
specify
those
registry.
C
You
know
do
those
registry
specifiers
on
the
command
line,
so
you
could
do
something
like
to
you
know
if
you
published
it
to
an
internal
registry,
and
now
you
want
to
take
that
same
exact
thing
and
publish
it
to
the
public
registry,
because
now
it's
you
know
been
tested
or
what
have
you
you
can
do,
npm,
publish
and
then
the
registry
specifier
at
my
internal
registry
and
what
that
will
do-
is
sort
of
fetch
it
from
my
internal
registry
and
then
publish
that
same
package
up
to
the
public
registry.
C
So
there's
some
really
interesting
things
you
could
do
with
that
and
it's
it's
mostly
typing
work
to
to
implement.
It
is,
unfortunately,
a
lot
of
typing
because
we
do
use
this
npm
package
arg
thing
in
a
lot
of
different
places
and
we
sort
of
hang
a
lot
of
like
the
the
those
spec
objects
are,
are
extremely
load-bearing
within
the
npm
stack.
So
I
would.
C
I
would
probably
argue
that
adding
a
new
specifier
type
is
itself
a
breaking
change
within
npm
package,
arg
and
a
minor
in
anything
that
uses
it
because,
even
though
you
know,
even
though
it
might
not
be
you
know,
it
might
sort
of
be
technically
a
minor
because
it's
strictly
additive,
it's
going
to
change
how
you
have
to
use
this
thing.
So
I
would
call
that
a
major
in
npm
package,
drug
at
least
and
I'll
leave.
It
leave
it
to
the
rest.
If
folks
have
comments
or
questions.
B
Or
anything
yeah
go
ahead,
christian
and
just
be
mindful
of
time.
We
got
like
a
mirror
too.
D
I
have
a
question
for
this
like
what
would
the
registry
need
to
provide,
or
could
I
just
like
well
basically
give
you
like
an
ftp,
folder
and
just
say
like
well,
that
is
where
the
where
the
package
resides
and
that's
about
it
like,
if
you
find
a
proper
registry
use
it,
but
if
I
only
have
like
one
internal
package-
and
I
have
like
an
ftp
folder,
where
I
just
want
to
put
it
quickly,
could
I
do
that
with
that.
C
No,
but
you
could
also
provide
I
mean
you
can
already
provide
a
url
to
a
tarball
or
a
a
file
path
to
a
tarball.
If
you
want
to
publish
something
so
what
the
regis,
in
order
to
be
a
regis,
a
valid
kind
of
thing
for
the
registry
specifier,
the
the
url
has
to
be
something
that
the
the
top
level
request
for
a
package
name
gives
me
a
pacument
that
the
full
package
metadata
document
with
all
the
versions
and
and
those
contain
dist.
C
You
know
dist
objects
which
have
the
tarball
url.
Now
you
could
put
an
index
file
in
an
ftp
folder
and
when
it,
you
know,
makes
a
request
for
that
thing.
Just
configure
it
to
do
that,
but
that's
really
just
saying
you
could
configure
an
ftp
server
to
be
an
npm
registry,
which
I
I'm
not
sure
is
technically
true,
but
it'd
be
fun
to
try.
B
So
I
apologize
we're
at
time
here
a
little
bit
over
appreciate
you
going
through
that
quickly
isaac.
I
know
it's
new,
so
feel
free
to
anybody
to
add
comments
to
that
issue
and
yeah
we're
I
think
at
time.
I
know
there
was
a
couple
other
rc's
we
didn't
get
to
specifically
the
the
one
two.
Seventeen
is
the
initial
rc
that
sort
of
spawned
us.
B
So
that's
the
ad
registry
per
package
for
organization
rc,
so
I
may
we
may
want
to
either
close
that
or
somehow
merge
or
essentially
close
that
with
this
being
sort
of
the
thing
that
supersedes
it
but
yeah,
hopefully
folks
will
continue
the
conversations
in
the
rc's
themselves
and
appreciate
everybody
jumping
on
today
and
giving
their
feedback
we'll
be
again
online
next
week
same
time
same
place
and
yeah.
Thank
you
for
joining
I'll,
see
you
soon.