►
From YouTube: Open RFC Meeting - Wednesday, May 12th 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
B
And
we're
live,
welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday,
may
12
2021.
B
I'll
copy
and
paste
the
note
stock
that
you
can
follow
along
here
in
chat,
feel
free
to
add
yourselves
as
attendees
we'll
be
going
through
the
agenda
that
was
posted
in
issue
381
in
the
mpm
rfcs,
refill
and
yeah.
I
just
want
to
quickly
remind
folks
that
these
calls
and
all
comms
on
the
rfc's
forum
or
sorry,
the
rfc's
repo
and
all
of
our
repos
are
under
a
code
of
conduct
that
we
ask
you
to
please
abide
by
on
these
calls.
B
We
ask
that
you
please
be
kind
and
and
consider
it
as
others
are
talking.
Please
raise
your
hand
if
you
have
a
comment
and
we'll
we'll
call
on
you
and
yeah
just
hopefully
we
can
have
good
good
conversations
in
these
calls.
So
any
quick
announcements
that
folks
had
things
going
on
in
the
ecosystem.
They
want
to
share.
B
If
not,
I
do
have
one
announcement
from
our
end:
open.js
world
is,
is
coming
around
the
corner
and
june
2nd
and
3rd,
as
far
as
I
know,
feel
free
to.
If
you
haven't
already
sign
up
as
an
attendee
or
follow
along,
I'm
sure,
there's
going
to
be
lots
of
great
presentations.
B
Folks
from
our
team
are
involved
and
yeah
we're
we're
excited
about
the
the
work
that's
being
put
into
that
conference
and
event
and
hoping
that
there's
going
to
be
some
great
content
come
out
of
it,
so
just
want
to
put
a
spotlight
on
that
if
we're
moving
along
here.
The
first
item
we
actually
had
on
the
agenda
is
pr
375.
B
So
this
is
the
rc
that
isaac
put
together
and
quickly
mentioned
at
the
end
of
last
week's
rfc
call.
Maybe
you
can
go
into
a
little
bit
more
depth
about
what
we've
been
up
to
since
then
isaac
and
and
sort
of
like
the
impetus
behind
this.
This
work.
C
Yeah,
so
I
believe
actually,
jordan
has
been
the
most
frequent
or
vocal
person
bringing
this
this
issue
up
as
far
as
workspaces
and
just
kind
of
how
it
sets
up
sets
people
up
for
undeclared
dependencies
very
easily
and
at
the
same
time,
anything
we.
You
know
if
we
fix
that,
if
we
change
that,
then
there
are
things
that
ought
to
be
tested
together
and
ought
to
be
shared.
C
That,
then
won't
be
so
it
gets
kind
of
challenging,
and
so
we
we
have
talked
about
this
a
few
times
in
this
in
this
context,
but
I
just
basically
wrote
that
down
so
there's
a
spec
for
which
I
didn't
hear
a
lot
of
didn't,
get
a
lot
of
like
push
back
on
on
at
least
the
rough
strokes
of
it,
but
the
there.
C
At
the
same
time,
there
is
a
proposal
in
the
works
coming
from
vincent
on
the
microsoft
side,
about
something
he's
calling
pure
mode,
which
is
basically
a
very
pnpm-like
approach
to
avoiding
undeclared
dependencies
and
there's,
obviously
a
lot
of
overlap.
C
So
he-
and
I
have
synced
up
on
that
and
where
we
kind
of
landed,
is
both
of
our
both
of
our
rfcs
are
somewhat
overlapping
and
and
at
the
same
time
trying
to
do
too
much
so
we
talked
it
through
and
it
really
should
be
three
separate
kind
of
much
more
tightly
scoped
proposals,
the
first
one
is
what
gets
shared
by
default
and
what
gets
isolated
by
default
and
just
identify
that
there
is
a
way
to
opt
into
one
or
the
other
period
like
we're
not
going
to
tell
in
that
proposal,
we're
not
going
to
talk
about
like
what
that
syntax
is
just
sort
of.
C
If
you
opt
into
sharing
it,
then
here's
how
it
gets
shared.
If
you
opt
into
isolating
it,
then
it
will
be
isolated,
and
this
is
kind
of
the
ramification
of
that
from
a
you
know,
what
can
require
what
point
of
view
not
not
even
talking
about
like
the
implementation
details
at
all.
The
second
proposal
is
a
syntax
and
that'll
cover
both
pure
mode
as
well
as
workspaces
as
well.
As
you
know,
individually,
isolating
saying,
I
want
this
thing
to
be
always
isolated
at
this
point.
C
In
the
tree,
and
not
ever
hoisted,
the
second
proposal
is
the
defining
the
syntax
for
how
we
specify
that,
whether
that's
a
config
or
package.json,
what
have
you
and
then
we
can
kind
of
just
bike
shot
on
like
how
does
the
user
express
that
they
wish
this
thing
to
be
isolated,
or
this
thing
to
not
be
isolated,
and
then
the
third
is
kind
of
defining
the
shape
of
the
of
the
internal
package
store.
What
sim
links
where
what
are
the?
C
What
are
we
hashing?
What
are
the
file
names
and
there's
there's
a
fair
bit
of
complexity
just
in
that
part,
but
I,
I
suspect,
it'll
be
less
to
kind
of
bike
shed
because
it's
basically
going
to
just
be
a
matter
of
you
know.
Does
this
meet
the
needs
of
the
prior
to
rfcs?
Yes
or
no,
then
we
as
we
get
into
the
weeds
with
the
implementation.
C
We
may
need
to
go
back
and
kind
of
adjust
or
bring
up
new
concerns
for
the
first
two,
but
I
think
this
is
kind
of
the
most
sensible
order
of
operations,
even
though
it's
not
like
a
a
strict
waterfall
per
se,
it's
it's.
It's
waterfall-ish.
D
D
I
suppose
that
are
not
explicit
dependencies,
so
I
definitely
think
that
should
be
a
separate
rfc
and
I
don't
think
anything
should
be
predicated
on
its
existence,
but
the
the
workspaces
thing
I'm
asking
for
really
the
ability
to
fine-tune
it
as
to
which
things
are
isolated
and
which
are
shared
makes
sense
to
me
as
a
as
a
like,
a
third
rfc,
but
really
it's
the
the
the
thrust
of
my
initial
interest
here
is
by
hoisting.
D
Everything
to
the
root
of
the
sharing
of
dependencies
is
conflated
with
the
hierarchical
nature
of
node
modules
and,
like
literally
just
making
a
separate
folder
like
work,
node,
module
nodes,
underscore
modules,
underscore
workspace
or
something
and
doing
everything
exactly
the
same
and
then
sim
linking
the
things
that
are
ex.
You
know
that
are
in
the
root
into
the
roots,
node
modules,
like
that,
even
something
as
basic
as
that.
D
What
I
think
work,
but
the
yeah
I
like
I,
I
think
the
the
important
thing
for
me
is
isn't
absolutely
not
that
a
child
workspace
is
restricted
to
requiring
its
direct
dependencies.
I
think
that
is
an
anti-pattern.
I
think
that
the
important
thing
is
that
a
root
dependency
does
not
or
any
of
its
transitives
and
or
sorry
a
sibling
child
workspace
dependency
or
any
of
its
transitives
do
not
become
available
to
a
child
workspace
that
doesn't
have
them
in
its
dependency
graph.
C
Okay,
so
you
touched
on,
I
I
do
want
to
yeah
sorry
wes.
I
know
that
the
language
can
be
can
be
tough
to
follow,
or
I
I'm
going
to
also.
C
That
out
before
we
communicate
more
widely
we're
gonna
we're
gonna
definitely
have
to
sort
of
settle
on
some
technical
term
terminology
on
some
of
these.
You
know
just
make
it
make
it
precise
jargon
in
in
some
some
of
these
cases,
so
I
think,
as
far
as
you
know,
pnpm
and
yarn
pnp
break
the
ecosystem
and
therefore
pure
mode
is
about
idea.
C
I
think
it
is
a
bad
idea
to
make
the
default
for
sure,
but
we
have
been
asked,
for
you
know
very
explicitly
for
for
a
lot
of
the
same
reasons
that
you've
brought
this
up
with
with
workspaces
we've
been
asked
very,
very
specifically
for,
like
you
know,
we
don't
want
to
use
pnpm
because
it
breaks
some
stuff.
What
we
want
to
do
is
use
pnpm
and
just
hoist
this
or
that
particular
thing
that
needs
to
be
hoisted
because
it
does
provide
some.
Even
though
it's
it's
really
obnoxious,
it's
really
inconvenient.
D
B
C
D
C
Well,
they
don't
want
to
have
dependencies
that
are
that
are
breaking
the
encapsulation
barrier
of
working
within
pnpm
right
like
they
want
to
be
able
to
say
we
only
want
you
know
dependencies
that
have
unlisted
dependencies.
That
is
a
bug
we
need
to
either
go
fix
it
for
them
or
stop
using
that
thing.
D
C
D
C
B
C
D
I
just
want
to
say
it's
what
to
the
default
point,
though,
that
that's
what
people
said
about
type
module
and
package.json,
and
literally
every
tutorial
from
esm
and
node.
Just
naively
tells
you
to
use
it
without
telling
you
why
you
don't
need
it
or
why
you
do
need
it
or
what
the
caveats
are,
so
everyone
just
uses
it
and
so
the
fight,
despite
the
fact
that
it's
opt-in,
it's
still
effectively
the
default
because
of
that
property,
and
I
suspect
that
would
be
the
case
because
any
flag
like
this
would
be
marketed
as
this
fixes
bugs.
D
C
The
second
point
that
you
brought
up
as
far
as
you
know:
well,
we
should
have
a
node
modules,
underscore
workspaces
and
we
should
sim
link
things
places
like
that's
save
that
for
the
third
rfc
we
have.
We
have
some
running
code
right
now.
Vincent's
got
some
running
code
that
that
works,
and
I
don't
know
if
we're
just
going
to
take
it
as
is,
but
you
know
it's
working
on
linux
and
and
windows
right
now.
So
that's
kind
of
a
a
good
good
proof
of
concept.
C
At
least
it
will
need
a
little
bit
of
work
to
sort
of
fix
or
sort
of
come
into
line
with
where
we,
where
we
landed
in
our
discussion,
for
where
the
spec
is
probably
going
to
end
up,
but.
C
But
yeah
we
we
can
definitely
have
those
discussions
and
I'll
have
a
I'll
have
a
draft
of
the
all
three
of
those
coming
up
very
or
at
least
the
first
two
of
those
coming
up
soon.
I
think
the
fir
the
the
first
one
is
probably
going
to
be
the
most
juicy
as
far
as
bike
shedding
goes.
The
second
one
will
be
sort
of
the
the
uf.
C
Of
number
them,
because
the
ordering
is
not
clear
to
me
so
the
first
one
is
what
gets
shared
and
what
gets
isolated
by
default.
C
The
second
one
is
a
proposal
for
specifying
what
is
isolated
and
what
is
shared
via
some
sort
of
configuration
mechanism,
and
the
third
is
a
spec
for
the
shape
of
the
isolated
depth
store.
What
sim
links
where
and
so
on.
The
actual
like
disk
implementation
of.
C
Yes,
but
it
gives
us
it,
you
know
it
clearly
defines
the
the
success
metrics
for
that
third
one,
rather
than
rather
than
sort
of
saying
we're
going
to
implement
a
thing
and
then
whatever
it
does,
is
the
spec.
C
It's
also
why
I'm
trying
to
use
a
language
of
like
shared
versus
isolated,
rather
than
hoisted
versus
sim
linked,
because
I
really
do
want
to
not
get
too
much
into
the
implementation
weeds
until
we're
very
clear
about
what
what
it
is.
We
want
to
happen.
B
So
just
to
be
mindful,
since
this
rc
doesn't
really
touch
on
those
other
aspects,
yet
this
is
going
to
be
probably
ready
by
the
next
time.
At
least,
like
you
said,
isaac,
the
first
two
pieces
that
should
be
ready
by
the
next
time
we
reconvene
here
next
week.
I
think
right,
so
we
can
actually
speak
to
those.
Hopefully
next
week,
or
at
least
maybe
the
first
rfc
will
be
put
together.
C
B
Any
other
comments
on
that,
then,
specifically
jordan.
Did
you
want
to
follow
up
or
do
you
want
to
essentially
wait
till
again
this
initial
rc
was
drafted.
It's
definitely
not
what
is
going
to
move
forward
based
on
everything.
D
Yeah,
I
mean
I'll
definitely
wait
and
see
what
gets
written
up.
I
mean,
I
think
that,
like
and
based
on
what
isaac
wrote
up
in
the
first
case,
which
was
the
example
syntax
of
configuring-
that
nobody
really
liked
like
it
sounds
like
the
second
rfc
is
the
one
that
defines
we'll
we'll
try
to
define
that,
and
I
think
that's
useful.
I
I
remain
concerned
if,
at
any
point
someone
can
naively
configure
something
that
will
create
more
noise
for
maintainers.
D
I
think
that
is.
It
is
not
anybody's
business
to
fix
the
bugs
in
their
own
in
their
dependencies
without
cloning
that
dependency
and
like
developing
on
it
yeah,
I
think
so,
but
that,
but
with
that
feedback
in
there
I'll
of
course
provide
that
again
when
the
rfc
is
drafted.
B
Yeah
and
and
just
to
be
mindful,
I
think
that
the
ideas
that
are
being
proposed
here
are
also
trying
to
fix
the
exact
same
thing
that
you're
saying.
Let's
say
I
installed
two
dependencies
and
one
is
able
to
manipulate
the
other.
D
C
And
that's
that's
also.
I
mean
that's
exactly
why
I
think
it's
so
important
to
tease
these
apart,
because
otherwise
we
get
into
like
you
know
we
get
sort
of
up
to
our
eyeballs
in
a
particular
implementation
and
and
then
realize,
oh
well,
you
know
there's
this
other
thing
that
we
need
kind
of
an
escape
hatch
for
and
then
we
start
having
to
kind
of
have
stuff
sort
of
duct
taped
onto
it.
C
I'd
rather
just
identify
those
escape
patch
needs
up
front
and
have
a
spec
that
we
say
this
is
what
we're
doing,
and
this
is
how
it
works,
and
then
we
can
say
does
this
do
what
we
said
we're
doing
and
does
it
work
the
way
we
said
it
works?
Yes
or
no.
That's
a
much
simpler
thing
when,
when
evaluating
the
implementation.
B
Okay,
just
to
be
my
full
time,
I'm
going
to
move
on
to
the
second
item
we
had,
which
is
a
issue,
essentially
a
tracking
issue
that
I've
put
on
here.
Three
seven,
oh
my
gosh,
I
can't
speak
words.
372
discuss
the
npm
audit
resolver
need,
so
I
think
myself
and
wes
have
been
doing
a
bit
of
work
in
the
package
maintenance
working
group,
but
now
we've
spun
up
the
package,
vulnerability,
collab
space,
which
we
had
the
first
sort
of
kickoff
call
for.
B
I
think,
based
on
the
fact
that
a
lot
of
that
conversation
is
moved
over
there
and
that
we're
going
to
have
hopefully
a
good
space
to
essentially
talk
about.
You
know
security
problems
in
general.
In
that
space,
I
think
we
can
probably
remove
this
from
the
agenda.
I'm
not
sure
wes.
If
you
want
to
add
any
more
like
context
around
the
work
that
we're
doing
there
or
in
prep
for
openjs
world.
I
guess
even.
E
Yeah
sure
I
can
do
that
sorry,
I've
been
eating
lunch,
so
turn
the
camera
on
and
talk
yeah.
So
I
think
the
goal
of
that
group
is
to
come
to
some
consensus.
That's
not
necessarily
exclusive
to
npm.
I
think
what
we
would
come
back
with
would
be
a
proposal.
E
That
is
something
other
folks
could
implement
around.
You
know
sneak
tooling,
you
know
yarn
pnp,
those
you
know
those
other
ecosystems,
and
if
we
can
come
up
to
sort
of
a
core
consensus
on
what
the
you
know,
the
contracts
need
to
be.
We
can
come
back
with
a
better
proposal
and
I'm
I'm
guessing
it's
going
to
end
with
a
proposal
to
npm
we're
way
early
on
that.
So
no,
you
know
no
promises.
I
think
you
know.
E
If,
if
that's
not
the
way,
the
conversation
goes
once
we
get
everybody
in
the
room,
but
I
would
like
to
I
you're
you're
planning
on
leaving
it
open
right.
You
don't
mean
to
close
it.
B
I
assume
I
was
actually
going
to
close
the
issue
for
now.
It
was
more
so
just
because
I
was
trying
to
track
that
we
were
talking
about
this.
It's
the
topic
name
is
not
very
descriptive.
It
was.
It
was
specific
to
zb's
implementation
of
npm
monitor
resolver,
whereas
like
we
could
have
a
tracking
issue,
if
we'd
like
to
continue
to
give
updates
here,
like
weekly
updates,
if
we're
making
progress
in
that
cloud
space,
but
I
don't
think
it
makes
that
much
sense.
Probably
since
we're
gonna
have
a
longer
cadence
in
between
yeah.
E
Yeah
that
that
makes
sense
okay,
so
I
I
would
work
zb's
not
on
the
call
today
right,
I
think
not,
okay
yeah!
I
I
just
I
guess
my
only
reason
of
saying
leave
it
open
would
be
more
that
when
folks
come
on
to
the
that,
you
know
the
collab
space,
we
can
link
them
to
this
as
some
prior
art,
maybe
closing
it
with
a
big.
E
B
B
Sure
it's
not
closing
the
pr.
I
think
the
pr
is
still
open.
This
was
a
separate
issue
for
just
tracking,
like
needs
so
yeah,
but
I'll
I'll,
provide
that
context
for
us
before
I
close
it
so
and
and
we're
picking
up
essentially
that
prior
art
in
that
cloud,
space
right
so
cool
and
if
folks
on
this
call,
are
interested
in
that
in
interested
in
that
work,
I
can
provide
some
links
as
well
in
the
meeting
notes
and
also
in
chat
here
in
a
few
minutes.
B
If
you
want
to
take
a
look
at
what
we're
kicking
off
there
moving
on
then
to
our
third
item:
was
the
pr364
restore
npm
six's
ability
install
a
single
package,
so
I
think
we
have
some
good
discussion
about
this
last
week.
B
C
I
think
this
has
to
be
an
opt-in
thing,
we're
not
going
to
go
back
to
npm
6's
way
of
doing
it
just
inconsistently.
Based
on
whether
or
not
you
have
a
lock
file,
because
we
do
a
lot
of
work
to
behave
consistently
in
cases
where
you
have
a
lock
file
or
don't
have
a
lock
file.
So.
C
F
Part
of
this,
it's
my
turn.
We,
I
might
not
understand
the
problem
space
here,
is
the
dash
dash.
No
lock
file
parameter
the
solution
here.
It
doesn't
work,
but
like
should
that
work,
should
we
just
install
this?
Don't
worry
about
the
log
file,
because
that's
the
thing
that
changes
the
behavior
is
the
presence
of
the
lock
file.
If
we
were
able
to
tell
the
cli,
don't
worry
about
the
lock
file.
Does
that
solve
the
problem?.
C
So
the
the
thing
that
changes,
the
behavior
in
npm
v6
is
the
presence
of
a
lock
file
and
the
fact
that
it
changes
the
behavior
in
this
way
was
surprising
to
at
least
rebecca
turner,
who
wrote
most
of
that
code.
That
does
that
it's
it's
not
like
by
principled
design,
it's
just
sort
of
how
it
happens
to
be
working.
C
The
root
project
always
has
its
set
of
dependencies
loaded
into
place,
whether
you
have
a
log
file
or
not,
because
we
read
them
from
the
package.json,
and
I
I
certainly
don't
want
to
go
back
to
the
bad
place
of
you
know.
Install
is
a
wildly
different
command,
whether
you
based
on
whether
you
have
a
lock
file
or
not
it.
D
If
there
was
any
possibility
that
we
were
that,
we
would
want
to
have
the
npm
six,
no
lock
file
behavior
as
the
consistent,
always
behavior,
meaning.
When
you
ask
for
one
package,
you
only
get
one
package,
then
it
seems
to
me
that
the
inconsistent
situation
is
better
as
a
transition
to
the
consistent.
Only
do
one
thing
situation
right
like
if
we
switch
to
all
if
we
keep
the
npm
seven
behavior
and
then
change
both
of
them
back
in
npm,
8,
let's
say
or
9
or
10
or
something.
D
I
mean-
maybe
that's
the
thing
that
that's
hard
to
understand
like.
What's
the
I,
I
understand
that
in
npm
six
it
was
unintentional
that
absent
a
lock
file.
It
did
a
thing
and
that
that
lack
of
intention
might
create
a
source
of
bugs,
but
I
want
to
make
clarify.
Are
you
saying
that
when
I
ask
for
to
install
one
package
and
having
it
only
install
that
one
package,
are
you
saying
that's
a
source
of
bugs
the
behavior.
C
That
behavior
in
npm
six
well
more
okay,
like
the
behavior
of
because
it's
not
what
is
npm
sex
is
not
building
out
the
entire
ideal
tree
and
then
filtering
it
down
to
just
refine.
D
Right,
but
in
the
same
spirit
as
the
hoisting
discussion
like
to
tease
apart
them
into
separate,
like
things
the
I
understand
that
the
implementation
in
npm6
was
buggy,
but
I'm
clarifying
that
the
arborist
filtering
implementation
and
that's
an
npm
7
would
not
be
buggy
in
this
regard,
and
so
that
semantic,
if
we
went
with
it,
would
be
solid.
Is
that
correct.
C
But
then
we
have
to
know
from
like
then
we
basically
have
to
detect
whether
or
not
a
lock
file
is
present,
not
just
when
we're
building
the
ideal
tree,
but
when
we're
reifying
and
when
we're
diffing,
so
we
have
to
go
back
and
say:
okay,
I've
got
I've
got
these
two
trees.
I
need
to
dip
them
and
instead
say
I've
got
these
two
trees.
C
D
C
The
the
implicit
branching
behavior
yes
right.
B
C
If
we
want
to
make
it
explicit
and
say:
okay,
the
user,
the
user
has
indicated
via
some
some
way.
We
can.
You
know,
there's
there's
good
and
bad
ways
to
express
this,
but
the
user
has
expressed
that
they
wish
x
to
happen.
I
will
make
x
happen,
that's
totally
fine
and
that's
very
predictable
and
very
consistent.
You
know
whether
you
have
a
lock
file
or
not,
regardless
of
where
I
got
these
two
trees
from
you're
telling
me
that
you
only
want
to
diff
this
portion
of
the
graph
great
I'll.
C
Do
that
and
that's
what
like
npm
install
dash
w
foo
will
do
right,
it'll
only
install
foo
workspace
and
its
dependencies.
C
I
would
actually
be
fine
with
saying
I
mean
if,
if
npm7
hadn't
already
shipped
with
this
behavior,
I
would
be
fine,
saying
npm
install
foo,
only
installs
foo
and
its
depths.
We
still
build
the
entire
ideal
tree,
but
we're
only
you've
only
asked
me
to
reify
this
portion
of
it.
So
I'm
only
going
to
ask
refine
that
portion.
D
D
The
small
group
of
people
that
haven't
run
npm
install
before
they
are
running
npm
install
foo,
we'll
get
a
warning
telling
them
hey.
You
should
run
npm
install
first
next
time
because,
like
in
the
future,
this
will
change
and
then,
when
npm
8
happens,
that's
the
like
it'll
just
do
that.
Is
that,
like
a
possible
path.
G
D
E
H
A
C
C
C
Reactions,
I
understand
okay,
so
we
will
not
touch
the
portions
of
the
package
lock
that
are
outside
the
portions
of
the
tree
that
we're
touching.
H
C
Right
so
it's
like
the
the
lock
file
is
the
starting
point
and
gives
us
some
metadata
about
the
resolved
and
integrity
values
that
we
expect
to
encounter
when
we're
resolving
those
things.
If
you're
saying
npm,
install
express
you're,
saying,
okay
take
the
intended
tree,
that's
expressed
in
the
lock
file
and
add
express
to
it
and
then
make
it
valid.
C
So
if
there's
anything
in
that
lock
file
that
we
then
have
to
change,
like
maybe
there's
a
version
of
maybe
you're
already
using
a
version
of
connect
which
isn't
compatible
with
the
version
of
express
you're
doing,
but
we
can
upgrade
it
and
still
be
within
your
dependency
range.
Okay,
then
that
might
change
yeah,
but
if
you're
also,
depending
on
some
other,
completely
different
thing
like
we're
just
gonna
take
what's
there
because
we
haven't
been
told
to
re-evaluate
that
particular
edge.
C
Okay,
there
there
may
be
cases
where
the
the
only
exception,
that
is,
if
the
data
is
missing,
we'll
fill
it
in.
So
if
there's
something
that
doesn't
have
an
integrity
value
and
then
we
reify
it
we'll
put
that
integrity
value
in
because
now
we
know
it.
B
B
This
is
behavior
in
mpm
seven
and
we
need
some
m6
and
sometimes
in
mpm6,
but
this
is
the
this.
Is
the
stable
behavior
in
mpm7.
B
Then,
if
you
want
to
opt
into
this
other
behavior
like
can
we
exercise
some
creativity
here
in
terms
of
like
what
that,
what
shape
we
could
provide
that
in
like.
B
Exactly
what
tune
is
yeah
exactly
like
an
only
flag
or
something
yeah?
Okay,
okay,
so
that's
the
feedback.
It
sounds
like
to
give
so
action
item
is
respond
with.
B
B
B
Okay,
so
just
to
be
mindful
of
time
and
again,
if
folks
have
more
that,
they
want
to
add
on
this
specifically
feel
free
to
follow
up
in
the
threads
itself
async.
B
But
I'm
going
to
be
moving
on
here
to
the
fourth
item
we
had,
which
was
the
issue
363
the
rfc,
which
we
spoke
about
a
bit
at
length
last
last
week,
jordan's
issue
here
about
the
mpm
ignore
and
git
ignore
sets
of
files.
I
forget
where
we
landed
with
this
and
what
the
actions
were.
If
there
were
any
action
items.
D
I
mean,
I
think
we
just
haven't
nobody's
like
come
up
with
a
great
suggestion
of
how
to
do
it,
like
the
sense
that
I
had
from
talking
about
it
was
like
if
we
can
come
up
with
a
way
that
solves
the
bat
compat
problems.
It
doesn't
create
new
ones,
then
like
great,
but
nobody
knows
exactly
how
to
do
that.
Yet
it
sounded.
D
And
I
guess
I
mean
arguably
we
could
add
that
as
an
npm
function,
right
like
construct,
git
ignore
from
this
or
construct
npm
ignore
from
git
ignore
and
this
other
file
right
and
then
that
at
least
makes
it
really
easy
to
add
that
functionality
and
then
it
does
crash
in
older
npms.
So
that's
actually
something
that
just
occurred
to
me
that
might
work
but
I'll,
try
and
put
that
on
the
rfc
comment
or
the
rc
thread,
and
we
can
talk
about
it.
There.
B
G
C
Well,
you
said
what
I
was
about
to
say:
spike
implementation
would
be
worthwhile
and
the
other
the
other
bonus
of
doing
it.
That
way
is
you
would
have
npx
make
npm
ignore
as
a
as
a
thing
you
could
use
today,.
C
And
then
we
could
decide,
you
know,
should
this
logic
just
live
in
npm
pack
list
and
be
how
it
works
if
it
sees
both
or
if
it
sees
this
pragma,
but
that
will
make
it
a
lot
easier
to
reason
about.
B
Yeah,
I
think
next
step
here
is
yeah
to
actually
do
do
a
little
bit
of
work
to
see.
So
we
can
look
at
code,
maybe
if
you're
willing
to
invest
some
time
there.
Jordan,
like
we,
can.
B
Those
are
definitely
two
separate
things
for
sure:
okay,
awesome,
so
moving
along
then
to
pr
343.
This
is
the
rc
on
the
workspaces
context,
switching
basically
running
commands
within
a
nested
workspace
or
a
child's
workspace.
B
That
would
then
essentially
operate
that
command
as
if
it
was
run
in
the
route.
We've
talked
about
this
quite
a
bit
over
the
last
couple.
Rc
calls
around.
You
know
how
to
make
this
happen
or
whether
or
not
we
should
introduce
a
new
file
which
would
essentially
dictate
where
the
workspace
route
was
and
provide
a
path
to
that
roy.
I'm
not
sure,
because
you've
missed
out
on
a
few
rfc
calls.
Did
you
also
want
to
maybe
add
more
color
than
or
contact
them
than
I
already
have.
A
Yeah,
I
don't
know
if
there
was
any
discussion
that
I
missed,
but
from
where
I
remember
this
landed
was
the
idea
of
having
a
configuration
to
kind
of
opt-in
to
this
behavior
and
yeah.
I
think
the
only
conversation
that
I
would
like
to
bring
on
is
that
I
would
prefer
it
to
be.
The
other
way
around
like
would
be
okay.
A
Maybe
we
have
a
configuration
but
to
opt
out
and
make
this
the
default,
because
I
think
for
most
the
majority
of
users
out
there
they
would
expect
to
just
cd
into
their
workspace
and
npm
install
foo
and
get
that
dependency
added
to
their
workspace,
and
things
will
be
added
to
the
project
level
package
lock
file
and
work
as
intended.
So
if
it
is
an
opt-in
kind
of
thing,
it
would
be,
it
would
be
more
error-prone
to
the
standard
user
to
just
get
that
that
user
experience
out
of
the
box,
but
yeah.
A
C
So
I
think
I
I
was-
I
was
suggesting,
like
there's,
there's
one
constraint
that
we
have
on
workspaces,
which
is
preventing
this
now
in
a
safe
way,
and
that
is
that
a
that
we
make
no
changes
within
the
workspace
folder
right.
So
we
you
can
have
a
you,
can
define
it
works
packages.
The.
C
The
child,
so
if
you
define
a
workspace,
a
child
workspace,
we
we
don't
touch
it
at
all,
really
except
to
install
dependencies
and
and
occasionally
to
you
know,
save
updates
to
dependencies.
But
we.
C
That
would
give
us
something
very
explicit
to
say.
Oh
when
I
run
npm
install
in
this
folder,
what
I
really
am
doing
is
running
npm,
install
dash
dash
prefix
equals
dot,
dot,
slash,
dot,
dot,
workspace,
equals
foo
right,
and
then
it's
just
a
matter
of
setting
our
prefix
and
setting
our
setting
two
configs.
It's
not
a
big
deal
at
all.
The
the
hard
part
is
we.
We
need
that
explicit
thing,
because
I
don't
want
somebody
to.
C
I
don't
want
to
like
put
a
package
json
in
my
in
my
root
of
my
dev
folder,
that
has
you
know,
workspaces
equals
you
know
star
and,
and
then
anything
I
do
in
any
of
those
folders.
It's
always
happening
in
a
workspace
mode
like
it
has
to
be
something
that
you
opt
into.
C
B
Yeah,
I
sort
of
agree
with
the
not
going
with
the
implicit
route
based
on
if
I'm
running
npm
commands
in
a
folder
like,
and
it
has
no
other
context
provided.
There's
no
explicit,
like
reference
back
to
like
some
sort
of
workspace
root,
then
I
I
feel
like
I
want
to
run
as
if
I
was
not
in
a
workspace
right
like
I've
cd
into
that
folder
and
I
want
to
you,
know,
execute
some
commands
on
there
like
on
that
package.
B
Json
all
right,
that's
my
personal
thought
on
that
is
not
to
not
change
that
behavior
based
on
that
context
and
and
we'd
have
to
find
the
context
too.
We'd
have
to
walk
up
and
and
figure
out
whether
or
not
you
were
a
part
of
a
workspace
project
right
so,
like
that's
the
I
think,
the
problem
with
that
with
that
behavior
as
well.
B
How
much
of
a
blocker,
let's
say,
of
not
having
this
feature
of
connecting
like
how?
I
guess
we
don't
know
and
haven't,
had
a
ton
of
feedback
about
people
having
this
problem,
where
they've
cd
into
a
workspace
directory
and
then
tried
to
run
command,
and
they
had
this
on
an
unexpected
experience
like
I
don't.
I
I
personally
haven't
been
seeing
a
ton
of
feedback
around
that
yeah.
A
All
the
complaints
I
hear,
I
see
about
workspaces
on
all
across
all
the
communities.
There's
people
setting
up
workspaces,
then
they
cd
into
a
child,
workspace
folder
and
they
try
to
npm,
install
something
and
they
get
a
brand
new
node
modules
in
there
a
path
do
you
know
an
extra
nested
package
lock
and
everyone
is.
A
I
I
I
Interesting
I've
done
it
several
times.
I
still
get
and
doesn't
walk
up
the
way.
It's
expected
to
that's
a
lot
of
our
instances.
D
C
A
Yeah,
I
believe
it
probably
yeah.
Now
it's
probably
the
time
that
we're
gonna
be
unlocked
to
start
really
putting
this
on
the
on
the
road
map,
because
we're
we're
getting
all
the
commands
there.
Right,
especially,
I.
A
Yeah
right,
so
we
need
that
first,
the
ability
of
running
commands
in
in
specific
workspaces
right
like,
but
then
once
we
have
that
this
would
be
an
improvement
over
the
the
experience
right
and
my
hope
was
to
just
make
kind
of
fix
that
that
that
error
for
most
of
the
users
who
were
expecting
this
to
be
default,
behavior.
B
B
Most
likely,
the
reified
commands
that
we
have
are
the
ones
that
are
the
most
as
roy
was
saying,
the
most
challenging
and
most
like
confusing
for
end
users,
probably
that
those
are
the
right
set
of
commands.
That
would
have
something
along
those
lines
and
we
already
have
standard
behavior
that
when
we
see
workspace
config
for
another
set
of
commands,
but
don't
support
workspaces
at
all,
we're
gonna
throw
so
there's,
there's
certain
default,
behavior
and
sort
of
communication
mechanisms.
B
I
think
we
can
put
in
place
that
will
not
again
not
take
away
like
if
I
want
to
try
to
install
in
this
project
for
whatever
reason-
and
I
want
to
actually
generate
a
package
log
like
like.
Don't
stop
me
like,
maybe
you
can
tell
me,
you
can
prompt
me
and
there
can
write
right,
be
in
the
console
that
it
looks
like
you're
running
in
a
workspace
or
that
it
looks
like
this
is
a
you
know,
a
part
of
another
like
a
project
but
yeah.
D
C
That
is,
that
is
another.
That's
a
really
great
idea.
It's
it's
something
that
I
think
we've
talked
about
internally,
a
little
bit
that
we
should
have.
You
know
whether
we
should
have
separate
lock
files
for
each
thing
within
the
workspaces
project,
rather
than
having
them
all
in
the
in
the
top
level,
because
right
now
it's
just
yeah
everything
is
in
one
lock
file,
there's
an
arborist.
It
only
looks
at
the
lock
file
from
the
root
the
root
node,
so
splitting
that
up
would
be
would
be
great
for
a
lot
of
reasons.
C
D
Like,
like,
oh
I'm,
sorry
yeah
just
talking
about
that
they're
both.
B
Yeah
not
sure
if
it's
the
internet,
where
you
are
I've,
never
listened
to
a
potato
before.
But
tyranny
might
be
right
that
that
sounds
like.
A
Yeah
just
want
to
be
mindful
of
that.
I
do
yeah
just
to
say
I
do
like
your
alternative
dorsey.
I
will
add
that
at
least
to
the
alternative
section
of
the
rfc,
I
think
it
is
a
possible
one.
Just
did
you
mean
and
then
cd
back
into
the
route
and
run
with
the
workspace
flag.
I
think
that
could
be
helpful
in
educating
the
users
that
that's
the
thing
and.
B
Then
again
like
we
could
recommend
the
command
to
run
like
if
you
don't
mean
this,
like
you
know
like
mean
to
do
this
type
thing
like
or
like
whatever
yeah
it's
a
it's
about
a
communication
and
and
education.
I
think
in
in
the
space
versus
just
trying
to
always
do
what
you
know,
we
think
is
the
implicit
understanding
for
the
80
20,
even
like
of
developers,
let's
like
think
about
how.
B
B
Yes,
I've
got
to
do
work
but,
like
my
you
have
to
do
the
work
there,
but
my
concern
was:
if
you
do
the
work,
if
you
do
the
work
to
find
out
that
out
and
then
make
the
decision
for
the
developer,
that's
what
I
don't
like
about
like
the
implicit
strategy
there
right,
yeah,
okay,
okay,
sorry
moving
on!
So
the
action
there.
Roy
you're
gonna,
add
some
more
alternatives.
B
B
Based
on
discussion
there-
and
it
sounds
like
jordan-
had
a
couple
things
that
you
want
to
add.
Hopefully
you
can
add
them
async
to
the
rc
as
well.
I
wanted
to
give
some
time
here
because
we
only
have
about
five
minutes
left,
so
the
I
moved
up
tyranny,
your
your
rc
182..
So
this
is
npm
audit
licenses.
Did
you
want.
H
To
yeah
seems
to
be
going
pretty
well,
I
I
owe
licensee
a
pr
that
I
haven't
gotten
to,
because
I've
been
doing
interviews
for
the
past
week
and
by
interviews
I
mean
interviewing
people,
not
interviewing
myself.
I
owe
that
a
pr
to
change
waitlist
to
allow
lists,
I
don't
think,
there's
any
block
list
in
there,
but
the
the
big
one
there
is
just
discussion
about
like
in
a
dot.
What
was
it?
H
I'm
I'm
failing
to
remember
the
audit,
audit.json
or
package.json
and
or
both
and
choosing
the
path
there
to
codify
the
rfc.
I
believe
jordan
had
had
had
an
opinion
on
it.
I
don't
care
I'm
happy
to
write
whatever
people
want,
so
I
I
am
happy
to
change
it.
I
you
know
I
I
generally
lean
toward
allowing
multiple
different
avenues,
the
same
thing,
so
I
I
proposed
both
and
having
them
both
be
allowed,
but
if
there's
reasons
to
do
one
over
the
other,
that's
totally
fine.
H
Yeah,
if,
if
people
could
look
at
it,
super
appreciate
it
and
then
also
look
at
it
with
that
question
in
mind,
also
super
appreciated,
so.
B
In
terms
of
time
frame
like
if
this,
if
we
agreed
on
sort
of
like
the
approach,
would
you
be
able
to
spend
time
like
working
on
the
actual
implementation?
It
sounds
like
you
had
already
been
playing
with
us.
H
So
I
had
been
playing
with
this
as
a
separate
module
that
I
built
myself.
That
was
not
licensee.
I
would
I'd
be
happy
to
work
on.
H
You
know
on
this
with
someone
from
the
cli
team,
I
I
don't
know
how
you
would
want
to
approach
it,
whether
you'd
want
to
like
shell
out
to
it
or
whether
you'd
want
to
consume
it
as
a
module
and
re-implement.
The
api's
commands
but
happy
happy
to
happy
to
try
to
spend
some
time
on
this.
If
that's
helpful
for
sure.
B
Now
it's
easier
to
actually
like,
based
on
how
much
discussion
we've
had
around
this
would
be
easier
to
look
at
a
pr
with
the
actual
code
like
implemented,
and
then
we
can
massage
it
into
a
form
that
we,
we
think,
is
good
based
on
there's
like
a
lot
of
prior
art
as
well
that,
like,
hopefully,
there's
a
ton
of
work
to
like
implement
yeah
like
just
pulling
in,
I
guess,
licensee
and
massaging
that
into
like
a
sub
command,
so
yeah.
So
if
you
you
can
take
that
away.
B
We'll
also
try
to
get
some
time
to
review
that
rc
see.
If
there's
like
anything
that
stands
out
but
cool,
we
had
two
other
items
here.
Unfortunately
enough,
I
don't
think
was
able
to
join.
We've
talked
about
his.
It
seems
pretty
on
controversial
his
rc336.
B
The
only
thing
here
is
the
actual
name
of
the
config
so
being
able
to
specify
where,
for
npm,
config
and
npm,
exactly
look
which
directories
they're
looking
at
are,
you
know
it
seems
pretty
uncontroversial
than
naming
so
like?
We
might
just
want
bike
shed
that
in
some
sort
of
poll
I
think
that
was
maybe
one
of
the
action
items
we
had
from
last
week,
so
it
just
needs
to
get
done
and
then
issue
number
156,
the
rrc
optional
installs.
I
believe
this
is.
B
We
had
followed
up
in
this
thread,
or
at
least
I
had
about
the
potential
for
filtered
installs
once
we
land
workspace
awareness
for
some
of
the
real
five
commands
later
this
week
or
next
week.
This
might
be
an
option
for
for
them
to
utilize
workspaces,
essentially
to
parse
out
different
types
of
depths
that
they
have
and
they
want
to
essentially
install
that
might
be
an
option
for
them.
I
think
I
might
remove
this
from
the
agenda
unless
other
folks
have
comments
on
that.
Specifically,
it.
F
B
They
want
like
sets
to
find
sets
of
dependencies
that
they
can
install.
I.
C
C
To
happen,
that's
a
super
big
hazard,
there's
there's
too
many
of
those
things
already,
and
they
each
have
very,
very
precise
and
and
defined
semantics,
which
it
would
be
unclear
like
what,
if
you
define
something
like
optional,
dev
dependencies
or
e2e
dependencies
like
is
that
required?
Should
that
be
ins
at
what
point
should
that
be
installed
like
now?
We
need
to
track
those
flags
all
the
way
through
the
tree
like.
Oh,
this
is
it's
brutal.
C
It's
only
reasonable
now,
because
there's
such
a
small
number
of
them
having
a
way
to
install
something
and
just
limit
it
to
only
certain
top
level
nodes,
like
that's
that's
kind
of
what
they
want.
It's
a
little
more
like
verbose
than
what
they're
asking
for
they're
asking
for
kind
of
some
sugar
on
top
of
that,
but
we
should
deal
with
that
later
and
and
shut
this
rfc
down.
I
think
yeah
not
that
it's
a
bad
use
case.
It's
just
we're
not
going
to
go
in
that
direction.
B
But
I
I
can
probably
close
it
out
with
with
that
feedback,
so
we're
essentially
that
time
a
little
bit
over
apologized
for
getting
started
late.
I
appreciate
everybody
jumping
on
the
today,
as
usual,
we'll
be
back
next
week
same
time
same
place
and
feel
free
to
open
up
and
keep
the
conversation
going
in
in
the
rcs
themselves.
So
I'll
talk
with
you
folks,
online
and
async
and
next
week
cheers.