►
From YouTube: Open RFC Meeting - Wednesday, February 23rd 2021
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
we're
live,
welcome
everyone
to
another
npm,
open
rc
call.
Today's
date
is
wednesday
february
23rd,
2022
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
537,
and
I
shared
with
folks
the
meeting
note
stock
there,
which
I'll
spam
again
for
folks
that
are
just
joining,
feel
free
to
add
yourselves
as
attendees
and
quickly
just
to
remind
everybody.
A
A
One
quick
announcement
here
that
I
was
wanting
to
put
on
folks
radar,
our
team
has
been
working
pretty
diligently
on
a
backlog
of
high
priority,
bugs
and
decided
to
stay
heads
down
for
the
month
of
march
to
try
to
really
put
an
emphasis
on
cleaning
up
those
issues,
and
so
we're
gonna
essentially
take
a
pause
on
rc
calls
specifically.
A
Async
we'll
continue
to
do
that,
and
we
may
even
have
one-off
conversations,
as
I
noted
last
week,
specifically
about
the
distributions
rc,
so
I
may
still
be
setting
up
that
call
that
I
know
some
folks
were
interested
in
in
contributing
to,
but
just
want
to
make
the
note
that
yeah,
these
calls,
the
regular
schedule
calls
won't
be
happening
in
march.
A
I
appreciate
the
note,
jordan
that
the
that
you
sent
earlier
that
they
were
still
on
the
calendar,
so
I've
removed
them
now
and
that
should
be
updated
and
reflected
in
our
public
calendar
for
folks
that
are
following
along
there
as
well.
So
the
next
rfc
call
then
should
be.
I
think
wednesday
april
6th
is
the
right
date,
so
a
little
bit
of
a
pause
here
but
yeah.
A
The
hope
is
that
we'll
get
over
this
backlog
and
get
back
to
sort
of
developing
features
and
improving
we,
we
have
a
pretty
good
backlog
to
date.
Actually
of
accepted
rfcs
as
well
that
we'd
like
to
get
to
as
as
we're
talking
about
new
things
as
well
so
bit
of
announcement,
there
did
anybody
else
have
anything
they
wanted
to
share.
A
If
not,
then
we'll
jump
right
into
our
relatively
small
agenda
today.
The
first
issue
that
we
have
here
is
rfc
522.
A
This
is
the
adding
the
npm
adding
options
for
npm
diff
to
ignore
white
space,
carriage
returns,
end
of
line
and
carriage
return,
and
I
think
roy
you
had
put
this
on
the
docket
or
left
this
on
socket
to
be
ratified.
I
think.
B
Yes,
so
I
just
I
revealed
it,
I
love
to
come
in.
C
B
B
But
honestly,
like
I
really
don't
think
that's
the
case,
but
like
whether
or
not
we
should
just
change
npm
death
so
that
ignoring
carried
return
at
the
end
is
just
the
default
behavior
and
I
believe,
like
the,
I
believe,
it's
npmdf
goal
is
to
like
surface
so
all
types
of
possible
changes
and
like
I
believe
that
would
include
like
this
metadata
like
and
it's
fairly
easy
to
just
opt
into
ignoring
them
with
the
new
option.
B
So
I
would
be
inclined
to
just
use
the
option
whenever
the
flag
is
provided,
or
you
just
set
that
config
true
in
your
npmrc
file,
and
you
get
that
new
behavior.
So
yeah,
I
see
that
oscar
there
that
opened,
the
rfc
already
started,
contributing
to
the
jsdf
dependency
to
actually
implement
this
behavior
there,
because
it's
not
it's
not
implemented
in
the
in
the
package
that
provides
the
diff
yet
so
that's
awesome.
B
It
looks
like
they're
engaged
like
check
into
this,
for
this
feature
so
looks
ready
to
go
so
yeah,
but
if
folks
really
have
strong
opinions
on
having
that
enabled
by
default,
feel
free
to
comment
there
too,
we
can
follow
along.
B
B
In
the
working
in
a
team
with
windows
and
unix
users
at
the
same
time,.
A
Yeah,
we
should
just
double
check
what
the
the
experience
is
there
for
for.
B
Yeah
well,
and
it's
different
too.
I
know
kit
also
has
this
option
that
I
believe
I
have
enabled
in
my
global
config
for
a
long
while
to
just
normalize.
So
even
when
you
are
working
in
these
situations
with
half
a
team
on
windows
have
a
team
of
unix.
There
is
a
setting
to
just
normalize
everything
whenever
you
commit
to
the
repo.
If
and
not.
C
D
We
actually
have
the
opportunity
to
be
a
little
bit
more
permissive
than
get
safely
in
this
environment.
Remember
that
git
diff
needs
to
be
able
to
work
against
arbitrary
content,
but
if
we're
trying
to
use
npm
diff
to
resolve
things
like
package.json
files
merges
on
an
automated
basis-
which
I
think
is
what
you're
doing
here,
we
can
safely
ignore
those
crs,
whereas
the
get
guys
can't
so
limiting
npm
to
what
gets
doing
there
might
not
be
the
best
choice
for
the
community.
B
Yeah,
that's
a
good
point,
my
argument
in
favor
of
just
not
turning
it
on
by
defaults.
It's
basically
like
correctness
over
over
the
the
flexibility
right
so
and
so
anyone
can
just
opt
in
and
like
if
your
team
is
comfortable
with
that,
you
can
just
put
that
in
your
npmrc
and
have
that
by
default.
But
I
just
think
that
for
the
default
experience
like
it's
probably
better
for
the
community
to
just
err
on
the
side
of
safeness,
so
that
was
my
thought
here,
partner,
so
yeah
and
to
also
answer
to
jordan.
B
A
Yeah
I'm
just
concerned,
we
were,
I
fall
into
the
same
trap
that
we
have
with
like
get
ignored,
like
precedents
with
get
config
precedents,
etc
and,
like
the
expectation
that
we're
very
tied
to
those
two.
But
I
I
also
do
think
that
it'd
be
nice.
A
If
you
can
just
set
things
in
one
place,
but
if
we
have
different
options
and
we
have
different
expectations
potentially
and
I
actually
don't
mind
the
idea
that
we
could
be
more
prison
permissive,
potentially
as
wes
was
noting
but
yeah,
I
do
think
they're
two
separate
like
commands,
so
we
should
have
separate
config.
I
think
I
don't
know
it's
it's
maybe
up
for
the
ecosystem
to
help
normalize.
A
B
Yeah,
but
with
that
in
mind
with
that
idea
of
just
we're
just
basically
using
get
the
fs
kind
of
the
the
reference
for
the
implementation
and
like
it's
just
natural,
to
accept
this
new
options
as
they
come
along
as
the
as
the
community
surface,
the
need
for
them.
I
think
that
was
the
idea.
B
Since
the
beginning,
like
we
ship
a
minimal
set
of
viable
options
for
npm
diff
and
like
we
can,
we
can
grow
it
like,
as
as
it
becomes
clear
that
the
community
wants
them
like
we
have
people
championing
for
it,
like
we
have
in
this
case
here,
so
I'm
totally
thumbs
up,
but
I
think
we
should
ratify
it.
A
Cool-
let's
do
it.
Can
I
put
you
in
charge
of
doing
that
today
at
some
point.
B
A
A
So
I
will
keep
it
on
my
radar
to
actually
set
up
that
call.
We
could
even
consider
it
to
be
like
a
deep
dive
session,
but
I'm
probably
going
to
call
it
like
a
working
session
where
we'll
have
a
shared
hack
and
b,
where
we
can
work
on.
Essentially
both
the
distributions
rfc
to
get
in
a
good
place
as
well
as
potentially
whatever
we
can
call
it
conditional
conditional,
optional
dependencies
improvements
or
something
like
that.
A
A
Yeah,
notably
in
terms
of
how
I
look
at
this-
I
don't
imagine-
distributions
landing
until
mid
to
later
this
year,
just
as
a
fyi
and
it's
probably
going
to
be
flagged
so
potentially
introduced
as
a
you
know,
on
optional
feature
that
you
can
opt
into
before.
It
becomes
something
that
we're
we're
able
to
support
by
default
to
set
up
meeting
okay,
and
that
brings
us
to
our
last
agenda
item,
which
is
issue.
42.
A
E
It
an
update,
I'm
here
yeah.
So
this
is
not
my
rfc,
but
it's.
I
left
a
comment
on
there,
and
so
this
is
asking
for
standard
error
for
errors,
and
I
just
wanted
to
raise
concerns.
I
had
and
then
bring
it
to
the
rfc
community
just
to
see
what
other
thoughts
people
had
about
it,
but
basically
this
breaks
the
ability
for
some
output
to
be
passed
to
other
programs,
specifically
json
output.
E
So
certain
errors
are
treated
like
I
feel
like
there's
two
classes
of
errors,
there's
like
ones
that
we
don't
know
are
going
to
happen
and
those
should
maybe
get
printed
to
standard
error.
But
then
there's
ones
like
e-resolve
or
you
know.
If
you
npm
install,
you
know,
react
and
you
misspell
it
and
that
doesn't
exist.
E
So
what
and
there's
been
issues
opened
about
this
in
the
past
we
currently
have
a
few
that
I've
gone
through
and
linked
in
the
rfc,
but
so
I
don't
have
a
good.
I
don't
have
another
rfc,
but
I
just
wanted
to
bring
this
one
up,
because
I
don't
think
we
should
print
all
errors
to
standard
error
or
we
should
have
some
way
to
distinguish
between
types
of
errors.
We
should
and
shouldn't
print
to
standard
error.
C
I
mean
so
when
I
pass
json
to
me
the
guarantee.
The
only
guarantee
I
expect
and
require
is
that,
if
it
succeeds,
standard
out
is
only
parcel
json,
which
is
the
same.
If
you
make
an
ajax
request
to
a
web
server
and
request
json
in
the
headers,
if
it
succeeds,
you
expect
json
if
it
doesn't
maybe
the
server's
nice
and
gives
you
json,
but
if
it's
a
503
error
or
something
maybe
you're
not
going
to
get
json,
you
simply
can't
expect
the
error
path
to
give
you
a
valid
like
well-formed
well-formed
response.
C
So
I
think
that
it
would
make
sense
to
me
that
errors
are
always
printed
on
standard
error.
They
are
not
guaranteed
to
be
parsable.
The
json
flag
doesn't
change
that,
and
just
like
every
other
shell
tool,
the
exit
code
and
standard
out
standard
error
are
used.
Idiomatically
to
give
you
that
information.
C
If
we
want
to
then
go
beyond
that
and
make
standard
error,
output,
parsible
awesome,
but
that's
a
very
difficult
guarantee
because,
like
you,
could
have
a
memory
error
in
the
middle
of
your
process
and
crash
and
like
you're
not
going
to
reliably
trap
that
on
every
system
that
npm
supports
so
like.
I
think
it's
just
if
you
have
an
expectation
that
standard
error
output
is
parsable
like
you're,
you're
gonna
be
sad,
no
matter
what
we
do.
So
don't
have
that
expectation.
E
Go
ahead,
luke
yeah!
I
I
agree
with
all
that.
The
one
thing
I
wanted
to
add
is
that
the
one
thing
I
don't
want
to
make
impossible
is:
if
you
have
a
default
log
level,
which
is
notice,
I
believe,
and
you
and
we
are
able
to
print
json
output
for
an
error.
That's
recoverable,
like
you
know,
out
of
memory
errors
stuff
like
that.
We're
not
gonna
be
able
to
print
json
for
that,
and
that
should
be
air
paths
that
you
know
all
code.
You
know
all
libraries
consuming.
E
This
should
expect
and
be
able
to
handle
those,
but
ones
where
we
are.
Like
you
know,
registry
errors
come
to
mind
because
those
are
already
formed
as
json,
I
believe,
and
so
there's
more
information
there,
and
so,
if
you
did
want
to
pipe
that
to
jq
or
something
we
currently
make
that
impossible
with
the
default
log
level,
because
you'll
never
get
well-formed
output,
you'll
you'll
never
get
well-formed
json
output
on
standard
error
because
that's
where
logs
go
and
those
are
not
json.
E
So,
unless
there's
some
way
to
you
know,
we
wanted
to
make
new
line
delimited
json
logs
in
in
json
mode,
which
is
outside
of
the
scope
of
this
discussion,
but
that
that's
my
only
concern
where
I
want
to
not
make
that
path
where
we
are
able
to
pass
that
error
impossible
for
people
to
consume.
That
way.
A
So,
what's
the
strategy
going
forward,
because
I
agree
with
both
jordan
and
luke
your
assessment
of
this,
it's
kind
of
like
what
is
the
contract
that
we're
setting
users
up
to
expect.
A
When
they
pass,
let's
say
the
json
flag,
that's
how
it
sounds
like.
Are
we
like,
if
we
air,
as
jordan,
noted
for
any
other
reason,
that
isn't,
let's
say
a
recoverable
error
or
an
error
in
which
we're
throwing
within
the
cli
itself
like
we
do
not
control?
We
cannot
control
that
and
we're
going
to
yeah
we're
we're
not
going
to
be
able
to
pass
back
a
participle
like
json
response,
so
it
seems
like
we're,
like
that's
like
impossible
to
that
contract's
impossible
to
keep.
A
E
There
there
is
one
change:
well,
so
either
way
we're
gonna
have
to
make
changes,
because
currently,
I
believe,
json
errors
specifically
get
sent
to
standard
error
and
that's
different
than
other
error
paths.
So
the
I
think
the
number
one
action
item
I
would
have
from
this
is
decide
whether
we
want
some
errors
to
go
to
standard
error
and
some
to
go
to
standard
out
or
if
we
want
to
say
you
know,
be
consistent
and
all
errors
always
go
to
standard
error.
E
And
if
you
know
that
you're
going
to
handle
json,
you
are
passing.
You
know
a
separate
flag
for
log
level.
Two
well
passing
silent,
wouldn't
work,
because
silent
has
special
code
paths
that
also
hide
output.
But
some
combination
of
that
that
would
be
documented,
say
if
you
are
expecting
to
handle
json
errors
from
the
cli
like
this
is
the
flags
you'd
have
to
pass
or-
and
I
just
don't
like
the
any
indirection
of
like
we
try
to
guess
user
intent,
which
we've
talked
about
on
these
calls
before,
where
like.
E
If
you
pass
json
mode,
we
change
your
log
level
or
something
like
that.
I
feel
like
all
of
those
would
be
non-starters
for
me,
of
like
switching
flags
based
on
other
flags
which
are
seemingly
unrelated.
E
Sorry
yeah,
I'm
I
have
my
recommendation-
would
be:
let's
see
my
recommendation.
It
feels
like
it
goes
against.
I'm
also
looking
for
best
practices
here.
If
anyone
has
any,
but
is
all
output
goes
to
standard
out
and
all
logs
go
to
standard
error
and
output
is
defined
as
anything
that
the
cli
is
thinks
that
you
could
either
that
is
useful
to
the
end
user.
E
So
you
know
in
certain
cases
that
that
is
going
to
be
errors
like
you
resolve
errors
in
in
certain
modes
like
those
are
going
to
get
printed
to
standard
out
only
so
that
we
don't
have
to
ever
switch
between
standard
out
and
standard
error
in
some
cases
to
make
it
parsable
for
users.
C
E
Okay,
yeah,
that's
great,
I
I
think
that's
all
I
wanted
to
resolve
from
this.
I
don't
know
if
I
need
to
write
another
rfc
just
to
or
maybe
just
leaving
a
comment
on.
This
is
enough
because
I
just
want
a
decision
record,
because
we
have
people
asking
both
ways
and
issues,
and
so
I
just
need.
I
want
to
write
up
something
that
we
can
point
people
to
and
say
this
is
the
reason
that
you
are
getting.
What
you
think
is
an
error
and
it's
not
on
standard
error.
A
Is
it
possible
that
you
could
have
just
read
it
in
not
like
necessarily
the
forum
on
our
rfc
but
yeah
like
just
something?
That's
like
I
don't
know
like.
I
would
totally
be
okay
with
you
ratifying
just
like
a
document
even
of
the
current
implementation
or
like
where
we're
going
with
that,
like
like,
like
a
plus
one
to
just
like
even
ratifying
like
this,
is
how
we're
gonna
handle
these.
B
Yeah
I
was
going
to
propose
just
maybe
some
lightweight
rfc
like
then.
We
can
just
document
this
all
these
ideas.
It
can
just
leave
there
in
an
accepted.
Obviously
it
doesn't
need
to
be
anything
too
complex
or
you
know
just
something
right.
Then
we
can
point
people
like
you're,
saying
in
other
discussions
and
even
guide
future
implementations,
because
I
know
it's
possible.
Something
will
tack
on
the
future
ui
ux
revamp
of
the
of
the
cli,
so
it's
definitely
good
to
be
there
for
future
reference.
A
Yeah,
I
think,
like
just
leaving
in
an
issue,
isn't
as
formal
like
that's
kind
of
like,
I
guess
what
we're
I'm
I'm
saying,
and
it
doesn't
have
to
be
as
massive
as
a
full-blown
rfc,
but
it
can
just
be
like
in
these
situations.
This
is
how
we
do
x,
yeah.
E
Is
there
a
place
in
the
docs
where
stuff
like
this
lives?
Currently,
that
feels
like
maybe
a
good
candidate
I've
been
I've
had
in
my
head
for
a
while
to
write
something
like
this
like
how
the
cli
thinks
about
logging
and
display
the
logging
section
here
we
made
the
other
day
you
can.
I
can't
remember
where
I
put
that.
A
Oh
no,
the
like
in
the
docs
itself,
npm
docs.
We
now
have
a
section
called
logging
in
using
npm.
I
think.
D
A
And
so
you
could
just
essentially
amend
that
whole
page
with
any
kind
of
additional
input
you
want
to
add
there
luke.
E
Okay,
that
sounds
good
and
reading
my
comment
again.
There
is
one
other
thing
I
wanted
to
to
bring
up,
and
that
is
whether
we
treat
the
change
from
currently
all
json
errors
go
to
standard
error
and
whether,
if
we
change
that
to
standardize,
we
treat
that
as
a
breaking
change
or
not
because
it
got
changed
in
mpm7
as
a
bug
fix.
E
I
believe,
where
we
just
switched
that
code
path
from
basically
console.log
to
consoleair
and
that
broke
other
people's
stuff,
but
we
kept
it
in
as
a
bug
fix,
because
someone
was
relying
on
that
behavior,
which
I
can't
I
don't
know
the
full
history
of
that
behavior.
But
if
we
change
that,
how
do
we
want
to
treat
that
for
sember?.
E
I'm
just
leaving
it
open,
I
can
say
my
initial
thought
was
saving
that
for
mpm9,
but
seeing
how
we
want
to.
We
have
a
current
focus
on
fixing
priority,
one
bugs
and
there's
a
few
priority,
one
bugs
that
this
would
fix.
I'm
not
leaning
towards
it,
just
being
a
bug
fix
on
a
bug
fix.
A
Yeah,
I
don't
have
any
strong
feelings,
one
way
or
another
we're
damned
if
we
do
and
we're
damned.
If
we
don't
so
it's
it's
sort
of
yeah,
no
good
deed
goes
unpunished,
as
is
the
case
yeah.
So
I
I'm
I'd
rather
ship
it.
As
I
don't
know,
maybe
we
could
ship
it
as
a
miner.
Instead
of
saying
it's
a
bug
patch
we're
saying
it's,
an
improvement.
E
Yeah,
I
also
think
if,
if
I
add
this,
if
I
had
more
information
to
the
docs
about
this-
and
we
have
somewhere
to
point
it's
less
likely
to
at
least
there's
an
explanation,
I
think
in
the
past
we
made
this
bug
fix.
It
was
basically
a
one-line
change,
pull
request
that
we
made
and
then
people
were
it
broke
them
unexpectedly,
where
it's.
E
I
think
it's
impossible
to
never
break
anybody,
but
if
we
have
somewhere
to
point
users
to
when
they
have
questions
about
this,
I
think
that
could
go
a
long
way.
A
It's
only
breaking
if
it's
documented
right,
okay,
so
this
is
the
lack
of
documentation,
has
been
our
biggest
problem
that
we've
tried
to
combat
here
and
which
is
why
people's
expectations
are
a
little
bit
all
over
the
place.
So
I
think
that
you're
right
that
if
we
float
this-
and
I
would
suggest
as
a
minor
with
alongside
the
like
clear
docks-
then
this
is
actually
an
improvement
right
and
we
can
set
people's
expectations
accordingly,
so
yeah
cool
any
other
feedback
on
on
this.
A
If
not
I'd
like
to
open
up
the
floor
for
folks,
if
they
have
any
other
topics
that
they
want
to
bring
up
or
questions
or
anything
else,
that
is
on
folk's
minds,.
F
I
have
some
go
ahead.
F
I
got
my
cover
on
my
camera
apparently
so
I
was.
I
was
working
an
issue
and
you
know
they
mentioned
that
npm
audit
wasn't
working
properly
and
after
a
little
bit
of
back
and
forth
come
to
find
out
like
they
were
recommended
to
run
npm
audit
from
a
global
install
of
a
package.
F
So
I
don't
think
this
is
really
rfc
worthy
necessarily,
but
I
we
do
need
to
be
careful
about
recommendations
for
action
if
they
don't
apply
to
the
command,
because
npm
audit
does
not
work
at
all
for.
C
One
separately,
like
npm
audit
fix
dash
g,
should
probably
immediately
error
out,
as
should
npm
update,
dash
g
and
any
dash
g
command.
That
includes
an
explicit,
save,
save
dab,
save
peer
like
there's
a
ton
of
global
commands
that
just
shouldn't
work,
but
they
currently
either
silently
do
the
wrong
thing
or
like
silent,
fail
in
a
weird
way.
F
Yeah,
if
you
do
run
dash
g
with
npm
audit
right
now,
it
does
give
a
sensible
error
for
that.
But
yeah
it'd
be
good
to
look
at
the
others,
but
yeah
in
this
specific
case
like
we
really
should
not
be
recommending
a
user
course
of
action.
A
Just
one
one
thing
to
clarify
and
may
because
you
mentioned
this
jordan-
maybe
you
know,
but
npm
update,
dash
g
was
historically
in
v6,
was
to
update
all
globally
installed
packages
to
latest
has
that
did
that
change?
Are
we
not
doing
that
anymore?
Is
that
broken.
C
I
mean
if
that
works
still
correctly,
then
that's
fine,
but
in
general
I
think,
there's
also
a
huge
bunch
of
threads
about
npm
update,
failing
suddenly
failing
to
update
package
json
in
npm,
seven
plus
you
fixed
that
okay.
So
so,
but
like
it's
it's
sort
of
in
general,
it's
kind
of
weird
like
because
it
seems
like
almost
all
these
commands
were
built
with
a
project
in
mind
and
then
like
they
kind
of
also
do
something
for
global
and
it's
certainly
a
valuable
use
case
to
say,
hey.
C
I
want
to
update
all
my
global
packages,
maybe
but
like
especially
since
one
of
those
is
npm
and
that
can
cause
your
entire
npm
installation
to
break
like
it's
sort
of
a
dangerous
thing
to
run
and
because
there's
no
package
json,
there's
no
way
to
even
track,
what's
been
updated
from
what
to
what
so
it's
like,
I'm,
not
even
sure,
even
though
that's
a
thing
that's
reasonable
to
want,
I'm
not
sure
it's
a
thing,
that's
reasonable!
To
make
easy,
like
it
kind
of,
seems
like
if
someone
is
taking
the
truck.
C
That's
the
trouble
to
install
something
globally.
They
should
like
explicitly
manage
that
thing
one
at
a
time,
so
I
I
don't
know
it's
like
I.
I
just
think
that
there
hasn't
been
a
lot
of
holistic
thought
about
local
versus
global
and
an
ap
npm's
api
in
the
modern
world,
where
global
packages
themselves
are
deprecated
and
discouraged
like.
F
I
think
maybe
we
should
take
a
look
at
this
when
we,
when
we
look
at
v9,
braking
changes
around
config.
Maybe
we
we
also
look
at
global
a
little
bit
and
make
sure
that
we're
doing
something
smart
there.
I
kind
of
feel.
Like
you
know,
the
the
the
global
update
thing
is
is
like
what
people
expect
from
brew
and
stuff
like
that,
so
they
might
expect
the
same
from
npm.
C
Right
but
like
yeah
and
that's
true,
but
the
when
you
do
that
with
brew
right.
Not
not
only
do
you
have
no
idea
what
version
you
updated
from
or
when
that
was
updated,
but
also
like
the
the
folks
that
have
a
ton
of
things
installed
with
brew
like
they
tend
to
want
to
just
oh
forget
it:
let's
just
update
everything
and
then
things
break
in
their
system
and
they
have
to
laboriously
figure
out.
A
Yeah
so
we've
had
on
our
radar
for
a
long
time
like
improving
npm
update
in
general
and
and
the
place
that
I
see
that's
done
best
or
I
see
it
referenced.
The
most
is
npm
check
updates
package
where
there's
an
interactive
mode,
there's
a
the
ability
for
you
to
update
all
all
packages.
The
latest
like
very
easily,
like
those
are
two
specific
features
that
I
hear
are
often
asked
of,
of
npm
update
and
because
we
don't
support
those
two
specific
use
cases
it
seems
like.
A
Okay,
like
like
people
have
to
reach
for
a
tool.
Those
specifically
we
should
support
and
we
ideally
will
support
come
this
time
next
year.
Ideally,
we
are
supporting
that,
but
it's
a
pretty
good
time
frame
to
say
that
by
next
year
we
should
have
those
kinds
of
features
in
npm.
The
use
case
of
doing
that
interactively
like
should
apply
not
just
to
project
level,
but
also
globally,
which
I
think
would
alleviate.
Maybe
some
of
your
concerns
there,
jordan,
so
yeah
like.
A
I
do
think
that
update
does
have
some
improvements
that
we
should.
We
should
add
the
number
one
that
we
were
seeing
that
we
did
just
recently
fixed
is
saving
back
to
package.json,
which
you
mentioned,
which
was
a
major
pain
point
for
folks,
since
they
they
often
were
used
using
npm
update
to
to
manage
their
package
json,
and
we
sort
of
eliminated
that
use
case
in
v7,
and
we
fixed
that
now.
So.
C
While
we're
taking
a
look
at
npm
update,
I
don't
actually
know
if
it
does
this
or
not,
but
when
I
get
a
cve
for
a
transitive
dependency
in
an
application
with
a
lock
file
having
a
command
where
I
can
just
say,
update
that
thing
everywhere.
It
occurs
in
my
lock
file
to
the
latest
in
range
thing
like.
That
would
be
very
useful
because
that's
the
fastest
way
you
can
resolve
most
cbe
warnings
like
npm
audit
fix,
can
do
it,
but
like
it.
C
F
A
Yeah,
it's
just
like
how
do
you
keep
that
that
option
that
you
just
said?
How
do
you
keep
a
reference
to
it,
either
in
the
log
file
or
in
the
package.json
or
how
was
that?
Well.
A
I
think
I
was
confused
because
you
said
at
first
you
said
that
the
latest
transit
of
defensive,
but
then
then
you
said
enrage.
A
Yes
latest
sorry,
yes,
okay,
yeah,
see
that
we've
also
heard
some
folks
asking
for
the
ability
to
break
the
contract
and
get
latest
no
matter.
What
outside
of
ranges
so
like
even
breaking
like
majors,
has
been
an
ass
for
some
folks,
and
that's
where
I
think
overrides
probably
is
the
right
place
but
yeah
what
you're
asking
for
makes
sense.
F
I
have
one
more
thing
to
to
maybe
bring
up
to
the
group
issue:
four
four
six
zero,
which
I
did
close,
but
it
talks
about
missing
integrity
entries
for
the
registry
in
in
an
older
package
lock,
and
the
expectation
that
npm
install
should
warn
and
or
fix
these,
and
I
just
thought
it
was
interesting
because
there
are,
you
know,
use
cases
where
or
there
are
instances
where
an
integrity
might
not
exist.
C
Right,
I
mean
if,
if
those
scenarios
are
something
actionable
like
my
company's
private
registry,
is
failing
to
provide
integrity
value,
that's
something
I
would
want
to
be
told
about,
or
if
it's
like
this
category
of
dependency
can't
have
an
integrity
value
like
it's
a
git
depth.
Maybe
you
want
to
look
for
something.
That's
in
a
registry
that
seems
like
it
would
have
value
but
like
if
it's
something
like
npm
has
a
bug,
and
then
the
registry
side,
like
that's
not
actual.
For
me,
I
don't
know
what
other
scenarios
would
be
but
like.
C
F
F
Yeah,
I
mean
that's,
that's,
I
think
that's
a
good
argument
and
it
may
be
worth
us
changing
that
behavior.
There.
B
We
had
it
coming
up
for,
for
the
opposite
right,
like
getting
rid
of
integrity,
values
for
for
good
taps,
so
might
be
a
good
thing
to
explore.
A
Yeah,
I
think,
there's
two
two
things
that
we
can
do
here,
which
are
good
good
things
to
know
pretty.
Is
it
possible?
Can
I
ask
you
to
maybe
add
two
separate
issues
for
in
our
stashboard
or
is?
Is
there
issues
that
we're
already
tracking
for
this?
A
Cool
any
other
topics
folks
want
to
to
bring
up.
We
have
about
15
minutes
left.
Those
were
two
good
ones.
B
Maybe
just
the
last
reminder
for
march
before
we
go.
A
Right
so
yet
again,
just
for
folks
that
may
have
not
been
on
the
call
before
or
just
tuning
in
we're
going
to
take
a
bit
of
a
break.
A
pause
on
the
rc
calls
being
live
streamed
for
march,
but
we
will
still
be
reviewing
and
giving
feedback
in
the
rfc's
repo
async
from
our
team.
So
the
next
rfc
call
will
be
wednesday
april.
Sixth
2022..