►
From YouTube: Open RFC Meeting - Wednesday, June 1st 2022
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
everyone
to
another
npm,
open
rc
call.
Today's
date
is
wednesday
june
1st
2022
we'll
be
following
along
in
the
agenda
that
was
created
and
posted
in
the
npm
rfc's
repo.
This
is
issue
596..
A
I've
copied
and
pasted
me
note
stock
for
folks
in
chat,
feel
free
to
add
yourselves
to
the
attendees
list.
Quick
reminder
these
calls
and
all
comms
on
the
rfc's,
repo
and
all
mdm
repos
are
is
covered
under
our
code
of
conduct.
We
ask
that
you
please
be
kind
respectful
to
each
other,
especially
on
these
calls.
A
If
someone's
speaking,
please
raise
your
hand
and
we'll
call
on
you
and
also
quickly
some
announcements.
We
continue
to
flush
out
sort
of
the
v9
roadmap
and
and
items
to
do
for
v9,
we've
been
queuing
up
some
deprecation
warnings
and
things
like
that
for
v8
and
have
a
number
of
items
there
queued
up
for
benign,
there's
a
link
there
in
the
mean
notes.
If
you
want
to
go
check
out
what
that
is
shaping
up
to
look
like
also
next
week
we
aren't
going
to
be
running.
A
One
of
these
calls,
because
we'll
be
most
of
our
team,
will
be
in
austin
attending
open.js
world
and
we
will
have
some
of
our
team
participating
in
the
collab
summit
as
well,
which
is
just
after
the
opengs
world
conference.
A
So
hopefully
we'll
be
able
to
see
some
books
there
in
person,
and
I
think
that's
it
for
announcements
on
my
side
did
folks
have
anything
they
want
to
share
any
news
or
anything
like
that.
A
If
not,
we
can
jump
right
into
the
agenda.
It's
pretty
small
and
not
many
things
have
changed.
This
is
actually
the
one
net
new
thing,
which
is
this
pr
595,
which
is
proposing
a
backwards
compatible
improvement
to
our
compression.
This
is
by
evan
han.
I
don't
think
they
were
able
to
jump
on
this
call.
I
know
it
was
last
minute
and
there
weren't
a
ton
of
details
in
the
conversation,
but
the
rfc
goes
into.
I
think
some
great
length
about
how
we
could
improve
compression
go
ahead.
Jordan.
B
Yeah,
I
was
just.
I
was
really
impressed
when
I
saw
the
like,
read
the
first
couple
sentences
I
was
like.
Oh
here
we
go.
Let's
see
how
many
problems
this
is
gonna
have,
and
then
I
kept
reading
and
like
it
is
really
well
fleshed
out
about
how
it
can
be
made
backward
compatible
and
assuming
that
the
claims
made
are
true
right,
which
I
have
no
way
of
knowing,
but
I'm
assuming
they
are,
like
it
kind
of
seems
like
a
no-brainer
like.
B
Why
would
we
not
just
do
it
if
it
won't
break
for
anyone,
and
it
will
make
things
smaller
and
whether
you
want
to
backfill
old
packages
or
not
like
is
a
completely
different
discussion
and
the
integrity
thing
is
an
issue
but
like
there's,
also
lots
of
old
packages
that
don't
even
have
integrity
checksums
because
they
were
published
before
that.
So
you.
B
Least,
backfill
the
compression
of
those
or
something
but
but
either
way,
certainly
doing
it
for
new
packages.
It
seems
pretty
simple
so
like
again,
assuming
all
the
claims
are
true
right
like
it
sounds
awesome.
Let's
do
it.
A
Yeah,
I
haven't
had
a
chance
to
really
dig
deep,
but
I
basically
plus
100
sentiment
if
there
is
a
way
that
we
can
like
optimize
and
shrink
the
package
size
like.
Why
not?
Why
not?
It's
like
there's
no
reason
right.
You
know
the
projects
are
only
growing
and
not
getting
smaller.
A
B
Well,
and-
and
one
thing
I
guess
that
is
occurring
to
me-
is
we
still
might
want
to
add
a
config
item
to
opt
out
of
softly
as
an
escape
patch
for
those
dealing
with
private
registries,
that
maybe,
for
reasons
unknown,
don't
work
well
with
it,
but
like
with
that
approach,
but
like
that's,
that's
a
relatively
minor
thing
to
add,
especially
if
it's
not
the
default
go
ahead.
Okay,.
C
B
Increase
the
fact
that
it's
in
go,
I
mean
it's
the
algorithm,
that's
important
right,
not
the
implementation.
So
like
may,
perhaps
that's
something
to
consider
right.
Maybe
someone
would
then
have
to
port
and
maintain
a
javascript
version
of
the
algorithm,
which
I
understand
why
that
would
be
awful,
but
like
somebody's
gonna
need
this.
B
If
this
is
a,
this
is
a
new
good
compression
standard.
That's
as
backwards
compatible
as
this
right,
like
npm,
won't
be
the
only
one
that
uses
it
so
like
it
seems
like
the
sort
of
thing
that
the
team
that
developed
it
would
probably
even
be
willing
to
help
maintain
and
once
it
exists
and
works
in
javascript.
B
C
B
Also,
a
fine,
I
think,
a
fine
conclusion
right.
If
the
consensus
of
this
this
meeting
is
like,
we
absolutely
want
to
do
this.
The
precondition
is
that
a
sufficiently
fast
implementation
must
exist
on
npm
in
javascript,
then
like
it's
fine,
if
the
irc
sits
here
for
two
years,
while
somebody
doesn't
build
that
and
then
somebody
builds
it
and
then
we
do
it,
but
like
it's
still,
okay
to
telegraph,
our
intention
to
do
it
pending
some
work.
A
Exactly
yeah
like
we
can
accept
this
or
like
agree
that
this
is
like
something
we
would
want
to
do.
Caveating
I
mean
you
know
a
javascript
level.
B
Like
there
might
be
a
number
of
people
out
there,
both
at
google
working
on
softly
or
like
in
the
ecosystem,
who
want
package
sizes
to
be
smaller,
whatever
I
mean,
there's
how
much
money
did
google
pump
into
like
bundle,
phobia
and
whatnot
for
that
exact
goal,
or
you
know
a
similar
goal.
So
it's
like.
B
I
imagine
that
there
will
be
that
if
npm
says
we
will
implement
this
as
soon
as
someone
builds
it
in
javascript.
I
imagine
that
it
shouldn't
take
long
before
people
either
implement
it
or
stop
complaining
about
package
sizes
because
they're
not
implementing
it.
D
Yeah
does
it
I
noticed
in
there
that
they
link
to
a
wasm,
a
webassembly
version.
Would
that
assist
with
the
portability
issue
or
address
the
portability
issue?
I
suppose
you'd
have
to
like
vendor
it
into
npm,
maybe
or.
A
Potentially,
this
is
something
we've
also
like
until
we
you
know
tossed
around
in
the
past,
like
there's,
there's
definitely
benefits
for
us
shipping,
npm
sort
of
unpacked
and
with
our
like
bundle
depths
you
know
and
not
not
not,
throwing
everything
into
a
single
binary
or-
or
you
know,
there's
definitely
like
reasons
why
that
has
benefited.
A
I
think
adoption
and
collaboration
and
contribution
from
the
ecosystem
if
we
start
to
ship
more,
like
wasm
code,
if
we
potentially
move
our
you
know,
even
the
brain
of
npm,
like
arborist,
essentially
into
wasm,
which
is
potentially
could
have
performance
gains,
although
most
of
our,
I
think
most
of
our
cost
in
npm
is
stuck
in
sort
of
file,
system,
io
and
and
potentially
a
network
things
that
we
are
out
of
our
control
are
like,
then,
you
know
we
would
potentially
want
to
start
to
explore
like
what
potential
we
could
use
spasm.
A
B
I
mean
there's,
there's,
there's
always
gonna,
be
a
trade
off
with
wasm
components.
Right
like
it's,
the
performance
is
increased,
but
the
approachability
and
maintainability
is
going
to
be
decreased
because
there's
just
fewer
people
that
can
work
with
that,
tooling
that
that
reality
may
change
over
time,
but
it
will
be
a
while
before
that
changes,
if
it
does
so
like
it
seems
like
in
general.
B
Any
project
that
wants
to
replace
javascript
with
wasm
should
probably
do
it
in
very
small
granular
ways
for
the
highest
value
parts
to
avoid
you
know,
making
the
wrong
trade-offs
there,
but,
like
obviously
that's
gonna,
be
very
case
by
case
okay.
C
B
A
I'm
okay
with
saying
that,
like
again,
we
would
have
to
do
some
testing
and-
and
there
there's
some
cut
questions
here
in
the
bike,
shutting
section
around
like
what
would
happen
if,
if
this
algo
like
fails,
for
whatever
reason
do
you
fall
back
to
like
the
legacy
compression?
Like
I
don't
know,
yeah,
I
would
want
to
see
like
if
they're
bringing
up
that
question.
It
makes
me
think.
A
Maybe
they've
seen
some
failure
rates,
unlike
on
on
packaging
like
essentially
during
the
compression
and
decompression
like
that's
may
be
concerning,
so
we
would
have
to
again
like
we
should
probably
just
investigate
this.
Some
more
leave
it
open
for
now,
but
I
think
yeah
as
enough
is
noting,
if
c
lib
mini
c
live,
could
essentially
add
support
once
node
core
supports
this
and
that's
pretty
straightforward,
so
yeah
any
other
comments
or
discussion
on
this.
I
think
we
just
leave
it
open
for
now
it
gives
everybody
some
time.
A
A
A
D
D
Add
this
flag
to
npm
audit
instead
of
install,
I
guess
either
what
I
forgot
since
then,
or
maybe
what
I
don't
understand
is:
is
audit
like
a
no-op?
Is
there
like
a
failing
mode?
You
can
put
it
in
like
the
point
with
install.
Was
that
you'll
get
the
feedback
immediately
like
or
in
your
ci?
But
does
an
npm
audit
with
like
a
fail
option
makes
sense
like?
Is
it
does
npm
audit
fail,
or
is
it
just.
B
D
Okay,
so
it
is
a
convention.
I've
never
really
used
it
that
much
so
I
didn't
know
if
it
was
just
like
pretty.
You
know
just
printing
stuff.
So
would
that
mean
if
I
wanted
so
it
was
part
of
my
ci.
If
I
wanted
this
failing
behavior
would
I
do
an
npm
install
and
then
an
audit
or
does
install?
Do
the
audit.
B
I
mean
install,
does
the
audit,
but
I
don't
think
it
fails
the
install
if
there's
audit
problems
but
npm
audit
fails
if
there's
audit
problems,
and
so
that's
exactly
what
you
would
do
is
you
would
do
npm
install
if
you
were
really
performance
sensitive.
You
might
disable
auditing
during
the
install
with
an
mpm
config,
and
then
you
would
run
npm
audits
separately.
So
I
have
350.
You
know
300
plus
projects
that
all
run
a
form
of
npm
audit.
B
You
know
because
it
doesn't
work
without
a
lock
file,
so
I
have
to
jump
through
one
of
my
packages
but
and
they
all
run
them
in
a
separate
job
like
like
as
part
of
npm,
run
post
test
so
like,
and
it
works
just
fine.
D
So
npm
audit
on
its
own
can
fail,
but
npm
install
with
implicit
audit
would
not
fail
under
the
same,
like
triggering
scenario.
The
I
guess
is
that
I
guess
correct
before
I
ask
my
next
question.
Just
to
you
know,
okay,
so
is
that
maybe
not
a
bit
of
a
catch
22,
because
I
thought
maybe
one
of
the
the
values
of
this
is
not
getting
those
packages
on
my
disk,
if
someone's
sneaking
in
a
malicious
package,
isn't
it
that
maybe
yeah
guys.
C
Yeah,
I
was
just
going
to
ask
what
problem
this
is
solving,
because
I
wondered
about
that.
You
can
run
the
auto
before
the
install.
All
audit
needs
is
your
lock
file.
So
if
you've
got
a
lock
file,
it
audits
that
the
tree
it
would
have
made
so
just
run
out
at
first.
D
B
Yeah-
and
I
just
I
mean
I
just
also
wanted
to
add-
like
npm
audit-
should
work
without
a
lock
file
because
it
should
use
it
should
compute
your
virtual
or
ideal
tree
or
whatever
and
run
with
that,
and
that's
something
we've
talked
about
in
the
past
and
should
just
get
fixed
it'd,
be
great.
If
owen,
your
rfc
fix
that
and
from
the
grid
out
the
gate,
so
it
like,
it
uses
the
lock
file
if
present
and
if
the
lock
file
is
not
present
it.
B
You
know
loads
the
ideal
tree
or
whatever
and
or
loads
the
actual
tree
from
node
modules.
You
know
whatever
the
order
we
want
to
do
there,
because
that
way,
you
know,
I
can
run
it
on
all
my
projects.
C
Yeah,
you
might
lose
a
bit
of
that
functionality,
though,
because
in
order
to
read
the
tree
in,
we've
got
to
read
those
remote
packages.
So
now
we're
done
so
requiring
the
lock
file
is
the
only
thing
that
gives
us
this
whole
safety
thing
that
we
wanted
by
running
the
audit
first.
So
that
is
something
to
consider.
C
B
B
A
I
was
going
to
make
the
exact
same
comment
like
basically,
the
understanding
here
is
like
the
recommendation
of
running
audit
before
install
it's
like
well,
you
know
that
that
doesn't
work
for
this
use
case.
I
think,
because
you
as
jordan
just
literally
just
said,
like
I,
don't
potentially
want
to
mitigate
ever
installing
one
of
these
dependencies
right
so
like
if
I've
already
installed
it
once,
then,
that's
the
only
way
that
I
would
have
got
the
like
package
lock.
So
I
do
think
that
we
need
to
fix
that
problem.
A
A
Doing
sort
of
an
audit
and
our
audit
type
functionality,
which
is
engine
strict
and
specifically,
we
have
a
flag
there
for
you
to
essentially
opt
into
sort
of
that
strictness
which
would
then
make
install
fail.
So
that
might
be
a
good
prior
art
to
so
pure
depths
right,
yeah,
that's
potentially
again.
B
A
Think
we're
basically
yeah
a
lot
of
these
seem
to
be
all
in
similar
concert
that
potentially
in
the
future,
we
could
align
them
all
to
be
essentially
audit
type
checks
and
versus
like
these
yeah.
Exactly-
and
I
think
we've
talked
about
this
even
last
week
where
you
know
they
could
essentially
be
all
opt-in
or
update
like
type
checks
and
whether
or
not
you're,
failing
or
warning
or
whatever,
like
might
be
sort
of
secondary
to
that.
A
I
guess
to
instead
of
trying
to
solve
that
whole
world
and
to
get
this
functionality
sooner,
I
would
say:
take
the
engine
strict
type
approach
that
if
we
were
you're
going
to
run
this
check
on
install
or
you
want
to
propose
in
your
rfc
hero
and
that
this,
like
this,
this
check
could
be
done
during
install.
What
I
would
say
is
like
maybe
consider
like
what
the
flag
would
be.
A
That
would
provide
that
strictness
to
essentially
opt
into
erroring
or
not
airing,
because
the
default
audit
experience
does
not
fail
for
install
the
implicit
experience
does
not
fail
right.
So
maybe
that's
something
you
can
also
add
to
the
rc,
where
there's
some
sort
of
like
fail
on
audits
and
that
kind
of
covers
your
your
bases
and
it
actually
covers
a
lot
of
other
bases
that
might
be
a
whole
separate
rfc.
A
Potentially
just
you
know
that
might
block
this
work
where
essentially
it's
some
sort
of
flag
that
is
provided
to
install
where
we
will
fail
on
any
audit
error
and
then
that
sort
of
covers
our
basis.
B
Right,
well
I
mean
I
want
those
to
be
more
granular,
because
cbes
are
almost
exclusively
false
positives,
but
the
registry
stuff,
the
signature
stuff,
would
be
almost
exclusively
real
problems,
so
I
would
never
want
to
install
the
fail
on
cves.
I
I,
but
I
always
want
it
to
fail
and
everything
else.
You.
A
Can
start
with
like
very
broad
and
then
like
once
I
say
we
start
with
very
broad,
because
we
don't
have
the
granular
like
a
lot
of
the
other
types
of
checks
that
we're
doing
aren't.
Audits,
right,
like
the
like
you
said
pure
depth,
is
an
audit.
The
engine's
check.
Isn't
an
audit
check
like
isn't
something
that
we
can
yeah.
B
Yeah,
I
just
mean
like
whatever,
whatever
opt-out
or
opt-in,
we
want
for
failing
the
install.
I
just
think
we
should
probably
design
it
with
the
intention
that,
like
like,
I
think
the
the
the
holistic
design
should
probably
be
something
like
there's
a
bunch
of
npm
audit
foos
and
each
one
does
a
thing
and
by
for
legacy
reasons,
npm
audit
runs
npm,
audit,
cves
or
something
and
then
separately.
There's
a
config
item.
B
That's
like
a
comma
separated
list
of
foos
npm
audit
whatever's
and
those
things
fail
on
install
and
the
default
could
be
like
the
empty
string
and
then
you
could
put
star
in
there.
I
don't
know
like
we
could
bike
shed
all
that,
but
like
it's,
it
shouldn't
be
very
difficult
to
design
something
that
can
be
as
granular
as
people
want
from
the
beginning,
like
I'm
starting
to
get
like
yes
lent
sort
of
vibes.
B
Going
to
record
want
similar
twiddles,
you
know
to
configure
it
so
like.
I
agree
it
sort
of
approaches
like
it
dangerously
treads
in
that
that
direction,
but
like
I
think
that
if
the
goal
is
for
npm
to
be
able
to
be
prescriptive
by
default,
but
not
in
stone,
then
that
configurability
is
almost
necessary.
A
D
Yeah,
I
think
so
I
think
the
thing
I
understand.
One
thing
I
think
I
understand
so
far
is
that
so
npm
install
runs
audit
but
does
not
bubble
up
any.
D
I
guess
failures
that
it
comes
across,
so
one
thing
would
be
to
basically
add
a
flag,
so
any
level
of
granularity
that
we
add
to
audit
with,
like
an
error,
the
potential
error
state
could
bubble
up
to
the
install
on
its
own
so
that
it
still
makes
sense
to
have
sale
of
silent.
D
Warn,
I
guess,
errors
that
are
fail.
What's
the
nomenclature.
A
A
B
If
we're
deciding
that
we're
going
to
create
this
new
class
of
audit
sub
commands
for
each
of
them,
the
like
we
can
come
up
with
the
wording
but
like
it's
essentially
like
off
or
or
silent
or
whatever,
and
then
warn
and
then
like
fail
and
like
yeah
and
then
because
at
some
point
we
would
probably
want
npm
audit
to
run
all
the
sub
commands
and
we
would
want
to
be
able
to
configure
each
of
the
sub
commands
for
one
of
those
three
modes.
And
then
that
way
somebody
can
just
say.
B
Yes,
I
want
install
to
fail
when
my
set
of
audits
fails
or
no,
I
don't
want
install
to
fail.
But
I'm
separately
running
all
my
audits
right
and
then
like
the
default
can
be
that
they're
all
on
you
know
fail
or
whatever,
but,
like
I
don't
know,
you
know
we
have
to.
We
can
work
on
that,
but
I'm
not
saying
that.
I
don't
think.
B
D
Yeah,
so
so
we're
just
looking
at
the
audit,
so
is
it
so
there's.
D
A
A
Yeah,
like
that's,
why
I
said
like
there
might
be
a
not
global.
Sorry
like
an
install
level,
config
that
you
could
essentially,
and
so
just
putting
a
comment
here-
don't
worry
about
the
names
of
it,
but
it's
like
you
know
you
could
have
a
flag,
let's
say
for
install
to
tell
it
to
respect
whatever
the
audit
you
know
status
was
and
then
you
could,
as
jordan
is
recommending,
then
maybe
configure
audit
specific.
A
You
know
checks
to
have
different
types
of
sort
of
statuses
so
like
if
we
we
have
issues
with.
If
you
have
issues
with
signatures,
maybe
it
just
warns.
If
you
have
issues
with
the
remote
depths
that
you're
proposing,
then
that
might
fail
right.
So
if
you
find
issues
with
that
yeah
I
see
it.
D
Okay,
so
right
so
so,
obviously
letting
the
that
so
one
example
that
you
have
there
is
the
flag
that
just
lets
those
whatever
that
api
of
npm
audit
messaging
erroring
comes
through,
but
on
its
own
npm
audit.
Would
then
you
know
basically
we're
looking
at
using
this
like
no
remote
urls
as
a
template
for
surfacing
other
things.
So
almost
like
an
eslint
config,
you
could
say
I
want
these
two
silent,
this
one
worn
and
these
two
fail
and
then
I
suppose
at
that
point.
D
If
any
of
them
fail,
then
just
trips,
the
whole
thing
right:
okay,
okay,
so
it's
set
because.
A
You
can
configure
whether
you
want
certain
like
right
now.
You
can
do
no
audit
for
install.
You
can
do
no
fund
like
for
audit
specific
features.
We
will
want
to
configure
those
checks
as
well
right,
but
that's
that
to
me
is
a
nested
audit,
specific
configuration
and
not
an
install
configuration
right.
So
when
we're
talking
about
install,
I
think
that
there's
just
like
one
specific
flag
that
you
could
introduce
that
essentially
listens
for
or
respects.
A
You
know
the
outcome
of
audit
right
like
the
status
of
audit
and
then
we
can
introduce
all
these
new
types
of
configurations
to
audit
them
separately.
So.
B
Okay,
go
ahead.
I
put
in
chat
like
I
feel
like
there's
three
modes
for
each
of
the
audit
types.
One
is
just
off.
I
don't
care
the
middle
one
is
like
on
installs.
I
want
a
warning,
but
it
should,
but
if
I
just
run
npm
audit
foot
or
npm
audit
or
whatever
it
should
fail,
and
then
the
third
one
is
fail.
B
Install
also
like
that,
I
don't
think
there's
a
use
case
for
warning
on
the
npm
audit
right
like
so
I
like,
if,
if,
if
in
fact,
everyone
agrees
with
that,
then
that
there's
those
three
cases
is
like
off
war
and
install
fail
audit
and
then
fail
everywhere.
We
can
bike,
shut
the
names
of
them,
but
then,
like
then,
we've
ended
up
with
a
sort
of
maybe
esl
like
scenario
where
you
run
npm
audit
and
it
runs
all
of
your.
B
We
could
turn
them
all
on
on
warren
or
we
could
turn
some
of
them
on
like
fail
or
whatever.
I
don't
know
like
that
feels
like
an
extensible
system
to
me
that
that
maximally
meets
use.
Cases
and,
like
I
mean
a
bunch
of
people,
were
pissed
off
when
audit
and
fund
were
independently
added
to
install
and
people
wanted
a
way
to
turn
it
off,
and
I
forget
how
prepared
for
that.
Npm
was
like.
I
don't
know
if
npm
had
to
implement
those
or
just
tell
people
about
them,
but
like
it
seems
so.
A
Fun
funny
came
around
after
audit,
obviously
they
both
shipped
admirers.
So
it
was
a
little
bit
yeah,
not.
B
Not
the
best
experience
for
sure,
but
I
think
with
the
escape
patches,
it
would
have
been
fine
and
that's
why
I'm
sort
of
advocating
for
those
confidence.
A
B
A
D
I
I
guess
maybe
this
is
more
for
you,
jordan,
so
I
guess:
what's
the
distinction
of
just
I
mean
I
get
off
silent,
warn
and
fail?
Are
you
suggesting
that
those
three
settings
behave
differently
in
an
audit
only
versus
an
install
with
implicit
audit?
I
think
it
was
just
under
the
impression.
B
Sorry
no
go
ahead.
Oh
yeah,
the
middle
setting
is
what
the
current
default
is
for
vulnerabilities,
which
is
that
it
fails
on
audit,
but
it
warns
uninstall
and
doesn't
fail.
The
overarching
install,
oh,
and
so
I'm
saying
that
there's
those
three
modes
and
the
middle
mode
is
the
one
that
is
currently
the
only
behavior
and
the
third
mode
fail
everywhere
doesn't
exist
yet,
and
the
off
mode
exists
with
the
no
audit
config.
B
Then
you
have
a
world
where
you
can
independently
check
individual
types
by
npm
audit,
whatever
you
can
run
it
just
npm
audit
and
check
a
configured
bundle
of
things,
but
not
all
of
them,
you're
not
forced
to
do
all
of
them.
It's
only
the
ones
you
care
about
control,
whether
that
set
of
things
you
care
about,
fails,
installed
or
not,
and
then
like
you're
as
max.
You
know
you're
as
protected
as
you
want
to
be.
You
can
make
it
not.
You
can
make
it
fail.
B
Installs,
if
you
like,
don't
want
that
stuff
to
touch
your
disk,
you
can
make
it
not
fail.
Installs
if
you
have
a
separate
ci
check
and
you
just
don't
want
it
to
get
merged
right,
like
you,
can
turn
them
on
and
off
individually,
if
you,
for
example,
have
no
confidence
in
the
cve
ecosystem,
but
have
a
lot
of
confidence
in
the
other
checks
like
myself
right
to
me,
that
sounds
like
a
really
nice
world
to
be
in
and
then
a
world
where
people
will
show
up.
B
D
B
D
B
D
So
you're
just
talking
about
worn
as
the
like
you're,
basically
saying
that
each
of
these
separate
filters
or
eventually
queries
maybe
would
just
have
different
defaults
out
of
the
gate.
B
B
D
But
then
why
is
but
then
it's?
I
guess
it's
just
weird.
If
I'm
trying
to
transpose
my
audit
configurations
to
install
because
I
just
want
to
run,
install
and
get
the
the
cascade
of
all
those
checks
that
I
can
just
say
you
know,
I
don't
warn
you
whether
I
audit
or
warn
me
whether
I
install
but
you're,
basically
saving
me
a
command
at
ci
time
or
something.
A
A
Right,
okay,
I
feel
like
this
definitely
sort
of
like
goes
off
into
a
bit
of
a
tangent,
but
it
is,
I
think,
fundamental
to
the
design
of
this.
So
I
think
there's
a
bit
of
work
that
we
might
have
to
do
to
be
either
parse
out
these
two
ideas-
or
maybe
this,
like
your
rceo
and
like
mutates
into
like
this
broader
kind
of
like
strategy
for
how
we
fail
installs
based
on
audit,
auto
checks.
D
Yeah
because
it
sounds
like
there's
the
sounds
like
there's
three
things
here:
there's
one
this
query
like
categorization
or
filtering
of
actual
audit
types
like
your
cves
or
your
these
remotes,
like
whatever
flags,
then
the
second
is
how
to
actually
signal
those
infractions,
silent,
worn
or
fail,
and
then
the
third
part,
I
guess
the
third
layer
once
those
two
are
available,
is
how
to
bubble
those
up
to
npm.
Install
and
kind
of
you
know
just
get
that
you
know
if
it's
worn,
if
it's
silent,
you
don't
see
it.
A
A
Well,
we
do
have
some
so
like
we
can.
Basically
you
know
we
could
add
this
functionality
and
sort
of
bless
in
like
the
existing
vulnerabilities
checks
that
we're
doing
right
like
so
that
is.
A
Thing
that
we
have
right
now,
the
thing
that
we've
accepted
and
we're
working
on
right
now
with
the
package
security
team
here
at
github
and
guys
working
closely
with
them,
is
the
npm
signatures
on
its
signatures.
So
that's
going
to
land
soon.
So
that's
a
sort
of
secondary
check
that
we
could
also
add
to
this
that
list,
and
then
yours
could
come
in
as
sort
of
that.
A
Third
one,
the
ones
that
we
would
have
to
do
a
bit
of
work
massaging
into
this
would
be
the
engines
and
the
pure
depths
that
jordan
enlisted
here
in
terms
of
checks,
but.
B
A
A
A
Exactly
so,
the
default
configs
for
the
npm
audit
vulnerabilities
would
be
the
exact
same
behavior
we
have
today.
So
all
we're
doing
is
codifying
what
we
do
today
and
those
defaults
and
then
basically
you're,
allowing
for
people
to
opt
into
different
functionality.
Right,
like
it's
again,
an
opt-in
to
change
that
config
to
be
a
fail
right.
D
A
You'll
prefix
prefix
the
config,
if
you
can
with
audit,
if
it's
specific
to
audit
config
we've
gotten
into
the
hairy
situation
in
the
past,
where
we
have
configs
that
aren't
prefixed
with
the
name
of
the
subcommand
and
until
we
have
command
specific
configuration,
which
is
obviously
another
rfc
we've
been
waiting
sitting
on
for
a
while
that
becomes
you
know,
just
being
more
verbose
is,
is
better
so,
like
we've
done
within
it,
a
bunch
of
the
in
it
config
that
is
prefixed.
I
think
that's
a
bit
kinder
to
to
folks
to
understand
what
exactly.
A
B
B
Eases
a
lot
of
these
questions
right
like
how
do
we
do
config
when
all
the
configs
are
global,
is
just
a
big
pain
in
the
butt
but
like
once
command
can
specifically
exist.
Then,
like
we,
don't
have
to
worry
about
the
prefixes
as
much
it's
like
audit,
dot,
vulnerabilities
or
something
it's
like
audit
dot
engines,
and
it's
just
like
obvious.
I
don't
know
the
dot
is.
D
And
so
would
we
need
to
add
one
of
these
dash
dash
audits,
for
once
we
start
adding
like
signatures
and
then
this
dependency
types
would
just
npm
audit
by
itself
still
be
implicit
cve
like
a
vulnerability
check,
or
would
you
extrapolate
that
into
its
own
flag,
with
silent
warner,
error.
A
D
B
That's
why
I'm
sort
of
thinking
that
we
should
re-architect
it
so
that
npm,
audit
vulnerabilities
or
whatever
is
the
sub
command
like
and
then
like?
We
can
like
it
like
if
we
can
envision
a
backwards
compatible
way
to
make
it
so
that
npm
audit
runs
all
your
checks,
but
by
default
vulnerabilities
is
the
only
check.
That's
there
then,
like
then,
that
sort
of
does
what
arguably
it
should
have
been
designed
to
do
in
the
first
place
and
makes
vulnerabilities
not
special.
D
Yeah,
okay,
I
think
I
think
I
think
this
gives
me
some
more
stuff
to
work
with
I'll,
try
and
figure
out
kind
of
the
best
way
to
break
this
down.
I
guess
maybe
the
question
then
is
so
does
this
I
guess
maybe
this
rfc
more
more
into
a
broader
vision
of
npm
audit,
specifically
with
that,
like
cherry
on
top
of
bubbling
it
up
to
npm,
install
then,
and
we
just
basically
enumerate
a
couple
examples
of
what
its
future
state
could
look
like.
D
Yeah,
okay-
and
I
guess
the
last
thing-
and
I'm
not
sure
if
this
is
specific
to
just
remote
like
the
specific
flag
we
originally
talked
about.
I
was
looking
at
deprecate
for
messaging
examples,
but
I
feel
like
there's,
maybe
more
metadata
involved
in
some
of
this
stuff,
like
what
hey
like
in
this
example
like
what
url
is
this
tarball
actually
pointing
to
and
who
actually
is
trying
to
install
it?
D
If
it's
not
me,
I
assume
all
that
hierarchical
data
is
available
in
arborist,
but
I
wasn't
sure
if
there's
any
sort
of
like
formatting
or
it's
just
you
know,
like
I
said
I
imagine,
it'd
be
like
listed
out
or
something
like
that,
but
yeah
yeah
would
that
kind
of
metadata
be.
You
know,
acceptable
in
the
output.
A
I
think
the
default
output
no
like
we
want
to
keep
for
install
specifically
what
the
reason
why
I
said
deprecate
is
like
we
want
to
have
a
very
streamlined
default
experience
and
then
deprecate
goes
into
a
more
verbose
output.
A
A
Because
those
definitely
give
you
like
half
where
a
package
is
or
how
it's
being
like
included.
If
that's
the
kind
of
context
you
want
to
add
to
this,
but
the
default
experience
should
just
be
like
basically
a
number
in
the
output.
I
believe
a
number
is
there,
like
the
number
of
remotes
found,
let's
say:
oh.
A
A
Npm
whatever
and
it
might
be
around
npm
query-
that's
why
we
kept
talking
about
last
week
like
it
could
be
that,
like
you,
can
use
query
to
find
all
these.
In
fact,
roy
has
that
working.
I
don't
want
to
like
give
this
away,
but
like
it's
working,
I
saw
it
today
this
morning,
so
you're
on.
A
You
heard
something
special,
but
yeah,
so
you
know
you
could
run
this
command
and
you
can
see
all
these
types.
I
would
say
that
the
important
information
for
the
type
of
check
that
you're
doing
is
the
number
of
them
and
then
the
number
of
hosts
or
like
the
the
locations.
A
Unique
hosts,
I
think
that
is
very
interesting.
Like
interesting
information,
I
think
those
two
things
together
in
a
one-liner,
so
it's
like
essentially
eight
remote
depths
bound
from
four
different
hosts
like
potentially
or
it
might
be
one
host
it
might
be.
Everybody's
using
github
might
be
people
referencing
gitlab,
it
might
be
people
referencing
their
own
custom
domain
whatever
it
is,
I
think
that's
kind
of
important
and
go
ahead
guys.
C
A
I
think
it's
specifically
for
get
remote
depths
right
like
so
that
that,
when
you're
talking
about
registry
config,
that
would
not
apply
to
these
types
of
depths
right
so
host
name
for
sure,
like
we
could
bubble
that
up
for
installs,
like
the
number
like.
A
I
would
love
to
see
that
actually,
like
the
number
of
packages
installed
from
this
many
hosts
and,
like
you
say,
there's
only
going
to
be
one,
maybe
if
you're
proxying
you're
using
a
third-party
registry
and
everything's
going
to
that
one
host
you'll
only
see
that
everything's
coming
from
there,
which
might
be
the
safest
thing
right.
You
trust
that
proxy
to
give
you
the
right
packages
so,
but
that
might
I
think
that
that
kind
of
information
is
very
important.
A
When
you
see
the
number
of
sort
of
sources
of
truth,
I
think
that's
something
that
I'll
not
a
lot
of
people
understand
and
what
we're
trying
to
really
with
this
proposal
bubble
up
the
sources
of
truth
that
you're
pointing
at
and
if
you
only
expected
that
you
were
appointed
at
the
public
registry
and
you're
only
going
to
get
registry
packages,
and
you
start
to
see
that
there's
other
hosts
being
referenced.
Somehow
in
your
in
your
graph,
then
that's
that's
the
that's
the
code
smell,
that's
the
right
red
flag,
so
I
apologize.
A
We
only
got
about
10
minutes
left.
I
really
want
to
get
to
john
john
jensen's
rfc.
Here
we
joined,
I
apologize
so
owen.
Hopefully
that
gives
you
enough
to
go
on.
Did
you
want
to
go
through
this
one.
E
Sure
I
mean
just
a
quick
summary
for
anyone
who
hasn't
seen
it
yet
just
adding
the
ability
to
have
registry
scope
options
for
specifying
the
key
insert
that
are
used
for
you
know,
client
certificates
for
mutual
tls
and
specifically
having
them
be
paths
and
not
the
the
contents
themselves,
and
that
would
give
a
bit
more
flexibility
and
also
improve
the
security
around
some
of
this
stuff.
E
For
my
use
case,
specifically
at
netflix,
we
use
mutual
tls
for
like
everything
internally.
So,
as
you
know,
a
user
uses
a
service,
all
authentication
happens
via
those
client
certificates
and,
additionally,
services
service
calls
have
in
that
way
as
well
and
so
we're
using
artifactory
for
internal
registry,
and
it's
like
one
of
the
exceptions
for
how
we
do
authentication
internally,
because
we
have
you
know
these
shared
credentials
and
managing
that's
just
kind
of
a
pain
and
there's
lots
of
different
ways.
People
publish
to
it.
E
You
know
a
lot
of
them
are
doing,
npm,
publish
or
other
things
like
that,
so
this
seemed
like,
as
I
was
looking
at
the
problem,
this
seemed
like
a
nice
improvement
to
npm
to
improve,
improve
it
for
us
and
then
I
think
generally,
it
would
be
useful
for
people
so
yeah
curious
to
hear
just
high
level
comments
directions.
E
The
rfc
should
go
next,
maybe
blind
spots
things
I'm
not
thinking
about,
because
my
my
understanding,
the
code
is
still
pretty
superficial,
as
I
kind
of
dug
in
and
looked
at
the
different
pieces,
but
it
seems
to
be
mostly
inside
of
npm
registry
fetch
and
depending
on
like
if
we
move
some
of
these
checks
for
need
off.
There
may
be
some
other
changes
in
places.
C
I
would
say:
don't
worry
about
implementation
with
the
rfc,
it's
it's
a
no-brainer.
For
me,
this
is
an
oversight.
C
This
should
have
always
been
how
it
worked
with
key
files
locked
to
your
registry,
because
it's
the
same
as
off
and
as
far
as
the
potential
loss
of
user
experience,
where,
if
you've
specified
a
key
file,
we
now
assume
you're
logged
in
and
we
don't
then
have
the
check
of
like
oh
you're,
not
logged
in
that
you're
not
logged
in
as
a
is
a
user
experience
thing,
and
I
think
it's
it's
okay.
C
E
And
just
to
just
to
clarify
so
I
mean
I
did
put
a
comment
on
the
rfc
just
the
other
day,
as
I
was
digging
into
like
some
of
the
usa
or
getting
it
get
identity
stuff
and
I
think
yeah.
The
rfc
could
be
simpler
in
the
sense
of
just
focus
on
the
scoped
options.
I
do
think,
and
maybe
it's
outside
of
the
rfc
process.
I
I
would
like
to
see
this
improved
as
far
as
like
having
the
key
and
the
cert
be
acceptable
as
credentials
so
that
we
don't
need
to
like
maintain.
C
A
So
I
don't
think,
there's
a
lot
of
pushback,
I'm
not
sure
if
anybody
else
had
time
to
review
this.
I
hadn't
had
time
before
now,
so
I
appreciate
you
digging
in
and
looking
through
it
so
yeah.
I
don't
know
if
there's
much,
we
want
to
change
about
the
rfc,
but
I
would
land
on
gar
and
nelphi
will
also
have
a
ton
of
background
in
terms
of
scoped
off
so
yeah.
I
would
leverage
their
insights
and
let
them
review.
C
It
so
I
don't.
I
have
no
feedback
other
than
you
know,
take
advantage
of
the
fact
that
we're
going
to
be
out
next
week
just
leave
it
and
we
can
approve
it
at
the
next
meeting.
I
think
it's
it's
fine,
it's
and
I
saw
your
other.
I
I
really
want
to
open
the
issue
that
led
to
this
rfc.
I
remember
commenting.
A
A
One
question
john:
any
interest
in
helping
to
club
on
on
adding
this.
E
A
Cool,
it
might
be
an
opportunity
once
we're
back
yeah
once
we're
back
from
the
conference
next
week
to
maybe
set
up
some
time
to
have
you
folks
pair
and
we're
always
looking
for
like
adding
more
contributors
and
collaborators.
So
getting
your
first
pr
getting
your
first
feature
would
be
amazing
and
then
it
makes
it
more
likely.
You'll
add
more
so
yeah
cool.
Thank
you
so
much
for
bringing
this
bringing
this
up.
This
guy
said
it
sounds
like
an
oversight
on
our
part,
so
we
have
about
four
minutes
left.
A
Was
there
any
other
items?
The
last
item
is,
I
guess,
the
dependency
selector,
syntax
and
mdm
query
roy.
Did
you
want
to
give
a
quick
status
if
you're
around.
A
A
Yeah,
I
won't
talk
about
it
anymore
until
you're
ready
to
talk
about
it.
It's
basically
a
work
in
flight,
we're
hoping
to
to
share
more
maybe
next
week.
I
guess
so
cool.
I
think
that's
about
it.
Unless
folks
had
any
other
comments
or
feedbacks,
you
got
three
minutes
left.
A
If
not
I'll,
give
you
a
couple
minutes
back
and
thank
you
everybody
for
jumping
on
this
week
again,
we
won't
be
here
next
week,
but
the
week
after
we'll
be
doing
calls
again
same
time
same
place
and
hopefully
we'll
see
some
of
you
next
week
in
person
and
yeah
stay
safe
and
take
care
bye.