►
From YouTube: Open RFC Meeting - Wednesday, May 25th 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
And
it
looks
like
we
are
live
on
youtube.
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday.
May
28
2022
we'll
be
following
along
in
the
issue
that
was
created
in
the
npm
rfc's
rebo
issue,
5,
94.,
folks
and
also
spam
here,
the
meeting
of
stock
feel
free
to
add
yourselves
to
the
attendees
list
there.
A
As
is
usual,
these
calls
and
all
comms
on
the
rfc's
repo
are
covered
under
a
code
of
conduct
link
there,
and
we
ask
that
you
please
be
kind,
as
others
are
speaking
on
this
call
and
raise
your
hand
if
someone
else
is
speaking
and
we'll
call
upon
you
to
talk
and
just
quickly
in
terms
of
announcements.
A
We
want
to
reiterate
that
our
majority
of
our
team
is
headed
out
to
open.js
world
2021
2022
here.
Actually,
I've
linked
to
2021,
somehow,
which
will
be
in
austin
in
june
6
to
I
think
the
10th,
so
we're
also
all
going
to
contribute
to
the
collaborator
summit,
which
is
just
happening
right
after
the
conference
as
well.
So
we
hope
to
see
a
lot
of
folks
in
person
at
the
conference
there
in
in
about
two
weeks.
Also
wanted
to
quickly
highlight
again
the
v9
roadmap
that
we've
been
updating.
A
We've
been
making
tweaks
to
that
throughout
the
last
few
weeks.
You'll
see
the
issues,
hopefully
getting
more
flushed
out
as
time
goes
on
and
more
details
about
the
braking
changes,
but
also
anything
that
should
land
prior
to
v9,
including
any
sort
of
deprecation
warnings,
or
things
like
that
and
v8,
which
we've
been
trying
to
stay
on
top
of
and
cut
releases
for
over
the
last
few
weeks.
So
just
quick
reminder
to
go
check
that
out
feel
free
to
give
us
feedback
or
comments
on
that
issue
thread
and
appreciate.
A
Folks,
like
I
know,
jordan
has
been
keeping
up
to
date
with
that
and
just
know
that
it
is
in
flight,
sometimes
we're
working
on
it
in
real
time
so
yeah.
I
want
to
open
the
floor
for
anybody
else.
If
they
had
announcements
they
wanted
to
share
or
news.
A
If
there's
nothing,
we
have
a
pretty
small
agenda
today,
only
three
items,
so
we
can
open
open
the
floor
up
for
other
discussion
topics
if
we
want-
or
we
can
give
folks
time
back
today
if
we
blow
through
the
agenda
really
quick.
The
first
item
that
we
had
queued
up
here
is:
yours:
owen
is
the
pr
593.
A
This
is
essentially
the
idea
of
only
installing
registry
dependencies
and
ignoring
sort
of
other
types
of
dependencies
or
or
being
able
to
configure
essentially
an
install
to
ignore
other
types
of
package.
B
Sure
so
yeah
so
from
the
initial
conversation,
mostly
moved
the
content,
one
to
one
from
the
issue
and
more
or
less
just
fitted
into
the
format
of
the
rfc.
I
would
say
the
the
part
that
got
a
little
bit
of
a
deeper
dive
was
one
of
the
feedback
items
about
configurability
of
the
flag.
B
From
the
outset,
with
the
potential
to
tweak
those
in
future
december,
major
versions
most
likely
from
a
silent
to
a
a
warn,
I
don't
think
a
fail
would
make
sense,
but
yeah
I'll
leave
that
up
to
you
and
yeah,
so
just
flush
that
out
with
some
more
examples
and
as
far
as
prior
art,
I
mean
all
the
major
package
managers
support
this
url
and
get
repo
convention,
but
none
of
them
from
what
I
see
call
that
out
as
a
potential
anti-pattern,
at
least
from
the
context
of
our
conversation.
B
So
I
think
it's
an
opportunity
for
npm
to
be
a
first
mover
in
this,
which
I
think
is
great
oftentimes.
You
know
kind
of
helps,
set
the
pace
and
you
know
commitment
to
security,
which
is
great
they're.
I
think,
for
the
sake
of
so
I'll
pause
in
a
second,
so
could
definitely
flesh
out
more
from
that
bit
of
information.
But
I
think,
for
the
benefit
of
this
call,
I
did
have
a
couple
bike
shed
items
that
I
think
are
worth
chatting
about
in
real
time.
Jordan.
B
Sorry,
we've
spoken
to
a
couple
of
them,
so
I
can
jump
into
those.
If
there
are
no
questions
on
what's
presented
so
far,
go
ahead.
C
Yeah,
and
so
the
comment
I
made
was
essentially
I
I
think
that
there
should
be
the
modes
of
operation
right.
There
should
be
the
current,
the
silent,
the
current
behavior.
Obviously
there
should
be
I
like
warren,
that's
a
like.
That's
almost
something
npm
doesn't
have
to
do
as
a
semi-major.
It
could
just
do.
C
Maybe
the
the
problem,
though,
is
that
warning
and
failing
are
both
modes
that
I'd
want,
but
I'd
also
want
both
of
each
of
them
to
have
the
granularity
of
directs
only
or
include
transitives,
and
so
essentially
I
want
five
modes:
silent,
worn
on
directs,
fail-on-directs
worn
on
everything
fail
on
everything
and
the
imp.
The
reason
there
is
that
I
can
control
my
directs.
C
Even
if
I
want
the
repo
for
everyone
else
to
only
fail
on
directs-
let's
say
yeah,
I
don't
know
the
best
way
to
like
bike
shed,
how
those
five
modes
can
can
be
configured
but
like
it
seems
important
to
me
to
offer
all
five
right
off
the
gate.
B
Yeah,
I
was
going
to
end
this
by
offering
to
actually
work
to
implement
this,
so
I'll
acknowledge
the
additional
cyclomatic
complexity
in
that,
but
I
have
no
disagreement
with
that
on
the
surface
level,
but
yeah,
I
think
that's
you
know,
I
think
that's
certainly
open
worth
opening
for
debate.
So
it
sounds
like
the
the
options
are
good
in
terms
of
the
surface
level
to
the
user
yeah.
I
could
go
either
way.
I
guess
I'm
not
sure
what
others
think
about
being
able
to
turn
the
dial
on
a
per
dependency
type.
B
I
don't
know
if
that
then
oh
yeah
direct
versus
transitive.
I
suppose
that
covers
the
spectrum
of
all
dependency
groups.
I
think
we're
going
to
call
them
like
pure
optional.
You
know
all
that
stuff,
so
I
figure
it's
just
it's
one
of
two
buckets
irregardless
of
the
grouping
or
key
and
package
json
yeah.
C
And
that's
actually
a
whole
other
thing
that
I
hadn't
thought
of
then
is
being
able
to
set
one
of
those
five
modes
per
dependency
group,
because
maybe
my
dev
depths,
I
don't
care
if
they
install
non-registry
depth
or
runtime.
That's
I
do,
and
vice
versa.
C
A
So
we've
been
having
some
internal
discussion
about
this
in
a
couple
different
ways:
one
sort
of
what
you're
getting
at,
at
least
with
all
of
these
different
wants.
Jordan
is
there's
no
really
expressive
way
of
creating
sets
and
groups
of
dependencies
right,
and
so
I
think
we're
going
to
get
there
with
npm
query
right
so,
like
the
dependency
selector,
syntax
potentially
can
help
here
in
the
future.
When
we
have
that,
but
specifically
for
this,
this
rc,
I
think,
we've
actually
been
discussing.
A
Instead
of
just
the
expansion
of
the
dependency
groups
and
you're,
saying
transitive
versus
direct
dependencies,
we've
been
discussing
actually
the
types
of
dependencies
so
like
git,
verse,
remote
versus
file,
so
those
are
the
actual
types
that
we
were
considering
having
individual
flags
for,
because
right
now
this
is
a
boolean
for
on
off
just
on
registry,
and
it
basically
ignores
those
other
four
or
five
different
dependency
types
versus
having
five
flags
that
are
specific
to
those
types
and
the
way
in
which
we
saw
you
working
around
this.
A
Our
recommendation
would
be
to
utilize
overrides
to
essentially
be
the
mechanism
in
which
you
opt
into
using,
let's
say,
a
git
type
depth,
for
whatever
reason
you
want
to
use
a
git
dependency
for
a
transitive
depth,
you
would
actually
have
to
explicitly
opt
into
using
an
override
which
would
not
be
affected
by
those
flags
right
so
and
again.
Ours
and
luke
actually
brought
this
up.
A
C
And
well,
and
it
does
sort
of
apply
globally
right
like
in
the
same
way
as
is
only
dev
or
everything
or
like
only
production
or
only
dev,
or
everything
right
is
sort
of
a
mode
that
kind
of
conceptually
applies
to
every
npm
command.
I
can
see
without
having
an
audit
of
them
in
my
head.
I
can
see
almost
every
npm
command,
also
care
being
having
a
valid
use
case.
For
saying
I
only
want
to
look
at
dev
versus
prod.
C
I
only
want
to
look
at
registry
depths
versus
at
file
depths
and
so
on,
and
so
I
it
does
sound
like
a
good
idea
to
try
and
with
npm
query
in
mind,
think
of
a
holistic
way
to
provide
that.
But
there's
I
mean
like
I.
I
still
have
open
issues,
because
I
need
npm
explain
to
only
work
on
production
depths,
because
I
don't
care
how
it's
there
from
the
dev
depths.
C
I
care
how
it's
there
from
production
depths
and
that
currently
doesn't
work
properly
and
we've
discussed
that
before,
but
like
it's
another
one
in
the
long
list
of
things
where
there's
almost
a
universal
need
to
be
granular
about
what
the
command
applies
to,
whether
it's
explain
or
ls
or
you
know,
or
this
or
various
validations
right
and
I'd
probably
want
that
on
audit
stuff
too,
and
so
it
almost
seems
like
something
should
be
holistically
designed
to
work
with
everything
and
not
one
command
at
a
time
and
if
it
overlaps
with
query
syntax
awesome
like
there's
some
synergy
but
like
yeah
so
yeah,
I
don't
have
any
ideas
about
like
the
implementation
or
the
the
design.
B
No,
I
like
the
idea
of
using
overrides
as
a
kind
of
a
short
circuit
to
kind
of
what
jordan
was
saying,
is
kind
of
like
a
v1
and
then
potentially,
like
you,
said,
leveraging
the
query
syntax
to
drill
down
per
grouper
set.
You
know
so
you
can
opt
in
at
any
of
those
levels,
but
it's
nice
to
have
the
override
just
you
know,
escape
and
avoid
the
noise.
B
B
I
think
it
would
be
great
to
be
able
to
have
a
nice
path
towards
interrupt
with
the
query,
syntax
stuff.
C
And
another
wrinkle
here
is
that
arguably
this
should
be
maybe
like
npm
on
its
signatures,
an
npm
audit
thing,
some
like
an
npm,
auto
sub
command
like
npm
audit
dependency
types
or
something,
and
then
and
each
of
the
npm
audit.
Things
should
eventually
have
a
way
to
be
automatically
invoked
as
part
of
npm
install
and
right
as
like
the
same
way,
npm
audit
vulnerabilities
currently
is
and
then
separately,
every
npm
audit
subcommand
has
a
need
for
granular
overrides,
not
like
npm
overrides,
which
are
for
swapping
out
depths.
C
But
for
saying
like
for
this
step,
I
want
this
cve
ignored
for
this
step.
I
want
the
license
check,
ignored
for
this
step.
I
want
the
dependency
type
ignored
and,
and
if
we
think
of
it
more
in
that
terms
as
an
npm
audit
sub
command
and
then
also
try
and
design
a
holistic
way
of
granular
ignore
settings
for
npm
audit
things,
then
maybe
that
also
provides
the
mechanism
for
like
how
you,
how
you
say,
what's
permitted
in
your
debt
graph
and
what's
not
permitted.
A
A
First
before
you
do
a
command
even
before
you
potentially
even
like
it's
hard
to
think
of
doing
an
install
and
before
doing
query,
because
you
need
to
essentially
have
that
information.
So
it's
like
that
secondary
install
is
like
like
having
that
query
syntax
somehow
applied
to
install,
I
think,
is
important
being
able
to
to
do
that.
But
you
can
imagine
that
what
you're
asking
for
here
is
I
want
to
just
exclude.
A
I
don't
want
to
install
essentially
anything
that
isn't,
let's
say
a
let's
say
you
only
want
to
be
permissive
to
registry
depths.
You
can
essentially
exclude
using
the
query
syntax
before
you
do
an
install
right,
so
the
set
already
is
like
removing
those
depths
from
installation
from
reification,
essentially
right.
A
A
And
then
similar
to
audio
screen
yeah,
so
it's
similar
to
audit,
like
I
imagine
if
you
just
said,
like
audit,
had
like
a
warn,
if
you
know
warn
if
exists
or
something
like
whatever
and
the
query
is
the
key
thing
here.
You
query
could
be
very
robust
in
terms
of
and
is
robust
in
terms
of
setting
like
vulnerable
states
to
a
package.
A
So
you
can
do
the
query
for
any
vulnerable
packages
pass
that
to
npm
audit
and
empy
is
going
to
be
the
thing
that
throws
in
the
in
your
terminal
right
so
like
that
is
then
becomes
oh
well.
Npm
audit
is
pretty
dumb.
It's
really
npm
query!
That's
going
to
be
running
the
the
you
know,
doing
that
filtering
initially
right
so
and
that's
the
just.
A
These
commands
become
like
executing
so
anyways,
that's
kind
of
like
where
my
head
goes
in
terms
of
like
these
sets
and
these
groups
and
trying
to
limit
maybe
how
many
more
flags
we
introduced
that,
like
further
sort
of
I
I
don't
know
like
further
ad
sort
of
disparate
ways
of
creating
groups,
and-
and
I
don't
know
like
it's
yeah,
and
until
we
have
the
query
like
command
out,
I
think
we
should
like
pause
any
further
kind
of
like
nuanced
aliasing.
You
guys
grouping
nuance
to
like
like
mapping
of
depths
to
anything.
A
This,
though,
specifically,
I
think,
is
tailored
to
output
right,
like
it's
more
specific
to
like
actually
what
we're
going
to
do
when
we
have
found
those
steps
right
and
so
like
that's
where
I'm
like.
Okay,
this
totally
makes
sense,
and
we
can
potentially
move
forward
with
this,
because
essentially
we're
like
warning
on
our
best
practices
and
that's
kind
of
where
I
also
see
what
you
said,
jordan.
A
C
So
I
I
like
overall,
I
like
the
direction.
I
think
that
the
query
syntax
gives
us
a
way
to
kind
of
universally
add
the
the
granularity
I've
been
talking
about.
We
just
have
to
make
all
the
commands
like
obey
it
or
whatever,
but
you
know
that
that
just
puts
a
lot
of
weight
on
you
guys
to
do
the
work
to
implement
it
since,
like
if
we're
deciding
that
it's
effectively
blocking
a
whole
lot
of
other
things.
A
Yeah
so
like
originally
internally,
we've
talked
about
this
syntax,
where
essentially,
we
would
add
like
a
flag
like
ignore
git
depths,
and
then
that
is
that's
false
by
default
right
now
and
in
the
and
you
can
set
it
to
true
to
essentially
like
passing
that
flag
would
say
it's
true
and
you
would
essentially
be
able
to
take
more
githubs
holistically.
A
C
Like
anything
that
allows
someone
to
have
a
get
a
depth
graph,
they
that
isn't
ideal,
and
then
they
don't
know
about
it.
That
seems
like
a
harmful
setting.
It
should
fail
the
install
and
then
and
then
tell
them
here's
how
you
can
get
work
around
it.
If
you
really
have
to
have
this
bad
thing,
but
like
we
don't
want
to
be
making
ignore
the
first
class
thing
that
should
be
like
after
your
ci
has
failed
and
everyone's
alerted,
then
we
sneak
in
and
like
here's,
how
you
go
ignore
it,
but
like
the.
A
Only
problem
is
the
lock
file
right
now,
right
so
like
we
are
tracking
these
dependencies
in
the
log
file
and
like
again,
we
just
recently
had
this
conversation
and
it
was
in
slack
in
our
team
and
other
folks
can
chime
in
if
they
want
as
well
from
our
team.
But
I
think
the
idea
here
is.
We
would
actually
not
want
to
put
any
of
these
steps
that
aren't
a
registry
depth
in
the
log
file
going
forward.
A
That
was
actually
the
the
thing
that
we
are
considering
and
that's
a
major
breaking
change
so,
which
is
why
like?
How?
How
do
we
get
from
where
we
are
today
to
that
future,
which
is
we
don't
want
to
be
storing
in
a
log
file,
something
that
we
know
is
immutable
right,
like
a
remote,
a
file,
a
reference
to
get
a
git
depth
like
we
want
to
just
like
completely
say
we're
going
to
blow
up.
If
you
we
see
you
trying
to
give
us
one
of
those
types
of
depths
so
blowing
up
in
the
future.
C
Right,
but
that's
warranted
right
like
ignore
means
pretend
it's
not
there
and
actively
prevent
me
from
seeing
it
and
that,
as
what
I'm
saying
is
harmful
warning
is
great
like
and
then
like,
and
it's
fine
to
have
a
way
to
ignore
them.
It's
just
like.
We
should
never
that
should
never
be
anyone's
first
resort.
They
should.
They
should
only
get
be
told
how
to
ignore
it.
Once
like
they've
been
clearly
told
that
it's
bad
and
warn
and
fail
are
like
the
reason,
the
things
to
to
get
them
there.
A
A
A
We
know
that
this
is
not
going
to
be
easy,
not
even
saying
that
we
try
to
do
it
for
the
next
major
just
so
we
don't
get
slammed.
You
know
in
the
ecosystem,
like
by
people
being
angry
with
us,
but
I
think
that
this
is
the
right
path
forward.
Like
there's,
no
reason
we
have
zero
confidence
in
your
lock
file
right
now,
which
is
not
good
like.
A
You
know
replacing
the
source
code
in
the
repo
and
essentially
that
you
now
have
a
different.
You
know
you
have
different.
You
know
contents
and
package
like
a
different
package
on
disk
now,
even
though
the
lock
file
like
is
there
to
lock
you
in
to
what
you
thought
was
the
contents
of
of
your
tree.
Right
like
this
does
not
make
sense,
I
don't
know
so
how
we
get.
There
is
interesting
if
everybody
is
okay
with
that
as
a
concept.
A
D
So
warn
by
default
and
then
opt-in
to
actually
failing
or.
C
Well
born,
but
that's
they're
still
that's
three
right.
I
think
we
still
need
the
transitive
versus
like
like
all
versus
direct
like.
I
think
that
always
needs
to
be
the
case,
because
any
the
only
actionable
things
are
the
directs
and
that's
the
but
yeah.
Sorry
no
go
ahead.
I
mean
that's.
I
yeah,
that's
the
query
stuff
and
I
recognize
that
but
like
that's,
I.
A
The
actual
thing
for
install,
though,
is
you
can
change.
You
can
basically
add
if
you
do
not
want
care
about
like
if
you
do
not
want
to
meet.
Are
you
if
you
want
to
use
a
git
dependency?
You
can
use
that
do
that
in
an
override
right
right?
So
that's
how
you
get
around
that
as
a
direct
dependency.
C
But
I
don't
want
to
have
to
create
an
override
for
all
of
my
transitive
get
depths
for
things
that
I
don't
control.
I
it's
totally
fine
and
reasonable
to
say
if
you
want
a
direct
git
depth,
you
need
to
depend
on
it
for
real
and
then
use
an
override
to
point
to
the
github.
Fine,
that's
my
own
package
json!
You
can
make
me
do
whatever
annoying
stuff.
C
C
If
all
of
those
issues
are,
then
everyone
has
to
go
file
issues
about
it.
So
so
I
I
hear
what
you're
saying
that
that,
yes,
eventually
it
needs
to
be
warned
on,
there
needs
to
be
a
way
somebody
can
get
the
warning,
but
by
default
we
do
not
want
to
mobilize
an
army
of
users
to
go
and
burn
out
all
the
maintainers
who
are
using
git
depths
and
currently
there's
no
guidance
that
they
shouldn't
so
like.
B
C
I
think
that
the
first
step
is
telling
people
don't
directly
depend
on
gift
depths
when
that
is
established
as
a
best
practice
and
when
it's
really
easy
for
everyone
to
see
when
they're
doing
it,
and
when
it's
really
easy
to
see
to
get
warnings
about
it.
I
think
that's
the
first
step,
because
then
the
light.
First
of
all
from
that
point,
the
likelihood
that
that
all
of
the
maintainers
in
question
are
don't
become
aware
of
that
best
practice
and
adapt
to.
C
It
is
small
and
then
second,
if
there
is
a
way
first
for
the
extra
vigilant
person
to
opt
in
to
checking
all
their
entire
depth
graph,
then
they'll
see
those
warnings
and
the
maintainers
will
get
a
few
issues
and
there
will
be
some
pressure
to
migrate.
But
there's
a
big
difference
between
that
and
every
random
engineer,
getting
a
warning
about
it
and
then
going
to
complain.
A
A
Sure
and
we're
trying
to
improve
deprecation
work
exactly
right,
like
we
have
a,
we
have
a
ticket
to
modify
that
fix
that
up.
The
specifically
with,
though,
which
is
what
I
would
liken
this
to
in
terms
of
like
the
community
needs
to
clean
this
up
and
like
needs
to
become
aware
of
this
problem
that
exists
within
within
their
their
packages.
A
The
transition
is
important
right
sure,
exactly
how
each
other
is
important,
yeah,
yeah
and-
and
so
enough
was
asking
you
know,
can
we
even
find
out
about
our
own
usage
again
once
we
have
npm
query,
this
will
become
a
lot
easier
for
you
to
find
whether
or
not
you
are
susceptible
or
within
your
graph.
If
you
have
git
dabs
or
these
different
types
of
depths,
and
like
you
become
aware
of
this,
I
know
that
zbe
who's
come
to
these
calls.
A
Quite
a
few
times
he
wrote
npm
audit
resolver
he's
actually
done
some
research
in
the
space
of
the
top
10
000
packages
by
dependents
and
their
usage
of
git
depths.
Just
recently.
They
did
this
work
last
week
based
on
a
twitter
thread
and
came
up
with
that.
The
the
fact
that
they
only
found
84
packages
that
had
get
dependencies
of
the
top
ten
thousand,
so
it's
not
that
this
is
like
a
crazy,
especially
within.
A
A
We
will
break
every
single
time,
trying
to
tell
the
end
user
that
we've
created
some
sort
of
artifacts
like
a
lock
file
that
is
going
to
skewer
them
in
and
try
to
create,
like
a
immutable
reproducible
build
of
their
you
know
their
their
project.
A
That's
not
possible
right
now,
if
we
allow
for
git
depths
and
these
other
types
of
depths
and
lock
files,
so
that's
kind
of
where
I'm
I'm
willing
to
be
more
aggressive
about
getting
to
that
future,
because
we're
already
like
broken
we're
already
like
like
they
see
the
the
ecosystem
is
broken
right,
like
your
your
project
is
broken.
We
can't
reassure
you
in
any
sense
that
you're
going
to
get
the
same
project,
which
you
run
install
twice
so
that
to
me
is
like
whoa,
that's
a.
We
need
a
bug
fix.
C
C
I
agree,
but
I'm
I
am
confident
that
anyone
who
cares
about
reproducibility
will
notice
like
will
quickly
opt
in
to
checking
their
entire
graph.
Those
people
don't
need
any
encouragement
to
go
the
most
paranoid
possible
route
and
those
people
also
understand
the
context
and
will
be
able
to
file
helpful
issues
and
so
on,
and
so
I
I
don't
think
that,
like.
I
think
that
a
staged
approach
is
still
going
to
be
just
as
successful
here
and
yeah
as
as
milt
says
as
well
like.
C
This
is
much
more
important
for
production
depths
than
it
is
for
dev
depths,
which
speaks
to
the
need
for
type-based
granularity,
but
the
yeah
I
mean
I
mean
there's,
there's
an
open
issue
as
well
about
the
ability
to
make
a
lock
file
that
only
locks
down
production
deaths
which
you
know
has
been
sorely
needed
for
a
long
time.
So,
there's
like
a
lot
of
there's
a
lot
of
overlapping
different
things
here
that
play
into
it
right
and
yeah.
I
mean
I
would.
C
C
A
lot
of
overlapping
things
here
and
I
think
it's
I
think-
that
avoiding
maintainer
burnout
needs
to
be
a
very
high
priority.
A
So,
whether
the
specifically
for
this
rfc,
so
we
can
get
going-
and
it
sounds
like
owen-
you
you're-
actually
willing
to
do
something
work
here.
If
we
can
come
to
a
consensus
on
what
we
want
to
do
so
in
terms
of
next
steps
here,
it
sounds
like
our
we're
willing
to
warn
on
anything
that
is
not
a
registry
debt.
Is
that
what
everybody?
This
group
has
kind
of
agreed
on
we're
willing
to
maybe
ship
a
miner
that
starts
to
warn
on
install
when
we
see
anything
that
is
in
a
registry.
C
C
That
style
of
warning,
where
the
directs
are
up
front
and
center
and
the
transitives
are
just
a
summary
and
then
there's
a
way
to
opt
into
all
of
them.
That
would
that
wouldn't
bother
me
because
then
the
worst
noise
people
get
is
a
single
sentence,
saying
you
have
n
transitive
depths
that
use
non-registry
things.
A
Right
so
it
seems
like
because
creating
a
new
command
or
even
nesting
in
that
new
sub
command,
like
in
audit
to
get
that
information
out
sounds
like
it
should
almost
come
secondary
to
us
shipping
query
because
query
will
be
able
to.
We
can
quickly
be
able
to
say
sure
in
a
one
liner.
We
can
give
you
that
information.
A
If
you'd
like
to
see
those
depths,
you
can
run
this
query
to
get
those
steps
right,
instead
of
creating
what
we're
proposing
with
deprecated,
even
we're
creating
a
brand
new
command
for
for
information
that
you
could
easily
get
with
npm
right.
So
it
seems
like
we
need
to
ship
npm
query.
First,
before
we
do
the
warnings
even.
C
And
possibly
as
well
like
it
will
be
heavily
related,
the
sub
command
specific
config.
I
think
those
two
things
together
the
thing
where
you
can
do
a
config
that
only
applies
to
a
specific
sub
command.
Those
two
things
together,
unlock
a
lot
of
improvement,
occur
like
a
lot
of
rfcs,
will
end
up
being
implementable
as
a
combination
of
those
two,
but
not
necessarily
as
one
of
them
alone.
A
Okay,
so
it
does
sound
like
we're
a
little
bit
blocked
on
this,
like
until
we
cut
query.
Maybe
what
would
be
nice,
though,
is
to
modify
this
rc
a
bit
onto
I'm,
not
sure
if
you've
seen
the
deprecated
rfc
or
deprecate
npm
deprecate
rfc.
We
can
share
that
with
you
to
show
you
kind
of
like
how
we
consolidated
the
log
output
for
that,
because
we
I
I
to
jordan's
point
like.
A
I
think
it
would
be
like
not
a
great
experience,
if,
like
you
end
up
with
like
potentially
100
git
depths
and
you
get
100
logs,
outputs
warnings
or
or
whatever
so
consolidating
those,
I
think,
is
important,
and
then
we
can
like
shift
the
name
of
the
flag,
like
I'm,
not
sure.
If
it's
going
to
be
whatever
it
is.
B
Yeah,
so
just
to
clarify,
so
I
from
what
I
understand,
we
want
to
predicate
this
on
npm
query
already
being
available,
and
so
I
guess.
B
I'm
not
super
familiar
with
that,
so
I'll
brush
up
on
it,
but
presumably
so
I
guess,
if
you
didn't
use
it
with
them
pm
query,
is
there
still
like
a
default
behavior
like
if
you
just
run
only
registry
debts,
it
would
just
warn
across
all
your
dependencies
and
then
you
could
drill
down
using
query
to
be
like
only
only
peer.
Only
this
only
that
so,
basically
like
a
filtering
system
from
that
whole
bucket
that
you
would
get
by
default.
Is
that
kind
of
the
way
to
think
about
this.
C
And
I
wanted
to
add,
you
said
only
registry
depth.
It's
not
actually
that
exactly
because
files
and
links
are
fine.
It's
it's
the
only
remote
depths
that
you
want
are
registry
depths.
So
it's
like.
I
don't
like
this
gets
really
verbose,
but
it's
like
you,
don't
want
any
non-local
dependencies
except
registry
dependencies
so
like
and
and
and
it's
and
again
at
direct
dependencies
files
and
links
are
fine
but
transitively.
That's
not
necessarily
fine
right
like
but
like.
C
If
you
have
a
workspace
like
I
don't
know,
there's
just
there's
a
lot
of
there's
a
lot
of
subtlety
here
that
we're
like
where
the
real
goal
is
to
make
sure
that
things
are
reproducible,
and
that
means
that
everything
has
to
be
local
or
from
a
registry
and
anything
that
is
remote.
It's
not
from
a
registry
is
the
problem.
C
A
C
Mean
I
have
a
predicate
package
that
tests
feature
detects
like
when
export
patterns
work
in
node
and
it
uses
a
bundled
file
dependency
to
do
that.
Right,
like
that
works
perfectly
fine,
it's
perfectly
reliable,
there's
nothing
pulled
except
from
a
registry,
and
that
should
not
start
warning
for
people.
C
B
C
B
Is
there
a
convention
of
these
kind
of
things
speaking
in
the
affirmative,
so
would
it
be
like
only
like
continuing
like
the
only
xyz
depths,
or
could
you
invert
and
say
no,
no,.
B
Yeah,
I
don't
know
if
there's
a
particular
affirmative
tone,
that's
preferred
so!
Okay,
sorry,
so
do
someone
mind
re-winding
how
I
should
update
what
we
have
so
far
just
to
like,
I
guess
so
is
it
for
sure
that
we
want
to
build
on
top
of
query
and
then
and
then
for
and
then
it's
on
the
other
is
the
consolidated
output.
B
B
Okay,
so
if
I
were
to
update
this,
I
think
that's
the
implementation
or
whatever
the
section
is
that
explains
it,
so
there
would
be
so.
Would
there
be
a
so
I
guess
what
would
be
the
default
state
with
just
the
command,
as
is?
Is
that
worn
on
all
or
just
worn
on
direct
and
then
every
and
then
on
all.
B
Okay
and
then
with
the
inclusion
of
query,
npm
query,
so
then
the
examples
would
we
want
to
demonstrate
how
you
can
effectively
override
to
your
needs
like
exclude
or
include
a
group
of
depths,
or
I
guess
we
with
query,
then
we
wouldn't
need
the
override
escape
patch
at
all.
Would
we
just
funnel
everybody
through
using
npm
query
in
that
case,.
A
So
install
is
not
going
to
be
aware
of
mp,
employee
or
or
take
a
query
flag
for
a
while,
like
probably
six
months,
ish
like
like
it's
gonna,
be
towards
2023.
I'm
guessing
like
we're
not
going
to
add
support
for
the
query
syntax
into
the
rest
of
the
commands.
I
don't
think
it
will
depend
on
how
work
lays
out,
but
npm
query
will
likely
be
ready
as
soon
as
roy's
done
typing.
C
He's
he's
been
working
he's
been
working
like
a
crazy
person.
Over
there
I
mean
owen.
I
I
I
would
love.
Is
there
a
reason
why
we
wouldn't
want
to
go
with
owensrfc
being
an
npm
audit
sub
command
that
npm
install
runs
by
default?
The
same
way,
it
currently
runs
npm
audit
vulnerabilities
or
whatever,
by
default,
because
eventually
I
want
to
be
able
to
run
npm
audit
signatures
by
default
and
install
as
well.
It's
the
only
reason.
A
C
Yeah,
I'm
still
saying
we
wait
for
query.
I'm
saying
both
of
those
things
that
that
what
that
the
way
that
it
be
implemented
is
query
is
implemented
first
and
then
owensrfc
becomes
npm
audit
dependency
types
or
something,
and
then
npm
install
also
at
the
same
time
as
that
sub
command
is
introduced.
Npm
install
runs
it
by
default
and
there's
some
config
command
specific
config
for
install
that
you
can
skip
it
right
like
and
then,
and
that
way
people
can
run
it
themselves.
They
all
the
configuration.
C
Is
there
and
npm
install
just
invokes
it
and
the
command
specific
config
means
you
don't
have
to
pollute
the
install
config
with
anything.
Except
do
you
run
this
or
not,
and
then
all
the
config
they
want
for
npm
audit
dependency
types
can
be
command
specific,
config
config
there.
That's
why
I'm
saying
both
of
those
features
kind
of
gate,
a
lot
of
stuff
yeah.
A
Only
thing
I'm
considering
is
like
what
happens
to
the
log
files
right
with
these
flags
like
do
they
affect
the
log
files
at
all?
So,
like
we're
just
warning
right
now,
are
we
planning
to
do
anything
with
log
files
before
the
next
midpoint?
Well,.
C
C
Currently,
but
we
should
eventually,
I
mean
the
whole
point
of
running.
The
npm
audit,
like
npm
audit
in
install,
is
because
people,
presumably
don't
want
vulnerabilities
in
their
node
modules,
and
eventually
I
would
expect
we
want
to
wait
for
somebody
at
least
to
opt
in
to
saying
when
there's
a
cve
fail,
the
whole
install,
don't
let
anyone
do
anything
and
similarly,
when
the
signatures
are
invalid,
don't
install
anything
because
no,
I
can't
trust
any
of
the
files
anymore
and
when
the
dependency
types
are
invalid.
C
The
same
reason
we
want
that
out
of
block
files,
don't
do
anything
right
like
warning
is
is
just
like,
like
hey,
I
hope,
you're
paying
attention
right
like
unless
we're
actually
failing
we're
not
getting
anything
done
yeah
and,
in
particular
in
my
organization.
I
want
to
be
able
to
configure
npmrc
so
that
no
developer
can
get
any
work
done
when
things
are
broken.
C
A
So
would
you
be
willing
owen
to
kind
of
change
this
up
a
little
bit
then
the
rfc
then
could
be
instead
of
npm
install
specific,
it
becomes
npm
audit
and
a
sub
command
there.
You
can
name
it
as
jordan's,
suggesting
like
remote,
like
has
remote
depths
or
something
I
don't
know.
C
To
being
very
specific
to
that
use
case
is
a
more
generic
npm
audit
dependency
types
or
whatever
that
has
a
default.
That
only
allows
registry
things
and
local
things,
and
that
way
people
who
can
just
opt
out
of
it
when
they
want
to
using
query
syntax
and
command
specific
config,
which
should
theoretically
be
built
by
them,
so
dependency
type
check
or
something
yeah.
Whatever
terminology
we've
decided
for
this
yeah.
B
Okay,
so
piggyback
this
off
of
npm
audit
instead
warn
by
default
reference
npm
deprecate
for
well,
I
guess
the
output
messaging
will
just
be
taken
care
of
by
npm
audit,
or
do
I
still
have
to.
B
To
write
that
yeah
that
okay,
no
problem,
okay,
so
warned
by
default
reference
npm
deprecate
for
output
messaging
example
and.
B
Sweet
and
then,
as
a
new
bike,
shetty
name
renamed
to
only
non-remote
depths.
For
now,.
A
C
And
the
default
would
be
what
we've
been
talking
about
right,
just
local
and
registry,
but
that
way
we
don't
have
to
come
up
with
a
command
or
a
config
name.
That's
expressive!
For
this.
We
just
have
to
say
like
here's,
the
default
query,
selector
string
or
whatever
and
then
like
configure
it
to
whatever
you
want.
You
know.
B
I'm
just
gonna
tie
in
ensure
proper.
B
Communication
documentation
to
jordan's
point.
You
know
we
should
kind
of
start
setting
the
expectation
of
the
new
standard
going
forward,
or
at
least
our
recommendations.
You
know
maybe
yeah
and
so
last
thing,
then,
are
we
eliminating
a
predicate
on
npm
query
or
that
be
like
a
future.
A
A
Can
happen
separately
and
if
that
happens
separately,
then
I'm
also
way
less
cagey
about
having
npm
query
in
place
before
you
start
warning
on
git
devs,
because
then
it's
like
really
something
somebody's
opting
into
running,
and
then
you
can
go,
find
your
github.
So
that's
fine.
My
only
concern
with
like
adding
it
to
install
by
default
would
be
that
there's
no
way
for
you
to
fix
or
resolve
that
problem
like
it's.
It's
similar
to
the
deprecation
warnings
where
it's
like.
How
do
I
fix
this?
B
I
think
I
got
it.
I'm
gonna
type
in
the
comment
in
the
issue
now
so
I'll
cc
you
both
and
you
can
just
make
sure
I've
got
it
right
and
then
so
I'll
update
the
rfc,
and
then
you
know
once
that
goes
through
then
yeah.
You
can
talk
about
what
it
takes
to
land
it
from.
Like
an
actual
you
know,
working
you
know
committing
the
code
perspective.
B
Okay,
didn't
mean
to
take
all
the
time,
but
I
think
it
was
good
to
just
basically
it's
like
99
there.
It
seems
and
seems
certainly
achievable
as
is
so
thank
you
for
all
the
feedback
I
yield
back.
A
To
this
post
thanks,
thank
you.
We
had
a
very
light
agenda.
The
only
other
item
items
on
there
were
actually
two
that
we've
been
discussing
for
quite
a
while,
which
is
the
fancy
selector
syntax.
No
real
update
there
and
roy
says
he's
roughly
70.
Complete
is
what
I
heard
today.
I
don't
know
if
that's
optimistic,
judging
of
where
things
are
at
with
it,
but
yeah
I
I
don't
know
if
you
want
to
give
an
update
roy
on
on
where
we're
at
with
the
selective,
syntax
and
fancy.
A
Fire
it's
on
fire
he's
on
fire
and
then
I
think
the
other
only
other
item
we
had,
which
is
the
run
scripts
short
circuiting
on
scripter.
This
is
number
575..
We've
been
talking
about
this
for
a
while.
A
I
think
we
have
some
work
queued
up
now
to
to
support
the
various
flags
that
would
we
wanted
to.
So
I
think
we
can
potentially
remove
this
from
the
agenda
because
we've
talked
about
it
for
a
number
of
weeks
yeah.
A
This
is
essentially
the
topological
ordering
plus
like
a
fail,
fail
fast
mode
yeah,
I
think
that's
it
did
anybody
else,
have
any
other
topics
they
want
to
bring
up
with
a
few
minutes
left
that
we
have.
D
A
D
D
Maybe
next
week,
if
do,
we
still
have
a
rfc
meeting
next
week.
A
Yep,
the
only
week
that
we're
missing
is
the
week
that
will
be
in
austin.
A
Awesome
cool
well
that
pretty
much
brings
us
to
time.
I
appreciate
everybody
jumping
on
and
I
didn't
think
we
were
gonna
use
up
the
whole
hour
today.
So
oh,
and
that
was
a
good
good
one.
I
appreciate
you
also
like
keeping
us
honest
here.
We
we
talked
about
a
lot
of
things
and
sometimes
don't
document
them
or
get
them
rolling
into
actual
rfcs,
so
yeah
nice
deep
dive
on
on
this.
A
It's
definitely
something
that
we've
been
talking
about,
like
I
said
internally
quite
a
bit,
and
I
think
it
makes
a
lot
of
sense,
especially
when
we're
hearing
about
other
ecosystems
that
are
being
affected
by
sort
of
mutable
sources
of
truth
in
their
in
their
craft,
so
yeah.
Thank
you
so
much
for
for
having
the
energy
to
to
participate.
So.
B
Yeah,
thanks
for
making
a
good
experience
to
contribute.
A
Cool,
so
we'll
see
you
all
next
week,
I
think,
and
thanks
for
jumping
on
today
cheers.