►
From YouTube: Open RFC Meeting - Wednesday, Sept 16th 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
A
And
we're
live,
welcome
everyone
to
another
fpm
openrc
meeting.
Today's
date
is
wednesday
september.
The
16th
we'll
be
following
along
being
the
agenda
issue
that
was
number
231
in
the
npm
rfc
repo
and
I'll
copy
and
paste
just
for
everybody
everybody's
sake,
as
I
usually
do
spam.
A
The
link
to
the
meeting
notes
feel
free
to
add
yourself
as
an
attendee
and
we'll
be
following
along
the
agenda
there,
just
a
quick
heads
up
and
and
notice
these
calls
and
all
communication
on
the
rc's
repo
and
then
most
of
the
npm
repos
is
covered
by
a
code
of
conduct.
The
the
gist
here
is
that
we
just
ask
you
to
be
respectful
of
each
other
and
each
other's
time,
and
and
to
please
raise
your
hand
if
folks
are
speaking
you'd
like
to
add
a
comment.
A
The
desired
outcomes
of
these
calls
are
to
give
another
channel
and
another
means
of
communicating
with
the
community
and
hopefully
pushing
forward
initiatives
and
features
in
the
projects
and
sourcing
feedback
as
well.
A
couple
quick
announcements,
roy,
I
think
you
have
one
something
you
did
this.
A
And
I
think
we'll
have
a
blog
post
in
a
little
bit
here
on
that
as
well,
and
I
wanted
to
give
the
floor
to
anybody
else
if
they
had
any
other
announcements.
A
If
not,
I'd
love
to
do
a
couple,
quick
introductions
or
or
essentially
allow
some
folks
that
introduce
themselves
through
having
to
be
on
the
call
or
in
the
wall
or
before
maybe
nathan,
we
can
start
with
you.
You
can
say
hi
what
you're
you're
up
to
and
what
you've
been
doing
at
npm
and
what
you're
going
to
be
doing
in
the
future.
C
Sure
hi,
I
am
nathan
lafreniere
and
nelf
as
I'm
widely
known
on
the
internet.
For
the
most
part
I
am.
I
was
the
chief
architect
for
the
registry
for
quite
a
while
and
spent
most
of
my
time
working
there
and
I'm
now
transitioning
to
the
cli
side
of
things
just
started
this
week.
So
don't
really
have
a
firm
grasp
on
what
I'm
doing
quite
yet.
But
I'm
looking
forward
to
working
with
everybody.
A
You've
been
doing
a
lot
of
the
hard
work
behind
the
scenes,
so
it's
great
to
have
you
working
with
us,
and
so
you
should
be
seeing
a
lot
more
nathan
and
these
calls
nick,
I
don't
think,
we've
seen
you
in
a
while.
Like
did
you
want
to
say
quickly,
say:
hi
introduce
yourself
what
you're
up
to
yeah
yeah
yeah
yeah.
E
Something
about
20
minutes
ago
about
a
meeting
starting
live,
and
I
I
got
sick
of
listening
to
my
spotify
playlist
and
so
I've
replaced
that
chatter
with
yours.
So
thanks
for
including
me
as
a
part
of
your
community
rock
on
everybody,.
A
100,
that's
what
the
call
is
about.
We
appreciate
folks
dripping
on
brian.
Did
you
want
to
quickly
maybe
say
hi
what
you've
been
up
to
at
npm,
and
you
know
what
you're
going
to
be
doing
in
the
future
here.
F
Yeah
hi,
I'm
brian
jenkins,
I've
been
at
npm
for
just
over
two
years.
I
managed
the
back
end
team.
For
most
of
that
now
I
am
coming
back
to
engineering
and
I'll,
be
I'm
just
joined
the
cli
team
a
couple
days
ago.
So
I'm
excited
to
be
on
this
part
of
the
project.
A
F
A
Nathan
and
brian
will
be
helping
us
out
for
folks
that
have
been
on
the
call
on
these
calls
for
a
while.
Now,
it's
great
to
have
some
more
some
more
people
to
support.
You
know
the
the
work
we've
gotten
progress,
so
I
think
mark
also
like
you
joined
last
week,
we've
been
following
along
for
a
while.
We
finally
got
your
issue
on
the
agenda
for
today
that
you'd
be
poking
us
about.
Did
you
want
to
just
say
hi
and
what
you're
up
to.
G
Sure
yeah,
I'm
mark
I'm
a
software
developer
over
at
the
summer
type.
Those
who
don't
know
sonotype
are
responsible
for
the
nexus
repository
manager,
nexus
iq
and
the
likes
so
yeah,
that's
about
it.
Yeah.
A
Yeah
so
we'll
finally
circle
back
on
an
old
rfc
that
I
know
that
you've
been
watching.
So
I
think
christian
and
roy
and
myself
isaac
west
jordan-
are
pretty
we've
been
here
for
a
while.
So
I'm
not
sure
if
we
have
to
do
intros,
but
yeah
it'd
be
great.
If
we
can
dig
in
here,
if
you
haven't
already
run
for
for
yourself,
you
can
add
yourself
to
the
list
of
attendees
in
this
hackmd
dock.
A
So
it's
a
shared
dock
that
we
keep
notes
in
and
we'll
be
following,
along
with
the
items
that
essentially
were
chosen
for
for
this
agenda,
so
the
first
of
which
is,
I
wanted
to
at
least
shine
some
light
and
talk
a
bit
about
rc
224,
so
no
auto
install
for
pure
depths
that
are
marked
as
optional.
Essentially,
I
don't
think
this.
There
was
any
and
I
can
copy
and
paste.
H
You
can,
if
you
want
no,
no.
I
was
just.
I
was
just
honored
that
you
said
that
I'm
a
regular.
So
oh
well,
that's
about
it.
A
That's
great,
so
I
copy
and
pasted
the
the
pr
here.
This
is
something
that
we've
identified
as
requiring
to
land
before
we
essentially
ship
at
ga
of
mpm7,
and
I
think
this
is
something
that
we're
queuing
up
for.
You
know
sort
of
the
next
task
to
take
on,
as
I'm
not
sure
if
you
had
anything
else,
you
want
to
add
there
beyond
that.
I
There
is
a
little
bit
of
subtlety
in
in
the
fact
that,
if,
if
a
pure
depth
will
cause,
if
not
installing
it
will
cause
an
incorrect
one
to
be
resolved,
then
we
do
need
to
and
try
to
install
it
or
else
we'll
end
up
with
an
incorrect
tree
in
some
cases.
So
optional
is
basically
either
it
has
to
be
within
this
range
or
it
has
to
be
missing.
I
If
we
want
to
say
that
pure
optional
is
we're
just
not
going
to
install
it,
we're
going
to
accept
whatever
then
that's
somewhat
of
a
divergence
from
sort
of
optional
semantics,
which
you
know
is
a
lot
easier
to
do.
But
at
that
point
it's
just
sort
of
a
little
bit
more
risky
to
go
forward
with.
A
Yeah,
I'm
not
sure
if
anybody
had
any
other
feedback.
There
hasn't
been
any
pushback
on
supporting
this,
so
in
the
calls
that
we've
had
and
also
the
the
rc
that
jeremy's
put
together
so
yeah,
it
looks
like
it
should
be
something
that
we
can
ratify.
Potentially
then,
as
it's
written
now
like,
is
there
any
qualms
with
us
now.
A
Okay,
that's
good
yeah.
I
think
we
just
kept
it
open
for
the
extra
week
in
case
since
it
was
issued.
B
Alternative
here
I
noticed
that
the
the
in
the
rfc
itself,
as
it's
open
now,
the
the
pr
there
is
still
a
couple
of
unresolved
questions
there
at
least
maybe
like
if
they're
all,
if
they're
all
resolved,
we
should
get
rid
of
them
before
merging.
B
A
At
exactly
what
those
unresolved
are,
questions
are
they're
towards
the
bottom
here
I'll
look
for
folks,
and
just
so
you
don't
go
looking
it's
a
good
thing
to
know.
Right
for
sure,
like
you
know,
is
the
best
option
should
auto
install
false,
be
implemented.
Instead,
I
don't
think
that's
necessary.
A
What
is
that,
like
a
double
negative
like
it,
doesn't
feel
it
doesn't
feel
good
to
write
as
an
api?
It
doesn't
feel
good
to
set
as
a
config.
So
I
think
that
you
know
optional
true,
like
if
we
respect
that
that
makes
a
lot
of
sense
to
me
so
that
question
personally,
like
that
question,
I
think,
is
resolved
just
by
you
know
supporting
optional,
true,
the
second
of
which
we
can
definitely
poke
other
folks
and
and
definitely
jeremy's
done,
that
by
by
ceasing
mile
and.
A
Yeah,
I
always
forget
exactly
how
you
say
his
name
yeah,
that
this
is
you
know,
there's
an
opportunity
here
to
to
have
them
also
support
this
so,
but
I
don't
think
it
should
be
a
blocker
for
us
to
accept
and
then
move
forward,
the
last
of
which
can
a
solution
be
implemented
before
v7
is
final.
That's
that
should
be
the
case,
so
we
should
have
this
out
in
a
beta
and
or
release
candidate
before
it's
essentially
ga.
So
that's
that's
something
that
also
we
can
speak
to
so.
I
To
that
to
that
second,
to
last
point,
I
don't
think
it's
going
to
be
a
challenge
for
pnpm
and
and
yarn
to
implement
not
installing
optional
pure
depth,
since
they
don't
install
pure
depth
at
all
right.
It's
it's.
A
But
yeah,
that's
that's
a
good
thing
to
point
out.
They
already
support
it.
So
it's
great
it's
a
feature
cool,
so.
A
Essentially,
resolves
that
what
good
what
would
be
good
is
essentially
to
comment
back,
and
I
can
take
the
action
unless
somebody
else
wants
to
from
just
essentially
referencing
the
the
meeting
notes
and
the
comments
made
here.
A
Okay
thanks,
if
there's
nothing
else
on
that
item,
then
we
can
move
on
to
the
rc
217,
so
adding
the
registry
per
package
per
organization
support.
A
A
I
think
to
essentially
to
summarize
this
is
to
to
have
per
package
scoped
registry
configuration
capabilities,
and
I
think
this
was
something
that
we
we
thought
was.
You
know
something
acceptable.
What
might
be
good
to
discuss
is
whether
or
not
we
actually
think
this
is
a
breaking
change.
I
know
offline.
Might
I've
talked,
I
think,
with
isaac
about
this
and
some
other
folks
that
I
don't
necessarily
think
it's
a
breaking
change,
but
we
can.
We
can
potentially
talk
about
that
or
if
anybody
has
any
thoughts
on
that.
I
Yeah,
you
actually
convinced
me
in
that
last
conversation,
I
I
don't.
I
don't.
I
walk
back
from
that
position.
I
don't
think
it
is
a
breaking
change.
We
can
get
it
into
in
a
minor
just
fine
if
it
was.
You
know,
because
it's
limited
to
the
configs
in
a
given
project
like
there's,
there's
no
chance
that
it's
going
to
get
out
in
the
wild
and
something's
not
going
to
install
unless
you
have
it
or
whatever
it's
it's
sort
of
scoped
to
the
project
and
it's
just
adding
a
feature.
A
Is
this
another
one
that
it's
been
opened
for
a
couple
weeks
and
there
was
an
issue
corresponding
issue
open
before
that?
Is
this
something
we
want
to
ratify
after
this
call.
I
Yeah
fine
by
me,
I
think
I
posted
a
link
in
there
to
where,
in
the
code
the
change
would
be
made
and
it's
pretty
straightforward.
G
Is
is
this
part
of
the
configuration,
or
is
this
going
to
be
somehow
in
the
like
the
package.json
file,
it'll.
I
Be
in
the
configuration
so
in
the
same
in
the
same
way
that
you
can
do
at
scopes.
Colon
registry
equals
my
private
registry.
Okay,
you'll
be
able
to
do
at
scope
forward,
slash
package,
name
colon
registry
in
your
config,
understood;
okay,
so
that's
and
that's
what
makes
it
a
non-breaking
change,
because
you
know
it's
not
it's
not
a
change
to
package,
json
or
or
something
else.
That's
not
going
to
be
installable
with
v6
yeah.
Okay,
thanks.
A
Anybody
else
have
any
other
questions,
no
awesome,
so
those
are
two
the
two
sort
of
easy
rc's.
I
thought
that
obviously
we
could
get
a
bit
of
contestants
around
moving
forward
with
the
next
would
be
195,
so
the
rfc
round
for
for
checking
engine
requirements
on
every
install
and
I'll
link.
That
here
for
folks.
A
And
the
last
person
to
actually
I
think,
comment
on
this
was
jordan,
so
I
know
jordan's
in
and
out
today.
Yeah
did
you
want
to
maybe
comment
on
this
or
give
like
a
brief
summary
on
this?
I
think
the
last
time
we
talked
about
it,
we
we
kind
of
forget
where
we
landed
actually.
J
Yeah
I
mean
I
can
give
the
same
summary
I
gave
last
time,
which
is
basically
that-
and
I
think
it's
roughly
where
we
agreed
on,
which
is
that,
hopefully,
by
default
engines,
are
a
warning
like
engine
mismatches.
Are
a
warning,
not
a
not
a
failure
and
engine
strict
turns
it
into
a
failure.
In
either
case
there
should
be
appropriate
warning
output.
J
That
tells
you
that
there's
an
engine
mismatch
and
that
if
there
is
a
way,
even
if
it's
an
imperfect
or
imprecise
way
to
store
information
in
the
lock
file,
so
that
installs
that
don't
change
the
lock
file
or
the
you
know,
or
they
don't
change,
node
modules
or
whatever
can
recheck
those
things.
J
Then
that
would
be
really
helpful
so
that,
if
I
make
a
project
on
like
node,
12
and
switch
to
node,
14
or
something,
and
that
doesn't
work
that
I
shouldn't
have
to
like
rim,
rap
node
modules
or
regenerate
my
lock
file
or
whatever
in
order
to
determine
that
I
should
just
type
npm
install
like.
I
would
always
do
and
get
some
sort
of
message.
That
tells
me
this
actually
was
meant
to
work.
On
note
12.
It's
note
14.
I
But
yeah
it's
it's
essentially
just
sort
of
shuffling
around
some
some
code
that
exists
now
where
we
currently
only
check
engines
that
are
for
packages
that
are
being
installed,
and
this
would
be
go
ahead
and
check
all
the
engines
for
all
the
packages
in
the
tree.
I
You
know
we
we
build
that
tree
anyway,
so
we're
we're
already
kind
of
walking
over
them.
It's
just
a
matter
of
kind
of
moving
the
moving
where
that,
where
that
check
is
being
done.
I
Yeah,
there's
nothing,
there's
nothing
in
the
proposal.
That's
changing
what
the
default
behavior
is
in
terms
of
you
know,
making
it
strict
by
default
or
whatever.
There
was
some
back
and
forth
on
that
in
the
in
the
discussion,
but
where
we
landed
was
we're
still
going
to
have
it
be
a
warning
by
default?
It's
just
do
we
want
on
the
whole
tree
or
only
the
things
we're
actively
installing,
and
this
seems
reasonable.
We
can
accept
this.
I
Also,
I
don't
I
don't
know.
I
mean
this
is
sort
of
a
breaking-ish
change,
but
it
feels
pretty
low
risk.
We,
we
probably
ought
to
get
it
in
prior
to
seven
zero,
zero
ga,
because
because
it
will
change
the
the
error
and
warning
output.
A
Okay,
but
other
than
that,
we
think
that's
good
good
enough
and
we
can
accept
it
then
and
move
on
moving
on
then
to
pr
number
138,
the
rc
add
mpm
app
id
to
the
http
header
and
mark
apologize
that
we've.
We
did
get
this
on
for
the.
A
While
our
circle
back
to
this,
would
you
like
to
maybe
summarize
the
the
rfc
itself
and
then
sort
of
what
updates
your
you'd
like
to
like
to
give
or
sort
of
what
the
next
steps
would
look
like.
G
Yeah
sure
so
when
this
was
initially
proposed
actually
by
a
colleague
of
mine,
we
were
focusing
it
wasn't
very
generic,
so
we
were
focusing
on.
We
need
an
application
id
to
help
us
do
audits
that
are
particular
to
different
policies
have
been
defined
in
our
third
third-party
scanner.
G
Last
time
it
was
raised,
it
was
felt
that
this
could
be
a
little
bit
more
generic,
rather
than
being
focused
on
app
id.
So,
although
the
title
is
app
id
last,
we
spoke
it
was
wanting
to
be
generalized,
so
the
proposal
that
was
offered
was
to
essentially
have
like
a
metadata
object
in
the
package.json
file
and
then
that
metadata
content
would
be
sent
over
as
part
of
the
http
header.
So
it
essentially
allows
anybody
to
make
use
of
that
metadata
object
as
as
they
please.
Basically.
I
So
I
think
I
mean
if
we
have
adding
adding
a
new
field
to
package.json
called
metadata,
we
that
that's
definitely
going
to
require
sorry.
I
didn't
I
didn't
catch
that
this
change
had
been
made
in
the
proposal
that
is
going
to
require
that
we
check
to
make
sure
that
nobody's
currently
using
the
field
metadata
and
it's
a
little
bit
more.
I
I
The
yeah
I'm
wondering
what
use
cases
specifically,
we
want
to
use
metadata
for
and
if
everything,
if
everything
in
metadata
is
going
to
be
sent
as
kind
of
headers
to
the
registry,
then
there
might
be
kind
of
a.
We
could
probably
bike
shout
a
little
bit
on
just
the
spelling
of
it.
If
it's
you
know
if
it
should
instead
be
called
like
headers
or
something.
G
Sure
yeah
I
mean
at
the
moment
I
mean
I
know
this
is
on
the
rfc,
but
I
did
actually
raise
a
pr
against
this,
which
is
for
our
use
case.
It
was
focusing
on
the
npm
audit
side
of
things
only.
I
think
there
was
talk
about
making
this
generic
for
every
header,
but
yeah.
We
could
certainly
maybe
change
that
metadata
to
be.
You
know
something
a
bit
more
specific
to
the
header
information
itself.
I
A
K
K
The
generic
stuff
is
really
just
because
I
think
there
is
more
value
in
keeping
it
open
for
a
bunch
of
use
cases
out
of
this
like
lower
level
feature
right,
so
I
does
that
is
that
going
to
get
sorry?
I
was
also
distracted
there
a
second
ago,
so
I
think
I
must
miss,
maybe
the
middle
part
of
what
you
were
saying.
What
was
the
concern
about
making
it
more
generic.
I
Well,
so
the
the
main
thing
is:
if
we,
if
we're,
adding
a
header
called
app
or
a
top
level
package,
json
field
called
app
id
that
we're
pretty
sure
is
not
being
used
in
the
registry.
We
kind
of
already
done
a
scan
for
that
and
had
some
discussion
and
analysis
around
it
that
just
hasn't
been
done
for
the
field
named
metadata.
I
We
could
do
it
and
figure
that
out
it's
it's,
not
it's
not
particularly
hard.
It's
just
a
task
that
has
to
be
done
before
we
can
kind
of
ratify
this.
The
the
other
thing
is,
if
my
other
pushback
to
calling
it
metadata
is
just
if,
if
the
use
case
is
this
is
a
collection
of
key
value
pairs
that
are
going
to
be
added
to
http
headers
to
the
npm
registry.
Right,
like
that's
kind
of
what
this
semantically
is
used
for,
then
there
may
be,
you
know.
I
Maybe
we
should
call
it
headers,
rather
than
metadata,
just
to
kind
of
call
out
exactly
what
it
is
and
make
it
more
clear,
because
in
a
in
a
sense,
it's
like
metadata
doesn't
actually
tell
you
much
about
what
it's
being
used
for
like
everything
in
package.
Json
is
metadata
right.
A
Yeah,
I
think
it
would
make
sense
to
rename
it
headers,
but
then
we'll
probably
have
to
do
the
same.
What
you!
What
you're
talking
about
in
terms
of
making
sure
we're
not
colliding.
G
I
just
wasn't
sure
whether
this
would
be
potentially,
you
know
used
for
other
things.
If
someone's
just
passing
the
package,
json
finally
find
the
metadata
useful,
they
may
use
it
for
other
things
other
than
what's
sent
over
as
a
as
a
header,
whereas
some
naming
ahead
it
might
be
actually
limiting
it
potentially.
I
If
we're
going
to
call
something
metadata
and
there's
going
to
be
kind
of
blessed
fields
in
there,
then
some
of
them
are
used
for
some
things
and
others
for
other
things,
I
would
say
just
make
them
all
top
level
fields
right
like
it's.
Let's
just
add
an
app
like
that
gets
us
back
to
just
add
an
app
id
and
if
you
want
to
know
the
app
id
for
any
reason,
you
look
at
package.json.app
id.
H
I'm
actually
kind
of
thinking
about,
if
that
might
be
helpful
with
something
that
we're
doing,
which
is
we're
kind
of
trying
to
emulate
at
work.
The
idea
of
maven
snapshots,
which
is
basically
like
whenever
we
have
a
ci,
build.
H
We
have
something
that's
falling
out
of
the
ci
build
and
we
want
to
be
able
to
get
rid
of
those
snapshots,
and
I
could
think
that
like
if
you
had
like
something
like
a
nexus
repository
or
something
that
would
not
be
like
the
npm
registry,
you
would
be
able
to
say
if
it
has,
that
metadata
put
it
in
that
folder
and
just
like,
remove
that
folder
like
every
I
don't
know
every
other
week
or
something
to
I
don't
know
you
know
in
a
way
tag
the
the
things
that
you're
pushing
to
the
registry.
A
A
Yeah
the
generic
use
case
of
passing
things
to
like
a
third
party
registry
like
like,
I
think,
that's
exactly
what
this
is
meant
for
right
and
I
think
the
you
know
I
like
app
id.
It
doesn't
map
one
to
one
to
like
the
package
name.
So
I
think
that's
also
why,
like
mark
and
their
team,
were
we're
pushing
for
this.
I
see
where
there's
benefits
in
in
d
scoping
this
back
down
to
just
like
top
level
field
like
like
just
app
id.
I
I
I
K
I
Right
and
if,
if
that's
the
case,
then
we
we
probably
want
to
call
it
headers,
and
we
probably
want
to
be.
You
know
very
explicit
about
like
this
is
this
is
going
to
send
additional
headers
to
the
npm
registry,
and
so
you
can
put
in
their
npm
hyphen
app
hyphen
id
or
you
can
put
in
their.
You
know,
authorization
or
or
anything
else
that
you
want,
and
just
every
request
to
the
registry
in
this
project
is
going
to
get
these
headers
attached
to
it.
I
That's
very
simple
to
implement-
and
I
think
incredibly
powerful
for
for
this
use
case,
as
well
as
other
generic
ones.
What
I,
what
I'm
trying
to
avoid
is
a
situation
where
we
have
a
metadata
field
and
we
have
an
app
id
if
it
sees
metadata.app
id.
It
does
one
thing
if
it
sees
metadata.authproxy,
it
does
a
different
thing
and
so
on
and
so
forth,
and
then
it
kind
of
becomes
like
yet
an
sort
of
like
yet
another
config
level.
You
know
what
I
mean
in
in
a
kind
of
weird
orthogonal
way.
I
If
it's,
if
we're
only
going
to
attach
these
semantics
to
the
field,
the
app
id
field,
then
that
should
be
the
top
level
thing.
If
we're
going
to
attach
the
same
semantics
to
everything
in
this
collection
than
the
collection
should
be
the
top-level
thing,
do
you
see
what
I'm
getting
at.
A
I
think
so
I
was
wondering
if
this
should
be
a
config
thing
that
supported
like
an
ipm,
rc
specific
and
not
live
in
the
package.json,
that's
kind
of
where
my
head
was
going,
and
I
was
trying
to
see
mark
if
there
was
any
previous
discussion
as
to
why
that
might
not
be
like
what
you
want,
or
you
want
to
distribute
this
config
in
the
package.json.
I
One
one
other
thing
that
that
may
be
worth
considering
here
is
that
we
in
in
prior
discussions,
we
had
talked
about
app
id
specifically
being
something
that
the
server
can
set
so,
for
example,
the
first
time
it
sees
an
audit.
It
could
mint
a
token
and
give
you
that
and
say:
okay.
This
is
your
app
id
hold
on
to
it
and
give
it
back
to
me
later
and
if
that's
the
case,
then
that
is
a
different
that
is
additional
different
semantics
than
just
send.
A
Yeah,
I
do
think
I,
if
I
remember
that
conversation
it
was
that
you
can
pass
this
through
and
then
this
would
be
information
that
could
then
be
given
back
to
anybody.
That's
installing
the
package
right,
so
this
would
be
stored
in
in
like
the
package.
Somehow.
B
Here's
a
suggestion
we
should
like
this
scope
like
take
a
step
back
and
maybe
just
focus
on
that
behavior
of
attaching
the
header
for
the
sake
of
auditing.
Only.
A
I'm
interested
in
what
we
can
do
like
in
the
near
like
like
yeah,
descoping
and
thinking
about
the
first
step
of
this,
which
is
what's
the
client
like
what
can
the
cli
support
and,
what's
the
make
sense
for
it,
to
support
right
right
away
and
like
this
seems
like
it
would
almost
be
like
a
config
level
like
an
npm
rc
like
value
right
like
like
headers
or
something
we
could
put
in
there,
and
that
would
actually
be
a
bit
safer
than
having
to
bless
like
a
new
key
and
package.
Json.
G
I
A
You
know
the
naming
and
everything
else
and
like
how
we're
going
to
support
this
and
and
then
also,
I,
I
think,
we're
conceptualizing.
How
like
npm
then
would
use
this
information,
even
though
this
probably
like,
like
is
meant
to
you
know,
have
capabilities
beyond
just
our
registry
right,
so
I
think
the
cli.
It
would
be
easier
to
support
something
that
was
just
like
a
config
and
an
npm
rc
like
headers
and
then
just
pass
those
through.
That
would
certainly.
A
G
Not
that
I
can
think
of
off
the
the
top
of
my
head
other
than
I
think
in
our
particular
case.
We
probably
don't
pass
at
the
moment
the
npm
rc
files
or
get
hold
of
that
information.
Well,.
I
I
I
I
just
posted
a
comment
on
the
on
the
just
on
the
pr
with
some
of
these
options,
I'm
I'm
kind
of
leaning
toward
that
project
level
on
pmrc,
the
more
I
think
about
it.
It
is.
It
is
certainly
a
lot
easier
to
to
do,
because
you
know
the
the
options
that
we're
going
to
be
passing
to
you
know
we
already
parsed
that
in
we
already
kind
of
have
that
object
there.
I
We
could
even
add
some
semantics
that
if
we
get
a
particular
header
from
the
registry,
we
go
ahead
and
add
that
to
the
project
level,
config
and
save
it,
you
know
it
wouldn't
it
would
actually
be
somewhat
easier
than
than
stashing
it
in
package.json
and
maybe
less
disruptive.
C
I'm
sure
so
I
was
just
commenting
from
a
security
perspective.
It
makes
more
sense
to
be
in
the
mpmrc
also.
Inevitably,
if
you
allow
people
to
send
arbitrary
headers,
then
things
like
authorization
tokens
are
going
to
end
up
in
there
and
if
that's
in
the
npm
rc,
which
is
already
established
as
containing
secrets,
then
you
know
it's
it's
something
that
people
will
be
a
little
less
surprised
by
at
least
did
you
want
to
add
to
that.
B
Right,
which
is
a
great
point
that
made
them
bring,
but
I
would
like
to
also
point
there
is
a
separate
conversation
about
bringing
config
to
package.json
altogether,
but
that's
a
separate
one
and
a
much
larger
one
right,
and
I
think
it
would
implicate
this
kind
of
security
issues.
Nathan
just
mentioned.
K
Actually,
nathan,
you
bring
that
up
makes
me
actually
a
little
bit
worried
because
already
having
the
secrets
in
the
npm
rc
is
a
is
a
problem
for
security
right.
So
if
we
do
make
that
worse
here,
I'm
a
little
concerned,
which
I
think
you're
right
people
would
inevitably
put
that
in
the
npm
rc.
I
was
thinking
more
of
it
being
derived
the
reason
I
was
thinking
of
it
as
a
config
value.
K
Being
a
good
thing
was
you'd
pass
it
on
the
command
line
right,
so
you
you
could
like
store
it
encrypted
and
then
decrypt
it
as
part
of
your.
You
know
install
command
or
something,
but
if
people
start
hard
coding
tokens,
then
we're
just
introducing
another
vector
which
we
will
have
to
migrate
off
at
some
point.
Presumably
right,
because
you
know
nobody
thinks
that
the
npm
tokens
in
the
npmrc
is
actually
a
good
thing.
A
Right
yeah,
so
we
don't,
we
they're
default,
ignored
on
publish
so
like
that's.
You
know
like
we
know
that
people
use
and
put
stuff
in
there
that
we
don't
want
you
know
distributed.
So
I
mean,
if
you're
talking
about
wes
you're
concerned
about
like
people.
Checking
that
in
to
like
a
repo
is,
is
that
sort
of
a
big
concern.
I
So
I
think
I
don't,
I
don't
think
it
makes
it
worse,
though
right
we
don't
store
your
login
token
by
default
in
the
project
level.
Config
we
could.
We
could
even
add
some
more
kind
of
guard
rails
around
what
we,
what
we
store
in
there
or
what
we,
which
config
values
we
allow
to
be
stored
in
in
project
level.
Configs
it
it
doesn't.
It
doesn't
make
the
security
risk
worse
and
I
think,
adding
a
generic
headers
field
to
package.json.
Does
you
know
what
I
mean
we
we
can
talk
more
or
have
other
rfcs.
I
I
think
there's
tons
of
great
ideas
around
how
we
could
make
project
level
configs
less
risky,
but
I'm
not
sure
that
this
actually
makes
it
any
more
risky.
It
sort
of
adds
on
to
the
problem
we
already
know
we
have.
K
Yeah,
I
agree.
I
don't
think
this
should
be
considered
a
blocker,
because
it's
just
a
continuation
of
the
problem
we
already
have
just
concerning
whenever
we
add
more
surface
area
that
has
the
exact
same
thing,
we
already
know
is
a
problem.
I.
A
Guess
so,
and
this
probably
incentivizes
the
usage
right
so
okay
mark?
Are
you
picking
up
just
a
quick
question
on
this
rc
itself?
Are
you
sort
of
picking
up
whether
your
colleague
left
off,
but
with
this,
do
you
have
access
to
to
update
this?
I.
A
Is
it
possible
to
maybe
change
the
name,
the
title
of
the
rc,
so
we
don't
are
representing
the
app
id
specifically
sure
you
know
this
feedback,
I'm
wondering
if
we've
come
to
a
bit
of
a
bit
of
consensus
on
what
we
like
like.
I
know
that
personally,
I'm
a
fan
of
the
project
level
mpmrc
row
mark.
Would
you
be
willing
to
just
update
this
to
reflect
that,
like
the
update
the
example
of
how
to.
A
These
headers,
I
think,
also
showing
an
example
of
the
to
west's
point
showing
the
example
of
setting
this
via
config
as
well.
A
Interesting,
just
to
so
the
example
usage
of
running
you
know,
npm,
I
guess
it
would
be
npm.
Publish
with
like
that
config
set
would
be
a
good
example
whatever
that
is
like
dash
headers
equals
app
id
like
like
how
that
might
look
would
be
good
to.
A
If
not,
I
I
think
that's
pretty
good,
like
we'll,
actually
get
some
movement
on
this,
and
we
can
actually
put
this
on
the
road
map
here.
So.
I
So
one
one
possible
idea
that
would
actually
get
us
back
to
the
the
ability
for
for
registry
to
set
the
npm
the
npm
app
id
would
be
if,
if
we
get
a,
if
we
see
a
header
coming
back
from
the
registry
that
sets,
you
know,
npm
hyphen
app,
hyphen
id,
then
we'll
go
ahead
and
save
that
as
a
project
level.
Config
like
we
can.
A
I
Yeah,
so
the
so
the
first
one
would
be,
we
add,
a
config
value
called
headers,
which
is
a
list
a
list
type.
You
know
list
of
strings
that
we
that
we'll
pass
through.
The
second
is:
if
we
get
an
npm
app
id,
then
we
save
it
to
the
project
config
and
the
second
kind
of
builds
on
the
first
and
gets
us
everything
that
we
had
talked
about
and
all
the
reasons
for
having
it
stored
in
package.json,
which
I
quite
like.
A
So,
let's
say
you're
starting
a
net
new
project.
Let's
say
you're
installing
well
actually
yeah.
How
does
that
work.
I
So
the
way,
the
way
that
I
would
do
it
if
I,
if
I
worked
for
sonotype,
is,
I
would
say,
look
we
we
want
to
have
app
level
tracking
for
all
our
projects
right.
I
I
Save
it
to
the
project
config
yeah
and
you
could
also
send
a
I'll
post
an
example,
but
I'll
write.
This
up
try
to
write
this
up
today
and
post
an
example,
but
then
you
would.
You
could
also
send
an
npm
notice,
header
that
says:
hey
I've,
just
I've
just
put
something
in
your
npm.npmrc
file.
You
want
to
check
it
in.
G
A
So
it
sounds
like
there's
a
bit
of
work
just
to
break
those
two
concepts
out.
If
that's
okay,
I
think
they
are
distinct
enough
to
probably
you
know
ensure
that
they,
they
are
separate
rc.
So
if
you
can
take
that
on
mark,
then
we'd
love.
G
A
I
apologize
the
notification.
My
inbox
is
a
bit
crazy
and
I
know
you've
focused
on
this
for
a
while,
so,
okay
cool
did
anybody
else
have
anything
they
want
to
add
before
we
move
on
to
the
last
couple,
if
not
yeah.
So
the
second
last
item
here
we
had
was
the
rc4
npm
audit
and
audit
resolve
json,
so
number
18.
A
I
know
cp's
not
on
the
call,
and
I
guess
I
can
give
a
bit
of
an
update
here
and
I
think
wes
who's
on
the
call
was
in
the
essentially
we
had
an
out
of
band
package
maintenance
working
group
call
for
for
this
work
and
and
sort
of
trying
to
kick
off
the
discussion
on
and
what
is
we're
trying
to
solve
for
here.
Wes,
I'm
not
sure
if
you
have
any
like
anything,
you
want
to
add
from
that
call.
K
K
One
is
we
need
to
talk
with
some
folks
at
sneak
as
well
and
then
probably
have
a
continued
discussion
in
the
package
maintenance
working
group,
but
it
sort
of
centers
around
the
idea
of
letting
users
specify
a
source
for
which
they
will
load
a
ignore
list
for
certain
cves,
and
so
then
the
the
proposal,
which
would
probably
end
up
being
an
rfc
at
some
point.
K
If,
if
everybody
agrees
that
this
is
a
good
way
forward,
would
be
that
the
client,
the
cli
it
takes,
that
config
value
fetches
the
ignore
lists
and
then
applies
those
when
reporting
back
the
audit
results,
and
this
would
be
one
way
to
enable.
So
so
the
original
rfc
here
is
to
to
do
the
audit
resolve
feature
just
for
each
like
application
level.
But
what
we
were
discussing
this
morning
was
really
trying
to
federate
that
out
more
to
package
maintainers
and
other
authorities
so
like.
K
If
you
had
a
company-wide
list
you
wanted
to
implement,
or
you
had
authors
which
you
trusted
to
maintain
a
list
of
of
ignores.
You
could
do
that.
So
that's
sort
of
that.
The
outcome
that
we're
discussing
proposing
to
the
you
know
npm,
but
then
also
you
know,
it'll
it'll
require,
I
think
something
from
sneak
as
well.
Here
I
don't
think
we
you
know,
there's
enough
people
who
use
that
as
their
main
interface
for
this
data.
That
I
think
would
be
meaningful.
So
is
that
a
good
synopsis?
You
think
that's.
A
At
least
where
my
personal
understanding
of
that
was
that
we
want
to
have
that
list
live,
you
know
it's
hypothetically
near
where
the
cve
list
is
coming
from
like
so
you
could
support
somebody
could
support
both
those
right
like
and
so
in
in
our
case,
or
you
know,
github's
case
potentially
having
a
cve
database
advisory
database
also
you'd
have
a
corresponding
resolution
sort
of
db
or
something
or
some
place
to
have.
A
That
list
live
and
that's
based
a
little
bit
off
of
some
feedback
that
I
got
when
I
poked
out
on
baldwin,
who
said
you
know
there
needs
to
be
an
audit
trail.
This
thing
needs
to
be
immutable.
A
There
needs
to
be,
you
know
yeah,
so
it
just
didn't
make
as
much
sense
to
have
it
live
in
like
packet
json
or
in
the
package
itself,
which
is
sort
of
deviating
from
this
original
rc's
concept
of
of
having
this
resolve
json
and
more
looking
for
like
a
a
different
source
of
truth,
which
is
outside
of
the
package
itself
right.
So.
K
Maybe
yesterday
there's
like
a
specific
technical
reason:
why
having
it
in
the
package,
jason
is
bad,
which
I
think
is
what
adam
pointed
out
right.
Is
that
once
you
publish
it,
if
you
have
that
version,
then
the
the
the
result
resolution
is
to
publish
again
which
at
that
point
you
have
to
get
everybody
to
update
and
it
doesn't
really
work
technically.
So.
A
That's
the
crux
right,
so
if
somebody
says
your
package
is
bad,
you
have
no
way
of
saying
no,
it's
not
without
publishing
a
new
version.
So
that's
like
the
one
or
you're.
Not
your
package
is
bad,
but
your
package
is
affected
and
yeah.
So
that's
been
that
there's
a
there's,
a
lot
of
discussion
around
you
know
the
current
way
in
which
the
life
cycle
of
cv
is.
It
affects
the
ecosystem.
I
think
we
have
some
work
to
do
there,
but
yeah.
A
A
I
think
we
would
potentially
just
change
audit
resolve
json
being
the
the
source
of
truth,
the
shape
the
shape
of
what
tvs
put
together
may
not
change
like
like
this
is
a
good
like
first
crack
at
what
it
would
look
like
to
writing.
A
Let's
say
like
to
having
that
metadata.
Look
like
that,
so
I'm
not
going
to
say
that
that
that
this
isn't
like
invalid,
yet
or
or
we
would
ask
for
changes
until.
I
think
the
the
key
here
is
like
having
it
live
inside.
The
package.json,
for
sure
is,
is
something
that
we
probably
don't
want
to
see
so.
B
Yeah
sure,
but
but
having
the
audit
resolved
at
your
project
level,
that
idea
still
stands
or.
A
Oh
so
you're
talking
to
the
project.
First,
the
like
depth
level
like
the
root
author
level
versus
the
maintainer.
K
One
thing
I
was
considering,
which
might
be
solve
both
of
these
problems
would
be
that
if
the
source
of
the
data
was
just
anything
that
was
in
his
package
spec,
so
if
so,
it
could
be
a
file
right.
So
you
could
just
say
you
know,
dot,
slash,
audit
resolve,
and
then
that
would
be
the
thing
that
contains
the
your
sources
of
your.
B
Because
that
it
looks
like
this
rfc
like
we
might
just
move
away
from
it
completely
right.
K
K
I
think
you
could
move
that
part
out
into
say
it's
just
a
something
that
can
be
referenced
via
a
package
spec
and
then,
what's
in
that
package,
is
this
metadata
format
and
the
feature
set
that
there
that
he's
proposing
right?
It's
just
that
it
doesn't
live
in
in
the
package.json
or
the
package
itself.
A
K
You
move
it
out
of
packages
and
it's
actually
optional,
whether
it
lives
in
the
package
itself
or
not
right,
because
if
it's
a
spec,
you
could,
in
theory
publish
the
package
and
it
could
contain
an
audit
resolve
in
it
which
it's
self-referential,
because
that
could
be
for
like
an
application
right,
but
then
for
like
the
maintainer
version
that
we're
talking
about
you.
Wouldn't
do
it
like
that
because
of
the
problem
we
talked
about
with
it
being
in
the
package,
so
you'd
have
to
reference
it
externally,
right,
yeah,.
A
Yeah,
so
there's
definitely
some
changes
to
like
this
that
we'll
ask
for
from
this
rc,
but
I
essentially
wanted
to
leave
this
on
the
agenda
to
say
that
you
know
we're
having
this
conversation.
This
isn't
something
where
we've
forgotten
about,
and
this
is
still
something
that
I
think
we
care
about
in
terms
of
reducing
the
noise
and
ensuring
people
aren't.
A
I
think
the
crux
of
the
discussion
from
today
was
also
you
know
it's
getting
riskier
if
people
consider
like
audit
warnings
to
be
just
noise,
they're,
getting
sort
of
like
fatigue,
and
so
they'll
start
to
ignore
those
warnings
and-
and
they
won't
be
as
meaningful
right
so.
I
Yeah,
that
is,
that
is
exactly
why
we
took
such
pains
to
to
tighten
up
those
those
error
messages
or
those
warnings
in
v7,
specifically
because
it's
just
it's
too
much
and
it's
it's
too
many
characters
flying
by
on
your
screen
and
then,
and
most
of
them
are
not
really
helping.
You
know
exactly
what
you
need
to
change,
and
so
it's
it's
sort
of
it's.
I
A
H
A
H
This
is
basically
just
an
idea,
I'm
basically
just
throwing
around
and
just
seeing
if
anyone
else
feels
that
this
should
be
implemented,
and
then
I
would
present
something
that's
a
bit
more
thoughtful.
H
But
my
idea
is
basically
that
whenever
you
add
a
package
and
it
might
have
issues-
and
you
might
be
in
a
corporate
environment,
for
example,
we
have
a
firewall
that
gives
us
a
forbidden
for
a
package
that
has
security
issues.
H
So
we
don't
even
get
the
package
and
we
just
have
the
characters
flying
by
and
it
would
be
nice
to
have
some
sort
of
implication
of
like
how
secure
or
not
secure
the
package
that
you're
about
to
install
is
so
I'm
basically
trying
to
figure
out
the
impact
beforehand.
That's
the
entire
point.
I
With
the
new
so
I'll
say,
with
the
new
audit
endpoint
that
we're
using
now
the
bulk
advisory
endpoint,
it
is
incredibly
easy
to
to
say
given
a
given
a
specific
package,
name
and
version
show
me
show
me
any
advisories
that
affect
that
particular
version.
What
is
less
easy
is
to
say
for
a
given
package
and
range,
or
even
just
everything,
for
a
given
package
name,
I
don't!
No.
I
don't
believe
that
there's
a
capacity
to
do
that,
so
you
have
to
the
way
we're
using
it
now.
I
Basically,
we
get
a
list
of
the
names
and
versions
of
everything
in
your
tree,
and
then
we
set
that
up
as
a
as
a
one
big
object
and
that's
actually
how
we
do
audits
of
what's
local,
we
yeah
if
we
wanted
to
say
npm
audit
package
name.
That
would
be
pretty
easy
to
do
with
that
new
endpoint
with
the
older
endpoint.
It
receives
a
package
tree
in
the
form
of
essentially
the
same
data
object
that
you
have
in
package.json,
so
the
older
advisory
endpoint.
I
So
if
we
wanted
to,
if
we
were
willing
to
say
that
this
only
works,
if
you
have
the
the
bulk
advisory
endpoint
implemented,
then
I'd
say
like
yeah:
it's
a
great
idea:
let's
do
it,
it's
pretty
easy
to
do
the
the
other
thing
that
we
would
not
be
able
to
do
is
to
say
or
what
would
be
more
challenging
and
where
I
think
it
might
not
quite
meet
your
your
needs
here
would
be
to
say
I
want
to.
I
want
to
install
foo.
I
So
if
the,
if
the
use
case
here
is
actually
let
me
find,
if
there's
any
advisories,
that
will
be
pulled
in
as
a
result
of
adding
foo
as
a
dependency,
even
advisories
on
other
things
which
make
foo
vulnerable
and
make
food
something.
I
can't
install
that's
a
little
bit
of
a
stickier
problem.
It's
a
little
bit
more
work,
but
I
still
think
it's
not
impossible
and
I
think
it's
it's
worth.
I
It
just
means
that
we'll
have
to
kind
of
fetch,
essentially
build
a
sort
of
build
an
ideal
tree
with
just
that
one
node
and
then
do
an
audit
on
it
and
see
what
that
says.
K
K
K
One
thing
I
had
thought
about
which
might
be
a
possible
solution,
and
this
is
a
big
change,
so
I
probably
won't
land
in
this
forum,
but
included
in
the
pacument
like
include
the
the
metadata
about
the
currently
known
cves,
so
augment
the
pacument
data,
so
that
you
can
do
it
by
just
fetching
the
metadata,
but
that
I
think,
would
be
a
pretty
big
registry
change.
So.
I
It
would,
and
it's
it's
it's
complicated
because
they
sort
of
they're
updated
out
of
step
with
one
another
and
so
from
like
basically
denormalizing.
I
B
Yeah
that
might
sound
way
better
yeah,
because
I
was
going
to
also
raise
the
point
that
in
the
cly,
if
you
are
thinking
already
like
adding
sub
commands
to
audit,
maybe
it
wouldn't
be
ideal
to
just
add
and
cam
audit
and
then
spack
right
just
to
not
limit
what
we
can
use
as
a
subcommand.
But
I
do
think
it
sounds
way
better,
as
just
like
an
output
often
can
view
yeah.
K
Noted
I
can
ask
a
quick
question:
is
there
a
reason
why
you
can't
take
the
ideal
tree
from
arborist
today
and
just
make
a
package
lock,
even
though,
and
just
like,
you
know,
make
the
result
or
whatever
the
paths
you
know
null
or
something
or
you
know
so
that
you
could
just
from
an
ideal
tree
instead
of
actually
refining
it.
I
You
you
can,
I
mean
you,
can
do
npm,
install
dash
dash
package
lock
only
and
that'll
do
exactly
that.
It'll
still
run
the
audit.
We
we
kick
off
the
audit
before
we
start
before.
We
start
unpacking
things
it
just
it
takes
a
minute,
and
so
we
do
it
in
parallel.
But
if
you
have
a
package
lock
and
you
run,
npm
audit,
like
it's
gonna,
just
use
that
it's
just
gonna
use
the
virtual
tree.
A
So
just
to
be
mindful
of
time,
I
know
we're
over
now
a
couple
minutes
christian.
Hopefully
that
gives
you
a
bit
of
feedback
on
on
thoughts.
Definitely
this
is
something
it
sounds
like
there
would
be
support
for,
but
maybe
we
could
also
look
at
what
it
would
look
like
if
we
actually
bubbled
up
this
information
in
npm
view.
So
maybe
you
can
see
what
the
output
looks
like
today
of
npm
view
and
then,
especially
in
the
beta,
go
and
poke
at
that
yeah
and
then
maybe
how
we
could
add
it
to.
A
That
would
be
good
sure.
Okay,
appreciate
everybody
jumping
on
today
and
feel
free
to
keep
up
conversations
in
in
the
our
season
themselves,
and
then
I
hopefully
will
see
you
all
next
week
see
you
next
week
have
fun
thanks.