►
From YouTube: Open RFC Meeting - Wednesday, September 22nd 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.
B
Awesome,
I
think,
we're
alive.
Welcome
everyone
to
another
mpm,
open
rsv
call.
Today's
date
is
wednesday
september
22nd
we'll
be
following
along
in
the
agenda
that
was
posted
in
the
npm
rc's
issue,
number
461
and
I'll
just
copy
and
paste
for
everybody.
That's
on
the
call
right
now,
the
meaning
notes,
doc
feel
free
to
add
yourselves
as
attendees
and
I'll
do
my
best
to
take
notes
as
we
go
along
here.
B
Quick
reminder.
These
calls
and
all
are
these
cons.
We
ask
folks
please
abide
by
our
code
of
conduct,
which
is
linked
in
the
meeting
notes
and
on
the
mpmrc's
repo
itself.
B
Synopsis
here
is
just
please
be
kind,
as
other
folks
are
talking.
Please
raise
your
hand
and
we'll
call
on
you
and
yes
just
ideally,
we
can
have
some
civil
discourse
and
move
things
forward
in
this
form
and
on
the
rcu's
repo
itself,
diving
right
into
any
announcements
that
folks
would
like
to
share
today.
B
If
not,
we
can
jump
into
our
fairly
small
agenda,
the
first
of
which
is
issue
445..
B
Just
a
quick
reminder
here
of
the
intention
is
to
essentially
drop
in
support
for
node
10
and
also
drop
the
programmatic
usage
of
of
npm,
and
so
those
two
things
are
pretty
much
the
the
the
key
details
of
this
change:
jordan:
msu
hands
up.
Would
you
like
to
make
a
comment.
C
Yeah
over
I
mean
it's,
it's
taken
a
while,
because
npm
is
a
complex
beast,
but
it
seems
like
almost
all
of
the
things
that
issue
commenters
are
claiming,
keeps
them
from
upgrading
from
six
to
seven
have
been
resolved,
except
for
a
couple
things
which
I
I
could
guess
that,
but
don't
have
off
the
top
of
my
head.
I
can
help
you
find
them
later.
I
is
it
worth
trying
to
address
those
before
npm
eight,
so
that
the
like
to
ensure
that
you
know
as
many
people
as
possible
can
smoothly
upgrade.
A
No,
not
a
rebuttal.
I
think
it's
great.
I
think
it's
a
great
point.
I
I
wanna
bolster
that.
I
would.
I
would
just
sort
of
limit
that
I
think
yes,
however,
only
in
so
far
as
it
won't
cause
a
breaking
change
for
node
sure
the
the
reason
for
or
cause
it
to
be
delayed
to
too
far,
because
the
the
motivation
for
cutting
eight
now
is
just
so.
We
can
like
drop
old,
node
versions,
drop
the
programmatic
api
and
basically
not
have
any
obstacle
to
shipping
that
in
node.
A
So
if
it's,
if,
if
fixing
those
things,
will
be
a
breaking
change
from
node's
point
of
view
or
to
you
know
too
disruptive
from
those
point
of
view,
then
no,
and
if
it's
gonna
or
if
it's
too
much
work
and
it's
gonna
kind
of
take
us
too
long
to
do,
then
I
would
also
push
back
on
it,
but
otherwise
yeah.
If
there's
any
like
low
hanging
fruit
kind
of
in
that
area,
then
or
if
it's
stuff,
that's
you
know
it's
only
additive,
then
yeah.
C
Well,
the
categories
seem
to
be
authentication
with
git
dependencies
or
alternative
registries
and
linking
workflows
that
are
different
in
seven
versus
six
and
then
there's
a
bunch
of
people
about
the
npm
update
changes
in
npm
seven.
But
I'm
I'm
pretty
sure
that
that
can't
be
changed
within
seven.
But
maybe
that's
something
worth
considering
for
eight
is
reverting
to
the
sixth
behavior.
A
It
depends
on
what
aspect
of
the
sixth
behavior
we're
talking
about.
If
there
were,
there
were
some
things
about
the
way
that
npm
6
did
the
way
that
npm
update
worked
in
npm
6,
which
were
not
which
people
came
to
rely
on,
but
had
some
really
unfortunate
impacts.
So
it's
there,
there
was
kind
of
a.
There
was
a
principled
choice
to
go
the
way
that
we
did
in
some
ways.
One
of
the
things
that
people
have
objected
to
is
the
fact
that
update
no
longer
saves
back
to
package.json.
A
That's
that's
something
that
we
can
definitely
tackle.
I
we
just
haven't
because
it
hasn't
been
kind
of
the
top
priority
issue,
but
there's
there's
no
reason.
There's
no,
principled
reason
why
we
can't
do
that.
The
the
other
thing,
though,
like
with
the
way
that
that
it
worked
with
depth.
I
I've
seen
some
people
object,
that
when
they
run
an
npm
update,
it
updates
everything
rather
than
just
updating
things
that
are
at
the
top
level.
It's
not
responsive
to
depth
so
like.
A
If
you
do
npm
update
foo,
it
updates
every
instance
of
food,
no
matter
what,
and
that
is
actually
really
important
for
consistency
and
like
over.
B
A
Using
npm
update
in
a
way
that
was
kind
of
shallow
or
depth
limited
in
that
way
would
end
up
with
really
bizarre
package.
Trees
that
were
like
could
never
couldn't
be
made
efficient
very
easily.
So
I
mean
now:
we've
got
a
case
where
you
run
npm
update
and
it's
basically
the
same
as
a
fresh
like
package
log
free,
install.
C
Right
yeah,
so
I
guess
the
the
broader
thing
is
more
other
than
the
specific
about
updating
package
json
from
npm
update.
I
think
it's
just
kind
of
probably
worth
a
repass
of
the
issues
to
see
which
issues
have
a
bunch
of
people
saying
we
fixed
this
by
downgrading
npm
six
and
whittle
down
those
further
eliminating
the
ones
where
people
didn't
have
to
downgrade
and
then
whatever's
left
seems
like
it
might
be
important.
That's
sort
of
the
thought
I
have
thank
you.
B
Option
here
is
that
we
do
have
a
bit
of
a
gray
spirit
in
terms
of
note,
12
and
14
existing
and
still
going
to
package
npm
six
with
those
node
releases,
so
they're
still
life
left
in
those
unknown
releases
and
there's
still
options
available.
I
guess
for
those
users
that
might
be
having
trouble
with
or
currently
aren't
served
by,
the
the
current
feature
set
of
npm7.
B
B
It's
not
a
great,
like
sorry
to
say,
hey
stay
on
six.
We
still
want
to
obviously
address
those
issues.
I
guess
I'm
just
saying
that
there's
a
bit
of
a
grace
period,
maybe
for
us
to
continue
to
improve,
like
the
upgrade.
C
C
C
So
I
think
it's
it's
rapidly
gonna
get
to
the
and
then
that
that's
separate
from
even
new
features
like
workspaces
or
overrides
or
whatever
might
be
coming.
So
I
just
you
know
it
seems
like
seven
to
eight
is
going
to
be
a
pretty
easy
upgrade
for
anyone
who's
not
still
on
node
10,
but
six
to
seven
like
I
don't
know
it
just
it
would
be
nice
if
that
were
all
so
easy.
B
I
think
we'll
definitely
take
the
action
jordan
to
revisit
in
the
next
couple
weeks
the
the
sets
or
trends
of
issues
for
v7
and
specifically
folks
that
notify
us
that
it's
you
know
preventing
upgrading
and
usage
of
v7,
we'll
revisit
here
and-
and
just
I
guess
another
comment
on
on
this.
It
does
seem
like
we
were
we're
going
to
wait,
probably
another
week
or
two
to
actually
cut
I'm
getting,
which
gives
us
a
bit
of
time
to
address
any
of
those
issues.
B
If
not,
we
can
move
on
to
the
second
item.
We
had
a
kit
up
here
for
today.
This
is
an
old
issue
that
we
had
put
an
action
against,
but
our
team
that
hasn't
picked
up
yet
and
just
wanted
to
provide
some
visibility
on
this.
This
is
rc434.
B
B
B
Yeah
yeah,
and
so
I
just
wanted
to
bring
this
back
up,
because
we
had
the
action
item
to
have
someone
review
this
and
then
potentially
merge
it
in,
since
we
thought
it
was
had
had
worth
so
yeah.
I'm
not
sure
if
anybody
can
actually
take
the
action
to
review
this
in
the
next
week
or
two,
but
I
think
it
would
be
good
to
land
before
yeah,
especially
before
mbm8,
even.
A
I
think
we
should
definitely
not.
I
see
that
there's
some
talk
about
extending
the
package,
lock
property,
be
it
to
be
either
a
boolean
or
a
string
of
v1
v2
v3.
I
think
that's
terrible.
We
should
we
should
get
away
from
having
mixed
type
configs
if
at
all
possible.
A
You
know
we
have
a
handful
of
trinaries
where
there's
like,
there's
true
or
false
or
unset,
and
that's
kind
of
not
wonderful.
We
try
to
avoid
that,
but
it
is.
It
does
serve
a
purpose
sometimes,
but
in
cases
where
it's
like
a
boolean
or
a
string,
we
should
just
have
a
package
lock
version
field
that
says,
if
you're,
if
you're
writing
a
package
like
you
write
it
with
this
version
and
a
separate
config,
which
is,
should
I
or
should
I
not
use
in
respect
to
package
log.
B
A
B
Awesome
and
the
last
item
we
had,
I
know
toony
isn't
on
the
call,
but
this
is
the
rc
422
npm
audit
assertions.
I
will
share
the
link
to
this
rc.
B
C
Yeah
I
shouldn't
say
I
think
I
I
it'd
be
great
if
we
could,
like
summarize
in
a
new
comment
or
something
the
remaining
questions
or
issues.
So
I've
done
a
lot
of
discussion
on
this
one
and
it
would
be
massively
helpful
like
basically
right
now,
it's
fine
because
right
now,
there's
no
cves
plaguing
the
ecosystem,
but
the
instance
somebody
finds
like
a
theoretical
problem.
You
know
widely
used
like
widely
transitively
used
dependency,
where
maintainers
are
going
to
get
yet
another
onslaught
of
largely
false,
positive
complaints.
C
So
it
would
be
really
really
amazing
to
get
something
like
this
in
yeah
I
mean,
I
think,
there's
a
maintainer
burnout
is
for
many
maintainers
is
always
on
the
horizon
and
they
do
the
bulk
of
the
work
in
the
ecosystem
and
it
would
like,
like
yeah.
I
don't
think
it
can
be
understated
how
much
damage
is
done
in
the
absence
of
this
feature
and
how
much
benefit
would
be
thus
caused
by
having
it.
A
Yeah,
I
wonder
my
only
hesitation
with,
like
you
know,
putting
a
stamp
on
this
rfc
saying
yes,
we're
gonna
do
this?
Is
it's
really
kind
of
bigger
than
npm
right,
like
there's,
there's
actually
relatively
little
that
the
clyde
can
do
in
this
particular
case?
This
is
something
that
really
belongs.
A
That
kind
of
the
from
from
npm's
point
of
view
belongs
in
kind
of
the
github
advisory
system
right
and
there
is
a
there's,
a
specification
in
place
or
specification
in
development
on
like
how
to
how
to
represent
these
things.
I
think
we
discussed
it
previously.
A
There
was
vex
or
wex,
I
think,
basically,
like
an
exception,
exception
assertions
attestations,
develop
around
stations,
so
I
agree
it
as
as
somebody
who
gets
lots
of
prototype
pollution
spurious
things
are
like,
oh
well,
if
you
call
it
with
these
args,
then
you
own
yourself
kind
of.
C
C
Well,
so
what
I
wanted
to
sort
of
add
there
is
ideally
this
is
something
that
should
be
built
into
cves
themselves,
right
that
the
entire
computer
ecosystem
should
use,
but
that
has
not
happened
and
that
industry
has
incentives,
in
fact
not
to
do
it,
because
they're
incentivized,
like
in
all
sorts
of
ways
to
have
the
broadest
possible,
like
security
vulnerabilities.
C
So
similarly
like
yeah
github
advisory,
the
github
advisory
system
is
probably
a
better
place
than
just
doing
it
in
npm.
But
I
think
that
if
we
wait,
if
we
keep
waiting
for
the
best
place
to
do
it,
it'll
never
happen
and
that's
what's
been
happening.
So
I
think
it
needs
to
happen
one
way
or
another
somewhere.
A
Yeah,
I
I
think
I
agree
with
you,
but
also,
I
think,
there's
some
some
nuance
to
it.
The
cbe
system
itself
is
like
it's
a
it's
a
exponentially
bigger
data
set
right.
So
if
you,
if
you
have
it's
relatively
easy
to
say
the
thing
you
know,
xyz
has
this
vulnerability.
A
The
the
other
thing
is
to
say
of
all
of
the
things
that
use
xyz.
These
ones
exhibit
the
the
vulnerability.
These
are.
These
ones
kind
of
you
know,
don't
expose
it
so
that
becomes
you
know
much
a
much
larger
set
of
data
to
manage
or
deal
with
or
query,
and
it's
it's
less
about
like
it
has
to
be
at
the
right
place
and
more
that
it
has
to
be
on
the
server.
A
If
there's
no
server-side
support
for
this
feature,
it
doesn't
matter
like
the
client
can
post
the
attestation
if
it
just
goes
into
a
black
hole.
It's
no
good,
the
the
other
thing
from
incentives,
point
of
view.
I
think
I
think
github.
Just
as
an
organization
I
mean
I'm.
This
is
my
own,
my
own
hot!
Take
on
this.
A
I
don't
speak
for
my
employer
here,
but
it
seems
to
me
like
github's,
motivations
or
incentives
are
actually
aligned
with
the
community
in
this
case,
like
we're,
not
github's,
not
making
any
money
by
saying
you
know
getting
more
security
advisories
out
there
we
are.
Actually
we
actually
do
better
if
the
community
can
be
more
efficient
if
we're
kind
of
the
tool
that
everybody
wants
to
use
so
yeah.
I
think
I
think
the
right
thing
is
happening
but
yeah
it.
A
This
has
to
be
done
on
the
on
the
server
side
or
there's
not
really
much
value.
A
What
I,
what
I
don't
want
to
do,
is
kind
of,
let
us
to
wed
the
cli
to
some
particular
data
shape
or
implementation,
and
then
have
some
third-party
registry
start
leveraging
that,
but
then
the
thing
we
end
up
actually
using
is
something
different,
and
now
we
kind
of
have
to
support
two
different,
two
different
shapes
of
that
data
to
come
in.
We
do
that
already
with
advisories.
So
it's
not
like
the
end
of
the
world.
If
that's
what
ends
up
happening,
but
you
know
until
there's
some
kind
of
server
implementation
it.
A
B
Right,
so
I
guess
this
also
begs
the
question
that
I
know
zb
has
asked
many
times
in
terms
of
a
at
the
project
level,
with
the
his
tooling
and
npm
audit
resolver,
that
that
tool
having
a
local
or
project
level
file,
which
does
you
know,
audit
resolutions
and
is
not
something
that
you
can
essentially
like.
You
would
not
distribute
and
would
not
be
able
to
sort
of
have
as
kind
of
a
I
know.
Wes
has
talked
about
this
in
the
past.
B
A
sort
of
ignore
list
type
feature,
but
something
that
is
sort
of
created
and
supported
at
the
project
level
for
individuals
like,
is
that
a
potential
solution
as
we
wait
for
a
registry
implementation,
because
it
seems
like
we're
blocked
by
that
and
and
just
aren't
providing
any
kind
of
mechanism
today,
if.
C
We
could
make
a
local
ignore
list
that
was
scoped,
in
other
words,
not
just
every
minimus
cve
ignore
or
like
every
flav.
You
know
every
cve
number
one
two
three
ignore
like
if
it
was
more
like
ignore
any
of
this
cve
from
this
package
via
these
dependencies
right
right.
A
Need
to
know
about
it
yeah
if
you're,
using
something
that
uses
minimist,
you
should
be
able
to
operate.
That
right
I
mean,
or
maybe
even
you
know,
we
could
say,
look
either
ignore
this
vulnerability
when
it's
ignore
cve
one
two
three
ignore
advisory,
one,
two:
three:
when
it's
a
direct
dependency,
ignore
it
also
if
it's
a
dependency
of
foo.
Now,
if
I
have
a
dependency
bar
that
has
that
I
still
want
to
see
it
right
so
yeah.
B
So
that,
yes,
maybe
like
that,
is
preferable
like
because
again
I
don't
see
us
spinning
up
and
by,
as
I
say,
I
don't
see
registries
today,
like
or
in
six
months
to
a
year
and
I
could
be
wrong
based
on.
I
don't
know:
everybody's
backlogs
and
timelines,
spinning
up
the
ideal
counter
claim
mechanism
for
for
cvs.
C
Today
that
we,
I
think
I
mean
so,
the
current
state
is,
if
I
maintain
like
three
eslint
plugins
and
if
there's
a
regular
expression,
denial
of
service
vulnerability
somewhere
in
there.
All
of
those
are
not
problems
in
an
eslint
program
plug-in
like
categorically.
C
So
I
get
a
bunch
of
complaints
right
now
and
I
have
to
tell
I
have
to
convince
people,
it's
not
a
big
deal
and
but
then
like,
I
don't
have
any
work
around
for
them.
I
have
to
you
know
with
yarn.
I
can
tell
them
to
use
overrides,
or
you
know
something,
but
like
there's,
no
nothing
to
do
here,
so
the
ignore
list
would
at
least
let
me
just
say.
C
This
is
not
a
vulnerability
put
this
line
in
this
place
and
you're
good
and
then
like
the
longer
term,
solution
would
be,
which
is
even
better,
is
me
putting
that
assertion
in
before
those
people
have
even
seen
the
vulnerability
in
the
first
place,
and
then
I
don't
have
78
issues
opened
up
on
my
repo
about
it,
but
like
it's
still
a
marginal
improvement
to
have
a
workaround
to
provide
them.
So
I
I
am
happy
with
that.
As
an
iterative
step,
it's
definitely
not
enough,
but
it's
way
better
than
right
than
the
you
know.
B
I
apologize
I'm
just
taking
notes
here.
Did
anybody
else
have
any
comments
they
want
to
make
on
this.
B
I
believe
this
is
more
in
line
with
one
of
the
older
rc's
that
again
knocked
or
zbe
had
filed
to
introduce
something
like
the
npm
audit
resolver
schema
that
that
is
supported
right
now
by
that
tooling.
B
So
I'm
wondering
if
we
can
make
yeah
ignore
this
or
a
brand
new
kind
of
rc
that
that
threads,
the
needle
of
what
we're
like
speaking
to
here
now,
and
maybe
that
original
rfc
that
he
created,
which
I
think
had
both
the
it
was
proposing
inheriting
the
tool,
as
well
as
the
schema
and
maybe
there's
a
no
there's
like
a
fresh
perspective.
We
can
take
with
that
irc.
B
B
Okay,
I
feel,
like
that's
like
a
good
step
forward
that
actually
provides
some
mechanism,
and
it's
completely
independent
of
any
registry
implementation,
which
is
like
ideal
that
we
can
try
to,
like.
You
know,
solve
things
here
so
that
I
think
wraps
up
in
terms
of
what
we
had
on
the
agenda.
B
Thanks
for
jumping
on,
and
ideally
we'll
see
you
next
week
and
hopefully
keep
the
conversation
going
in
the
rfcs
themselves,
yeah
take
care
fun
thanks.