►
From YouTube: Open RFC Deep Dive Meeting - Wednesday, April 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
Capabilities
had
to
move
around
a
bit
but
appreciate
everybody
being
patient
and
appreciate
everybody
jumping
on
to
another
open
RC
call.
These
are
the
deep
dive
conversations
that
we're
having
that
alternate
with
the
more
general-purpose
open
RFC
calls
that
we're
running
here
at
MPM.
These
are
supposed
to
be
opportunities
or
discussion.
Here
it's
supposed
to
be
an
opportunity
to
go
further
into
conversations
about
our
RFC's
or
issues
or
ideas,
topics
that
we
want
to
get
a
little
bit
more
feedback
from
the
community
on
and
hopefully
move
initiatives
forward.
A
You
that's
why
we
call
these
the
deep
dives
today,
specifically
we're
going
to
be
talking
about
fancy
res
resolutions
and
hopefully
bubbling
up
some
use
cases
and
in
that
area,
but
Before
we
jump
into
that.
Does
anybody
have
any
announcements
that
they
want
to
bring
up
anything
going
on
in
the
community?
We
should
be
aware
of
or
promote.
A
A
We'll
dive
in
so
we
want
to
scope
the
conversation
today
around
dependency
resolutions
or
around
this
can
go
in
a
couple
different
ways,
as
we've
had
topics
brought
up
around
either
supporting
yarn
style
resolutions
or
including
discussions
around
also
what
to
do
now
that
we're
planning
on
installing
pure
Deb's
by
default
internally,
we've
had
some
discussions
about
this
Issac
Froy
myself,
even
just
before.
This
call
we're
talking
a
bit
about
some
of
the
scenarios
that
the
community
is
finding
itself
in
and
how
we
can
address
these
things
going
forward.
B
Yeah,
so
so,
basically
yarn
style
resolutions
are,
you
know,
kind
of
a
a
it's
a
feature
that
can
be
used
in
a
lot
of
different
ways
and
my
concern
with
it
is
it's
it's
essentially
one
of
these.
Like
infinite
API
exposure,
surface
type
of
features,
the
other
thing
is
kind
of
more
qualitative
or
you
know,
comes
down
to
kind
of
like
what
is
the
theory
of
what
a
package
manager
should
do.
B
I
think
a
package
man
manager
packages
for
you,
and
so
if
we
find
ourselves
in
cases,
were
like,
oh
well,
the
way
you
the
way
you
fix
this.
Is
you
figure
out
what
dependency
you
want
to
resolve
to
and
write
it
down?
That
feels
to
me
like
a
little
bit
of
an
inappropriate
abdication
of
responsibilities.
B
Since
you
know
it
should
be
able
to
determine
what
the
case
is
and
then
do
the
right
thing
so
before
you
know,
I'm
not
opposed
to
the
apart
from
kind
of
those
caveats,
I'm
not
opposed
to
the
to
the
feature.
If
we
can,
if
we
establish
that
it
is
the
best
the
best
way
to
resolve
or
solve
certain
kinds
of
problems,
but
before
we
do
just
start
digging
into
like
into
saying
well
we're
gonna,
you
know,
implement
yarn
resolutions
in
NPM.
B
I
wanted
to
take
this
deep
dive
to
go
through
some
of
the
use
cases
that
people
are
currently
using
it
for,
and
hopefully
you
know
just
just
really
understand
exactly
what
are
the
categories
of
things
that
that
people
are
doing
with
resolutions
today
and
for
each
one
of
those?
Then
we
can
you
know
either
on
this
call
or
later,
when
we,
you
know
when
we
do
have
a
sort
of
a
full
understanding
of
what
someone
is
trying
to
do
and
what
the
situation
is
see
if
there
is
a
better
way
that
we
can
address
it.
B
So
just
and
so
npm
install'
just
works
or
if,
if
some
other
feature
is
the
best
way
to
address
it,
so
you
know
maybe
easier
sort
of
less
what
Gunny
type
of
dependency
resolution.
You
know
explicit
dependency
resolution
or
just
say
yeah.
This
is
actually
a
good
use
case
for
doing
resolution.
This
makes
it
worthwhile:
let's,
let's
go
ahead
and
implement
it.
B
C
So
I
was
unable
to
do
a
full
write-up.
Sorry,
but
I
can
go
through
what
is
effectively
so
there's
the
most
popular
case,
I
found
in
our
in
our
usage
at
Netflix,
and
then
there
is
the
most
complicated
case
and
I'll
lay
out
both
of
those.
So
the
most
popular
case
is
just
a
really
really
simple:
there
is
a
bug
that
is
yet
to
be
fixed
in
a
transitive.
C
C
So
this
so
and
and
I
say,
bug
and
I
should
have
maybe
maybe
been
a
little
bit
more
vague
on
that
there
are
reasons,
so
the
most
common
is
a
bug,
but
another
common
one
is
that
I
found
is
react,
so
react
needs
one
copy
to
the
entire
tree.
Different
component.
Libraries
can
sometimes
define
things
incorrectly
in
their
package
dependency
list,
which
results
in
react
being
in
there
multiple
times,
so
that
that
is
the
the
other.
It's
the
simple
case.
C
It's
the
same
use
case
as
far
as
how
you
define
the
resolution,
but
a
different
reason
for
that
use
case.
So,
basically,
there
that
people
are
just
saying
I
want
react,
16
dot.
You
know.
Let
me
find
one
that's
an
exact
example
here:
16.9
dot
11,
and
that
means
that,
no
matter
what
all
of
their
dependencies
in
the
tree
transitive
component,
you
know
things
they're
gonna
get
reacted
to
16
9
11,
and
they
know
for
a
fact
that
that
works.
C
C
B
B
C
Yes,
always
well:
okay,
I
say
always
everyone
that
I
have
seen.
It
is
possible
that
there
are
some
some
of
these
are
kind
of
hard
to
dig
into,
because
you
have
to
install
a
whole
tree
and
really
go.
You
know
deep
into
the
dependency
graph,
to
figure
out
what
specifically
they're
trying
to
avoid,
but
in
every
case
that
I
have
found
it
is
yet
it
does
not
satisfy
the
explicit
we
just
stated
dependencies.
I
guess.
C
B
If
there's
a
newer
one
dot
X
than
one
two
three
well,
it
will
install
the
latest
and
greatest
on
the
assumption
that
that's
better
right
that
it's
like
better
to
have
the
newer,
the
newest
version
that
you
can
support
the
with
prefer
d-do
flag.
It
will
always
prefer
to
take
whatever
is
already
in
the
tree.
If,
if
that's
satisfactory,
yeah.
B
Of
those
cases,
may
you
know
and
I've
actually,
we've
actually
had
some
conversations
where
it
might
make
sense
to
just
have
preferred
you
do
be
the
default
right
and
say
you
know,
prefer
newest
is
the
is
the
flag
that
you
opt
into?
I
only
didn't
make
it
the
default,
because
it's
not
the
default
behavior
and
can
be
six
but
like
there's,
no
there's
no
conceptual
reason
why
that's
necessarily
better.
C
C
No
okay,
so
the
more
complicated
use
case.
I
I,
don't
have
an
example
in
front
of
me,
so
I
I'm
I'm
trying
to
do
this
from
memory.
So
we
had
a
case
where,
in
a
specific
version
of
node
there
was
an
error
in
a
transitive.
So
this
is
I,
think
a
G
RPC
thing,
so
the
transitive,
which
was
three
layers
deep
needed
to
be
updated
and
only
that
one
needed
to
be
updated.
C
So
this
required
the
deep
matching
which
was
like
you
know,
look
specifically
in
this
this
tree
path,
and
only
if
it
is
this
particular
version
and
the
key
there
was
that
it
also
needed
to
override
the
package
lock,
because
the
package
lock
was
conflicting
with
the
resolution
and
I.
Think
in
this
case
it
was
yarn.
So
it
was
a
yarn
lock
thing,
but
the
law
was
conflicting,
and
so
they
added
a
resolution,
but
they
were
still
seeing
the
error
and
the
resolution
was
a
fairly
complicated
one.
C
B
C
But
the
point
there
was,
it
wasn't
just
a
top-level
path,
which
is
the
more
simple
use
case.
It
was
a
deep
path
and
it
needed
the
ability
to
to
filter
out
once
further
up
in
the
tree
right.
So
so,
even
if
so,
the
rule
looked
like
star
star,
G,
RPC,
bla,
bla
bla,
some
internal
package,
star
star
and
I,
think
it
was
G
RPC
client
right.
So
it
wasn't
just
a
matter
of
like
take
all
ver,
all
versions
of
G
RPC
client.
It
was
only
when
they
were
under
this
other
path.
C
B
B
C
B
B
It
might
so
the
reason
why
I
ask
is
you
know,
let's
say
the
let's
say:
the
reason
is
something
that
we
that
we
could
programmatically
determine
and
address
right.
We
can
then
save
you
the
trouble
of
then
that's
actually
not
a
thing.
That
is
that
should
require
human
interaction.
That's
a
thing
where
we
should
just
update
our
tree
building
logic
to
make
that
not
a
problem
so.
D
You
they'll
use
a
tilt
even
and
pegging
themselves
to
a
minor
and
maybe
I
want
to
use
a
newer
minor
of
react
or
maybe
I
want
to
use,
react.
17
and
even
though
all
of
those
packages
haven't
explicitly
declared
a
compatibility
appear
dependency
that
allows
react.
17,
maybe
I
have
tested
it
and
it
works.
But
I
don't
want
my
graph
to
be
invalid.
I
don't
want
to
like
have
to
do
a
bunch
of
crazy
things
to
make
sure
that
there's
one
copy
of
react
in
the
entire
tree
and
it's
react
17.
D
So
some
sort
of
resolution
feature
could
allow
me
to
knowingly
use
something
that
is
allegedly
invalid,
but
works
right
sort
of
like
how
the
engines
filled
like
there's
a
lot
of
things
that
say:
oh,
we
only
be
required
node
10,
but
maybe
it
works
fine
on
no
date
like,
and
it's
easy
for
me
to
knowingly
opt
out
of
that
warning,
essentially
and
say:
yeah
it's,
but
it's
good.
It
works
I'm!
Fine
with
that.
D
D
D
Anybody
who
wants
to
use
es
lists
es
lint
seven
has
to
wait
for
all
of
those
peer
dependencies
to
explicitly
support
it.
Even
if
it
already
happens
to
work
for
all
rules,
they
happen
to
enable
and
there's
nothing,
there's
no
clean
way
for
them.
To
just
say
no,
just
just
use
yes,
Lissa
is
lint.
Seven
like
be
quiet,
I
know
it's
gonna
work
and
like.
Instead,
they
have
to
go
harass
me
on
a
github
issue.
D
Whereas
if
I
could
tell
them
like
with
caveats,
do
this
this
resolution
and
it'll
work
for
now,
while
we
upgrade
the
ecosystem,
then,
like
everyone
else,
is
unblocked.
No
one
has
to
bother
me
about
it,
and
you
know,
as
the
maintainer
of
like
three
of
those
four
peer
dependencies
I
also
have
a
little
more
leisure
time
to
push
those
updates
out.
B
D
C
B
B
Yeah
this
other
thing,
that's
a
little
bit
interesting
to
me,
I'd,
like
to
dig
into
a
little
bit
is
an
issue
that
we've
seen
in
the
past.
A
few
times.
We've
had
some
conversations
around
like
a
first
singleton
type
of
mode
for
some
of
these
packages
and
in
particular
with
react,
I
mean
the
the
challenge
with
react
and
saying.
Well,
we
actually
always
only
be
a
singleton.
Is
the
like
the
Incans
case
right,
so
you
might
have-
and
this
is
actually
I
think
what
I
said.
B
I
think
you
were
the
one
who
talked
about
just
being
the
case.
Even
some
web
apps
are
there.
There
is
actually
a
use
case
to
having
multiple
reacts
in
your
tree,
even
though
there
might
not
be
even
though
it
might
not
be
good
to
have
multiple
reacts
in
any
given
process
or
any
given
web
page.
A
single.
You
know
a
single
project
with
the
node
modules.
Folder
might
be
multiple
different
processes
or
multiple
different
web
pages
or
websites
that
all
use
kind
of
a
shared
new
modules
folders.
B
So
the
ink
use
case
is
I'm
using
ink
to
design
my
my
CLI
app.
Stop
ink
has
a
pure
dependency
on
react.
16,
but
I
can
use
ink
on
the
CLI
with
react.
16
and
use
react
15
in
my
actual
website,
and
everything
is
fine
right,
they're
completely
separate
environments,
but
they
might
both
be
pulling
out
at
the
same
node
modules
folder,
because
I
have
you
know
my
test
tooling
and
everything
and
my
linter
and
all
my
other
sort
of
CLI
tooling.
In
that
same
thermometer.
D
C
Don't
think
we
need
to
solve
for
all
use
cases
to
make
this
feature
valid
to
ship
and
highly
usable
by
the
end
end-user
right
so
like
if
a
user
has
a
use
case
where
they
need
to
reacts
in
a
tree
like
there's
nothing
stopping
them
from
getting
that
today
without
resolutions,
maybe
they
need
to,
you
know,
define
their
resolute
if
they
were
to
add
a
resolution
on
top
of
that
and
needed
to
exclude
something
like
supporting.
That
seems
fairly
straightforward.
Just
by
having
it
be
the
top
level
like
not
defining
a
deep.
D
D
B
Could
also
say
that
any
you
know
any
react:
16x
should
resolve
to
16
10.2,
and
so,
if
your,
if
your
package
and
then
the
way
that
we
I
would
check,
that
is
to
say,
okay,
if
my,
if
my
dependency
is
on
16
9.1
right,
let's
add.
Look
that
I
hand
my
peer
dependency,
because
I
am
an
extremely
person
in
person
who
cares
only
about
my
own
comedians,
so
I've
pinned
my
peer
dependency
to
1691
you're
using
my
module,
and
you
want
to
use
1610
well.
B
That
that
could
actually
be
a
lot
simpler,
so
we
could
have
resolutions.
You
know
I'm
getting
into
solutioning
a
little
bit
here,
but
I
think
that
we
could
get
very
close
to
like
a
you
know
ensuring
that
at
least
within
the
scope
of
react
16.
It
is
a
single
tip
within
my
tree
and
if
there's
a
react,
15
and
then
might
be
a
different
signature
or
a
different
resolution
with
a
different
scope.
B
B
The
other,
the
other
thing
that's
a
little
bit,
dicey
or
I-
think
just
kind
of
confusing
and
I've
seen
some
people
get
wrong
is
using
glob
patterns
in
a
like
in
a
dependency
graph
type
of
path.
So
because
the
dependency
graph
is
a
graph
and
not
a
tree,
there,
there
are
cycles.
There
are
you
know,
things
are
not
laid
out
on
this
the
same
way
they
appear.
You
know
that
they
sort
of
would
be
in
the
graph,
because
that
would
be
impossible
and
so
on.
B
So
using
glob
patterns
feels
like
a
little
bit
of
like
an
impedance
mismatch,
and
that's
that's
another
thing
that
I
think
is
kind
of
a
a
big
caveat
to
the
to
yarn
resolutions,
yarn,
selective
version
resolutions
and
one
one
thing
that
I
would
say
is
a
blocker
against
actually
just
implementing
it.
The
same
way
that
yarn
does
you
know
what
I'd
want
to
do
is
say
if
you,
if
you
have
a
package
that
resolves
within
this
name
and
range
and
potentially
a
couple
of
other
digits,
then
this
is
the
version
you
should
resolve.
B
C
So
so
I
understand
that
we
might
not
be
able
to
represent
all
of
these
cases
perfectly,
but
I
think
that's
actually
letting
perfection
get
in
the
way
of
the
good
or
whatever.
The
saying
is
right
because
again,
if
you
look
at
what
weird
we
have
a
lot
of
people
using
resolutions
and
even
the
most
complicated
case
is
still
representable
by
a
very
basic
glob
pattern
on
the
logical
position
of
the
package
in
the
and
I
say
tree
loosely
I
guess
I
should
say
graph
right.
C
So
if
you
look
at
a
real
world
use
case,
if
that
is
the
most
complicated
one
that
we
can
find
and
I
think
we
should
farm
for
you
know
people
to
come
with
their
most
complicated
real
world
use
cases
here,
then
why?
Why
do
we
care
about
the
perfect
ability
to
represent
every
case
right?
That's
where
yarn
went
wrong
and
I
think
if
we
just
say
like
yeah,
we
recognize
that
glob
patterns
don't
make
perfect
sense,
but
they're.
Actually
the
most
ergonomic
solution
to
this
problem
and
I
think
that's
a
reasonable
end.
State.
B
Right
so
the
I
mean
so
I'm
a
little
bit
concerned
about
the
you
know,
kind
of
the
limitations
and
caveats
that
nested
packages
may
not
work
properly,
but
I.
Guess
that's
just
saying
that,
like
you
know
you
might
you
might
stick
a
version
of
something
in
somewhere
that
doesn't
actually
meet
whatever
dependency
was
required.
C
But
if
we
think
about
the
user
experience
on
that,
that's
like
super
straightforward
right,
like
if
I,
if
I
may
end
user
there
and
I
see
in
a
package.json
react
you
know
and
then
a
version
and
then
a
sub
path
with
react
and
a
version
like
super
legible
I
as
an
end
user,
I
think,
would
be
very
easy.
For
me,
it'd
be
very
easy
to
reason
about
what
that
does.
Maybe
we
have
to
jump
through
hoops
on
the
implementation
side,
but
to
me
that's
a
very
acceptable
thing
to
do.
B
Yeah
so
I
mean
that
the
downside,
the
the
user,
it's
the
user,
facing
the
user
impacting
down
side
of
adding
more
complexity
there
is,
is
potentially
introducing
bugs
when
we're
doing
other
things
with
this
package
tree
right.
So
those
hoops
have
to
be
jumped
through
every
single
time
and
I
see
it.
I
could
see
it
being
a
little
bit.
Hairier.
B
B
If,
if
you
do
it
wrong,
if
you
just
say
I
won't
react,
I
won't
react
to
pin
to
version
in
1610
all
right,
because
I've
got
I've
got
three
depths
I'm
using
and
they're
squabbling
with
each
other
following
a
different
versions,
or
you
know,
I
won't
react
to
resolve
to
15
dot
whatever
and
so
I
say
react
resolved
to
15
blah
blah
blah.
The
error
I
get
is
not
like
hey.
B
B
C
But
well,
it
could
be
just
it
could
just
be
that
a
point
version
that
was
being
pulled
in
is
not
good
and
again.
This
is
where
the
lock
comes
in
right,
like
the
the
case
here
would
be,
I
want
to
apply
a
resolution
and
then
the
next
time
the
tree
is
resolved.
If
that
resolution
would
override
the
override
and
update
the
lock
right
and
that's
why
you
might
not
necessarily
even
go
more
specific,
you
might
just
say
slightly
newer
point
range
on
that
yeah.
B
I
mean
updating.
The
lock
is
actually
easy,
because
when
we,
whenever
we
do
a
build
ideal
tree,
like
you
know,
NPM
seven
is
a
little
bit
less
locked
by
the
lock
right.
So
when
we
do
build
ideal
tree,
we
basically
we
read
in
the
lock
file
and
we
treat
that
as
the
starting
point
for
what
we
want
the
ideal
tree
to
be,
and
then
from
there
you
know
so
a
if
you're
doing
update
all
we
just
throw
the
lock
file
away
and
rebuild
it
because
you're
updating
the
old
tree
right.
B
This
is
like
the
rim,
wrap
and
reinstall
use
case,
so
you
can
just
type
into
him
update
to
do
that
if
you're
doing
it
on
it
fix
it,
it
fixes
those
dependencies
all
the
way
through
the
lock.
If
you're
updating
a
particular
version,
we
go
through
the
entire.
You
know
every
instance
of
that
log
file
and
and
essentially
in
the
bill
that
ideal
tree
process.
We
make
certain
changes
to
the
tree
and
all
of
those
changes
automatically
get
updated
in
the
lock
that
would
save
back.
B
C
Don't
think
you
can
just
use
the
code,
the
lock
saying
it
applied.
The
resolution
at
a
point
in
time
does
not
mean
that
it
is
still
valid
right.
So,
if
you
have
a
resolution,
I
think
it
needs
to
re
result
every
time
irregardless
of
the
state
right,
because
what
if
a
new
version
has
been
published
at
in
the
range
that
the
resolution
is
telling
you.
B
If
the
new
version
has
been
published
in
the
range
that,
in
the
result,
range
right,
say,
I
say,
let's
say:
I
have
this
I
have
this
jerky
dependency
that
some
some
inconsiderate
person
pinned
their
peer
dependency
to
react,
16,
1.2
and
so
in
order
to
get
around
this
situation.
I
create
a
resolution
that
says
react
at
16.
1/2
should
instead
resolve
to
react
at
16,
X.
B
C
Even
if
there's
a
newer
version,
you
don't
really
care
it's
just
like
you
used
a
lock
before
it's
just
that
it's
got
it.
The
resolution
applied,
which
shouldn't
break,
which
should
keep
the
build
time
guarantee
without
putting
you
back
into
a
broken
state.
I
guess,
is
what
I
was
trying
to
get
out
so
that
yeah,
that
makes
sense.
B
B
B
This
gets
tricky
so
then
the
other.
The
other
problem
is
like,
let's
say
I,
let's
say
my
resolution
says
react
at
sixteen
should
be
react
at
sixteen
one.
Two
and
I
have
a
pinned
dependency
on
react,
fifteen
or
sixteen.
It's
not
clear
that
it
will
resolve
to
something
within
the
range.
Do
you
know
I
mean
like
it's
not
easily
determinable,
whether
or
not
the
resolution
should
apply
when
calculating
whether
or
not
a
DEP
is
valid,
because
my
dependency
is
still
going
to
say
some
other
version
of
react
which
might
not
be
satisfied
by
sixteen
one.
B
B
So
calculating
def
malignity
would
be
a
little
bit
tricky
unless
we
stash
that
information
somewhere.
You
know
either
in
the
lock
file
metadata
or
something
to
say
you
wanted
this
version,
but
you
got
that
one
because
of
a
resolution.
I
guess
that's
the
easy
solution.
You
just
always
always
slap
more
metadata
into
the
lock.
It's.
C
That
is
why,
like
they
have
this,
you
know
they
have
a
thing
resolution
rule,
but
but
in
the
end
the
end
user
doesn't
really
know
why
they
got
the
version
they
got
so
being
able
to
answer
those
questions
in
a
really
easy
way
would
be
very
helpful
for
you
know
for
the
end
user
and
if
it
was
just
something
that
was
stored
in
the
locker,
that
that
gave
like
a
fairly
straightforward
description
of
like
you
said.
This
is
what
you
asked
for.
D
A
Awesome
I
appreciate
anybody,
that's
adding
to
these
notes.
I'll
just
be
mindful
of
time.
We
got
about
eight
minutes
left
here.
I
know
we
started
a
bit
late,
but
want
to
make
sure
that
we
are
tracking
all
these
use
cases
and
that
the
notes
are
accurate
as
well
feel
free
to
update
them
even
post.
This
call
you
did
know
was
quickly
also.
It
might
be
good
to
try
to
poke
the
community
for
news
cases
beyond
sort
of
the
scope
of
what
you've
seen
in
your
org
or
in
the
wild.
C
C
A
E
A
C
Tried
looking
for
those
by
all
means
yeah.
That
would
be
great
if
you
can
find
them.
I
tried
and
I
could
not
find
them
in
their
repose
there.
The
prop
the
hard
part
is
it's
a
big
old,
mono
repo.
So
like
there's
conversations
about
all
sorts
of
topics,
all
mixed
in,
so
it's
really
hard
to
even
do
keyword,
searches
and
find
anything
reasonable.
C
Yeah,
that's
you
know
what
you
get
one
other
thing
I
do
know.
He
has
been
active
recently
in
the
that
issue
on
what
package
manager
is
shipped
with
node
in
the
node
repo.
So
you
know
maybe
we
could
reach
out
under
the
you
know
in
the
future.
We
need
to
have
a
better
communication
channel
for
how
these
things
affect
the
greater
known
community,
which
I
think
the
packaged
maintenance
working
group
is
a
great
place
to
have
those
kind
of
conversations.
C
B
Want
to
I
want
to
actually
touch
on
something
real,
quick,
just
I'm.
Looking
over
the
notes,
I
took
here
about
the
complicated
case.
What
if
we
did
a
you
know
if,
if
the
we
implemented
resolutions
such
that
use,
the
key
is
a
range
and
the
value
is
a
different
range
I'm,
not
sure.
If
that
would
solve
your
you
space,
like
let's
say,
I,
have
a
version
of
the
package
X
that
exists
in
you
know
four
instances
in
the
in
the
logical
graph
and
I
want
to
override
it.
B
C
D
B
C
D
Yeah,
maybe
a
really
common
use
case
for
that
is
I
found
a
bug
in
a
package
we
use
and
I've
made
a
PR,
but
the
maintainer
is
not
as
responsive
as
I'd
like
so
one
for
common
option
is
that
people
fork
it
internally
and
like
wow,
that
PR
is
happening,
or
they
even
forget
publicly,
under
a
scope
and
being
able
to
drop.
That
in
for
the
other,
is
very
important.
Well,.
A
B
Then
what
you
could
do
is
like,
let's
say,
let's
say,
the
the
result:
the
value
right
when
the
value
is
a
string,
is
some
package
spec
right.
So
let's
make
it
even
more
general
and
saying
it
has
to
be
a
range
or
version.
It's
some
package
spec
and
the
package
that
could
be
a
get
URL
or
you
should
be
URL
whatever
or
even
a
file
or
tarball.
Whatever
you
wanted.
D
A
D
C
Wait:
oh
right.
C
B
I
was
going
to
say
that
it
might
be,
it
might
be
kind
of
nice
just
as
a
way
to
kind
of
guide
guide
users
to
say
that
the
the
value
does
not
a
should
not
include
the
package
name.
It
should
only
be
aspect
so
I
could
say
X
at
one
will
resolve
to
1.2.3
y
at
one
can
resolve
to
NPM
:
X
at
one
two
three,
and
so,
if
you
want
to
do
aliasing,
it
just
has
to
be
explicit
that
that's
an
alias,
but
the
name
of
the
thing
that
gets
installed.
A
D
B
A
C
C
B
That's
right,
so
then
the
question
is:
does
that
get?
Is
that,
subject
to
the
previous,
the
previous
resolutions
right?
Should
exit
1,
1
3
to
be
rewritten
to
exit,
1.2.3
and
I?
Think
the
answer
is
no
because
this
is
not
a
case
where
you're,
depending
on
X
at
1.
This
is
a
case
where
you're,
depending
on
Y
at
1
and
you're
aliasing
it
so.
D
A
So
just
be
mindful
again
here
we're
about
five
minutes
past
the
hour
and
appreciate
everybody.
Jumping
on
and
given
feedback
here,
I
think
we're
gonna
continue
this
conversation
and
potentially
actually
come
up.
It
seems
like
they're
they're,
my
some
consensus
around
like
how
we
could
move
forward
with
a
nice.
A
C
So
one
so
one
thing
we
need
to
strongly
consider
which
hasn't
been
mentioned
yet
is
there
needs
to
be
a
compatibility
mode?
So,
if
we're
using
the
same
resolutions
key
that
exists
in
the
package
Jason
today,
we
need
to
make
sure
that
that
either
continues
to
work
or
breaks
in
a
very
predictable
way,
so
that
we
can
move
users
forward.
B
F
B
Mindset
that
I
that
I
adopt
with
this.
So
if,
if,
if
there's
something
that's
currently
in
in
wide
usage
like
we
try
very
very
hard
not
to
break
that
now,
if
it's,
if
it's
something,
that's
not
in
very
wide
usage
but
some
other,
you
know
if
P
NPM
was
using
some
field
in
package.json
and
1%
of
P
NPM
users
we're
using
it
and
that's
you
know,
1%
of
users
of
the
NPM
registry
I'd
be
like.
B
A
A
C
Point
there
and
I
don't
want
to
extend
the
conversation
too
long,
but
my
point
there
was
the
explicitly
said
trying
to
support
yarn
style.
Workspaces
was
the
intent
with
works.
Is
we
have
just
said?
We
are
explicitly
going
to
implement
something
different
than
what
has
been
yarn.
Resolutions
and
I
just
want
to
make
sure
that
we're
very
clear
there
is
a
difference
there
and
we
need
to
make
sure
we
reconcile
those
before
shipping
yeah.
That
would
be
part
of
the
RFC.
A
Selling,
that's
also
possible
yeah,
yeah
awesome
so
appreciate
again,
your
folks
jumping
on
I
thought
this
was
actually
super
helpful.
So
hopefully
we
can
actually
put
together
on
RFC
eventually,
for
this
and
I
know
that
this
is
something
that's
been
coming
up
a
lot
with
the
fact
that
we're
installing
peered
ups
again
by
default.
So
resolutions
is
also
like
something
that
you
know
we
see
as
a
potential
mechanism
for
helping
with
some
bugs
we've
been
seeing
with
workspaces.
So
yeah
appreciate
everybody
jumping
on
and
hopefully
talk
with
you
that
next
week,
chance.