►
From YouTube: Open RFC Meeting - Wednesday, June 9th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live,
welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
june
9th
2021
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
396,
I'll
copy
and
paste
that
issue
here
in
chat,
if
you
haven't
already
feel
free
to
add
yourself
to
the
meeting
notes,
doc.
That
was
also
copied
and
pasted
into
the
chat,
we'll
be
adding
notes
in
there.
Thank
you
roy
for
for
agreeing
to
and
helping
out
with
taking
notes
today
and
yeah.
A
I
just
wanted
to
quickly
acknowledge
that
we
do
have
a
code
of
conduct,
so
we
asked
folks
to
please
abide
by
in
these
calls.
You
can
go
check
it
out.
It's
linked
in
the
issue
that
I
shared
there.
A
The
general
overall
sentiment
is
that
please
be
kind,
please
allow
other
folks
to
talk
and
raise
your
hand
if
you'd
like
to
respond
or
or
comment,
and
we
asked
the
same
also
in
the
rfc's
repo
itself-
that
we
try
to
keep
things
civil
and
and
hopefully
progress
things
forward
as
as
a
community
in
terms
of
announcements.
I
just
wanted
to
quickly
note.
We
took
a
bit
of
a
break
hiatus
last
couple
weeks:
open
js
world
was
last
week.
A
You
can
find
the
presentations
that
and
talks
that
were
done
last
week
on
the
openjs
foundation,
youtube
channel.
If
you
want
to
go
check
those
out.
I
know
a
few
folks
on
this
call
participated
in
those
sessions
and
thought
it
was
a
great
event,
so
just
want
to
give
a
shout
out
to
that.
Also,
if
you've
been
keeping
up
to
date
with
the
npm
client
releases,
we've
been
cutting
pretty
much
consistently
a
release
on
thursdays,
the
most
recent
of
which
went
out
last
thursday.
A
I
believe
it
was
v7
16.
feel
free
to
correct
me
if
I'm
wrong
clyde
team
and
we've
been
landing
and
sort
of
finished
off,
making
our
sub
commands
workspace
aware,
which
we're
really
proud
of
and
the
team
has
been
working
really
hard.
So
if
you
haven't
been
playing
with
our
workspace
implementation,
now
is
the
time
to
go
check
it
out
and
give
it
a
run.
Give
us
some
feedback.
A
We
want
to
know.
You
know
your
thoughts
and
feelings,
and
hopefully
we
can
improve
and
have
a
best-in-class
experience
there.
So
did
anybody
else
have
any
other
announcements
they
want
to
share.
A
If
not,
then
we'll
dive
right
into
the
agenda
as
we
had
it
in
that
issue.
The
first
item
we
have
is
issue
number
395,
the
rfr
rfc
that
roy
put
together
for
npm
ad
I'll,
give
you
the
floor
roy.
If
you
want
to
speak
to
this
a
bit,
and
I
can
take
some
notes.
B
Sure
sure
thank
you
yeah,
which
yeah.
Basically,
this
rfc
here
is
not
yet
a
proper
rfc,
but
I
would
say
somewhat
a
continuation
of
325,
which
was
a
way
to
run
pre-install
and
post
install
scripts
when
adding
new
dependencies
to
to
your
project.
So
it's
it's
somehow
like
it
tries
to
say
to
save
the
solve
that
same
problem,
but
I'm
also
trying
it
to
separate
problem
space.
I've
seen
it
a
lot
happening,
a
lot
which
is
basically
users.
Npm
user
is
confusing.
B
Just
the
pure
rarification,
just
a
simple
npm
install
with
the
act
of
adding
a
dependency,
so
maybe
you're,
adding
a
dependency
at
a
different
version.
Maybe
you're
just
adding
dependency
at
latest
and
users
get
totally
confused
about
that.
Like
I,
it's
more
adoptable
evidence
than
an
actual
item
in
this
issue
here,
but
one
of
the
things
I've
seen
things
along
the
lines
of
users
being
confused.
Oh
npm
install
will
install
from
a
for
my
lock
dependencies
from
a
package
lock.
B
Oh
but
look,
I
just
did
an
npm
install
and
it
updated
my
package
lock.
I
don't
understand.
What's
going
on
so
it
turns
out.
You
go
see
what
that
what
happened
was
just
that
the
user
was
npm,
install
a
dependency
as
latest
and
like
updating
the
current
version
of
the
dependency
in
the
tree
does
updating
the
package.
Log
and
the
users
are
confused
to
them,
is
all
npm
install,
so
it
should
be
all
the
same.
B
This
is
something
that
we're
missing
right
now
so
kind
of
tying
the
two
problem
spaces
into
like
trying
to
come
up
with
a
single
elegant
solution
for
both
of
them.
So
that's
pretty
much
the
idea
here.
I
would
appreciate
any
feedback.
It
is
just
an
initial
idea:
rfc.
B
A
I
mean
the
only
thing
I
think
we
already
talked
about
internally
was
just
the
fact
that
npm
ad
today
is
an
alias
for
npm
install,
so
this
change,
if
we
did
at
this
command,
would
have
to
probably
happen
in
v8
unless
we
somehow
change
you're,
saying
no
guard,
you
want.
C
D
So
I
have
a
question:
what
would
probably
be
a
breaking
change,
though,
is
I
mean
that,
as
I
understand
it,
is
this
isn't
this
going
toward
the
direction
of
I
want
to
add?
Like
I
have
a
okay,
I
have
a
dependency
on
foo
and
it's
not
installed
right.
I
have
an
empty
node
modules
tree.
D
C
D
Then
the
benefit
here
is,
we
have
two
separate
commands.
Maybe
we
rename
install
no
args
to
npm
refi
or
we
leave
it
as
npm
install
that's
a
question
for
another
day
and
we
have
npm
ad,
which
requires
that
you
give
it
an
argument.
D
D
What
is
the
I,
what
I'm
trying
to
kind
of
just
zero
in
on
them
is
like
a
kind
of
clear
articulation
of
like
what
the
benefit
is
of
that
versus
one
install
that
one
install
command
that
can
be
used
for
both
purposes.
I
guess
there's
anecdonic
data
that
people
are
confused
about
either
it
can
take
args
or
not.
D
B
B
If
it
becomes
a
proper
command,
then
it
gets
its
own
documentation,
page
right,
and
then
we
explain
about
also
the
the
ad
lifecycle
scripts
and,
and
it
becomes
more
prominent
right,
like
people
can
actually
find
about
it,
and
so
I
think
it's
more
about
the
syntax
really
like
it's,
not
any
functional
change.
If
we
don't
introduce
the
the
difference
between
simply
refine
that
that
single
dependency,
like
you
mentioned
right.
D
Right
because
I
mean
I,
I
think
that
that
that
I'm
kind
of
torn
like
on
the
one
hand,
it
would
be
nice
to
be
able
to
say
I
just
want
to
add
this
one
depth
and
I
don't
want
to
reify
the
rest
of
the
tree.
That's
a
thing
that
people
have
asked
for
right
and
there
was
kind
of
this
weird
back
door
way
to
do
it
in
npm
v6.
If
you
just
deleted
your
lock
file,
but
it
was
never
really
the
intent.
D
D
E
Yeah,
so
these
are
probably
minor
things,
but
just
just
to
bring
them
up
in
the
context.
If,
if
the
decision
is
to
make
npm
ad
the
only
way
of
installing
a
single
package
in
the
future,
you
probably
need
to
take
into
account
that
almost
every
package
in
their
readme
has
a
section
that
says
you
install
it
by
typing
npm,
install
name
of
the
package,
so
I
don't
think
the
ecosystem
would
ever
update
that.
E
I
would
not
advise
to
take
that
one
as
an
official
command
because
well
I'm
not
a
native
speaker
of
english
and
I
would
have
trouble
remembering
what
that
does.
So.
Maybe
another
name.
F
D
D
Yeah.
That's
the
term
that
arborist
uses,
because
that's
at
that
point,
you're
you're,
eyeballs,
deep
in
package
management
welcome.
C
Car,
I
see
your
hand
off
yeah,
just
trying
to
think
through
because,
like
we
know
where
we
want
to
get
to,
and
this
rfc
is
trying
to
push
us
in
that
direction,
even
if
the
net
benefit
isn't
much
here,
is
there
value
in
starting
to
separate
these
terms,
even
if
npm
install
foo
always
eventually
just
aliases
to
add
flu
under
the
hood,
and
we
never
break
that?
That's
fine,
and
even
if,
for
now,
mpm
ad
foo
doesn't
add
only
foo
like
is.
C
D
Well,
I
think
the
I
think
that
question,
if
essentially,
what
you
described
from
a
user-facing
point
of
view
is
they
are
exactly
it's
exactly
the
same
as
what
we
have
now
right
because
effectively
add
remains
ad.
Does
a
full
refi
install
can
take
an
argument
and
calls
add,
add,
does
a
full
refi
and
calls
install
or
if
it
doesn't
get
any
from
a
user
point
of
view,
there's
no
change
right,
they're,
effectively,
aliases
to
one
another
still,
the
the
benefit,
then
is
is
really
kind
of
just
an
internal
refactoring.
D
D
But
I
think
where
it
gets
interesting
for
our
purposes
here
is,
if
there
is,
is
going
to
be
some
some
net
kind
of
user
change
and
I
think
the
and
that's
kind
of
what
I
was
asking
about.
The
the
life
cycle
hook
right.
So
if
the
life
cycle
hook
for
ad
is
going
to
happen
every
time
you
add
a
package.
D
D
None
of
them
are
particularly
hard
to
answer,
and
I
I
think
that
it's
it's
okay,
like
that's,
definitely
a
a
user
benefit.
I
still
think
that
we
should
probably
have
a
a
broader
like
mutation
event,
and
mutation
is
another
one
of
these
words
like
reify.
That
is
totally
sensible
when
you
are
eyeballs
deep
in
package
management,
and
probably
a
lot
of
users
would
think
we're
talking
about
the
x-men.
A
I
think
those
two
things
are
separate
right
like
because
the
in
this
proposal,
or
in
this
like
topic,
I
think,
we're
speaking
to
pre-ad
and
post
ad
in
terms
of
like
you
running
the
command
right
like
versus
what
I
think
you're
speaking
to
which
is
the
you
know,
lower
level
like
actual
mutation.
Events
that,
like
we
want
people
to
be
eventually
be
able
to
plug
into
right.
A
G
D
Even
what
gar
suggested
is
still
a
breaking
change,
because
the
the
lifecycle
event
name
in
the
environment
for
install.
A
A
D
C
A
C
If
that's
a
different
scenario
than
everyone
out,
there
says
type
npm
install
people
reacting,
a
life
cycle
is
probably
going
to
be
a
little
easier,
but
I
think
to
to
your
point
yet
this
is
this
is
solving
the
one
problem
of
like
how
do
we
have
an
event
when
the
user
said.
I
want
to
add
this
package
to
my
tree
right
right.
G
C
D
The
what
I
meant
was
the
npm
underscore
command
environment.
Variable
yes,.
C
D
Think,
there's
there's
not
very
many
things
that
that
hook
on
an
npm
command
environment,
the
the
big
one,
is
usually
publish
versus
something
else
in
pre-published
scripts.
That's
the
only
case.
I've
seen
people
actually
use
that
npm
command
name
and
test
runners
that
well
tap
write
checks
to
see
if
the
oh,
no,
that's
the
event,
lifecycle
command
yeah,
it's
not
the
npm
command
that
almost
anything
is
is
looking
at.
D
D
E
I
have
to
admit
I
did
use
post
install
for
unusual
stuff
in
my
time,
so
it
might
not
be
that
uncommon.
I've
seen
a
few
usages
and
I
I
blocked
it
for
a
few
cases
where
I
didn't
want
to
risk.
Someone
messing
up
my
installation
with
some
hacks,
so
it
would
probably
be
fairly
easy
to
scan
the
registry
and
see
how
often
it's
being
used.
C
Only
for
public
packages
private's
quite
a.
A
Yeah,
so
in
terms
of
this
roy
do
you
it
does
seem
like
there
is
some
there's
enough,
like
willingness
to
to
see
this
implemented
to
actually
create
an
rfc,
I
think
for
it
yeah.
So
if
you
want
to
like
take
the
next
step
of
like
turning
this
into
that,
then
that
I
think
that's
like
a
good
next
step
and
then
in
terms
of
when
it
would
actually
land
or
when
we
would
actually
do
this.
I
think
that's
a
completely
separate
like
topic,
whether
or
not
you
know
yep
sounds
great
cool
moving
on.
A
I
know
I
shuffled
the
order
here,
a
little
bit
zb.
I
know
you
you
poked
me.
We
had
this
issue
371,
which
is
sort
of
like
a
holding
issue
for
the
npm
res
audit,
resolver
topic
that
we've
been
having
for
a
couple
years.
A
At
this
point
the
I
know
you
had
the
rfc,
which
is
one
of
the
oldest
open
rfcs,
that
we've
had
and
we've
made
some
progress
in
terms
of
moving
the
conversation
forward
in
the
package
maintenance
group
and
now
we've
opened
up
a
new
collaboration
space
called
the
package,
vulnerability
and
reporting
collaboration
space
in
the
open.js
foundation.
Just
we
sort
of
kicked
that
off
last
week,
but
yeah.
A
I
wanted
to
give
you
the
floor
and
give
you
some
time
to
speak,
maybe
a
little
bit
about
what
you
know
what
your
hopes
are
for
next
steps.
I
know
we've
talked
about,
and
even
previously
I
know,
adam
baldwin
even
was
in
big
support
of
potentially
pulling
in
some
of
the
concepts
in
npm
audit,
resolver
and
yeah
would
love
to
just
let
you
speak
to
this
and,
and
you
know,
questions
that
you've
raised
in
this
issue.
E
Okay,
so
a
bit
of
background
first,
most
of
you
are
aware
of
what
order
resolver
is,
but
the
idea
is
twofold:
actually,
there's
one
tool,
that's
interactive
and
helps
the
end
user
make
decisions
about
what
to
ignore,
but
it's
very
specific
about
how
it's
ignoring
things
and
it
helps
maintain
how
long
the
thing
remains
ignored
for
various
reasons
and
has
a
few
other
minor
features.
E
They
generally
help
you
make
and
store
decisions
about
what
you
want
to
do
with
vulnerabilities
reported
in
your
your
packages,
audit,
and
that's
mostly
for
end
users.
I
I
don't
think
a
lot
of
package
authors
are
currently
using
this,
but
the
the
the
collab
space
is
intended
to
change
that
and
move
forward
with
something
that
would
be
usable
for
both
end
users
and
package
maintenance
other
than
that
there
is
a
second
tool,
that's
simply
wrapping
around
npm
audit
and
applying
the
decisions.
E
So,
instead
of
running
in
pm
audit,
you
run
the
wrapper
I
built
and
your
decisions
that
you
want
to
ignore.
Some
specific
instances
of
a
package
with
a
vulnerability
are
taken
into
account
and
effectively
it
exits
zero.
More
often,
simply
put
so
that's
been
working
with
npm
six
starting
from
6.1,
I
think
or
or
something
like
that
and
now.
Npm
7
has
been
a
major
change
for
me
and
I
have
a
branch
already.
E
I
even
made
a
release
candidate
with
npm
7
support,
but
there
is
a
bunch
of
things
missing
in
there,
because
the
the
biggest
issue
is
that
there's
much
less
output
from
npm
seven
in
the
audit
and
the
the
key
item
for
me
is
the
via
field
or
whatever
american
pronunciation
of
that
is,
and
that
means
it
gives
me
a
graph
where
I
can
go
through
the
graph
and
find
out
where
the
in
the
dependency
tree.
E
E
I
can
let
the
user
decide
that
they
want
to
ignore
these
specific
instances
of
the
package,
but
if
the
package
becomes
a
dependency
of
their
other
dependency,
all
of
a
sudden,
they
will
have
to
look
at
it
again
and
decide
if
this
use
case
can
also
be
ignored
like
so
so
they
by
ignoring
a
regular
expression,
denial
of
service
somewhere
irrelevant
they
don't
later
introduce
it
somewhere
else
where
it's
become
a
dependency
of
a
server
component.
E
So
with
that,
I
really
need
to
figure
out
the
the
path
again,
so
we
used
to
have
path
in
npm,
6
and
now
I
have
to
rebuild
it
from
the
the
graph
of
via
fields
and
this
generally
works.
But
the
prerequisite
to
that
is.
I
need
to
npm
ls
depth
zero
to
figure
out,
what's
an
actual
dependency
that
someone
pulled
in
instead
of
taking
all
of
them
as
potential
top-level
dependencies.
E
So
ask
number
one
fairly
simple
would
be
an
indication
that
says
either
a
depth
field
or
an
indication
that
something
is
a
direct
dependency
from
the
current
packet
json
in
the
output
of
npm
audit
minus
minus
json
command.
So
that's
that's
my
ask
number
one
which
would
remove
the
necessity
to
run
npm
ls
for
npm
seven.
E
So
the
does
that
thing
sound
reasonable,
like
how
so
my
overall
question
is:
how
willing
are
you
to
add
to
the
output
in
npm
audio.
D
D
D
One
one
thing
might
be
challenging,
though,
because
we
do
de-duplicate,
you
may
have
something
at
you
know:
node
modules,
slash
trim,
which
is
depended
upon
by
the
root,
as
well
as
a
bunch
of
other
stuff.
But
if
all
you
care
about
is,
is
it
a
root
dependency
or
not?
Yeah
that
that's.
E
What
I
care
about
so
I
want
to
then
yeah
just
count
the
route
dependencies
and
then
build
paths
for
them.
D
D
Yeah
I
mean
if
it's
not
a
breaking
change
like
you,
could
probably
just
get
your
get
your
hands
dirty
in
the
in
the
coden
arborist.
That's
generating
this
report,
because
it's,
but
you
know,
or
or
post
a
an
issue
or
a
pull
request
like
hey.
I
need
you
to
add
this.
This
particular
thing.
D
We
tried
to
make
it
straightforward,
so
you
could
see
you
know
what
that
isn't
in
as
little
with
as
little
a
challenge
as
possible,
but.
D
A
E
E
E
Npm
audit
used
to
have
that
information
like
it
would
say
if
it's
a
dev
dependency,
if
it's
an
optional
bundle,
etc.
So
I
I
don't
really
care
much
about
the
optional
and
bundled
use
cases,
but
highlighting
the
difference
between
direct
dependency
for
production
and
a
dev
dependency
is
kind
of
useful
for
my
end
users
in
audit
resolver.
E
So
I
was
thinking
if,
if
there's
a
way
to
look
it
up
easily
yeah
other
than
just
you
know,
pulling
into.
D
D
E
Not
as
obvious
as
just
pulling
in
the
package.json
and
looking
it
up,
so
I
need
that
for
for
each
path,
I
need
to
figure
out
if
that
path
is
in
production
or
death
dependency
right.
D
D
The
design
of
this
thing
initially
was
just
like
what
is
a
what
is
a
reasonable
kind
of
human
readable
report
that
is
a
little
bit
less
noisy
and
more
actionable
than
than
the
previous
human
readable
report,
and
then
we
kind
of
built
the
data
model
up
to
just
do
that
yeah,
and
so
so
you
know
the
thing
you
mostly
care
about
is
like
what's
actually
vulnerable,
why
is
it
vulnerable
and
can
I
fix
it.
D
You
know
any
any
combination
of
dev,
optional,
dev,
optional,
dev
optional,
but
not
strictly
dev
or
strictly
optional,
like
all
of
the
flags
yeah,
neither
bundled
or
not,
although
usually
when
it's
bundled,
we
do
tell
you
like,
we
do
actually
specify
in
the
report
like
you
have
to
upgrade
this
this
thing
in
order
to
get
out
of
the
potential
of
getting
a
bundled
vulnerable
version,
but.
D
Yeah
yeah,
it
does
it'll
tell
you
if
something
is
dev
or
a
workspace
or
what
have
you.
E
But
then
again
can
I
use
it
on
oh,
okay,
I
I
should
I
remember
what
the
x
plane
returns
and
I
should
be
able
to
use
it,
but
only
in
the
interactive
part,
because
I
probably
I'm
not
sure.
If
I
want
to
call
npm
explain
on
every
single
thing
I
I
go
through
in
the
check
option,
but
yeah
that
might
not
be
necessary.
Okay,
I
I'll
look
into.
D
It
npm
explain:
json
is
like
npm,
explain,
package
name
dash.
Json
is
I
mean
that
gives
you
every
instance
of
it
every
dependency,
it's
it's
kind
of
path
back
to
the
root
project
or
workspace.
Yeah.
E
Okay
and
one
last
thing
is
about
fixing
so
npm
audit
resolver
used
to
have
a
feature
where
you
could
decide
to
fix
the
specific
vulnerability
and
it
would
record
the
fact
that
these
paths
were
fixed
before
and
if
someone
installed
the
old
versions
again
by
dropping
the
package
lock,
for
example,
and
regenerating
it
in
an
unfortunate
way,
you
would
get
notified
about
it
that
this
is
not
only
vulnerable,
but
it
was
also
fixed
before
so
you
could
investigate
and
individual
fixing
is
no
longer
exposed
at
all.
So
there's.
D
Yeah
there's
there
were
some.
There
were
some
pretty
significant
problems
with
the
the
way
that
we
had
the
the
server
kind
of
tell
you
what
to
update
and
how
to
fix
it.
D
Obviously,
npm
audit
resolver
kind
of
address
some
of
that
by
having
the
user
pick
what
version
I
want
to
fix
it
to,
but
I
think
the
potentially
a
solution
here
might
be
to
have
npm
audit
resolver
create
an
override
rule
in
the
package
json
file,
because
then
that
could
say
look
if
you
have
this
particular
path
to
you
know
some
module
to
low
dash
version,
whatever
whatever
version
range.
I
want
it
to
be
replaced
with
this
other
version
range
instead.
E
E
Or
just
run
npm
audit
fix
jason
and
ask
you
to
provide
in
the
output
what
was
fixed
or
scan
what
changed
and
try
to
use
that
as
input.
And
then
just
you
know,
mark
everything
as
fixed
in
bulk.
E
D
So
way
that
fix
works
right
now
is
we.
We
create
a
list
of
all
of
the
nodes
that
are
that
are
marked
as
vulnerable
all
right,
so
we
get
the
internally
in
arborist.
None
of
this
is
actually
handled
in
the
npm
client
anymore
internally,
within
arborist
we
get
the
list
of
all
the
things
that
are
vulnerable,
get
the
report,
and
then
we
identify
all
of
those.
We
have
the
identification
of
all
those
nodes
that
are
vulnerable.
D
Then,
essentially,
we
we
re-evaluate
all
of
those
for
a
new
dependency
match
right.
So
we
effectively
like
we
ignore
the
lock
file
for
those
particular
nodes
within
the
tree
and
we
re-evaluate
them
and
because
we
start
with
the
the
kind
of
nearest
meta
vulnerability
to
the
root
project,
we're
able
to
kind
of
steer
around
the
vulnerable
versions
and
we
can
determine
at
the
time
of
of
generating
the
report.
We
know
whether
or
not
we're
going
to
be
able
to
do
that.
D
We
just
do
a
best
effort
and
we
end
up
fixing
what
we,
what
we
determined
was
fixable.
D
E
Okay,
so
either
selecting
which
ones
to
fix
or
output
that
says
which
were
fixed
in
the
in
the
json
output,
because
I
could
use
that
and
I
think
it
would
be
an
upgrade
for
the
end
user
because
they
would
run
the
fix
once
like.
No
one
really
wants
to
decide
if
they're
fixing
or
not,
unless
it's
a
braking
chain,
so
a
major
version
bump.
E
That's
that's
something
to
investigate
further,
but
if
we
could
just
run
the
fix
on
everything
and
save
the
result
in
the
resolve
json
file,
that
would
be
okay,
because
it's
not
important
which
exact
packages,
someone
decided
to
fix
it's
important
to
mark
that
they
were
fixed
before
so
I
would
be
happy
with
npm
audit
fix
just
giving
me
the
list
of
fixed
paths
as
output.
D
Yeah,
this
kind
of
gets
back
to
our
to
a
an
issue
that
we
have
that's
kind
of
a
long-ish
standing
issue.
It's
a
ux
shortcoming
where,
if
you
run
you
know,
for
example,
if
you
run
npm
find
dupes,
that's
supposed
to
run
dedup
in
a
dry
run
mode
and
then
tell
you
what
the
duplicates
are,
but
our
our
kind
of
final
stage
in
the
refi
process
doesn't
know
that
it
was
a
dry
run.
D
So
it
just
says:
oh
well,
I
updated
three
packages
and
removed
two
and
added
one,
but
I'm
not
going
to
tell
you
what
they
are
and
I
didn't
actually
do
it.
So
it's
like
not
very
useful,
so
I
think
I
think
what
we
kind
of
need
here
is
a
a
way
to
tell
npm
to
output
the
actual
diff
of
the
trees
like
what
would
what
were
the
set
of
steps
that
we
did
in
a
very,
very
verbose
way
and
if
you're
running
in
dry
run
we
do
that
by
default.
G
D
Like
we,
we
did
if
we
didn't
actually
do
it.
That
would
just
give
you
a
summary
output.
If
we
did
actually
do
it,
you
maybe
don't
care
it's.
If
you
want
to
see
what
change
you
can
like
diff
your
package
lock
right
and
it's
fine,
so
I
think
that
that
functionality
like
arborist
is
already
making
that
available
and
the
client
is
just
sort
of
not
doing
anything
with.
A
D
I
would
I
would
make
it
a
you
know,
describe
your
use
case
in
a
cli
feature
request
to
say
that
you,
like
you,
want
the
diff
data
to
be
made
available
somehow
and
then
we
can
take
it
from
there
and
then
it's
just
a
question
of
like
what
is
the
flag
that
we
use
to
say
always
dump
the
diff.
E
D
I
would
say
if,
if
we're
doing
a
dry
run
install,
we
probably
always
want
to
show
the
the
diff,
because
otherwise,
what
are
you
doing
right?
A
It
okay,
I
have
three
actions
I
think
one
and
and
if
you're
okay,
so
you
be
with
taking
them
all,
it
seems
like
one
there's
a
pr
that
if
you
want
to
go,
dig
in
to
our
wrist
itself
and
update
the
audit
report
and
add
the
information
that
you're
missing,
it
seems
like
we're.
We
would
be
open
to
reviewing
that
and
adding.
I
think
I
might
have
skimmed
this
file
already
before.
A
Okay,
but
adding
essentially
back
in
some
sort
of
like
top
level
flag
or
type
information
like
or
depth
information
that
you're
looking
for.
We
can
review
like
a
pr
on
that
and
then
there's
the
investigate,
take
away.
I
guess
for
you
to
investigate
npm,
explain,
json
or
npm
audit
when
we're
essentially
resolving
a
vulnerability,
and
then
the
ask
that
you'll
have
of
us
is
to
yeah
to
essentially
show
diff
information,
yeah.
E
B
A
We
are
we
roy
and
myself
do
our
best
to
note
sentiment.
Not
it's
not
a
one
to
one
of
what
you've
said
in
a
call,
so
apologize
if
we
are
paraphrasing
quite
often
so,
is
that
that
good
tv
do
you
feel
like
there's
action
items
there
we
can.
We
can
move
on.
E
Yeah
sure,
that's
that's
a
good
path
forward.
A
Awesome
so
moving
on,
we
have
isaac,
you
have
pr
375.
A
D
This
is
still
pending
some
some
work.
I
was
supposed
to
get
to
it
this
week,
but
instead
I'm
fixing
fixing
a
pretty
gnarly
pure
depth,
bug
yeah,
where
we
left
this
just
briefly.
In
summary,
this
pr
that
I
wrote
and
the
the
pr
that
vincent
wrote
about
pure
mode
are
going
to
be
split
up
into
three,
the
first
being
a
definition
of
kind
of
what
is
shared
by
default.
What
is
not
shared
by
default
across
workspaces
and
just
across
dependencies
in
general.
D
D
A
Okay,
this
next
one
we've
had
on
the
radar
for
a
while
pr364
restore
npm
six
ability
to
install
one
package.
This
is
basically
npm
ad,
which
we
sort
of
alluded
to.
I
I
believe-
or
this
is
yeah.
I
think
this
is
pretty
much
that
right
we
could.
We
would
imagine
that
npm
ad
would
essentially
provide
this.
D
Mechanism
yeah,
like
I
said
this,
it's
a
little
bit
of
misnamed
pr,
because
this
was
only
the
behavior
in
v6.
If
there
was
no
package.json
file
and
by
default
there
is
a
package.json
file
and
the
intent
in
npm6
was
to
ins
to
always
have
a
fully
realized
tree
fully
refined
tree,
and
I
don't
know
which
word
to
use
the.
D
If
we're
going
to
add
it,
then
we
we
kind
of
need
that
to
be
some
somehow
an
opt-in
feature,
and
I
wouldn't
want
to
make
it
the
default
for
npm
install
foo
to
only
install
foo
like
it's.
The
hazards
are
not
really
worth
that,
but
yeah
I
mean
if,
if
we
decide
that
the
spelling
of
that
is
that's
like
that's
what
npm
ad
foo
does
is
it
just
adds
foo
and
nothing
else.
That's
pretty
straightforward.
D
There's,
definitely
some
some
care
to
be
taken
in
how
we
how
we
do
that,
how
breaking
it
is
at
which
point
it's
breaking.
If
we,
you
know,
put
deprecation
notices
ahead
of
npm
version,
8
or
whatever.
A
Well,
I'm
muted.
Sorry
can
I
like
these
two
essentially
npm
add
in
this
install
one
package.
D
I
mean,
if
I'm
not
sure
like
if
we
think
that
the
long-term
goal
of
npm
ad
is
to
iden,
is
to
address
this
use
case
then.
Yes,
that's
exactly
the
right
thing
to
do.
If
we
decide
that
the
long-term
goal
of
npm
ad
is
just
you
know,
internal
code
cleanup
and
a
new
lifecycle
hook.
Well,
then
it
doesn't
really
satisfy
the
the
request
here.
So
it's
it's
kind
of.
I
think
we
need
to
answer
that
question.
First,
okay,.
D
Yeah
and
there
you
know
there
could
also
be
some
some
net
new.
You
know
config
flag
or
something
that
is
like
only
only
install
this
one
particular
version
or
only
install
this
one
particular
node
in
the
tree.
Don't
install
anything
else.
The
implementation
of
that
in
arborist
is
pretty
straightforward.
We
already
do
that
for
global
packages
and
for
workspaces,
so
allowing
that
to
just
be
some
arbitrary
path
is
totally
doable.
It's
it's
really
just
a
matter
of
kind
of
figuring
out
the
ux
and
and
then.
A
Specifying
it
let's
leave
it
open
and
we
can
maybe
discuss
changing
or
modifying
the
rc
or
asking
the
the
individual
to
update
it
with.
Maybe
the
option,
like
you
say,
to
like
introduce
a
net
new
flag
to
get
that
behavior
back
okay
moving
on,
because
I
want
to
get
through
these
three
43
mpm
workspaces,
auto
switching
contacts
based
on
the
current
working
directory
roy.
Is
there
any
update
on
this.
B
A
B
A
B
Still
see
confused
users,
I
was
working.
B
Issue
this
week,
another
confused
user
that
wanted
to
npmls
inside
a
workspace
directory
and
oh,
it's
not
working.
Everything
is
extreme.
It's
missing!
What's
going
on
so
yeah,
but
I
don't
remember
where
we
left
it
up
last
time
with
this
discussed
this
rfc,
I
remember
there
was
the
idea
of
making
it
an
opt-in
by
adding
another
configuration
to
basically
track
make
sure
that,
if
you're
running
from
a
workspace
directory,
you
should
actually
refer
to
the
project
route
and
run
it
from
there.
B
D
You
know
another
another
way
that
this
like
what
is
shared
across
dependencies
rfc
might
address.
This
is
we
could
just
put
the
sim
links
in
all
of
those
workspace
routes
right
so
that
when
you
see.
G
D
That
folder
and
you
run
npmls,
we'll,
say
yeah
you're
getting
this
from
outside
your
project
and
then
we
don't
have
to
have
any
like
magic,
walk
up
the
walk
up
the
file
tree.
D
B
B
B
A
Yep
yeah,
I
think
this
was
jordan's
idea
of
the
file
or
something
pointing
back
towards
the
workspace
route
yeah
and
so
for
me.
I
totally
agree
that
that's
like
a
way
that
you
opt
into
this,
but
just
how
you
set
those
up.
A
I
would
want
like
the
ergonomics
of
that,
to
be
like
really
simple
so
like
if
we
introduce
some
sort
of
like
sub
command
like
workspace,
sub
commands
like
ws,
or
something
to
eventually
help
manage
workspace,
specific
config
in
the
future,
like
I
can
imagine
that
something
could
live
under
there
to
like
set
up
those
links
or
set
up
those
files
for
you.
A
I
just
want
to
make
it
easy,
so
you
do
like
an
npm
init
dash
w
and
then
the
workspace
name,
but
then
you
want
to
like
link
that
or
make
sure
that
it's
like
set
up
properly
like
there's
got
to
be
like
a
way
to
opt
into
that
somehow
to
generate
that
file
for
you,
so
you
don't
have
to
do
that
manually,
but
that's
just
my
two
cents
on
like.
A
F
Just
tiny
update,
I
did
the
dependency
the
pr
to
licensee
the
dependency
update
there
to
get
it
in
a
shape
where
I
was
comfortable
printing
it
in
so.
I
believe
I'm
gonna
end
up
figuring
out
if
we
compare
with
someone
from
the
npm
team
in
the
next
month
this
year,
so
like
in
june
to
to
get
that
going
to
get
get
work
done
on
that.
So.
A
Thank
you
and
then
I
don't
think
that
they're
here
enough
isn't
here
and
I
know
unfortunately
looks
like
the
person
who
created
the
group
update
packages
by
dependency
type.
Isn't
here,
but
I
know
gil,
I
think
you've
been
on
our
jill.
I've
been
on
the
call
I
apologize.
We
didn't
give
you
more
time
here,
but
I
want
to
give
you
the
last.
You
know
five
ten
minutes,
but
we
got
to
speak
to
the
rc
386.
G
Yeah
sure
hi,
so
I
saw
optional
peer
dependencies
and
I
assumed
that
it
would
do
a
bit
more
than
it
does
so.
My
assumption
was
that
if
you
have
an
optional
peer
dependency
and
the
consuming
project
has
that
dependency
installed,
you
would
still
get
a
warning
if
it's
the
incorrect
version
but
turns
out
that
it
just
turns
off
warnings
completely,
which
doesn't
seem
that
helpful
to
me.
So
I
think
you
should
check
the
version
and
it
should
give
you
a
warning
if
it's
an
incorrect
version
but
remain
silent.
G
If
it's
not
installed,
that's
pretty
much
it
so
yeah.
Initially,
I
said
that
we
should
have
an
extra
option
in
the
configuration,
but
somebody
else
commented
that
yarn.
Does
it
the
way
I'm
suggesting
what
I
was
trying
to
avoid
was
a
breaking
change,
but
I
think
a
breaking
change
would
be
better
to
change
the
existing
behavior
of
the
optional
peers
so
that
you,
you
still
get
an
error.
If
it's
installed,
you
should
get
an
error
if
it's
got
a.
G
Version
I'm,
I
would
really
hesitate
to
say
that
you're
wrong.
D
D
D
In
my
code,
I
wouldn't
be
too
surprised,
but
definitely
the
intent
is.
If
you
have
appear
optional,
the
contract
is,
if
you
have
a
pure
optional
depth,
we
we're
not
going
to
put
it
there
by
default,
but
if
there
is
a
version,
that's
there,
we
will
verify
we'll
make
sure
that
it's
not
a
different
version.
It's
not
a
conflicting
version.
D
G
You're
describing
is
correct.
I
did
have
a
look
at
the
pr
that
implemented
the
optional
peers,
but
maybe
it's
changed
since
then,
and
it
seemed
to
just
turn
the
warning
off,
but
you
know
I've
not
tried
it
in
pm7,
so
I
might
be
talking
rubbish.
D
I
didn't
realize
you
were
talking
about
sex,
so,
yes
in
sex,
you're
correct
it
would
just
not
warn
you
if
it
was
missing,
which
you
know
was,
I
guess,
a
little
bit
nicer,
because
it
wasn't
telling
you
to
go,
install
it,
but
in
seven
it
will
actually
it
will
actually
crash
the
install
if
there's
a
conflicting,
pure
optional
in
that
in
that
level
in
the
tree
and
if
there's
no
way
for
it
to
like
get
you
a
correct
version
for
your
pure
optional
depth.
D
So
I
think
maybe
what
you're
requesting
is
what
we've
done.
You're
welcome,
yeah.
D
Yeah
yeah,
that
would
be
probably
the
way
to
go.
I
think
the
only
thing
is
the
the
only
so
the
only
thing
that
we
actually
do
with
pure
dependencies
meta
and
it's
it's
kind
of
a
rather
baroque
way
to
to
go
about
specifying
this.
Is
we
just
check
optional,
true
or
false?
And
if
it's
not
there,
then
we
don't.
D
D
We
have
something
that
just
cannot
be
resolved
because
you
have
a
bunch
of
stuff
that
has
pure
depths
and
there's
no
kind
of
way
that
we
can
find
an
overlap
between
them.
There
is
some
heuristics
there
to
keep
people
from
just
being
broken
by
this,
so
there's
a
strict
mode
where
we
say
any
any
conflicts
we
crash,
but
the
default
is,
if
it's
yours,
if
it's
like
a
conflict
between
two
of
your
dependencies,
then
we'll
crash
on
it.
D
If
it's
a
conflict
that
happens,
you
know
two
or
more
layers
down
the
tree
of
dependency
of
the
dependency
graph
will
print
a
warning,
but,
like
you
know,
we're
not
gonna
get
in
your
way
of
getting
your
job
done
and
if
you
do
dash
dash
force,
we'll
just
accept
the
broken
setup
and
there's
always
the
legacy
pure
depths
solution,
which
just
goes
back
to
npm
v6
style
and
does
not
look
at
peer
relationships
at.
G
All
okay
right,
thanks
for
your
help,
I'll
go
back
and
reconsider.
Thanks
for
coach.
A
Yeah
yeah,
if
it's
not
working,
feel
free
to
poke
us
either
in
a
bug
on
the
cli
repo
or
just
come
back
to
the
rfc
and
comment
back
on
its
yourself
as
well.
So
but
appreciate
you
adding
that
so
and
enjoying
the
calls.
A
G
A
Anything
else
from
folks
I
know
we
skipped
over
one
or
two
rc's,
but
hopefully
we'll
get
to
them
next
week
give
updates
there.
I
quickly
added
a
note
about
the
rc
for
the
where
config
I
think
we
are
just
at
the
point
of
by
saying
the
name.
I
don't
think
there's
much
pushback
for
that,
making
npm
config
and
npm
exec
configurable
in
terms
of
where
they
are
looking
but
yeah.