►
From YouTube: Open RFC Meeting - Wednesday, Sept 23rd 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Awesome
and
we're
live,
welcome
everybody
to
another
edition
of
the
npm
open.
Rc
call.
Thank
you
all
for
joining
today's
date.
Is
wednesday
september
23rd
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
number
237
of
the
rfcs
repo
and
I'll
paste
that
as
well
and
chat.
Just
a
quick
reminder.
All
calls
npm
rfc
calls
and
all
discussions
on
the
threads
are
covered
under
a
code
of
contact
which
is
found
on
the
rfc's
readme
and
we'll
make
sure
to
link
that
actually
in
the
meeting
notes.
A
Just
after
this
and
again,
these
calls
are,
are
meant
to
be
a
channel
and
an
opportunity
for
folks
in
the
community
and
and
for
ourselves,
the
mpm,
primarily
the
npm
cli
team,
to
come
and
connect
and
ideally
move
forward
features
and-
and
you
know
the
initiatives
that
we
want
to
see,
build
and
grow
the
community
and
the
cli
itself.
So
I
wanted
to
give
the
floor
for
any
folks
that
had
any
announcements
roy,
I
think
you
might
have
one
from.
A
Yeah,
so
if
you're
not
following
along
we've,
been
posting
on
our
blog,
every
tuesday
you'll
see
an
announcement,
blog
posts
go
out,
so
that's
blog.npmj.
A
Also,
if
you
follow
on
twitter,
you'll
get
notices
when
we're
when
we're
doing
releases
so
yeah
we'll
continue
to
be
shipping
weekly
releases
of
beta
and
then
rc
release,
candidates
of
npm7,
so
love
the
feedback.
We've
been
getting
and
feel
free
to
continue
to
file
issues
and
bugs,
as
you
find
them
against
the
cli
repo.
So
awesome
did
anybody
else
have
any
other
announcements
they
want
to
give.
A
If
not
we'll
move
on
to
the
agenda,
the
first
item
we
actually
had
on
here
was
pr
number
235
so
mark.
I
think
this
was
related
to
allowing
the
essentially
customize
their
configurable
header
values
to
be
passed
through
to
the
registry.
Did
you
want
to
speak
to
this
updated
rfc.
C
Sure
yeah
so
like,
like
you
say
this
is
sort
of
going
above
and
beyond
the
the
other
rsc.
That's
we're
going
to
talk
about
later
on,
so
this
is
I'm
maybe
getting
this
wrong.
So
I'm
hoping
somebody
can
correct
me
if
I
am
wrong,
but
this
is.
This
is
basically
for
the
ace,
a
server
side
to
basically
to
populate
the
the
content
of
any
missing
header
information
that
might
be
needed.
C
I
think
in
a
nutshell,
the
idea
being,
if
you
wanted
to
create
any
authentication
tokens
or
any
identification
that
the,
if
there's
anything
missing
from
when
the
server
retrieves
the
requests
the
server
itself
can
generate
whatever
is
required
based
on
that
server
that
can
be
passed
back
and
then
the
content
can
then
be
saved
into
the
rpm
rc
content
for
future
use.
Basically,.
A
A
C
A
And
again,
you're
speaking
to
the
235,
I
am
yes,
sorry,
yeah
yeah!
No,
just
like
that
for
folks.
The
one
thing
I'll
note
on
the
actual
implementation
side
of
the
headers,
like
the
any
spec,
is
that
how
you
define
usually
nested
or
arrays
in
any
spec.
I
think
it's
usually
that
the
key
would
take
up
so
like
npm,
app
id
would
actually
be
the
key
inside
of
the
headers.
C
Yeah
I
was
gonna,
do
it,
I
was
gonna.
Do
it
that
way,
but
this
was
the
example
that
came
from
isaac,
some
of
the
other
pr.
So
I
thought
this
was
maybe
a
suggested
way
of
doing
it,
which
is
why
I
kept
it
in
that.
However,
so
yeah,
I
can
change
it
to
a
typical
array
style.
One.
A
Yeah
we
can
discuss
it
like
in
further
like
in
terms
of
that
actual
design,
but
I
think
it
is
supposed
to
be
like
a
typical
array
fashion.
I
think
that's
how
all
other
yeah
any
files
work.
So
just
so,
it's
like
you
know
easy
to
parse.
A
Yeah
was
there
did
anybody
else?
Have
any
thoughts
on
this?
I
haven't
had
a
chance
to
read
through
exactly
what
you've
updated
here,
but
like
the
in
terms
of
the
actual
implementation
that
looks
exactly
what
we
discussed
last
time
so.
B
C
C
It
seemed
that
might
have
some
security
implement
implications
so
well,
I
couldn't
quite
think
it
through
fully,
which
is
why
I've
gone
the
route
with
with
the
the
client
still
has
to
sort
of
ask
what
head
is
it
once
filling
in
where
then
I've
just
got
like
a
like
a
sort
of
a
hard-coded
npm
generate
token,
so
that
that's
basically
saying
what
the
server
needs
to
replace
essentially
is
the
way
I
went
at
the
moment.
C
A
Awesome,
I
think
wes
just
noted
the
way
it
works
yeah.
The
way
any
supports
by
quirks
so.
D
I
I'm
pretty
sure
it
is
correct,
and
you
know
isaac
is
the
author
of
that.
So
I'm
guessing
that
people
would
be
correct
according
to
that
packages
parsing.
So
but
the
point
is
that
it's
not
a
and
I
mistyped
it
so,
but
it's
it's
not
an
array
of
key
value
pairs,
it's
an
array
of
strings
and
then-
and
so
that's.
Why
he's
doing
the
key
value.
A
E
E
B
E
So
what
were
the
reasons
to
choose
the
config
instead
of
reifying
it
in
like
like
if
it's
meant
to
be
per
package
and
it
comes
from
the
server?
Why
does
the
server
the
server
has
already
decided?
What
information
to
send
down
the
server
already
controls
the
information
that
gets
put
into
node
modules?
A
So
I
think
in
this
case
this
would
be
information
that
could
potentially
be
passed
through
the
registry
and
then
back
to
your
project
on
subsequent
installs.
I
think
that
was
the
primary
use
case
for
it,
and
if
you
don't
set
past
this
through
the
your
registry
could
potentially
be
passing
back
headers
that
it
expects
or
like
it
thinks
you
need
like
an
app
id.
So
it
could
potentially
automatically
generate
that
for
you
and
then
that
could
be
saved
back
to
the
config.
E
If
I'm,
if
I
have
already
configured
an
app
id,
then
great,
my
npm
installed
tells
my
registry,
who
I
am,
and
at
that
point
it
should
have
enough
information
to
customize
the
node
modules.
Payload,
however,
it
wants,
and
similarly
since
that
app
id
is
already
configured
it
shouldn't.
I
don't
know
what
extra
information
it
would.
It
would
not
like
any
extra
information
it
already
has,
because
it
was
able
to
send
them
down
in
the
first
place.
So
if
I've
configured
the
app
id,
I
don't
see
the
point
in
adding
additional
metadata.
E
If
I
have
not
configured
it,
then
the
server
has
to
be
able
to
figure
out
who
I
am
from
stuff.
That's
already
sent
anyway,
in
which
case
we're
in
the
same
scenario
where
the
server
already
knows
this
information
and
knows
I
need
it.
So
I'm
having
trouble
understanding
what
the
the
point
is
of
telling
the
client
to
tell
the
server
this
extra
information
when
it
already
knows
it.
B
Well,
I
think
the
goal
is
to
be
able
to
for
for
these
rfcs
specifically,
it
is
to
be
able,
like
the
server,
gives
you
a
random
id
right,
and
you
you
put
that
in
your
npm
rc
and
next
time
you
reach
out
to
the
server.
It's
gonna
recognize
you're,
coming
back
right,
similar
as
a
cookie
right
same
as
any
cooking,
but
that.
F
E
Is
not
attempting
to
attach
information
to
a
specific
package?
It's
essentially
a
la
you're
asking
this
rfc
is
asking
for
the
server
to
be
able
to
set
my
app
id
on
the
initial
response.
C
Yeah,
I
think
the
idea
was
it
it's
adding
on
to
the
sort
of
generic
http
header.
So
I
think
where's
that
came
up
with
another
possibility
was
for
the
authentic
some
kind
of
authentication,
tooling
that
you
might
have
so
that
could
be
a
that
could
be
generated
at
the
server
end
rather
than
having
to
you
know,
configure
it
at
the
front
end
and
get
your
tokens
and
so
on,
and
then
append
it
to
the
mppm
rc.
E
Then
then,
that
lead.
Thank
you.
That
clears
it
up
a
lot,
and
that
leads
to
my
next
question,
which
is
what
happens
if
the
server
wants
to
set
a
field
that
I've
already
put
in
my
npm
rc,
who
is
in
charge
of
my
local
npm
config
myself
for
the
server.
A
E
Yeah
and
then
the
second
question
is,
if
that's
true,
which
is,
I
would
what
I
would
expect,
that
the
server
can't
override
my
local
value.
Then
that
means
that
anything
the
server
sets
here
is
a
set
once
never
touch
again
thing,
so
why
would
they
want
to
do
that
like
other
than
an
app
id
like
even
a
login
token,
you
wouldn't
want
to
do
that,
because
those
need
to
be
refreshed
occasionally
so
other
than
an
app
id.
What
information
would
you
possibly
want
to
set
once
and
never
again
from
the
server?
D
D
So
so
I
think
for
this
feature,
so
the
new
rfc
seems
to
me
that
that
is
probably
the
only
thing
you'd
ever
want
to
do.
The
old
rfc
was
to
to
provide
sort
of
a
lower
level
thing
for
a
bunch
of
other
types
of
features
you
may
want
to
build
on
top
this
being
one
of
them,
and
this
one
just
makes
the
most
sense
with
just
the
app
id
the
other
ones
I
was
thinking
about.
D
Were
you
know,
I
think
the
authentication
one
is
is
one
that
is
fairly
clear
to
me
and
it's
not
a
set
once
and
never
update
it's
a
it
might
be
like
authentication
mechanism
settings
what
your
you
know,
auth
your
server
should
off
against.
Like
I
know
we
have
a
couple
of
different
methodologies
at
netflix
that
we
use
for
different
types
of
auth.
You
know
so
if
the
package
was
saying
it,
I
I
haven't
fully
thought
through
some
of
these,
so.
E
E
D
Yeah,
so
I
was
actually
thinking
also,
it
would
be
valuable
to
take
like
build
metadata
and
throw
it
in
there
so
that
we
could
then
report
that
back
to
the
server
on
every
install.
So
you
could
have
you
know
a
an
npm
r
c
in
the
root
of
the
jenkins
instance.
That
says
like
I'm.
You
know
this
is
my
instance
id
and
then
np
any
npm
install
in
that
box
would
then
send
that
along.
So
that's
sort
of
that,
the
underlying
feature
could
be
used
in
a
bunch
of
interesting
ways
like
that.
D
E
Headers,
of
course,
that
I
mean
I
think
that's
established,
I
I'm
I
I'm
basically
asking
the
ability
for
the
server
to
install
headers
on
the
client
other
than
like,
initially
generating
an
app
id.
That's
the
only
thing
I
can
think
of
where
it
would
would
even
be
not
terrible
for
the
server
to
do
it.
Yeah.
E
E
B
Be
one
of
the
alternatives
I
I
guess
to
these
rfc,
specifically,
maybe
just
narrowing
the
scope,
but
that's
it.
I
do
remember
chatting
with
wes
and
will
back
in
last
conference
and
they
were
sharing
some
interesting
use
cases
specifically
from
netflix-
nothing,
I
think
it's
nothing
to,
but
basically
they
do.
They
were
trying
out
the
cool
stuff
with
like
dividing
your
install
tree
for
a
given
project
like
into
sub
subtrees,
basically
within
a
single
npm,
install
right
that
could
possibly
be
optimized
for
repeating
users
right.
B
So
I
guess
one
of
the
things
they
could
try
to
identify
this.
The
sub
trees,
with,
let's
say
a
hash
and
put
that
on
the
clients
and
then
any
further
npm
install
like
would
send
out
that
same
hash.
As
long
as
there
is
no
change
in
the
install
tree
right
and.
E
E
E
You
and
wesley
have
mentioned
a
bunch
of
really
great
use
cases
for
where
the
server
can
update
it
over
time,
but
it
would
be
really
bad
if
the
server
updated
my
config
over
time
and
overrode
some
a
value
I'd
put
in
it.
So
I
I
don't
think
that
this
rfc
is
going
to
solve
any
of
those
use
cases,
and
this
rfc
seems
like
delightfully
generic.
A
Sure
mark
did
you
have
any
other
when
you
were
drafting
this
and
when
we
initially
brought
in
the
scope
beyond
the
app
id
like
was
there?
Do
you
remember
like?
Is
this
this
piece
as
well
super
important
for
your
your
team,
or
is
this
the
more
important
aspect
just
like
sending
that.
C
No,
I
mean
I
mean,
to
be
honest,
I
don't
even
think
we'd
probably
make
use
of
the
auto
generated
app
id
for
the,
for
the
reasons
just
mentioned
that
this
was
just
like
say,
this
wasn't
really
our
team's
intention.
This
was
just
as
we
were
talking
about
the
other
rfc.
It
sounded
like,
I
think,
last
week's
discussion.
It
was
potentially
another
good
idea
on
top
of
the
other
proposal,.
A
Okay
and
maybe
we
can
bundle
and
then
with
that,
because
I
thought
we
did
you
update
the
original
rfc,
then.
A
Yeah
we
can
pull
that
pull
that
up.
Actually,
so
that
was
number
138
yeah
yeah,
we'll
pull
that
up,
because
they're
related
here.
D
D
A
A
A
But
is
that
even
necessary,
like
what
we're
doing
is
providing
a
convenience
mechanism
for
that
so
specifically
doing
that
much
work?
Is
that
worth
it
versus
just
asking
like
being
able
to
generate
this
for
for
whoever,
like
it
seems
very
specific,
then
in
that
case,
which
is
why
I
think
we
broadened
the
scope
of
it
right.
B
Well,
I
think,
there's
still
value
right,
like
you
still
want
to
be
able
to
the
register
to
send
that
info
and
be
able
to
just
recognize
that
user
later
on
right
without
having
each
user
do
that
manually
right,
you
can
just
have
the
the
server
send
the
header
it
gets
put
in
the
config
and
later
on,
every
npm
install
is
going
to
have
that
app
id.
A
So,
okay,
then
I
would
want
to
look
at
the
naming
of
it
a
little
bit
more
like
app
id
versus
anything
else,
right
yeah,
so
I
I
think
that
we
leave
it
open
for
now,
as
rory
mentioned
and
potentially
mark.
If
you
want.
A
I
don't
think
you
have
to
really
update
this.
We
can.
We
can
have
see
if
there's
folks
that
actually
can
bring
up
some
other
use
cases
beyond
just
setting
an
app
id
to
jordan's
point
and
then
and
then
we
can
see
if
we
want
to
move
forward
with
this
or
scope
it
back
to
just
something.
That's
very.
E
Specific
well
and
to
be
clear
if
the
server
sent
headers
can
be
stored
somewhere
other
than
the
user's
config,
even
if
that's
merged,
with
the
user's
config
in
some
way
right,
but
like
that,
there's
no
chance
that
the
server
can
actually
override
what
I've
put
in
my
config.
Then
that
actually
unlocks
all
of
the
use
cases
that
wesley
and
roy
have
mentioned,
because
it's
safe
for
the
server
to
update
it
over
time
and
that
can
always
be
allowed.
And
at
that
point
the
generic
mechanism
makes
sense
to
me.
But
I
I
haven't
thought
about
that.
A
Awesome,
so
did
we
want
to
look
at
the
updates
then
to
the
rc
130
838
yeah,
and
did
you
want
to
give
a
quick
synopsis?
I
guess
mark
of
the
updates
you
made.
C
Sure
yeah,
so
I
mean
there
wasn't
an
awful
lot
of
changes
really
other
than
previously.
It
was
making
use
of
the
package.json
to
store
the
header
information
that'll
be
sent
in
the
http
header
requests.
It
was
asked
to
make
that
change
to
the
npm
rc
file
that
could
be
either
a
the
global
mpmrc
or
project
local
mbmrc
file
as
well.
A
A
Sorry,
I'm
just
taking
notes
here
as
well.
Did
anybody
have
any
thoughts
on
this
or
any
other
feedback?
If
you've
had
a
chance
to
look
at
it?
Christian.
F
I
am
not
sure
this
just
came
to
the
top
of
my
head,
so
I'm
not
sure
if
this
is
a
valid
point.
What
I'm
thinking
is
like
do
you
always
want
to
have
a
field
in
package.json,
or
might
there
be
use
cases
where
you
just
would
want
to
have
something
like
dash
dash
headers
and
it
would
only
be
sent
once
or
only
if
you
run
a
certain
script
or
whatever.
C
So
for
our
particular
use
case,
it's
really
for
the
npm
audit,
so
it
only
really.
We
only
really
need
it
specified
for
an
npm
audit
itself,
the
the
app
id
in
particular
so
yeah.
So
it
doesn't
really
need
to
go
with
every
request,
but
throughout.
C
A
F
Yeah,
sorry,
I
I
don't
know
the
the
kind
of
point
that
I'm
making
or
trying
to
make
is.
Actually
we
use
the
nexus
repository
at
work,
and
I
could
see
some
kind
of
functionality
where
we
would
be
able
to
like
move
something
that
is
tacked
into
a
specific
folder
within
the
nexus
repository
to
get
rid
of
them
at
some
point
because
they're
like
snapshots
so,
but
this
would
probably
be
something
that
we
would
be
doing
through
the
command
line
and
not
through
npm
rc
configuration.
A
Yeah,
so
you
should
be
able
to
set
them
via
through,
like
the
command
line
for
sure.
I
think
we
had
an
example
of
that
in
the
yeah.
A
Yeah,
it's
line
44
yeah,
so
additional
configuration
yeah
yeah.
I
think
this.
These
updates
reflect
everything
we
chat
about
in
the
last
call
for
sure.
I'm
I'm
personally,
not
you
know
in
favor
of
sort
of
how
it's
specced
out
need
to
read
the
language
for
sure
and
and
yeah
did
anybody
have
any
reservations
about
this?
Our
thoughts.
A
If
not,
we
can
move
on
and
just
ask
folks
to
add
comments
over
the
next
week
or
so.
But
I
think
if
this
comes
up
again
next
week,
we
probably
can
ratify
it.
If
there's
no,
no
push
back
and
yeah
and
it's
definitely
something
that's
pretty.
I
think
pretty
easy
to
support
mark,
I'm
not
sure
if
you
and
your
team
actually
have
time
to
contribute
back
actual
code,
but
this
is
a
potential
opportunity
for
sure
to
land.
C
Switch
back,
I
can
try
and
take
a
look
at
that
yeah.
We
have
improvement
days
every
two
weeks,
so
I
can
try
and
make
that
part
of
the
improvement
day
that
that
would.
A
Be
awesome,
cool
cool,
moving
on
to
pr
number
232
npm
audit
for
a
not
installed
not
yet
installed
package.
So
christian,
this
is
your
pr.
Did
you
want
to
give
a
quick
update.
F
Yeah,
this
is
basically
just
an
rfc
coming
from
the
issue
that
we
discussed
last
week,
so
the
idea
is
to
add
npm
audit
information
to
npm
view.
F
Roy
did
actually
mention
that
this
should
be
opt
out
so
that
you
always
get
the
information.
I
honestly
don't
have
any
opinions
on
that.
So,
if
anyone
has
any
opinions
on
that,
please
share
them.
B
Yeah,
so,
basically,
is
that,
just
in
my
point
of
view,
the
the
choice
we
already
we
we
have
today
in
the
decline.
It
is
to
do
the
audit
when
installing
right.
So
I
would
expect
that
to
be
the
default
behavior.
Also
when
reaching
out
for
view,
because
it's
kind
of
like
I
wanna
to
just
basically
fetch
the
all
the
information
for
that
package
right.
B
E
Json
data-
the
yes,
it's
not
defaulting
to
showing
that,
but
you
can
do
npm
view
package
dependencies
and
it
shows
you
the
dependencies
field
of
the
json
right,
like
that's
just
the
way
that
that
command
works
with
or
without
the
json.
So,
if
you're
going
to
include
audit
data,
it
would
have
to
be
included
in
the
json
in
some
form
which
it
I
don't
think
there
is
a
canonical
form
for
that
anywhere.
Yet
I'm
sure
the
client
uses
one
but
like
there's,
not
one
that
users
ever
see
and
then.
A
Well,
we
do
have
update
maintainers.
Those
are
you
know
that
is
mutable
data,
there's
fashion
mutable
data
in
the
document
right
so
yeah.
There
is
a
precedent
for
having
let's
say:
yeah.
E
And
if
so,
if
you
want
to
add
it
in
there,
that's
fine,
because
then
it's
not
computing
it
on
every
call.
It's
it's
pre-computing
it
and
it's
just
part
of
the
json
right
but
sure,
but
that
would
be
a
much
larger
change
on
the
registry
side.
B
B
A
B
So
the
thing
is
that
I
think
jordan
has
a
very
special
view
in
which
even
I,
before
joining
the
team,
I
never
saw
commands
such
as
npm
view
as,
like
the
direct
connection
right
to
pacument,
etc.
Right,
I
do
see
it
from
the
point
of
you
know,
user
view,
point
of
view
I'm
just
like.
I
think
it
also
has
an
npm
show
alliance
to
it.
So,
yes
yeah,
I
don't
think
about
you,
know
the
relationship
of
the
internals,
like
I'm
just.
B
E
Mean
the
things
just
to
be
clear,
the
things
I
use
it
most
often
for
is
the
is.
I
should
use
it
with
time
or
with
versions,
because
I
want
to
know
when
a
version
was
published
or
what
versions
are
available
when
a
version
is
published
is
how
I
figure
out
did
a
publish
of
a
package
break
me
and
when
what
date
can
I
install
dash
dash
before
to
to
get
it
working
again
like
so
it's
for
stuff?
That's
not
actually
in
the
package
json,
it's
in
the
pack
event.
B
B
E
Right,
yeah,
the
the
turning
save
on
by
default
messed
with
our
shrink,
wrap
scripted
airbnb
a
couple
years
ago
for
the
same
reason.
So,
like
that's
a
separate
problem
that
would
be
great
to
solve,
but
until
that's
solved.
I
think
we
should
all
be
very
careful
about
adding
about
adding
a
existing
config
flag
to
a
new
sub
command.
D
So
here's
here's
my
concern
there.
My
point
that
I
see
of
this
pr
is
stop
before
I
install
stop
me.
I
want
you
to
stop
me
before
I
install
right
like
and
if
we
put
it
in
view,
then
we
have
to
go,
tell
everybody
you
cannot
run
npm
install.
You
have
to
run
npm
view
and
and
npm
install
every
time.
Otherwise
you
are
not
getting
the
benefit
that
I
would
hope
to
see
right,
which
is
don't
don't
pull
down
anything
other
than
the
pacument.
A
F
So
I
do
feel
you
west.
I
think
this
is.
I
don't
know.
This
is
definitely
also
an
issue
at
some
point
that
needs
to
be
tackled.
However,
I'm
just
I'm
just
trying
to
address
the
information
bottom
like
that.
Is
there
at
the
moment
the
information
gap,
because
you
don't
even
there's
no
way
for
you
to
even
know.
What's
going
to
happen
unless
you
install.
F
F
Would
I
be
even
aware
that
npm
view
exists
and
would
I
would
I
find
the
or
would
I
go
there
and
try
to
figure
that
out
because,
like
is
there
any
logical
connection
for
for
someone
who's
just
trying
to
who's
used
to
using
npm
audit?
That's
kind
of
the
concern
that
I'm
wanting
to
raise.
A
A
bit
sure
mark
I
saw
you
had
your
hand
up.
Did
you
want
to
try
my
nano.
C
C
I
think
people
might
not
notice
that
that's
additional
information
you
now
get
sure,
but
I
I
understand,
I
think
from
last
week's
conversation
that
the
order
can't
be
done,
so
I
think
that
will
fetch
everything
down
already,
so
it's
kind
of
a
bit
late.
At
that
point,
I
think
that
was
the
reasoning
last
week
on
discussion.
A
C
B
A
Like
npm
model
would
take
a
net
new
argument,
which
would
be
the
package
so
it'd
either
be
fix,
which
we'd
have
to
be
mindful
since
fix
is
not
not
a
flag
fix,
is
actually
an
yeah
like
a
command.
D
So
I
think,
there's
there's
two
there's
two
use
cases
here:
we're
sort
of
mixing
together
and
one
is
better
surfacing
of
audit
things
in
other
workflows
like
I
want
to
do
a
separate
workflow
that
lets
me
look
at
something
before
I
take
the
action
to
install
and
then
there's
the
I'm
installing
I
ran
a
command
that
should
install,
but
somehow
the
the
you
know
we
should
determine
before
we
pull
the
package
down
that.
Actually,
maybe
we
should
warn
them
and
say
you're
about
to
install
something
that
has
a
known.
B
Yeah
yeah
yeah
yeah.
So
to
your
point
I
do
think
for
point
number.
Two
last
I
was
I
heard
from
isaac
and
we
were
parrying
on
the
new
new
audit
stuff
for
v7.
B
We
try
to
skip
it
with
taking
into
account
when
building
the
ideal
tree
from
the
first
time.
So
that
would
be
something
like
useful
for
tackling
the
addressing
number
two
right
from
what
you
said:
yeah
you
have
docs
on
that.
I
didn't
know
that
it
was
that's
like.
B
Wants
to
write
a
blog
post
dedicated
just
to
the
new
audit
mechanism
that
he
built
for
v7.
So
that's
probably.
D
B
F
So
I
don't-
I
don't
know
how
you
feel
about
this,
but
the
way
I
feel
about
it
is
that
if
you
put
this
on
the
website,
then
that
would
be
a
bit
of
a
blame
game.
I
think
that
would
put
a
lot
of
pressure
on
developers.
F
But
I
I
I'm
not
sure
if
I
would
imagine
that
would
be
pushed
back
to
that
concerning
adding
it
to
npm
audit.
I
think
that
would
also
not
be
what
we
want,
probably
because
that
would
not
allow
you
to
limit
the
output
of
npm
audit
to
a
locally
installed
package
in
a
way.
So
what
I'm
just
thinking
now
is
what,
if
we
had
another
new
command
called
npm
advisory,
and
it
would
be
totally
reasonable
that
it
would
always
fetch
the
advisory
from
the
npm
registry
or
npm
audit
endpoint.
A
I'd
have
to
think
about
that
a
bit
more.
I
kind
of
want
to
circle
back
just
to
be
mindful
of
time
here,
because
we
only
have
about
13
minutes
and
we
spent
a
lot
of
time
on
this.
I
did
want
to
note
that
this
has
come
like
the
initial
rfc,
that
and
and
the
changes
that
you've
made
as
well
christian
like
based
on
the
conversations
we
had
about
this
before
do
still
seem
to
make
sense
to
me.
A
We've
come
into
this
discussion.
I
think,
because
of
the
audit,
by
default
on
npm
view.
I
think
that
there
might
be
another
way
to
look
at
this
and
another
like
one
small
change
we
could
make
to
the
rfc,
which
is
you
added
the
audit
audit
flag?
Maybe
we
just
changed
that
name,
it's
like
with
audit,
or
something
like
that.
So
it's
like
adding
supplemental
information
to
npm
view.
A
So
again
we
get
away
from
the
concept
of
trying
to
slow
things
down
or
trying
to
get
information,
but
we
start
to
tack
on
essentially
supplemental
metadata
to
that
npm
view
output.
I
think
that
would
maybe
change
how
we're
looking
at
this
and
slicing.
This
conversation
because
it
seems
like
we're
kind
of
going
in
circles
as
far
as
where
this
should
live,
I
think,
as
a
as
an
end
user.
I
think
it
should
live
in
view.
A
It's
just
that
that
information
isn't
going
to
be
there
by
default,
and
so
potentially
you
know
creating
some
sort
of
like
flag
that
tacks
on
that
extra
call,
then,
is
you
opting
into
getting.
A
Version
it
has
completely
different
functionality
right,
like
you're,.
E
Talking
about
well
npm
audit
is
saying
to
me
what
npm
install
is
saying
it's
if
I
don't
provide
a
specifier.
It's
saying
like
tell
me
the
audit
warnings
for
my
current
project
with
install.
If
I
then
do
provide
a
specifier,
I'm
saying
go,
reach
out
and
do
the
action
on
that
package
version.
So
if
I
say
npm
audit
package
at
version,
why
would
that
not
be
intuitively
auditing?
That
package
version
that
I
spent
that
I
indicated.
E
B
E
A
A
F
Yeah,
I
think
isaac
actually
brought
this
up
and
said
that
it
would
be
more
work,
but
it
would
be
worth
it,
and
I
completely
agree
with
that,
because
I
agree
with
jordan
here.
Otherwise
it
would
be
pretty
much
useless.
D
I'd
like
to
push
back
on
pretty
much
useless,
I
think
you
both
said,
but
it's
just
not.
I
there
are
so
many
times
where
what's
really
being
reported
here
is
just
wrong
because
it's
transitive
and
we're
not
doing
static
analysis
to
tell
whether
it
actually
applies.
This
is
the
whole
reason
why
we're
talking
about
letting
package
authors
block
the
propagation
of
those
being
reported,
and
I
think
that
we
could
start
by
not
reporting
them,
which
would
give
people
a
cleaner
set
of
things
and
they
they'd
know.
Oh
yeah.
D
No,
I
specifically
know
I'm
using
this
package
and
I
should
look
to
see
if
this
cve
is
going
to
be
affecting
my
usage
of
it.
It's
much
harder
to
do
when
you
go
and
do
the
whole
tree,
and
so
I
think
there
is
value
in
in
adding
this
without
that,
because
then
I
can
be
as
a
package
maintainer
very
critical
of
my
direct
depths
in
a
way
that
I
don't
have
to
go
dig
through
the
likes
noise,
which
happens
today
on
any
given
package
right
because
of
the
transitives.
A
E
But
npm
install
sends
up
oh
you're,
saying
npm
install
sends
out
the
lock
file.
A
A
E
Lock
file
that
does
that
it
puts
installs
your
package
in
a
temporary
directory
and
generates
a
temporary
log
file
for
the
sole
purpose
of
it
doesn't
even
install
the
files
it
uses
lock
file
only
or
whatever,
and
so
for
the
purpose
of
running
an
audit.
In
my,
I
have
a
package
called
odd
aud
for
that
purpose,
and
it's
existence.
D
E
Yes,
fair
those
have
been
needed
for
a
long
time
and
promised
at
the
time
npm
audit
was
created
and
never
delivered,
but
that's
a
separate
conversation.
The
the.
What
I
mean,
though,
is
that
it's
actually
fast
for
an
unknown
package
version
to
just
create
a
lock
file.
A
Okay,
I
think
there's
more
to
expand
on
here
for
sure,
and
I
we've
only
got
about
five
minutes
left
and
I
know
roy
specifically
added
a
few
more
of
these
bullet
points,
but
based
on
this
feedback
and
I'm
going
to
write
some
more
notes
when
I
get
a
chance
here,
please
please
add
comments
into
the
rfc
itself
and
it
sounds
like
there's
some
more
to
talk
about
here.
A
So
moving
on
to
the
next
item
we
had,
which
was
add,
strict
peer
depths,
so
the
override
eresolve-
if
not
true,
this
was
by
isaac
who
wasn't
able
to
make
the
call
today-
and
this
was
essentially
just
a
shout
out
to
landing
this
work
in
arborist
roy-
did
you
have
more
contacts?
Maybe
you
could
provide.
B
Well,
not
sure.
Well,
I
mean
yes,
I
remember
now
pure
dependency
change
right,
so
basically
what
we,
the
behavior
we
had
before
when
you
would
then
become
installed,
dash
dash
force,
and
it
would
try
its
best
to
install
valid
peer
dependencies
into
your
project.
Basically,
it
takes.
B
If
I
remember
the
algorithm
correctly,
it
just
takes
the
the
one
at
the
top,
the
higher
up
the
period
dependency
declared
as
as
the
one
that
counts,
so
basically
anyone
that
has,
if
you're
just
using
react
and
within
your
install
tree,
you
have
pure
depth
in
react
everywhere.
Well,
if
you
declare
the
top-level
react,
it's
going
to
use
that
anyway.
So
that
was
the
behavior
for
force.
B
A
I
know
jordan,
you
had
chimed
in
on
that
conversation
or
on
that
issue,
but
I
didn't
know
if
there
was
anything
else.
You
want
to
add
sorry
remind
me
which
one
I
was
busy.
I.
E
E
B
E
E
I
think
that
that
there
are
tons,
because
npm
has
never
done
that,
and
the
vast
majority
of
projects
never
even
never
run
npm
ls
nci,
for
example,
that
happens
a
lot
where
they
end
up
having
things
that
just
are
supposed
to
be
incompatible
and
they
just
run
it
and
don't
realize,
there's
bugs
the
counter
argument
that
was
given
was
essentially
well,
because
there
are
so
many
people
like
who
do
this
wrong
for
primarily
like
and
isaac
wasn't
even
talking
about
consumers
who
definitely
do
it
wrong,
but
like
they
can
fix
it,
but
talking
about
package
maintainers
who
may
do
it
wrong,
then
it's
that
a
lot
of
users
could
be
affected
and
won't
be
able
to
fix
it.
E
And
while
that
is
true,
if
the
maintainers
are
still
doing
it
wrong
at
this
point.
In
my
experience,
having
yelled
at
hundreds
of
maintainers
for
doing
pure
depths
wrong
over
the
years,
they
just
actually
don't
know
what's
right
and
as
soon
as
they're
told
what's
right,
they
fix
it.
E
They're
not
opinionated
about
the
way
they're
doing
it,
they're.
Just
it's
just
that
pure
depths
are
confusing
and
hard,
and
it's
really
easy
to
screw
them
up
and
everybody
does
it
and
like
so
it's
just
about
evangelism
right,
meaning
a
problem
has
to
be
surfaced
in
their
user
base
before
they
can
learn
how
to
fix
it
by
not
failing
by
like
not
doing
strict
peer
devs
by
default
and
npm
7.
E
B
It's
just
that
the
counterpoint
is
what
that
the
compromise
here
is
that
now
we
have
this,
this
big
block
like
really
hard
to
miss
explaining
where
the
conflict
is
right.
So,
instead
of
that
being
an
error
and
just
ending
with
code,
one
right
when
your
script
fails,
it
is
going
to
pass.
It
is
going
to
do
its
best
to
actually
install
all
your
dependencies
and
you're
gonna.
Have
that
big
block
of
warning
for
npm
seven?
B
So
the
compromise
is
maybe
to
try
to
flip
the
switch
for
and
can
eight
so
so
that
the
ecosystem
has
the
time
to
catch
up
right,
like
people
start
seeing
these
big
warning
blocks
right
in
this
tech
start
acting
on
it.
So,
and
I
think
if
at
least
we
have
the
big
players
right,
big
frameworks,
tooling
people
are
using
fixing
their
problems.
Then
we're
gonna
be
comfortable
in
turning
that
switch
for
npm
8.
E
E
If
it's
not
like
scary
and
tells
people
to
go
bother
maintainers,
then
I
think
people
will
just
ignore
it,
and
my
experience,
like
node
spent
five
years,
saying
a
message
that
unhandled
promise
rejections
were
gonna
break,
and
you
know
aside
separate
from
my
opinion
on
on
whether
they
should
or
not
the
fact
that
they
didn't
change
that
message
or
make
them
break
for
so
long
means
that
everyone
just
ignored
the
warning.
So
now
in
node
15.
E
The
likelihood
is
that
a
bunch
of
code
is
going
to
break
because
people
ignored
the
warning
for
so
long.
So,
similarly,
like
I
don't
know
how
long
it'll
take
npm
7
took
a
while
to
come
out.
I
don't
know
how
long
it'll
take
for
npm8
to
come
out,
but
if,
if
it's
coming
out
relatively
soon-ish,
and
if
the
warning
like
it
accurately
predicts
that
you
will
not
be
able
to
install
anything
unless
this
is
fixed
later
like
and
then
npm
follow
through
like.
E
If
all
those
things
happen,
then
I
think
that
that's
a
potentially
reasonable
compromise.
You
know
the
the
other
thing
I
suggested
isaac
that
I
don't
think
got
responded
too
much
was.
It
would
be
really
nice
if,
when
installing,
if
you're
like,
when
created
like
when
installing,
if
your
package
would
pass
on
strict
pure
depths,
stick
a
flag
in
the
lock
file
and
then
use
strict,
pure
depth
from
then
on.
E
In
other
words,
use
it
more
as
a
stop
the
bleeding
command
meaning
once
your
graph
is
valid,
it
will
never
be
invalid
again
without
you
knowing
it,
because
it
will
fail
the
install.
But
if
it's
currently
invalid,
the
first
time
you
run
npm
install
on
it.
Okay,
we
won't
be
jerks
and
like
break
you
we'll
we'll
give
you
the
big
warning
and
show
you
you
know
and
tell
you
that
this
will
be
scary.
E
Later,
in
that
case,
at
least,
that
would
that
would
help
new
projects,
and
that
would
help
projects
that
haven't
yet
run
into
this
bug
avoid
running
into
it.
Is
that
something
that
would
be
possible,
or
does
that
seem
too
magic.
B
That
definitely
sounds
good
to
me,
but
I
yeah,
I
think,
maybe
opening
an
rfc
and
like
discussing
it.
B
E
D
D
D
In
the
end
of
the
day,
these
problems
are
just
going
to
still
crop
up
like
quite
a
bit,
and
I
don't
think
saying
it's
going
to
break
in
some
for
unforeseen
release
date
of
npm.
Eight
is
necessarily
gonna
like
be
the
lighting
the
fire
under
people
that
you
might
think
it
would
so.
B
E
A
So
we're
about
almost
five
minutes
over
time,
so
I
just
want
to
be
mindful
of
that.
I
apologize.
There
was
a
another
two
or
three
items
I
think
we
didn't
get
to
today,
but
hopefully
we
can
follow
up
and
the
threads
themselves
specifically,
I
think
the
mpx
discussion
which
we'll
bring
up
next
week
in
the
call
just
about
the
future
of
that
but
yeah.
A
I
appreciate
everybody
jumping
on
today
and
for
the
good
discussion
and
I'll
follow
up
with
the
notes
and
posting
those
online
just
after
this,
hopefully
see
you
all
next
week,
ciao.
Thank
you.