►
From YouTube: Open RFC Meeting - Wednesday, April 13th 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
Got
the
recording
started:
this
is
the
open
rfc
meeting
for
the
npm
cli
for
april
13
2022..
This
is
my
first
time
doing
it
so
bear
with
me.
We've
got
an
agenda
today,
which
I
will
share
the
link
again
here.
A
And
so
there's
a
bunch
of
items,
but
first
I
want
to
acknowledge
our
code
of
conduct,
which
applies
to
these
discussions
and
any
time
you
interact
with
our
repositories
so
review
that
at
your
leisure,
so
our
intended
outcomes
that
we've
got
we've
got
a
list.
Today
I
took
a
chunk
out
of
of
upcoming
agenda.
A
A
Hearing
none
we'll
get
right
in
so
command
specific
configuration.
A
A
There's
there's
a
lot
of
configurations
right
now.
All
of
our
configuration
is
very
global.
Can
anyone
speak
to
this
rfc
specifically.
B
B
This
is
something
npm
has
lacked
since
day
one,
and
it
was
particularly
painful
in
npm
five.
I
believe
when
the
default
changed
for
save,
because
we
couldn't
put
in
npmrc
a
way
to
keep
it
on
for
install,
but
have
it
off
for
shrink
wrap,
for
example,
and
vice
versa.
I
forget
the
exact
scenario
that
screwed
us
up,
but
it
was
a
big
pain
in
the
butt
and
was
every
time
it
was
brought
up.
B
B
A
path
to
getting
it
done
so
if
this
rfc
is
a
path
to
getting
it
done,
amazing,
I
think
like
we
should
move
to
a
world
where
almost
all
config
is
command
specific.
You
know
the
the
use
cases
for
globally
setting
a
config
item
are
should
be
minimal.
A
So
the
good
news
is,
is
that
that's
that's
a
huge
priority
for
us
right
now.
V9
is
going
to
be
a
rework
of
the
config,
so
awesome,
and
so
this
is
something
that
we
want
to
tackle.
Luke
correct
me
if
I'm
saying
anything
incorrect
here
but
yeah,
I
think
we're
gonna
we're
gonna,
take
some
time
and
refactor
config
and
command
specific
config
is
a
big
part
of
that.
D
So
I
have
not
read
the
entire
rendered
rfc
we've
had
so
many
discussions
about
it
internally.
I
wanted
to
double
check
what
it
if
it
said
anything
about
what
we
would
do
in
the
case
of
now
that
it's
command
scoped.
If
you
specified
one
incorrectly,
and
I
don't
think
it
does,
I'm
just
skimming
it
now,
but
I
didn't
know
if
that
was
part
of
this
rfc
of
like
mpm9
config
stuff
or
if
that
came
up
in
a
different
rfc
but
another
just
to
bring
it
up
now.
D
Another
change
we'd
like
to
make
is
not
have
unknown
configs
silently
do
nothing
because
we
ran
into
the
case.
You
know
as
an
example
today
of
mpmls
not
taking
omit
where
other
commands
did
and
so
npm
ls
omit
dev
just
did
the
same
thing
as
npm
ls.
So
that's
another.
D
Hopefully
part
of
this
rfc
is
as
we
make
command
specific
stuff.
We
can
more
easily
error.
If
you
say
you
know,
npm
publish,
omit
dev
or
something
we
say:
that's
not
a
valid
flag,
so
I'm
not
sure
if
that's
been
brought
up
but
or
if
that's
part
of
this
rfc
or
not.
But
I
just
wanted
to
surface
that
as
well.
A
Yeah,
this
is
really
important.
I
think
I
think
v9
will
be
really
exciting,
just
to
get
like
a
bunch
of
deprecation
and
breaking
changes
on
the
config
all
right.
D
Sorry
just
does
anyone
have
feedback
on
if
npm,
through
an
error
for
any
invalid
config
instead
of
what
it
does
now
is
silently
keep
going.
B
I
think
the
downside,
the
problem
with
that
is
that
npm
configs
can
be
used
on
multiple
npm
versions,
including
older
ones,
so
throwing
on
unvalid
can
fit
invalid.
Config
is
fine
unless
I
need
that
config
for
an
older
npm
version
to
do
the
right
thing
yeah.
B
A
Yeah,
I
think
we
could
certainly
throw
warnings
in
v9
and
maybe
even
as
part
of
that
show
a
deprecation
that
this
will
show
an
error
in
a
future
breaking
change,
something
you
know
cycle
through
it,
a
few
versions
that
might
be
a
good
idea.
C
So
good
that
was
just
clarifying,
so
is
the
idea
that
you
can
have
this
config
file
npmrc
and
have
command
specific
config,
and
it
wouldn't
error
just
by
you
running
like
install
it
wouldn't
error
for
like
config.
You
have
for
audit,
because
that
might
be
something
you
actually
only
use
in
some
other
version
right,
but
it
would
error
if
you
run
the
specific
command.
B
B
Config
also
comes
from
environment
variables,
which
are
not
always
actionable
to
to
change
so
like
validating
and
also
npmrc
can
come
from
any
of
four
locations,
only
two
of
which
are
controlled
by
the
user
and
only
one
of
which
is
project
specific,
so
like
it
seems,
the
the
utility
of
throwing
is
high
in
a
project
specific
npmrc
and
it
starts
dropping
rapidly.
As
you
get
to
the
user's
npmrc
or
the
other
two
which
shall
not
be
named.
A
Yeah-
and
I
think
you
know
this,
this
isn't
yet
another
thing
we
could
add
to
npm
doctor
to
start
like
just
saying:
hey,
like
you
know,
you've
got.
You
know
this
config
and
your
global
config.
We
don't
really
consider
that
a
global
config
item
anymore
or
whatever
it's
yeah,
and
I
I
do
like
your
idea.
Phillip
for,
for
you
know
if
we're
gonna,
throw
a
warning
or
an
error
or
whatever
we
decide
to
do
based
on
an
invalid
config.
A
It
should
generally
only
be
for
the
command
you're
running
at
the
moment,
because
it'll
make
sense
right
because
they
may
have
specified
that
command
in
the
cli
itself.
You
know,
while
they're
running
it,
not
necessarily
even
in
a
config
file,
because
it's
ultimately
like
about
the
resulting
config,
not
about
the
not
necessarily
just
about
like.
What's
in
a
config
file,
cool.
A
Well,
let's,
let's
move
on
to
the
next
item,
which
is
the
biggie
for
today,
and
that
is
dependency
selector
syntax,
so
this
is
basically
just
like
css
selectors,
but
for
for
dependencies
for
packages.
A
So
the
idea
behind
this.
So
if
you
click
on
the
rendered
rfc,
the
idea
behind
this
is
that
this
is
very
css
like
this
will
be
familiar
to
people
that
write
css,
dom
selectors,
query
selectors.
A
A
B
Yeah,
so
I
just
I
wanted
to
just
talking
about
a
light
philosophical
concern.
I
have
so
eslint
added
a
rule
called
no
restricted,
syntax
and
also
yeah,
just
in
particular,
and
it
supports
ast
selectors
and
so,
as
a
result,
you
can
do
a
lot
more
powerful
things
in
what
syntax
you
block.
That's
awesome.
B
That's
great
right!
There's
no
complaints
about
that.
However,
then
people
go
to
eslint
and
ask
for
a
better
affordance
for
blocking
a
specific
kind
of
syntax,
something
more
first
class
and
and
I'm
glossing
over
some
of
the
esl
specific
diff
reasons
why
that's
beneficial
but
and
the
maintainer's
response
is
just
go,
use
a
selector
bye
and
I
get
why
that's
the
impulse.
B
B
A
B
So
I
would
want
to
make
sure
that,
if
possible,
that
we
could
sort
of
that
npm
could
sort
of
commit
to
not
using
query
syntax
as
a
scapegoat
for
why
not
to
implement
a
thing
in
the
future.
A
Yeah
yeah,
I
like
it
just
to
give
a
little
bit
of
insight.
Some
of
the
things
that
we've
been
discussing
with
this
is
we
can.
We
can
use
internally
the
query
logic
to
implement,
commands
and
basically
be
a
lot
less
like
okay,
this
command
walks
the
tree
that
command
walks
the
tree.
This
other
command
is
just
like
just
just
run
the
internal
query
stuff,
and
so
that
all
that
code
becomes
very
consistent.
A
Something
that
we
can
leverage,
as
you
said,
for
for
more
direct
command
and
config.
B
And
that
that's
amazing
in
turn
as
well,
because
it
makes
a
lot
of
rfcs
much
easier
to
implement
yeah,
and
it
makes
a
lot
of
right
and,
like,
I
think,
that's
also
really
great.
But
then
the
marginal
utility
of
adding
a
top
level
thing
decreases
objectively
and
then
like
it
might
become
a
harder
thing
to
convince
being
added,
because
you
can
point
to
people,
let's
just
put
in
the
documentation
and
they
can
run
this
query
command.
Instead
of
but
like
there
is
a.
B
A
Yeah
I
mean
and
sort
of
the
the
fun
stuff
that
I
see
potential
for
is
like
you
know,
if
there's
some
vulnerability
out
there
or
whatever
people
tweet
like
a
jq
command
or
whatever-
and
this
is
like
hey-
you
can
just
do
this
directly
right,
so
yeah,
no
and
yeah.
I
think
I
think
it
can.
It
can
help
us
implement
rc's
a
lot
faster,
too
owen.
E
Thought
there,
which
I
do
like
is,
is
there
a
risk
where
I
guess
like
yeah?
Where
do
you
draw
the
line
because
isn't
there
like
maybe
another
case
where
another
multiverse,
where
npm
owns
all
the
commands
and
you
have
to
start
making
up
your
own,
and
so
this
is
a
you
know
just
bypass
all
that,
so
I
guess
would
it
make
sense?
I
mean,
I
know
it's
hard
to
predict
the
future.
Obviously,
but
is
there
a
way
to
kind
of
define
when
and
why
npm
asserts
a
command
namespace?
E
But
you
know,
I
guess
just
to
leave
it
open,
because
I
think
this
happened
a
while
ago
with
I
mean
I
know
this
was
more
of
a
yarn
decision,
but
they
claimed
one
and
then
it
got
implemented
at
npm
and
they
had
to
escape
hatchet
and
obviously
yeah
like
I
said
it's
just
curious
if
this
does
provide
more
flexibility
to
the
team,
because
they
also
don't
have
to
assert
every
possible
command
name
space
either.
B
Yeah,
I
mean
my
instinct:
there
is
in
a
place
where
the
functionality
is
what's
needed,
not
a
top
level
command.
B
Having
this
having
query,
there
means
that
it
could
be
implemented
as
not
a
top
level
command,
and
thus
you
avoid
the
debatable
downside
of
a
different
package
manager
having
an
issue
with
it,
but
I
think
that
that
that,
because
that
is
debatable,
I
think
that
that's
sort
of
going
to
be
a
separate
ad
hoc
thing,
with
each
potentially
conflicting
command
that
comes
up
regardless
of
the
existence
of
queries,
sometimes.
A
Yeah
we
could
do
something
similar
to
like
what
the
gh
github
cli
does
and
allow
and
other
command.
You
know
other
tools
out
there
and
allowing
you
to
add
aliases.
C
A
A
Was
gosh?
What
was
the
other
thought
that
I
had
was?
Was
that
it?
It
might
be
nice
if
we
came
up
with
a
decision
tree
that
basically
said:
here's
where
we
would
generally
want
to
implement
a
top
level
command
and
here's
where
we
would
generally
like
say
you
know.
This
is
an
example
of
a
query.
You
can
run
right,
so
maybe
we
could
we
could
iterate
on
on
that
kind
of
thing.
I
I
think
we'll
be
making
that
decision
a
number
of
times
and
a
decision
tree
might
be
more
obvious
after
a
while.
A
But
that's
what
these
rfc
meetings
are
for
too
right
bringing
up
hey,
we
want
to
make
a
new
command,
you
know,
is
it
worth
doing
so
I
think
I
think
we
kind
of
have
process
for
that
already
and
we
can
object
and
think
things
through
anybody
else
have
like
an
initial
gut
reaction
to
this.
Is
this
a
surprise
to
anybody
this?
This
rfc.
C
Well
kind
of
a
thought
and
a
question
I
like
instinctively,
I,
like
the
I
like
this
proposal.
C
I've
worked
previously
on
dependable
and
we
ended
up
doing
kind
of
quite
gnarly
hacks
to
do
very
specific
updates
to
specific
packages,
for
example,
and
something
like
this
could
be
very
helpful
to
like
target
exactly
the
right
packages
and
then
like.
If
you
can
pipe
the
query
into
install
that
would
be.
That
would
be.
C
We
could
directly
use
that
dependable.
My
only
kind
of
concern
looking
at
it
is
like
it's
very
complex.
Giving
this
whole
query.
Syntax,
like
from
the
get-go,
just
skimming
the
pmpm
solution.
They
just
have
a
filter
option
which
is
maybe
like
too
simple,
just
kind
of
throwing
it
out
there
as
like.
A
Yeah,
maybe
maybe
there's
a
phased
approach
we
should
take,
or
maybe
that's
a
documentation
issue
where
we
go
like
here's,
the
subset
that
most
of
the
time.
This
is
just
the
stuff
that
you're
gonna
need
and
then,
if
you're
getting
fancy,
you
know
go
to
this
advanced
section
right
and
use
some
of
the
you
know
more.
B
That
I
made
left
on
the
rfc
about,
like
I
think,
using
class
names
in
the
terminology,
I
think,
is
very
confusing.
It's
borrowing
too
much
from
css
a
term
css
probably
should
have
avoided.
Also
so
like.
I
think,
there's
a
lot
of
surface
syntax
and
terminology
changes
that
can
be
made
to
improve
the
education
story
here
and
the
intuition
story
that
might
not
make
it
come
off
so
complicated
yeah.
I
hope
so
anyway,.
C
Go
ahead
so
on
that,
like
I
wonder
if
some
of
those
class
names
could
be
improved
by
having
like
a
a
type
or
something
so
instead
of
being
like
like
an
attribute,
so
instead
of
being
dot
prod
class
name,
you
can
have
a
it's
a.
A
A
Concerns
today,
so
I
think
I
think
this
has
a
ton
of
potential
and
I'm
super
excited
about
it.
A
So
on
that
note,
let's
see
if
we
can
get
one
more
thing
off
the
agenda.
A
D
Hand
right
before
you're
about
to
switch.
I
wanted
to
speak
to
the
complexity
of
it,
because
I've
been
looking
at
it
for
a
while
longer
than
most
other
people
being
on
the
team,
and
that
was
my
initial
reaction.
Also.
D
Is
that
having
it
mapped
too
closely
to
css
there's
kind
of
an
uncanny
valley
there
of
like
it's,
never
going
to
be
exactly
css
so
trying
to
map
it
one
to
one
is
going
to
be
impossible,
but
then
trying
to
map
it,
you
know
99
is
going
to
be
weird
to
have
that,
like
one
percent
or
five
percent
or
whatever
percentage
difference
it
ends
up
being
so
I
do
agree
that
terminology
there
is
a
big
part
of
it.
So
not
having
you
know.
D
I
think
the
word
classes
is
a
bit
strange
when
it
comes
to
dependency
types,
but
I
do
think
that
there
is
some
benefit
of
having
a
few
like
blessed
like
you
know,
if
we
don't
call
them
classes,
but
you
know
the
thing
you're
going
to
want
to
do.
99
of
the
time
is,
is
do
you
adopt
prod,
then
to
still
have
that
be
like
a
more
top
level
thing
than
an
attribute,
but
not
have
everything
be
like
you
could
still
do
a
type.
B
To
I
don't
have
any
conceptual
issue
with
the
thing
that
classes
currently
are
called
like
having
a
top-level
category
or
something
and
using
a
dot
to
access
it
like.
I
think
that
we
should
just
avoid
the
word
class
and
come
up
with
a
different
term
to
describe
it,
and
I
think
everyone
will
just
get
that.
Oh
that's
like
classes
in
css,
but
it
means
this
here
and
then
it'll
just
be
fine
and,
like
I
so
I'm
cool
with
the
capability.
I
just
think
that
the
terminology
overlap
is
a
big
problem.
D
Yep
yeah,
I
agree.
I
think
that
was
all
I
had
to
say
about.
It
is
just
yeah.
If
we
can
work
on
that
terminology,
I
think
it
would.
It
would
help
a
lot,
especially
in
examples
that
we're
gonna
write
out
for
this
stuff.
A
Great
luke
do
we
normally
end
this
after
30
minutes.
A
No,
no,
no,
we
can
keep
going.
I
just
for
some
reason
I
had
seen
on
the
calendar
event.
It
showed
me
30
minutes
for
some
reason:
okay,
let's
keep
moving
then,
unless,
unless
we,
since
we
have
more
time,
we
can
keep
talking
about
this,
but
otherwise.
A
Okay,
so
the
next
item
on
the
agenda
is
discussion.
Expanding
the
behavior
of
before
so
miles
wrote
about
being
able
to
reliably
install
a
bunch
of
packages
as
if
it
were
a
week
ago.
A
Right
for,
I
believe
the
motivation
is,
you
know,
for
people
that
are
looking
to
a
you
know,
as
as
as
a
mechanism
to
avoid
supply
chain
attacks.
Knowing
that
hey,
you
know
we
were,
you
know
everything
that's
been
addressed
and
noticed,
and
all
of
that
is
in
a
good
state
for
seven
days
ago.
Let's
stick
there
or
whatever
it
is
right.
So
I
was
wondering
if
people
had
a
chance
to
read
this
and
what
their
thoughts
were.
B
Yeah,
so
the
I
have
two
reactions.
One
is
the
use
case.
I'm
sort
of
I've
had
a
lot
of
discussions
around
supply
chain
security
lately
and
you
know
with
various
folks
in
ecosystem,
and
I
think
that
making
it
easy
for
people
to
do
what
I'm
going
to
hopefully
politely
call
the
lazy
approach
of
just
let's
just
give
someone
else.
Let
someone
else
find
it
first
right,
like
I'm,
gonna,
just
wait
a
day.
B
If
enough
people
do
that,
then
the
problem
is
a
race
or
the
problem
is
restored
because
nobody
catches
it
until
a
day
later,
and
it's
not
really
like
addressing
the
problem.
It's
just
kind
of
hoping
it's
kind
of.
What's
the
word,
I'm
looking
for
it's
like
everyone's.
Just
like
not
you
know
like
everyone's,
not
I
don't
know
everyone's
littering
and
hoping
somebody
else
picks
it
up
kind
of
thing.
B
However,
if
there
existed
some
sort
of
detection
and
mitigation
solution
where
it
would
make
sense
like
that,
had
some
sort
of
sla
that
it
would
make
sense
to
wait
for,
then
I
think
that
at
that
point
only
this
use
case
becomes
a
good
one,
because
then
some
people
will
put
the
time
and
effort
and
money
into
detection
and
will
create
a
window
of
time
for
everyone
else
to
use
that
may
not
have
those
resources,
and
then
this
rsc
is
how
you
would
use
the
you
know,
use
that
window.
B
So
I'm
sort
of
questioning
the
actual
the
like
unintended
consequences
of
having
it
right
now
and
then.
The
second
thing
is
the
current.
The
before
flag
currently
has
the
nice
property
of
exactly
matching
what
you
can
pass
into
new
date
in
javascript
and
nothing
else,
and
I
think
that
both
that
is
actually
really
useful
to
talk
about
to
teach
about
it
and
to
like
understand
how
what
it's
supposed
to
accept,
but
also
temporal,
is
stage
three.
B
A
language
proposal
which
creates,
like
I
don't
know,
eight
new
types
and
entirely
replaces
date
and
has
it
you
know
it
wouldn't
have
a
nice.
B
Like
relative
time
phrase
way
of
creating
something
like
a
week
ago,
but
like
they're,
it's
probably
worth
exploring
that
and
seeing
if
there
is
an
analog
to
be
made
to
the
replacement,
javascript
date
type
and
then
using
that,
rather
than
inventing
something
brand
new
or
car,
or
you
know,
cargo
culting
it
from
existing
ecosystem
libraries
like
moment
or
you
know
and
friends,
it's
cool
like
I
can
see
the
utility,
but
there's
also
there's
like
a
lot
of
different
syntaxes
for
this
there's
there's
some
like
obscure
syntax
with
letters
like
1d
3r.
B
That
type
of
thing
that's
a
thing
that
temporal
actually
supports
but,
like
I
don't
know
how
it
works
and
then
there's
english
phrases.
But
what
about
other
languages
like
you
know,
there's
I
don't
know
it
just
seems
like
a
really
complex
natural
language
space
to
get
into.
E
To
the
first
point
that
jordan
brought
up
about,
I
guess
just
kind
of
delaying
the
potential
impact
the
you
know.
Maybe
the
kick
the
can
metaphor.
E
One
thing
I
think
that's
interesting
about
that
thought
is
be
curious
to
find
out
when
one
of
these
supply
chain
attacks
happened.
E
People
that
already
have
existing
projects
are
most
likely
to
have
a
lock
file
and
kind
of
you
know
some
varying
degrees
of
I
don't
know
control
around.
I
guess
basically
contrast
that
to
someone
who's
going
to
a
package,
read
me
and
just
do
an
npm
install
because
that's
what
it
says
following
a
guide
like
basically,
it
seems
like
it's
most
likely
gonna
impact
the
new
users
as
opposed
to
anybody.
That's
been
using
npm
for
especially
now
that
you
have
like
automatic,
lock
files
and
stuff
like
that
and
so
to
jordan's
point.
E
E
Is
there
a
way
to
I
don't
know
if
there's
something
that
npm
or
github
can
do
when
these
supply
chain
attacks
happen?
Is
there
a
way
to
gauge
like
where,
on
the
spectrum
of
brand
new
npm
user,
running
npm
install
and
react
for
the
very
first
time
ever
in
their
life
to
hey,
I'm,
you
know
opening
a
pr
at
my
job
and
we've
got.
You
know
like
frozen
lock,
file,
commands
and
all
that
stuff
in
our
ci
pipeline,
and
I
guess
maybe
use
that
as
a
tuning
rod
to
figure
out.
E
E
Right,
I
just
don't
know
if
you
could
like
somehow
control
it
within
you
know.
I
don't
know.
I
think,
like
some
of
the
things
that
I
was
reading
about
and
I
don't
doesn't
have
to
dump
tail
into
this
or
what
others
opinions
are,
but
if
you're
familiar
with
barasa's
new
project,
socket
dot,
dev
or
io,
and
some
of
the
mitigation
or
some
of
the
heuristics
they're
using
like
you
know,
we
added
all
of
a
sudden
a
post.
E
An
install
script
was
added
in
a
patch
release,
or
you
know
this
is
the
first
time
from
a
newly
transferred
publisher
like
those
are
the
things,
especially
when
you're
reading
off
a
readme
that
should
fire
all
the
alarm
bells
to
the
most
susceptible
person
that
you
know
isn't
going
to
be
thinking
of
something
like
this
or
probably
isn't.
You
know
even
familiar
with
how
the
ecosystem
works
enough
to
protect
themselves
in
that
moment,
so
anyway,
just
wanted
to
throw
that
out.
There.
C
Phillip
yeah,
I
got
a
couple
of
thoughts
from
dependable.
We
had
this
type
of
feedback.
Quite
a
lot.
People
wanted
dependable
to
update
dependencies
that
were
like
delayed
by
sundays.
I
think
there
is
like
some
case
for
doing
it.
I
think
amazon
did
some
data
crunching
on.
I
saw
some
twitter
thread
on
it,
so
I
haven't
actually
seen
the
data,
but
they,
I
think,
figured
out
that
seven
day
delay.
C
It
was
like
the
optimal
time
where
you
don't
want
it
to
be
too
delayed
and
a
lot
of
things
get
patched
in
the
next
couple
of
days
after
being
published,
but
I'm
wondering
if
it's
like
confusing
to
also
to
uninstall,
because
yeah
it
could
be
coming
from
a
lock
file,
in
which
case
you
get
what
you
have
in
the
lock
file
and
that
doesn't
make
any
difference
right.
A
C
A
Install
will
update
the
lock
file.
Ci
will
use
the
lock
file.
C
A
Yeah,
that's
true
yeah
yeah,
so
I
I
you
know,
there's
a
little
bit
of
a
theme
here
in
this
discussion
in
that
we
need
to
understand
the
the
the
messaging
behind
of
this
kind
of
option
and
really
help
be
considerate
of
of
like
best
practices,
right
and
understanding
like
which
kinds
of
users
should
do
which
what
is
github
and
npm
as
a
repository
guaranteeing
or
what
is
their
sla
and
all
of
that
and,
of
course,
all
of
that's
evolving.
So
I
think
all
of
that
messaging
has
to
come
together.
A
I
will
say
that,
as
far
as
technically
implementing
the
command,
it
does
give
us
a
place
to
move
forward.
In
that
you
know
we
can.
We
can
play
with
defaults
in
the
future.
We
can
once
you
know
we
can.
We
can
say
you
know
this
is
what
we
recommend,
or
in
this
case,
for
that
case
so
yeah.
I
think
I
think,
there's
some
it's
kind
of
nice
to
have
it
as
an
option,
but
it
could
get
away
from
us
right
if
the
community
decides
like
this
is
the
best
practice
right.
B
B
It's
just
kind
of
there's
there's
a
lot
of
unappreciated,
underappreciated,
unintended
consequences
of
making
something
easier
and
in
general,
if
you're,
making
something
easier
and
it's
not
actually
helping,
let's
say
security,
but
it
makes
people
think
it
is,
then
that's
actually
harmful
and
replace
security
with
anything.
If
people
think
it's
helping
a
thing,
and
it's
not
actually
helping
that
thing,
it's
worse
than
not
having
that
convenience
at
all,
because
people
then
get
lulled
into
a
false
sense
of
security,
about
whatever
the
thing
is
they're
trying
to
help.
E
D
Yeah
I
had
a
few
thoughts.
One
is
it's
spelled
out
in
the
rfc,
but
being
able
to
put
this
in
an
npm
rc
file.
I
think
is
the
biggest
pro
for
me
for
standardizing
this
syntax,
whatever
we
whatever
it
ends
up
as
because
yeah,
you
can't
do
it
as
a
date
in
the
command
line.
But
if
somebody,
if
a
project
did
want
to
do
this,
we
should
make
that
possible
where
it
isn't
right
now
like
without
custom
scripting
and
then
on
the
topic
of
messaging.
I
have
a
lot
of
thoughts.
D
It
makes
me
think
of
a
little
bit
of
when
npm.
The
original
message
for
the
package
lock
was.
You
should
commit
this
file,
which
is,
I
think,
was
was
shown
by
default
to
everyone
in
six
or
five,
which
is
it's
that
type
of
message?
That's
that's
true,
but
if
you
don't,
if
it's
not
true
for
you,
then
it's
not,
and
so
I
think,
coming
up
with
a
messaging,
for
this
is
a
similar
thing.
D
I'm
not
like
saying
everybody
should
you
know
uninstall
you
should
set
before
relative
to
seven
days
but
to
have
more
nuance
than
that
and
that
I
think
that
probably
lives
in
the
docks
or
some
sort
of
or
the
the
help
page
for
the
command,
but
then
also
the
ability
for
this
to
do
unintended
things
and
have
users
who
run
npm
install
and
are
wondering
why
they're
not
getting
the
package
they
just
published
or
that
someone
told
them
on
twitter
go
down.
D
You
know
patch
has
been
released,
go
install
it
right,
and
this
came
up
the
other
day
in
an
issue.
I
was
triaging
for
the
tag
flag,
which
was
not
installing
what
they
thought
it
would
and
so
again
of
things
silently
failing
or
not
doing.
What
you
expect,
I
think,
is
a
theme
where
we
could
have
some
sort
of
logs
or
messaging
to
say
you
know,
maybe
behind
the
verbose
log
level
or
something
to
say
like
fetching.
D
C
Yeah,
I
just
had
another
thought,
so
I
found
the
twitter,
the
tweet
from
someone
working
at
amazon
who,
like
dave,
they
basically
did
a
bunch
of
data
crunching
and
found
that
seven
day
delay
was
them
optimal
for
them.
I
think
if
we
introduced
command
like
this,
maybe
a
better
use.
Experience
would
be
having
a
just
a
single
delay.
That's
based
on
analyzing
all
vulnerability
data
for
npm.
B
B
That
sounds
like
the
sort
of
thing
that
npm
would
be.
You
know
perhaps
want
to
offer
as
a
service,
maybe
even
a
paid
service,
and
then
once
that
exists
with
an
sla
that
immediately
becomes
the
best
practice.
Everyone
should
wait
because
this
service
is
going
to
find
it.
You
know
something
like
that.
B
Like
it
just
feels
like
one
of
those,
you
know
that
that
thing
about
how
you,
if
you
expect,
if
you
a
b
test
too
much,
you
find
a
local
maximum,
but
not
like
the
actual
maximum
somewhere
else,
and
I
think
this
is
like
that
sort
of
category
where
crunching
the
numbers
isn't
going
to
give
you
the
best
result.
It's
just
going
to
give
you
the
best
result
when
nothing
else
changes.
A
That's
a
good
point,
I
think
all
this
is
is
great.
We
can
add
this
back
into
the
discussion.
Thank
you.
Let's,
let's
go
ahead
and
move
on
to
the
next.
One,
which
is
excuse
me,
which
is
a
is
an
issue
in
the
cli,
cannot
work
on
fat32
usb
drive
luca
roy.
Do
you
have
any
insight
on
this.
D
I
was,
I
was
muted.
I
do
have
a
little
bit
in
that
I
was
triaging
it,
but
I
don't
know
the
original
if
there
was
anything
behind
it.
Besides
yeah
it's
just
in
the
cli
with
the
agenda
label,
so
I
think
it
came
up
as
a
feature
request
that
was
should
go
through
here,
because
sorry,
I'm
reading
it
again
to
to
get
the
full
context.
D
It's
with
it.
Not
so
npm
installed
by
default,
creates
same
links
to
binary,
so
it
would
be
a
flag
that
would
not
do
that
so
that
it
could
work
on
fat32
drives.
So
I
don't.
I
don't
have
any
more
context
than
that,
but
it
seems
like
a
a
relatively
small
feature
as
long
as
it's
not
the
default
that
someone
could
opt
into
to
use
shims
instead
of
sim
links.
D
I
think
yeah,
I'm
concerned
about
detecting
things
and
interpreting
user
behavior
that
we've
run
or
intent.
I
mean,
obviously,
if
you're
installing,
as
this
user
is
a
react
native
project
on
a
usb
drive.
I
think
that
would
signal
intent,
but
I'd
be
concerned
about
it
going
too
far,
and
I
don't
actually
don't
know
the
specific.
E
Seems
like
it
could
follow
that
convention
for
like
how
you
describe
like
native
binaries
to
install
like
the
package
author
lists
out
their
support
environment,
so
you
could
align
with
that.
Like
you
know,
you
tell.
D
E
Contextual
yeah
I
mean
I
don't
know,
you
know
how
you
know
how
many
people
this
would
impact,
but
you
know
I
don't
know
if
it's
ever
come
up
before,
but
you've
made
it
pretty
far
without
it.
So
you
need
to
be
vacant
in
the
system.
E
D
The
interesting
thing
about
this
one
is,
it
looks
like
this
user
has
found
an
environment
variable
that
we're
using
for
testing,
which
makes
it
behave
as
they
want.
So
that
leads
me
to
believe
it's
at
least
a
situation
we
test
for,
and
so
I
think,
if
it
is,
that
makes
me
lean
a
little
bit
more
in
the
direction
of
we
can
add
a
flag
for
it.
I
think,
in
other
cases,
I'd
be
concerned
with
adding
options
that
would
lead
to
more
options
which
would
lead
to
more
options.
D
D
A
D
D
Github
action,
raspberry
pi
platform,
when's
that.
A
There's
there's
a
big
fat
format.
I
forget
exactly
what
it's
called,
but
it's
essentially
fat32
there's
I
it's
still
pretty
common
okay,
but
it's
not
just
because
of
interoperability
between
os's.
A
Okay:
let's
go
ahead
and
move
on
to
the
next
item,
which
is
the
last
item
on
our.
B
A
Is
improve
signature
verification
and
we
have
phillip
here
himself.
So
if
you
want
to
introduce
this
one.
C
Yes,
so
I
think
can
helpful
to
see
this
as
a
basically
fixing
existing
register
signatures
by
doing
two
things.
One
is
migrating
from
pgp
to
a
ec
dsa
signature.
C
So
the
signature
become
it's
much
more
compact
and
can
be
verified
using
the
nodes,
crypto
library,
whereas
with
the
existing
pgp
signature
news,
you
need
to
install
open
pgp
to
verify
the
other
is
basically
making
it
easy
to
verify
these
register
signatures.
C
Currently
you
can
write
a
script
that
does
it
using
so
the
registry
signs
packages
and
publish
and
they
get
added
to
the
pacument.
A
C
C
I
think
we
could
do
that.
My
only
concern
was
like
do
we
want
to
just
go
with
that
from
d1
without
really
testing
the
performance
impact,
and
there
is
a
kind
of
gnarly
thing
to
figure
out
with
third-party
registry
support.
So
the
rfc
has
some
plan
on
how
we
can
support
third
party
registries
like
if
they
use
the
same
url
scheme
for
accessing
the
public
keys,
but
should
the
cli
just
trust
those
keys
by
default?
And
then,
if
we
don't
so,
you
might
need
to
add
some
kind
of
prompt,
ssh
style.
B
Well,
so
I
mean
these
are
all
good
questions
and
the
reason
why
we
wouldn't
we
would
probably
want
a
command
first
and
then
to
put
it
in
install,
but
they
have
to
be
resolved
either
way
right
like,
but
the
like.
In
other
words,
it
seems
to
me
like
the
the
end
goal
would
be
if
the
registry
provides
you
with
a
signature,
there's
never
a
reason
not
to
validate
it,
and
if,
if
they
give
you
a
signature
and
it's
invalid,
no
one
wants
to
proceed.
C
B
So
my
sort
of
expectation
is
that
if
we
went
with
that
model,
where,
by
default,
a
regis
signature,
it
understands
can
kill
the
install
if
it
fails
and
a
signature
it
doesn't
understand,
is
just
pass
through.
Then
third-party
registries
just
wouldn't
have
like
they
wouldn't
have
to
support
this.
It
would
just
continue
to
work
as
it
was
as
it's
doing
and
when
we
added
some
way
for
them
to
support
it,
they
would
just
you
know,
assuming
we
like
we'd
have
to
design
for
it
initially
but
like
when
they
started.
B
When
a
particular
registry
started
supporting
it,
it
would
just
magically
get
this
verification
behavior
like
it
just
I
I
don't
know,
I'm
just
not
it's,
I'm
not
seeing
any
reason
to
make
this
often
given
that
like,
like,
I
don't
like.
I
think
that
it,
I
think,
that
the
attack
vector
it's
protecting
against
is
highly
unlikely,
but
I
also.
B
Information's
there
and
if
there
that
ever
were
exploited
like
everyone
would
want
this
to
be
loud,
and
I
think
if,
if
it
were
ever
exploited
and
npm,
didn't
do
this
by
default,
but
could
have
chosen
to,
I
think
a
lot
of
people
would
be
very
angry
and
saying.
Well,
why,
like
you
know,
it
reminds
me
of
that
seinfeld
scene,
where
jerry
bought
a
huge
expensive,
like
deadbolt
for
his
apartment
door,
and
it
has
only
one
weakness.
You
have
to
lock
it
right.
It's
it
sort
of
reminds
me
of
that.
C
D
Oh
yeah,
I
just
had
a
few
a
few
general
thoughts.
I
do
agree
that
if
this
this
seems
like
a
really
good
feature
to
add
by
default,
I'm
always
concerned
with
false
positives
or
just
even,
if
they're,
you
know
at
npm
scale,
false
positives.
They
can
garner
enough
distaste-
or
you
know
in
the
case
of
audit
where
people
would
just
advocate
for
turning
them
off
entirely.
So
that
would
be
something
I'd
want
to
be.
D
You
know
be
more
sure
of,
and
I
I
you
know
I
don't.
I
haven't
never
implemented
this
so
it
you
know,
I
don't
have
any
specific
concerns.
I
would
just
I'm
kind
of
curious
if
we
could
run
like
large
package
installs
on
large
package
trees
and
just
as
a
test
beforehand,
just
see
how
it
how
it
performs
and
how
it
works.
I
would
be
interested
in
those
in
those
numbers,
but
overall
I
think
this
is
yeah
a
super
positive
change
and
one
that
yeah.
If
anything
ever
did
attack
this.
A
D
Yeah
we
have
some
open
issues
around
that
anyways
with
mpm8,
so
I
don't
see
that
being
we're
doing
something
with
with
hashing
and
integrity
already.
I
just
don't
think
it's
being
verified
against
a
public
key,
so
I
don't
know
technically
what
that
what
that
adds,
but
I
think
we're
already
doing
enough
work
in
this
case
that
if
we
don't
into
this
implementation,
we
could
do
it
without
a
large
net.
Increase
in
install
time
is
what
my
my
gut
feeling
about
this.
C
Yeah,
I
think
the
only
like
really
added
thing
that
would
happen
on
install
would
be
we
already
download
the
document
that
has
all
the
information
we
need
and
we
just
need
to
call
the
no
crypto
library
to
actually
do
the
signature
verification
give
it
the
public
key.
I
think
that
stuff
is
pretty
quick
and
maybe
it
could
even
be
done
concurrently.
C
A
Well,
I
think
that's
us
pretty
much
at
time
unless
there's
some
further
comments
on
this
signature,
verification,
rfc.
A
Well,
we
decide
whether
it's
in
in
in
a
final
state
and
then
we
then
we
put
it
on
the
roadmap.
A
So
yeah
that's
a
discussion.
We
could
have
nicely
all
right.
Let
me
look
up
something
real,
quick.
Let's
see,
I
just
wanted
to
thank
everybody
for
coming
philip.
Was
this
your
first
time?