►
From YouTube: Open RFC Meeting - Wednesday, February 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.
B
Thing
so,
okay,
and
then
okay,
give
me
one
second
here:
let's
go.
B
B
Great,
it
looks
like
we're
live
on
youtube
thanks
everyone
for
joining
another
mpm,
open
rc
call.
Today's
date
is
wednesday
february
3rd
2021.
I
am
going
to
copy
and
paste
the
meeting
notes
into
chats
feel
free
to
add
yourselves
to
the
attendees
list.
If
you
haven't
already,
we
have
a
pretty
small
agenda
today.
Only
the
two
items
that
essentially
we've
been
talking
about
for
a
little
while
now
have
been
added
here.
So
essentially
a
workspace.
You
know
the
workspace
discussion.
B
That's
been
ongoing
and
sort
of
the
strategy
there
with
you
know,
posting
and
shared
dependencies.
Also,
quick,
quick
note
announcements:
npm
went
to
general
availability,
npm
7
went
to
general
availability
yesterday,
so
it's
now
considered
latest
and
will
be
what
you
get
when
you
fdm
install
g
npm.
So
that's
a
big
big
congrats
to
the
whole
team,
and-
and
this
has
been
a
bit-
you
know
a
year
and
a
half
in
the
making.
So
that's
that's
amazing.
We're
looking
for
lots
of
feedback.
Just
before
this
call.
B
We
had
a
bit
of
a
discussion
that
you
know
we'll
queue
up
here
in
a
second
about
that.
So
just
quick
again.
Code
of
conduct
acknowledgements
these
calls
and,
and
all
this
course
in
the
offices
is
covered
under
the
npm's
code
of
conduct.
Just
please
be
kind
and
mindful
as
we're
talking,
please
raise
your
hand
if
somebody
else
is
talking
and
you
wanna
provide
some
feedback
and
yeah.
B
So
we're
still
looking
for
new
rc's,
we'll
be
doing
a
bit
of
cleanup
here
soon,
as
well
with
some
legacy
rc's.
I
know
that
there's
still
some
outstanding
items
that
got
approved,
that
sort
of
have
changed
are
being
essentially
amended
or
should
be
amended
by
rfcs
that
we've
now
approved
yeah.
But
I
want
to
open
up
the
floor
first
for
jordan
to
give
maybe
a
recap
of
some
of
the
feedback
he
was
giving
from
npm
7
and
sort
of
the
experience
that
you've
had
also
wes.
B
I'm
not
sure
if
you've
had
time
to
to
play
with
play
with
it
or
see
any
feedback,
but
would
love
to
hear
sort
of
thoughts,
feelings.
A
So,
first
of
all,
congrats
mpm7
going
to
latest
is
a
big
deal.
The
I
have
hundreds
of
packages
that
automatically
install
the
latest
supported
npm
in
ci
and
at
the
moment
I'm
only
aware
of
one
package
where
auto,
updated,
npm
7
caused
issues
and
that's
like
astoundingly
low.
So
that's
great.
So
what
I
wanted
to
talk
about
was
that
one
package
just
to
kind
of
get
thoughts.
It
may
or
may
not
be
an
issue
in
npm,
so
there
were
kind
of
two
problems.
One
was
that
this
is
a
package.
A
This
is
an
eslint
plug-in,
so
it
tests
multiple
versions
of
eslint
and
but
one
of
the
things
it
also
tests
is
multiple
parsers
and
in
this
example,
eslint
less
than
five
is
supported,
but
the
typescript
eslint
parser
requires
eslint
five
plus
so
during
my
ci
script
that
tried
to
downgrade
eslint
it
and
pm7
errors
out,
because
it's
a
pure
depth
violation
it
I
looked
around
but
there's
no
there's
no
satisfying
solution,
so
I
ended
up
just
using
the
legacy
pure
depth
setting
to
bypass
that.
A
So
thank
you
for
making
that
available,
even
though
I
wanted.
I
still
believe
that
the
default
should
be
stronger
if
your
dep
enforcement,
the
escape
patch,
is
necessary
and
I'm
glad
it's
there.
The
second
problem
is
really
interesting,
so
this
is
eslint.
Plugin
is
a
root
package
with
sub
packages
in
directories.
A
Npm
install
and
tests
in
the
root
and
some
of
them
run,
install
in
the
root
run,
a
script
which,
like
copies,
dot
files
down
to
the
sub
packages,
and
then
cds
into
the
sub
package
installs
and
runs
its
tests,
and
this
has
worked
fine
for
many
years
and
it
turns
out
that
when
the
root
node
modules
is
present
and
was
installed
with
npm
seven,
the
sub,
like
the
sub
packages,
one
of
the
sub
packages
tests
fails
when
the
root
node
modules
is
absent
or
was
installed
with
mtm
six.
A
A
But
the
this
does
does
illustrate
a
difference
and
I
between
six
and
seven
and
I
of
which
some
are
expected
right
and
I
generated
a
lock
file
for
both
npm
versions
and
diff
them
and
that
the
gist
of
that
diff
has
been
provided.
And
it's
in
the
issue
I
linked
in
the
chat
as
well.
A
So
if
anyone
has
any
ideas,
I
would
be
ecstatic
if
this
were
just
like
a
missing
dependency
or
something
or
you
know,
but
what
I
really
my
current
work
around
is
going
to
end
up
being,
if
I
don't
have
a
real
solution
in
ci
for
this
package,
downgrading
npm
from
seven
to
six,
so
that
I
can
unblock
prs
and
releases
and
stuff.
However,
I'd
rather
not
do
that,
because
that
feels
like
brushing
it
under
the
rug,
and
this
might
actually
be
reflective
of
a
real
problem
that
consumers
using
npm7
will
see.
A
And
so
my
hope
is
that
you
know
in
as
short
a
time
frame
as
as
practical,
we
can
figure
out
for
sure
whether
this
is
my
bug
or
npm's,
because
it's
clearly
one
of
those
two.
C
A
Interestingly,
if
I
npm
install
in
the
root
with
npm
seven
cd
into
the
package
and
npm
install
with
npm
seven
and
then
rm,
rf
dot,
dot,
slash
node
modules,
everything
passes
so
the
sub
packages
install
is
not
the
problem.
I
think
the
root
package
install
is
the
problem
and
the
theoretically.
The
root
package
install
shouldn't
know
about
nested
package
jsons
below,
like
in
subdirectories
right.
A
Yeah,
it
does
not
it's
just
getting
the
wrong
result,
and
I
even
given
that
this
is
in
the
webpack
eslint
plug-in
import
resolver.
I
tried
to
play
around
with
which
webpack
version
was
being
installed,
because
also
a
new
minor
version
of
webpack
was
released.
The
same
day,
npm
seven
was
promoted,
so
I
played
around
with
that
as
well.
I
even
used
the
npm
install
dash
before
argument
to
try
and
pick
a
last
known
good
date,
and
that
is
still
breaking
so
I
am
convinced
that
it
is
not
related
to
the
webpack
version,
but
yeah.
A
Correct
it
could
be,
it
could
be
a
bug,
an
existing
bug
in
the
resolver
that
npm
7's
layout
reveals
or
exposes.
I
don't
know
which
I
hope
that's
that,
because
then
I
can
fix
it
quickly,
but
yeah,
so
we
don't
have
to
spend
tons
of
time
on
the
call
digging
into
it
yeah
despite
we
have
a
light
agenda
but
like
I
wanted
to
just
bring
it
folks
attention,
because
the
issue
of
describing
this
is
a
pinned
issue
in
that
repo,
so
yeah
it'd
be
great
to.
B
Figure
that
out
weston
west
noted
that
and
I'm
not
sure
if
it's
true
can
you
see
the
chat
jordan?
Is
that
the
right
ci
or
build
that's
failing.
A
B
Okay,
all
right,
so
I'm
taking
notes
of
both.
We
can
definitely
dig
into
that
after
the
call
and
try
to
help
figure
out
thanks.
So
what
the
the
situation
is
there,
but
on
the
whole,
you've
had.
A
Good
good
experiences
so
far,
yeah
the
the
during
the
peer
dep
discussion.
I
was
talking
to
isaac
to
try
and
find
a
better
solution
and
ultimately
failing,
but
the
suggested
that
there
is
maybe
a
possibility
of
using
overrides
to
like
not
to
like
use
the
pure
depth
validation,
but
like
hijack
it
for
this
one
case.
But
you
know
that's
not
a
feature
that
has
materialized
yet
so
I'm
hopeful
that
it
will
in
the
future.
B
Queued
up
is
definitely
hi
hi
on
the
list
there,
so
that
sort
of
bleeds
into
the
next
did
anybody
else
have
any
other
announcements
or
anything
else
they
want
to
share
from
from.
C
B
B
D
D
Yeah
yeah,
so
I
just
I
noticed
that
isaac
was
talking
about.
I
I
found
a
behavior
that
I
was
trying
to
debug
and
then
isaac
was
on
twitter
talking
about
git
depp
handling,
and
I
am
something
is
happening
in
one
of
the
trees
that
I
am
using
arborist
on,
which
is
causing
prepare
scripts
to
run
on
git
dependencies.
D
D
Second,
that's
a
big
security
vulnerability
and
then
why
I
brought
that
up
in
relation
with
adam
baldwin's
work
is
that
you
know,
if
he's
starting
to
publicize,
that
that
I
think,
brings
more
attention
to
that
vector.
And
so,
if
we're
starting
to
build
tooling
around
the
these
internal
libraries,
we
we
should
make
sure
that
the
story
there
is
really
solid
and
it's
actually
doing
the
things
we
expect
aka
not
running,
install
scripts
on
build
ideal
tree.
D
D
D
But
I
also
think
that
those
cases
are
things
we
should
probably
explicitly
not
support.
So
the
case
that
the
bug
that
I
ran
into
is
it
ran
a
prepare
script
which
tried
to
import
a
the
built
file
and
the
built
file
didn't
exist
because
it
was
a
git
depth.
So
the
prepare
script
didn't
run
the
right
like
for
how
are
they
instruction
the
picture?
D
It's
a
deprecated
package,
it's
really
old,
but
it's
just
in
somewhere
in
this
tree
that
I
was
trying
to
install
and
like
it
failed
in
a
really
unexpected
way,
because
it
just
said
like
your
prepare
script,
failed,
cannot
import
indexed,
you
know
or
main
the
package.
Jason
doesn't
have
a
main
that
that
we
can
require
or
like
it
was
some
error
like
that
and
and
it
took
a
while
to
track
down
because
it
was
a
deep
transitive
and
it
was
a
deep
transitive
and
it
get
depth.
D
D
So
you
know
I
don't
know
how
popular
those
packages
are
on
the
public
registry,
but
if,
but
if
this
is
going
to
surface
in
an
npm
install
or
you
know
other
tooling
like
we
were
mentioning
that
that
uses
build
ideal
tree
but
doesn't
reify
like
that's,
probably
going
to
crop
up
somewhere.
C
B
B
And
just
the
beginning
of
that
note,
wes
you're
saying
it
doesn't
seem
to
be
enforcing,
ignore
scripts
like
false,
essentially.
D
I
haven't
made
the
reduced
test
case
yet
and
if
I
can
get
to
reduce
test
case,
I
can
try
passing
ignore
scripts.
Okay,
the
install
completely
doesn't
work.
If
I
do
that,
and
it's
because
of
an
unrelated
thing
in
the
in
the
particular
tree
that
I'm
trying
to
install
the
the
worry
that
I
have
is
that
build
ideal
tree
specifically,
is
when
it's
installing
the
the
get
dependency
into
the
cache.
D
C
C
Yeah,
it
definitely
makes
me
think
that
it's
something
in
the
coaching
right
like,
especially
because
that
fix
wasn't
coaching,
yeah
and
piccochi
happens
like
it's
going
to
fetch
all
these
during
the
build
ideal
tree
stop.
So
that
would
kind
of
make
sense
like
the
dots
kind
of
connect
there.
But
I
definitely
need
to
dig
down
some
more
into
the
internals.
B
And
I
just
knew
sort
of
anecdotally
that
adam
had
posted
that
blog
post-
I
just
I
haven't-
had
a
chance
to
read
through
it
myself
specifically,
but
I
know
there's
a
couple.
Other
security
related
topics
that
I
think
west
you
and
I
are
going
to
sync
up
on
after
this
call,
but
yeah
yeah.
D
At
one
point,
I
don't
know
if
it
still
does,
but
like
they're
they're
prevalent
enough,
that
that
the
the
fact
that
it's
unclear
what
we
should
expect
out
of
those
and
that
we're
seeing
some
odd
behaviors
in
npm
seven's
handling
of
it
is,
is
something
I
think
we
should.
We
should
make
sure
we
have
a
full
understanding
of
before
they
start
cropping
up,
especially
as
security
issues.
B
B
I
know
so
roy,
I
think
diff
did
land
on
on
friday,
thursday
or
friday,
so
that
was
after
our
last
call.
I
don't
think
there
was
anything
else
that
would
have
landed
in
the
last.
You
would
have
seen
actually
day
one
patch
release
as
well
so
announcement.
There
was,
I
kept
joking
that
we're
kind
of
like
game
developers
so
day.
One
patch
was
inevitable,
at
least
for
the
npm
v7,
going
to
latest
so
yeah,
better.
B
Right,
our
patch
was
a
little
bit
better
right,
still
still
works
on
legacy
systems.
Without
yeah.
We
didn't
throw
your
dependencies
up
in
the
air
and
and
yeah
game
breaking.
E
Yeah,
there's
no
there's
no
project
breaking
experiences
right
now.
I
guess
there's
a
few
but
anyway
I'll
stop.
I'm
done
yeah
yeah,
I'm
helping.
I
want.
B
To
yeah
I
was
very
excited
to
potentially
get
that
game
and
I
can't
make
any
jokes,
because
I
haven't
seen
like
all
the
issues
with
it
just
heard:
anecdotally
so
cool.
So,
let's
dive
into
the
two
items
we
have
are
essentially
their
one
one
item,
and
this
is
similar.
You
know
I
outlined
a
pretty
good
agenda
last
week.
B
Unfortunately,
I
know
jordan,
you
weren't
able
to
be
there
and
we
can
sort
of
maybe
even
rehash
some
of
the
the
sentiments
and
some
of
the
conversation
that
was
had
I'll
try
to
pull
up
the
meeting
notes
from
that,
but
yeah,
maybe
roy.
If
you
can
even
speak
since
these
are
both
your
issues.
B
Maybe
you
can
speak
to
just
like
state
of
the
world,
and
you
know
some
of
the
conversations
that
we're
having
around
workspaces
and
sort
of,
like
a
re-evaluation
of
you,
know
the
way
they're
implemented
today
in
terms
of
like
linked
ups.
Maybe
you
can
just
high-level
where
we're
at
today
and
what
we're
looking
to
maybe
change
sure.
C
Yeah,
that
sounds
like
a
good
idea,
so
yeah,
because
today,
workspaces
are
basically
same
as
same
links
using
a
file
column
protocol
in
your
package.json.
C
So
it's
pretty
much
just
sim
linking
them
to
your
root,
node
module
and
then
making
that
make
sure
it's
available
to
be
used
anywhere
right
as
you
can
require
them
from
anywhere
within
your
project.
So
but
it's
also
very
simplistic,
and
we
had
some
users,
some
feedback,
that
it's
kind
of
limiting
and
one
of
the
things
the
important
ones
we
were
trying
to
tackle
recently
was
the
no
heist.
C
C
C
So
basically
there
is
that
one
which
is
kind
of
like
part,
two
follow-up
from
the
original
workspaces
work
and
the
second
one
that
kind
of
triggered
this
reevaluation
rethinking
of
how
workspaces
are
installed
is
the
is
this
our
rfc
issue
here
that
basically
asks
us
to
support
more
than
just
simple
ranges
in
order
to
replace
something
with
a
workspace.
C
So
these
are
basically
the
two
hitches
in
the
agenda
here
and
it's
kind
of
a
little
bit
of
state
of
the
world
yeah.
I
think
the
part
two
follow-up
is
definitely
implementing
the
commands
implementing
the
missing
workflows
to
work
with
workspaces
and
after
that
we
jumped
into
this
conversation
a
little
bit
more
about
changing
some
of
the
fundamentals
so
yeah.
So
with
that
said,
maybe
maybe
someone
wants
to
pick
up
and
add
some
comments.
C
D
Mean
you
did
sorry,
I
I
saw
you
in
there
chatting
with
the
folks
from
google
on
what
they're
doing
in
release.
Please
and
I
think
that's
an
excellent
example
of
a
workflow
that
that
should
probably
just
be
built
into
npm
like
there.
He
had
a
proof
of
concept
using
lerna,
but
I
think
getting
a
sane
handle
on
on
you
know.
Dependency
updates
in
a
mono
repo
like
that
would
be
would
be
excellent.
Also
I
would,
I
would
very
much
use
it
so
it
saved
me
a
bunch
of.
D
B
So
sorry,
the
the
feedback
there
wes
is
the
having
those
use.
Cases
like
outlined
is
good.
D
C
D
I
think
you
could
actually
circumvent
the
need
for
what
they're
doing
entirely,
if
you,
if
you
just
did
this
as
an
npm
feature
so
like
what
they're,
what
they're
trying
to
do
is
just
do
automated
prs,
updating
dependencies
across
the
entire
monorepo
right
and
and
the
fact
that
there's
not
like
a
really
good,
clear,
explicit
workflow.
D
There,
I
think
is,
is
the
problem
trying
to
be
solved
and
the
reason
they
need
that
underlying
feature
of
the
package
tree
and
memory,
and
all
that
is,
is
sort
of
not
really
the
point
if
they
could
just
run
an
npm
command
and
get
an
updated
workspace.
E
Yeah,
I
think
in
general,
especially
like
you
know,
with
both
github
and
npm
and
all
the
different
things
that,
like
we
have
kind
of
access
to
there's
so
many
different
great
things
that
we
could
start
exploring
on.
You
know
improving
releases
as
a
whole
release.
Please
I
I
think
it's
just
like
fantastic,
fantastic
work
and
I
think
it's
super
cool
and
so
yeah.
E
I
guess
I
guess,
like
one
of
the
big
challenges
in
my
mind,
is
definitely
finding
that
balance
between
like
doing
things
that
are
npm
specific
versus
generic
to
like
releases
as
a
whole,
things
that
make
sense
when
I
don't
know
the
exact
number
but
like
so
many
of
these
npm
projects
are
actually
tracked
on
github.
So
if
you're
going
to
use
like
github
actions
to
this
like
how
do
we
make
that
better
and
there's
so
many
different
things
that
we're
poking
at
there?
E
And
so
I
guess
what
what
I
would
say,
wes
in
general
is
like
the
more
that
you
can
surface
like
some
of
these
release
processes,
and
maybe
you
and
I
just
catch
up
offline
on
this
offline
about
this,
as
well
as
someone
who
has
been
in
the
release
mines
before
and
has
the
scars
to
prove
it.
This
is
a
space
that
I
really
care
about,
and
I
think,
like
another
part
of
it
too,
is
also
like
you
know.
E
There
is
like
the
creating
and
there's
also
the
like
consuming
so
thinking
about
like
how
do
we
present
releases
to
people
like
we
just
did
great
work
with
the
typescript
information
and
the
per
release
downloads
and
we're
going
to
keep
thinking
about
like
what
are
ways
that
we
improve
this
consumption
scenario
for
folks
as
well,
and
so,
if
you
have
ideas
in
there,
we're
always
open
to
hearing
them.
D
Yeah
I'd
be
I'd,
be
happy
to
do
that
and-
and
I
think
the
the
value
add
here
could
be
really
big.
If
we
can
go
beyond
just
the
you
know,
github
release,
please
like
not
only
would
it
help
things
like
you
know,
release
please
just
operationalize
better
and
have
less
custom
one-off,
you
know
things
they
need,
but
I
think
the
tooling
there
can
be
pretty
generic
and
solved
because,
like
we,
you
know
we
we're
not
on
we're
not
on
github.
It's
like
we
can't
use
those
things
like.
D
D
Until
we
move
to
some,
you
know,
move
to
github
and
so
like
finding
that
balance
has
been
really
difficult,
and
I
imagine
most
you
know
there
are
many
engineering
orgs
that
are
in
a
similar
boat,
where,
like
it's
all
great
and
well
to
say,
like
yeah
look
release,
please
go
use
it,
but
you
just
can't,
but
so
having
some
some
base
tooling,
that
maybe
doesn't
go
as
far
as
release
please,
but
still
support
some
of
those
workflows
like
with
workspaces,
and
you
know,
dependency,
updates
and
stuff.
D
You
know
that
that
would
still
move
the
needle
quite
a
bit.
So.
B
Yeah
yeah,
I
think
what
you
were
speaking
to
as
well
was
I,
if
I
remember
the
conversation
now
correctly
was
they
were
looking
for
essentially
like
an
api
from
arborist
to
surface
the
package,
jsons
of
workspaces
and
or
list
out
the
workspaces
in
a
project
programmatically,
so
that
they
could
then
do
something
else,
unique
or
or
right.
A
D
B
Dog
fooding
that
api
yeah,
like
we
just
don't.
I
don't
think
we
have
the
api
for
us
to
give
you
that
or
we
don't
have
any
to
do
it
a
synthetic
way
we
still
pass
so
like
everything
is
predicated
on
like
the
prefix
and
like
the
directory,
whereas,
like
I
know,
you've
asked
in
the
past,
and
I
think
that
this
is
definitely
something
we
should
support.
Is
the
like
synthetic
creation
of
like
a
package
json
that
gets
passed
in
and
then
you
get
returned
right
for.
D
What
it's
worth,
one
of
the
main
reasons
why
I've
asked
for
that
in
the
past
is
the
same
exact
user
workflow.
So,
like
I
have
a
tool
that
literally
goes
and
builds
a
synthetic
package.
You
know
tree
of
package
jsons
and
says
which
ones
do
I
want
to
update?
Okay?
These
are
the
ones
and
I
apply
some
special
rules
to
it
in
logic
that
you
know
I
would
never
maybe
not
never
expect
npm
to
do.
D
But
you
know
it's
custom
stuff,
so
I'm
fine
with
that
living
outside
of
npm,
but
if
just
the
base
workflows
of
of
you
know
providing
some
like
being
able
to
load
this
up
in
memory
apply
some
very
light
changes
to
it
and
then
write
it
to
disk.
If
that
was
something
I
could
do
with
some,
you
know
npm,
tooling,
and
not
have
my
own
a
whole
ton
of
extra
work
to
do
that.
On
my
own
big,
win
right
and
again,
that's
the
same
thing
they're
doing
in
the
release.
B
Okay
definitely
improvements.
We
made.
D
Yeah,
it
is
and
that
it
does
almost
work.
So
again,
I
think
you
know
on
a
I
I
haven't
tested
what
they
were
trying
to
do,
yeah
directly.
So
the
things
I
I'd
be
lo
I'd
love
to
know.
If,
when
they
tried
just
running
you
know
it
with
npm
7
like
did
it
fail
in
some
particular
way
that
caused
them
to
go
the
learner.
You
know
package
route
like
like,
maybe
there's
something
that
we're
unaware
of.
I
know
the
the
pack,
the
the
projects
that
I've
tried
it
on
it.
D
I
think
it
seemed
to
work.
I
just
don't
have
the
fine-grained
control
that
I
needed
so
like
we're
doing
some
things
where
I
needed
to
after
I
applied
that
update,
also
generate
like
a
nice
display
that
I'm
gonna
submit
with
the
pr,
and
I
I
like,
pull
in
some
things
like
I
generate
diff
links
for
all
of
the
top
level
packages.
D
I
also
don't
do
I
do
deep
updates
for
internal
packages,
but
not
external,
like
there's
a
bunch
of
these
little
things
where,
if,
if
we
could
better
support
that
with
just
npm
update
like
instead
of
having
to
go
deep
into
arborist
like
I'm
doing
or
use
lerna
like
they're
doing,
I
think
that
would
be
would
be
great.
And
I.
A
D
Have
an
explicit
rfc
for
this,
like
I
wanted
to
start
rolling
this
out
internally
and
see
what
roadblocks
I
hit
before.
I
proposed
anything,
but
I
do
think
that
the
fact
that
they're
working
on
it
I'm
working
on
it
and
you
are
looking
at
what
improvements
we
need
to
make
to
work
spaces
seems
like
this
is
a
timely.
You
know,
would
be
a
timely
topic
to
sink
on.
So.
B
B
The
way
that,
like
workspaces,
are
linked,
but
like
that,
the
conversation
that
I
think
like
we
should
be
considering
like
is
very
important,
is
like
how
like
what
do
you
get
access
to
when
you
essentially
define
a
workspace
and
like
how
does
do
those
dependencies
get
resolved
and
like
what
are
the
strategies
or
like
improvements?
We
should
be
making
or
changes.
We
should
be
making
to
how
that's
implemented
today,
because
that
will
then
affect
the
implementation
of
running
commands
or
these
other
sort
of
apis
right,
because
I
almost
feel
like.
B
We
know
exactly
what
not
exactly,
but
we
know
like
how
you
know
you
can
imagine
the
api
to
look
like
today
for
running
commands
and
in
workspaces,
so
like
filtering,
etc.
Like
we've
had
that
conversation
now
for
for
a
long
time
and
like
there's
prior
art
with
lerna,
there's
prior
with
yarn
v1,
so
it's
kind
of
like
you
know,
do
we
like,
or
are
there
limitations
to
the
way
that
we've
implemented
workspaces
and
treating
them
like
link
depths
today?
B
If
we
keep
going
down
that
route
like
are
we
going
to
have
problems,
as
jordan
has
mentioned
many
times,
do
we
want
to
explicitly
start
to
define
you
know
shared
verse,
not
shared
dependencies
instead
of
this
concept
of
like
hoisting
and
no
not
hoisting,
because
again,
you
know,
that's
a
part
of
this
conversation
as
well.
Once
we
get
into
like
you
know,
so
those
are.
B
Those
are
the
things
that
I
think
that,
like
we
should
be
focused
on
and
talking
through
and
getting
some
consensus
around
and
then
like
these
other
sort
of
like
these
are
the
easier
parts
like
literally
you
you,
the
components
are
all
there.
It's
almost
like
do
this
right
now
right
so
like
the
folks
that
release,
please
are
yourself
like
I
have
already
written.
B
You
know
something
to
work
around
it,
so
it'd
be
really
quick
for
us
to
build
once
we've
maybe
got
consensus
on
these
harder
things
which
are
like
the
yeah
and
jordan
nice
year
right.
A
Jump
in
yeah,
just
I'm,
I'm.
I
think
it's
very
important
that
npm
provide
the
only
non-broken
workspaces
implementation
that
exists,
and
I
think
it
would
really
help
the
ecosystem
a
lot,
because
I
think
that
there's
almost
anyone
who's
done,
work
work.
A
Spaces
like
work
runs
into
hoist,
slash,
no
hoist
type
problems
or
bugs
related
to
it,
or
they
just
throw
up
their
hands
and
they
like
throw
everything
in
the
same
dependencies
block
and
don't
even
care
about
depths
versus
dev
depths
anymore,
and
you
know
I
think,
that
and
that
that's
also
a
loss
to
kind
of
funnel
people
there.
So
I
I
would
really
like
to
see
us,
try
and
solve
this
problem.
C
Yes,
which
brings
me
to
my
some
of
the
ideas
I
wanted
to
share,
and
maybe
I
can
give
some
quick
feedback
on
it
because
yeah
I
was
thinking
about
all
these
things
together
and
I
kind
of
do
feel.
Like
the
you
know,
the
part
two
of
workspaces
support
being
able
to
run
commands
across
workspaces
all
the
stuff
everybody
that's
kind
of
trying
out
workspaces
in
npm
right
now,
they're
kind
of
complaining
about.
D
C
C
Invasion,
yeah,
but
basically
yeah.
Maybe
I
was
thinking
just
which
that
work
is
more
about
defining
that
those
apis,
so
that
we
can
just
have
a
way
to
running
these
commands
having
a
way
to
work
with
workspaces
and
that
kind
of
can
be
adjusted.
If
you
change
the
way
that
workspaces
are
installed
internally
and
then
maybe
we
can
hold
on
to
npm
eight
to
do
maybe
big
shifts
in
the
way
the
workspaces
are
installed
so
still
following
you
along.
I
think.
B
Yeah,
so
thanks,
and
so
I
kind
of
agree,
I
I
agree
with
you
that
the
behavior
changing
the
default
behavior
changing
can't
can't
happen
until
the
next
major,
but
then
I
also
agree
with
jordan
in
terms
of
we
could
potentially
provide
configuration
to
to
change
this
in
a
minor
or
like
an
opt-in
change,
and-
and
I
liken
this
and
I've
said
this
many
times
and
and
I've
actually
been-
and
I
can
make.
B
I
can
say
this-
I've
been
working
with
some
folks
internally
at
who
are
working
on
like
m365,
who
have
very
large
workspace
project
and
they're
trying
to
move
over
to
npm.
B
They
also
want
they
need
not
want
they
need.
You
know
the
ability
to
essentially
scope.
B
And
have
more
strictness
in
the
way
that
the
dependencies
are
being,
let's
say,
installed
and
shared,
and
so
they
don't
want
hoisting.
They
don't
want
the
current
behavior
to
happen
or
what
we
call
hoisting
and
so
and-
and
I
I've
said
this
multiple
times,
we
already
have
flags
to
change.
The
behavior
here.
Legacy
bundling
and
global
style
are
two
flags
right
now
that
I
look
at
and
I
go.
B
Oh
somebody's
opting
into
a
different
behavior
and-
and
you
know,
yeah,
like
style,
essentially
and
different
strategy,
and
so
I
think
that
us
introducing
something
that's
a
a
new
opt-in
feature
for
for
changing
this
and
and
and
adding
some
strictness,
and
we
can
call
them
strategies,
you
can
call
them
whatever
you
want
to
call
them.
I
think
that
that
can
be
added
in
a
minor.
We
don't
have
to
wait
until
the
next
major
to
introduce
that
right
and
yeah.
Sorry
wes.
I
see
your
hands
up
and
then
jordan.
I
know.
D
Just
a
just
to
follow
on
to
this,
so
it
I
I
think
in
a
minor
behind
a
configuration,
would
be
excellent.
I
think
one
of
the
hard
parts
when
seven
was
rolling
this
stuff
out.
You
know
for
me
to
go
and
get
real.
D
So
having
it
in
a
minor
would
be
great,
especially
if
we
can
have
it.
You
know
I
mean-
and
I
think
this
would
just
be
part
par
for
the
course,
but
have
it
in
a
config
variable
which
we
could
set
in
the
npm
rc,
so
that
all
users
they
could
just
roll
it
out
as
a
feature
for
the
entire
team,
because
then
we'd
be
able
to
get
real
user
feedback
because,
like
right,
the
challenge
I'm
having
right
now
is
like.
I
have
to
ask
them
to
switch
from
yarn
to
mdm
72..
D
It's
not
even
like
we're
going
from
a
you
know,
we're
changing
their
muscle
memory
right,
because
they're
used
to
typing
yarn,
this
yarn
that
so
so
being
able
to
to
get
this
without
them
not
only
having
to
to
go
to
npm,
but
also
have
to
go
to
a
npm.
Eight
beta,
like
is
not
gonna,
happen
right
like
so,
I
won't
be
able
to
give
real
user
feedback
so
anyway,
that's
my
my
only
take
on
it
is
is
that
you
know
to
get
to
get
the
real
feedback.
A
I
think
that
the
vast
majority
of
them
would
be
able
to
transition
from
the
current
default
mode
to
this
new
mode,
and
it
would
just
work
it
would
do
exactly
what
they
think,
but
I
think
that,
if
that
it
would
be
really
disruptive
for
the
subset
of
folks
that
are
used
to
a
less
idiomatic
monorepo
workflow,
if
like
it,
would
be
very
disruptive
to
them
if
they
couldn't
upgrade
to
like
npm
eight,
let's
say
because
it
switched
how
this
this
thing
worked.
A
So
I
think
it's
actually
really
important
that
it
be
sember
miner,
and
I
think
that
the
fact
that
well,
that
if
my
intuition
is
correct,
then
the
then
the
the
resulting
fact
that
the
majority
of
people
would
be
able
to
use
both
modes.
Equally.
Well
is,
actually,
I
think,
endorses
the
new
mode,
because
it
means
that
they
will
just
get
better,
more
correct
strictness
that
matches
the
way
they're
already
authoring
their
net
their
workspaces,
and
they
can
just
flip
back
and
forth
and
try
it
and
be
like
yep
all
the
tests
still
pass.
A
I
guess
we'll
use
the
better
version
right
and
then
like
for
the
people
that
have
a
different
workflow.
We
can
just
say
in
the
docs
like
the
this
is
the
workflow
that
this
mode
is
expected
to
work
with.
If
you
don't
have
this
workflow
stick
with
the
default
right
or
or
like
explicitly
specify
this
mode.
So
when
we
switch
the
default
in
npm,
eight
or
nine,
like
you,
you
know
you
aren't
broken
right.
There's
I
think
like
as
much
as
I
always.
A
B
C
Yeah,
no,
I
just
maybe
compliment
it.
I
think
I
also
have
a
question
to
jordan
or
any
of
you
really,
but
basically,
if
we
go
this
route
of
just
having
different
strategy
or
a
different
configuration
that
installs
workspace
in
a
better
way.
So
maybe
question
first
question
those
that
fixes
the
no
hoist
use
case
like
by
default.
C
This
this
correct
same
way
of
handling
workspaces
and,
if
that's
the
case,
or
maybe
it's
not
like
still
for
a
lifetime
of
npm7,
like
I
still
think,
maybe
by
default,
we
want
to
at
least
make
the
cly
be
aware
and
respect
the
no
hoist
configuration
that
folks
used
to
use
in
the
rnv1,
because
that's
probably
what's
going
to
make
like
most
of
the
projects
in
the
ecosystem,
just
just
work
with
workspaces
out
of
the
box
right.
So
be
it
just
that
having
the
no
voice
will
trigger
this.
A
Is
hoisted
by
default,
and
then
you
specify
which
packages
aren't
you
could,
whether
you
have
that
mode
or
the
opposite,
where
nothing's
hoisted
and
then
you
specify,
which
are
you
have
to
have
both
skate
patches,
because
the
model
is
mismatched
like
you
cannot
apply
the
model
without
an
escape
hatch
in
either
direction.
A
B
We
didn't
like,
like
by
say
we
I'm
saying
broadly,
and
I
think
at
the
time,
if
I
remember
correctly,
that
a
lot
of
folks
didn't
like
this.
I
know.
Personally,
I
don't
like
this
as
personally.
I
don't
think
this
is
we
want
to
support
this.
I
don't
think
it's
it's.
It
seems
very
cumbersome
on
you
to
have
to
declare
these
things
inside
the
workspaces
and
yeah.
B
I
also
just
don't
like
I've
been
trending,
not
trending,
but
like
I,
I
I'm
thinking
about
this
more
and
more,
I
think,
like
yourself,
jordan,
with
like
utilizing
the
hoisting
nomenclatures
like
very
like
doubling
down
on
it,
is
not
the
right
move
here.
I
like
the
shared,
not
shared
like
like
yeah
yeah,
like.
B
A
B
I
think
people
are
going
to
get
run
into
the
problem
that
we're
installing
pure
dependencies,
though
so,
if
you're
running
in
yarn,
v1
workspaces
and
you're
migrating
to
npm
workspaces,
I
mean
the
prickly
part
isn't
going
to
be
the
no
hoist.
As
far
as
I
know,
they're
going
to
run
into
the
peer-to-peer
depths
problem.
First
yeah.
Did
you
raise
your
hand
or
is
that
you.
C
I
guess
I
guess
maybe
the
more
actionable
thing
like
that
we
can
maybe
settle
this.
Do
you
think
it's
a
good
idea
to
maybe
start
working
on
the
story
of
running
commands
across
workspaces
before
we
have
that
definition
or
because
I
do,
but
I
want
to
also
kind
of
feel
the
sentiment.
D
I
think
so
because
I
think
we
have
a
pretty
clear
understanding
of
what
users
need
here,
so
so
doing
that
and
swapping
out
the
implementation
under
the
hood.
Once
we
have
a
decision,
there
enables
both
the
like,
let's
test
this
out
in
a
minor
right,
lets
you
sort
of
work
on
what
I
see
as
the
most
immediately
impactful
workflows
without
having
to
you
know,
lift
and
shift
the
entire
ecosystem
here.
D
So
I
I'm
I'm
a
fan
of
of
that
and
I
don't
think
even
if
it
might
change
in
some
of
the
edge
cases
and
how
the
handling
works,
we're
already
planning
on
breaking
the
paradigm
so
like.
Actually,
if
we
have
some
people
on
these
use
cases,
we
can
then
test
out
breaking
the
paradigm
with
them
and
make
sure
that
it
works
in
a
reasonable
way.
So.
A
But
also
the
the
what
I'm
envisioning
with
this
new
mode
is
is
just
a
superior
node
modules
layouts,
and
so
I
would
assume
and
expect
that
all
user
interface
like
stuff
npm
command
invocations
would
be
identical
and
would
do
the
identical
thing.
It's
just
a
question
of
what
node
modules
are
available
during
that
that
running
of
those
commands
or
like
what
are
installed
by
those
commands
so
like.
If
that's
going
to,
if
we
think
that'll
be
different,
I
think
it's
very
important
that
we
call
that
out
early.
B
If
rory
starts
to
work
on
this
or
other
folks
on
our
team
start
to
work
on
the
the
you
know,
the
more
complex
workflows
just
like
running
commands
and
workspaces,
just
flushing
that
out
and
getting
that
out-
and
I
think
that's
the
easy
easier
part
and
like
it
would
be
good
and
useful
for
for
we
shouldn't
block
on
it.
That's
what
I'm
saying
we
shouldn't
block
on
this
other
thing
that
is
going
to
be
introduced,
probably
in
a
new
flag
or
configuration.
B
No,
I
really
like-
and
I've
documented
in
notes
here,
you've
said
a
couple
times:
jordan.
I
don't
know
if
you've
said
it
before
but
modes
modes
are
I've
been
calling
them
strata
calling
it
strategies
in
the
past,
but
I
like
modes
as
well.
So,
however,
we
want
to
spell
it,
you
just
want
yeah.
I
want
this
thing.
I
don't
care
how
it
like
yeah
and
what
flag
I
need
to
get
it,
but
okay,
so
just
be
mindful.
We
only
got
a
couple
minutes
left.
B
A
And
I
think
I
would
I
would
just
color
that
by
saying
I
no
hoist
is
something
that
would
doesn't
make
sense
in
the
new
mode,
but
doesn't
conflict
and
all
of
the
other
workspace
command
running
things.
I
don't
believe
conflict
at
all
and
would
would
work
in
both
so
like.
I
think,
if
we
just
are
cognizant
to
with
all
workspaces
work,
if
we
think
about
in
the
old
mode
in
the
new
mode.
A
What
do
we
think
like
then
like
as
long
as
it's
not
going
to
cause
a
problem
for
the
other
one,
then
there's
no
reason
to
block
it.
We
should,
of
course,
make
the
default
mode
that
we're
hopefully
going
to
keep
for
a
long
time
anyway.
You
know
like
see,
even
if
we
ship
this
new,
better
mode,
I
keep
you
know
hoping
for,
like.
I
still
think
npm
should
support
both
for
a
long
time
together
so
like
we
should
make
it
better
regardless.
B
Well,
I
appreciate
everybody
jumping
on
again
today.
I
know
we
had
a
light
agenda,
but
we
were
able
to
fill
the
time.
So
that's
a
good
sign.
Hopefully
it
was
useful
and
sounds
like
we
actually.
For
me
at
least,
I
feel
like
we're
a
little
bit
unblocked
to
get
to
work
here.
We
still
have
like
a
good
amount
of
work
to
keep
improving
seven,
but
yeah
awesome,
so
we'll
be
back
again
next
week.
B
I'll
try
to
be
better
with
getting
the
agenda
queued
up
earlier
and
get
feedback
and
make
sure
that
we
have
like
a
great
discussion
about
the.
What
we
want
to
talk
about,
feel
free
to
keep
giving
us
feedback
about
v7,
usage
and
and
jordan
will
circle
back
on
that
item
you
gave
to
us
async
in
whatever
slash
zone.
B
Thanks,
awesome
I'll,
see
you
all
soon
all
right.
Thank
you.