►
From YouTube: Open RFC Meeting - Wednesday, July 28th 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
rfc
call.
Today's
date
is
wednesday
july
the
20th
I've
copy
and
pasted
or
spammed
the
chat
with
the
memenos
doc
feel
free
to
add
yourself
as
an
attendee
to
that
agenda.
A
Notes
we'll
be
following
along
in
the
agenda
that
was
actually
posted
in
issue
421
and
the
ipm
rfc's
repo,
which
I'll
also
link
for
folks
to
to
look
at.
I
apologize
for
the
late
creation
of
that
doc.
A
I
want
one
point
in
the
future
and
at
some
point
in
the
future,
we'll
get
that
actually
automated
automatically
generating
earlier
and
often
so
apologize
that
that
just
got
put
together
this
morning
again
as
usual,
we
ask
that
everybody,
please
abide
by
the
code
of
conduct,
that's
referenced
in
the
mpmrcs
repo
in
general.
A
The
general
purpose
of
that
is
just
an
algorithm
acknowledgement
of
being
kind
on
these
calls
and
please
be
respectful.
If
you'd
like
to
talk
when
somebody
else
is,
please
raise
your
hand
and
I'll
call
on
you
and
yeah
just
be
mindful
of
others,
any
announcements
that
folks
have
on
the
call
that
they
wanted
to
share.
A
If
not
we'll
get
going
here,
the
first
item
that
is
actually
on
the
agenda
is
the
rfc
182.
This
is
the
npm
audit
licenses
work
that
tierney
had
queued
up.
I
left
this
on
the
agenda
just
to
essentially
keep
it
as
sort
of
like
a
staff
update,
I'm
not
sure.
If
there's
any
updates
from
last
week,
though
yeah.
B
I
don't
think
I've
done.
I
don't
think
I've
changed
anything
in
the
last
week,
but
I
I'm
happy
to
to
see
if
I
can
find
some
time
to
poke
on
on
continuing
down
the
path
of
this.
In
the
coming
weeks,
cool.
A
So
no
updates
for
now
moving
along
then
actually
is
it's.
Do
you
need
you
have
a
drafted
pr?
Is
that
right,
tiernan
yep,
I
do
do
you
need
any
help
from
folks
like?
Can
we
put
out
like
a
call
for
for.
B
I'd
love
to
bear
with
someone
yeah,
it
basically
just
needs.
It
just
needs
more
work
like
the
ap,
the
basic
the
basics
are
there
and
the
you
know,
interface
needs
to
be
built
out
and
like
it
just
needs
to
be
built.
Basically,
so
yeah
happy
to
work
on
that.
If
someone
else
just
wants
to
work
on
it,
you're
more
than
welcome
to.
B
A
If
not
moving
on
to
pr
418,
this
is
the
trust
system
root
certificates.
This
came
in
yesterday,
so
I'm
not
sure
if
many
folks
have
been
able
to
review
this
I'll
share
the
pr
link
in
chat.
C
Is
deltura
on
the
call?
C
C
Basically,
what
they
want
is
to
be
able
to
set
a
ca
file
option
and
still
have
npm
requests.
Also
include
the
system
certificate
store
certificate
authority
store.
The
challenge
here,
I
think,
is
that
most
of
that
is
not
handled
within
npm.
It's
basically
just
an
argument
that
we
pass
to
the
node
http
layer.
C
We
transform
that
ca
file
into
an
array
of
ca
certificates
by
reading
it,
and
you
know
splitting
it
on
the
certificate
boundaries,
and
then
we
just
hand
that
off
to
node
and
node
does
what
node
does
there's?
No,
that
I'm
aware
of
there's
no
cross-platform,
you
know
straightforward
cross-platform
way
to
get
the
list
of
all
of
the
system
certificates
to
like
include
those
all
by
default
and
pass
those
to
node.
I
could
be
wrong
on
that.
It's
been
a
pretty
long
time
since
I
looked
at
any
of
that
stuff.
C
One
potential
workaround
that
they
have
today
is,
they
can
add
their.
You
know
add
their
custom
certificate
to
their
system.
Certificate
store
in
whatever
way
makes
sense
for
their
particular
operating
system.
That's
not
a
great
workaround
because
it
doesn't
allow
you
to
have
like
different
ones
for
different
projects
or
or
things
like
that,
and
the
current
state
of
the
world
is
that
you,
you
have
to
replicate
the
entire
system
store
within
your
ca
file.
C
If
you
want
to
be
able
to
also
access
other
other
remote
systems,
so
yeah
long
and
short
of
it
here,
I
think
it
needs
a
little
bit
of
investigation
just
to
see
like
you
know.
What
would
what
would
go
into
that?
Is
there
a
way
to
tell
node
to
you
know,
use
these
certificate
authorities
and
also
your
default
ones.
C
Potential
hazard
that
I
can
imagine
is
it
makes
it
impossible
to
it
might
make
it
impossible
to
stop
accepting
a
certificate
that
is
in
your
certif,
your
system,
certificate
store.
So,
for
example,
there's
a
cert
that
you
no
longer
want
to
trust,
because
you
know
that
it's
been
compromised
or
what
have
you
there's
an
easy
way
right
now,
if
you're,
you
know
on
a
in
a
project,
you
can
have
a
ca
file
for
that
project.
C
That
only
includes
you
know
the
certificate
authority
required
for
github
for
npm
and
for
your
internal
registry
and
nothing
else.
I
don't
know
if
that's
a
use
case.
We
particularly
care
about,
but
that's
kind
of
I
I
feel
like
it's
a
stretch
to
to
find
a
downside
with
this
particular
suggestion.
It's
just
the
implementation
challenge.
C
Yeah
yeah,
and
we
could
just
like
have
a
you
know-
include
root,
include
system
certificate
store
as
an
option.
Then
the
only
challenge
is
just.
How
do
we
tell
node
that
right,
because
I
I
think
it's
maybe
even
statically
compiled
or
something
it
was
once
upon
a
time
like
I
said
it's
been
a
very
long
time
since
I
looked
at
that.
A
Okay,
so
it's
guard
go
ahead.
E
C
Correct
the
a
a
nested
npmrc
file
in
a
dependency
is
never
processed
and.
E
Can
get
you
to
have
a
bad
ca
and
go
to
a
bad
site
after
I
poison
your
dna,
like
it's
really
obtuse,
but
the
vector's
there.
If
I
can
change
that
setting
without
you,
knowing
it
obviously
at
the
top
of
a
project,
that's
a
different,
because
I
understand
that
the
config
is
going
to
be
overwritten,
but
not
on
nested
ones.
Thank
you.
A
Okay,
so
I
put
the
item
down
to
do
a
bit
more
investigation
and
then
we
can
post
back
on
the
rc
itself,
like
that.
This
seems
seems
like
something
that's
pretty
reasonable,
like
that,
we
could
look
into
cool
any
pushback,
immediate
pushback.
A
We'll
keep
it
open,
then,
for
now
also
pull
we
will
poke.
Emily,
I
think,
is
your
name.
Moving
on
to
pr405
resolved
packages
based
on
node.js
version.
I
will
share
this
link
for
folks.
C
So
this
this
seems
like
we
could
so
my
my
first
take
on
this
is:
if
we're,
if
we're
gonna,
do
this,
we
could
do
it
just
by
sort
of
changing
the
the
heuristic
for
how
we
select,
which
package
version
right.
C
So
we
could
say
you
know
if
you
are,
if
we
have
to
load
mocha,
8
or
9,
but
we're
on
node
10,
then
let's
prioritize
the
ones
that
don't
have
an
engine
mismatch
right,
so
we
might
still
allow
it
with
a
warning
if
there's
no
other
option,
if
something
depends
on
milk,
9
and
you're
on
node
10
we'll
go
ahead
and
install
it
and
warn
you
that,
like
hey,
this
is,
you
know
not
probably
not
supported
the
the
thing
that,
where
that
sort
of
falls
down
is
once
mocha
9
is
in
your
lock
file
like
we
we're
breaking
our
contract.
A
So
just
so,
I
know
we're
looking
at
the
same
thing
and
then
else
alistair
I'll.
Let
you
jump
in
you
were
speaking
to
the.
A
C
Oh
god,
there
is
also
one
other
workaround,
which
I
know
some
projects
are
using,
which
is
to
set
a
accept
version.
So
you
could
say
my
dependency
is
mocha
8,
but
I
will
accept
version.
C
I
will
accept
mocha
9,
which
means
if
9
is
already
there
that
counts
as
a
valid
resolution,
but
while
building
the
package
tree,
I'm
only
going
to
require,
like
version
eight
but
I'll,
like
v-dupe
against
nine,
I
can
try
to
dig
up
the
link
to
that
that
feature,
but
that
that
also
is
kind
of
another
release
valve.
In
some
of
these
cases,.
A
Go
ahead
I'll
see.
F
Yeah
now
I
was
gonna
say:
the
important
thing
to
keep
in
mind
is
people.
It
might
be
obvious,
I
guess,
but
people
don't
often
use
december
or
engines
correctly
as
well
in
some
packages,
especially
even
some
of
the
bigger
packages.
So
you
might
end
up
with
something
crazy
going
on
at
times
that
could
could
get
annoying,
and
if
it's
just
the
first
install,
then
it's
probably
fine
but
yeah.
F
I've
only
literally
just
seen
this,
so
you
know
it
just
had
me
had
me
thinking
yeah,
that's
all
so,
for
example,
let
me
think
if
a
if
a
package,
I
I've,
seen
a
lot
of
stuff
recently
where
people
say
they
only
support
versions
of
node
which
are
lts,
active,
lts
and
higher
and
don't
document
it
in
their
module.
F
A
Just
interject,
sorry
I
I
know
gar
and
wes
also
have
their
hands
up
but
I'll.
Let
you
finish
your
thought.
If
you
had
something
else
to
add
to
houston,
nothing.
F
Else
to
write,
I
was
just
throwing
out
there.
I
don't
know
if
it's
directly
going
to
impact
this,
probably
going
to
be
fine.
A
E
Then
wes
just
thinking
of
the
problem
it's
trying
to
solve,
is
and
when
we
run
into
at
npm
all
the
time,
the
node
library,
where
you
know
exactly
this
problem,
where
we
have
a
contract
we
have
to
support
in
order
to
update
to
a
new
version,
it's
got
a
different
contract
than
we
have
so
we
can't
update
this
wouldn't
solve
our
problem,
but
I'm
hesitant.
E
E
That's
just
kind
of
how
it
works
like
you
can't
update
unless
you're
also
gonna
wanna
support
what
the
new
one
supports
right.
It's
it's
unfortunate
and
there
may
not
be
a
solution
to
that
and
then
that's
where
this
pain
comes
from
is
because
we
want
to
resolve
it.
But,
like
the
resolution
of
like
when
I,
when
people
type
install,
you
know,
they're
gonna
get
a
bunch
of
different
things
in
a
land
of
package
locks.
G
Yeah
I
just
wanted
to
comment
on
the
package
support
intent
versus
in
reality,
what
people
put
in
the
engines
field.
This
is
what
the
package
maintenance
working
group
was
hoping
to
address
with
the
support
specification
never
really
landed.
Officially,
I
think
I
don't
know
if
anybody's
currently
working
on
it,
but
there
is
a
gap
between
intent,
support
and
you
know
like
this
will
break
when
you
install
it
and
try
to
require
it.
G
I
don't
think
it's
npm's
job
today
to
solve
both.
I
think
we
need
the
you
know
again.
I,
like
the
supports
back.
I
know
there
was
a
lot
of
question
on
how
deeply
it
went
you
know
and
how
opinionated
it
was
so
so
maybe
you
know
someday.
We
folks
can
revisit
that
and
to
me
that
would
be
the
advisory
versus
the
as
tyranny
said
in
chat
that
it
should
be
part
of
your.
G
You
know,
dependency
resolution,
maybe
engine
strip
by
default
someday,
but
I
think
we
need
to
have
some
sort
of
intermediary
which
says
like
we
think
this
should
work
versus
where
engines
is
like
explicitly
saying
it
does
or
does
not
work.
So
I
just
want
to
make
sure
there's
that
descriptor
that
difference
here
when
we
talk
about
this
problem,
because
I
think
what
they're
looking
at
is,
unfortunately
the
a
little
bit
of
the
intent
they
think
like
the
intent
should
be
honored
anyway.
A
So
next
steps
here,
it
sounds
like
giving
some
feedback
on
this.
In
general,
though
it
doesn't
yeah,
it
doesn't
sound
like
something
that
we
would
want
to
support
the
way.
That's
detailed
here.
D
Yeah,
I
mean
it's
unfortunate
because
I
think
all
of
us,
even
myself,
have
used
cases
where
we
would.
Things
would
be
easier
if,
like
a
dependency
of
version,
4
of
a
dependency
dropped,
support
for
node,
10
and
version
3
didn't,
and
then
I
could
say,
3
or
4
is
fine
and
then
node
10
users
and
below
got
version
3
and
the
others
automatically
got
version.
D
Four
right
like
that
sounds
like
a
wonderful
experience
would
solve
a
lot
of
problems
like
you
know
it
would
make
maintaining
packages
much
easier
for
people
when
their
own
transitive
dependencies,
you
know,
are
aggressive
with
dropping
support
for
for
for
platform
versions,
but
because
engines
as
it
currently
is,
is
so
like
misused
like
it's
not
consistently
specified.
It's
often
specified
incorrectly
or
too
broadly
a
package.
D
B
Yeah,
I
I
guess
like
if,
if
someone's
trying
to
use
something
that
is
greater
than
or
equal
to
node
0.6
on
node
12,
and
it's
not
going
to
work
on
node
12,
it's
not
going
to
work
like
that's.
That's
kind
of
a
non-problem
there's
already
a
problem
inherent
there
and
the
engine's
field
isn't
really
preventing
that.
Well,.
D
G
Like
we're
that's
the
whole
point
of
that
feature
right
is
that
the
application
owner
can
make
that
decision
for
their
entire
tree.
So
I
think
we,
if
we
want
to
go
down
the
route
of
discussing
whether
or
not
it
is
helpful
for
somebody
to
be
able
to
interject
and
jump
in
and
say,
hey.
No.
G
D
Like
the
thing
that
I
think
would
be
like,
so
let's
say
I
maintain
an
eslint
plug-in
and
I
need
a
certain
dependency
for
eslint
six,
but
I
don't
need
it
for
eslint
seven.
It
would
be
great
to
be
able
to
say
don't
install
this
if
you're,
if
you
have
eslint
seven
but
do
install
it
if
you
have
eson
six.
D
A
So
I
just
wanted
to
quickly
interject,
so
it
does
sound
like
you
would
still
need
some
sort
of
conditional,
spec
or
schema
to
provide
those
variants,
and
we
actually
talked
about
you
know
distributions
or
variants
varying
packages
internally,
I
think,
over
a
month
ago,
when
I
know
yarn,
was
starting
to
cut
to
discuss
that
as
well.
A
G
Yeah,
I
still
think
that
the
user
experience
you
want
can
be
achieved
through
other,
more
generic
mechanisms
that
have
already
been
rfc'd
out.
So,
for
example,
one
way-
and
I'm
not
saying
this
is
the
best
way
or
the
only
way,
but
one
way
could
be
the
parent
package
json
combined
with
overrides
right
so
say
you
have
a
version
of
your
plug-in
with
a
combined
set
of
dependencies
and
specific
version
requirements
that
aren't
explicitly
true
about
your
package
in
all
use
cases,
but
you
could
in
in
that
regard,
you
could
publish
a
a
parent
package.
G
Json
right
like
remember,
we
talked
about
being
able
to
say
the
parent
comes
from
a
registry
spec.
So,
like
you
could
in
theory,
say
like
here's,
the
configuration
you
want
to
use
if
you
need
this
to
work
with
old
and
unsupported
node
versions.
Right,
and
if
you
need
that,
then
you
go
this
other
route,
because
that's
the
legacy
way
anyway,
and
then
your
newer
one
would
work
on
lts's,
right
and
and
so
so,
yes
you're,
making
your
consumers
who
want
to
stay
on
legacy.
Node
versions
jump
to
an
extra
hoop.
G
But,
to
be
honest,
like
that's,
probably
a
good
thing
right,
even
from
the
user
experience
for
them,
because
they
know
now
they've
had
to
opt
into
this.
You
know
non-standard
world
that
you
don't
want
to
support
and
node
doesn't
want
them
on
right
so
like
to
me.
That
might
be
that
extra
hurdle
is
actually
maybe
fine,
as
opposed
to
adding
this
feature,
which
would
complicate
things
for
everyone
across
the
board,
trying
to
figure
out
why
that
version
got
installed
and
it
was
because
oops
I
ran
nvm.
G
You
know,
use
12
yesterday,
just
testing
something-
and
I
forgot-
and
now
my
build
that
was
deterministic
is
now
failing,
and
I
don't
know
why
right
and
that's
a
much
worse
debugging
situation
than
explicitly
having
people
opt-in
to
configuration
differences
because
they
want
to
be
on
older
notes.
Yeah.
C
So
yeah
the
we
do
kind
of
have
this
heuristic
matching
based
on
the
engine.
So
we
we,
when
we
sort
the
packages
and
then
select
kind
of
the
you
know
quote-unquote
best
one.
We
sort
them
such
that
ones
that
don't
match
the
engine
get
pushed
further
down
the
list.
The
problem
is
we
skip
that
whole
process
of
sorting
engine
sorting
package
versions?
C
If
the
disk
tag
latest
version
is
within
the
range,
then
we
just
say:
okay,
you
can
use
the
latest
one.
So
I'm
going
to
give
you
that,
because
that's
kind
of
like
you've
said
that's
your
default
tag,
that's
the
one
that
we're
going
to
go
fetch.
If
we
just
skip
that
check.
We
just
don't
you
know
like
we
only
we
only
shorthand
to
the
to
the
latest
version.
C
If
the
engine
is
okay
for
that
latest
version,
then
I
think,
like
the
80
of
this
problem
goes
away,
because
now,
at
least
on
the
initial
install,
when
you
don't
have
it
in
a
lock
file,
you
will
get
if
you
install
mocha
at
eight
or
nine
and
you're
on
node
10
you'll
get
eight
rather
than
nine,
so
we'll
perf.
We
should
we
really
ought
to
be
like
the
intent
is
there
for
us
to
be
preferring
the
one
that
is
allegedly
going
to
work.
C
With
your
current
note
version,
you
know
to
the
extent
that
we
have
that
information.
The
now,
of
course,
if
it's
within
a
lock
file,
we're
gonna
give
you
what's
in
the
log
file,
there's
no
way
around
that,
and
that
would
be
breaking
a
contract
to
do
otherwise,
so
we're
not
going
to
do
otherwise.
I
think
that
we
probably
need
to
surface
the
accept
versions,
because
that's
that's
something
that
is
actually
super
super
handy.
What
what
mocha
could
be
doing
is
saying
or
like
whatever
depends
on
mocha
could
say.
C
Well,
I
I
only
I
support
node
back
to
10.,
mocha
9
has
come
out
which
only
supports
node
12
and
up
I
work
with
eight
or
I
work
with
nine.
The
one
correct
way
to
do.
That
would
be
to
say
my
dependencies
is
mocha
8.
My
accept
dependencies
is
mocha
9,
and
so,
if
9
is
already
there,
fine
cool
you've
got
a
newer,
mocha
I'll
use
that
if
ten
comes
out
all
right,
we
gotta
nest.
C
Something,
but
the
one
that's
going
to
be
pulled
in
by
me
is
is
mocha
eight
and
then
the
the
third
thing
is
like
wes
said
like
this
could
just
be
handled
with
overrides
and
documentation
once
we
land
that
feature.
So
I
I
what
I
really
really
the
thing.
C
That's
like
the
you
know,
alarm
bells
and
clackson's
going
off
in
my
brain,
which
most
people
on
this
call
probably
know
exactly
what
I'm
going
to
say,
but
for
the
benefit
of
anybody
new
listening
to
this
video
on
on
youtube
or
the
stream,
we
cannot
resolve
the
package
tree
differently
on
different
systems
like
you're.
C
If,
if
we
create
one
tree
on
one
system
and
a
different
tree
on
a
different
one,
that
is
a
that
is
a
nightmare
because
we
have
to
lock
both
you
know:
potential
trees,
it's
it's
not
clear,
which
one
we're
going
to
be
using
at
any
given
time
like
all
all
determinism
goes
out
the
window.
If
we
do
that,
so
if
you
don't
have
a
lock
file,
there's
no
determinism
anyway.
So
you
know
who
cares?
This
is.
C
So
yeah,
so
that
is,
I
think,
a
bug,
and
we
should
just
fix
that
bug.
We
shouldn't
be
defaulting
to
the
latest
version
if
the
latest
version
is
allegedly
not
going
to
work
for
you.
C
I
say
allegedly
because
a
lot
of
times
people
have
aggressive
engines
fields
just
because
they
don't
feel
like
dealing
with
it,
and
you
know
I
cannot
fault
them
on
that.
I
I
do.
A
As
well
as
took
the
action
of
we're
going
to
remove
the
logic
to
sort
based
on
the
matching
engines
first
using
just
latest,
is
that
right.
Isaac.
A
Specifically,
the
variance
and
distributions
is
something
that
we
can
bring
up
at
a
later
date,
once
we
have
like
an
rc
potentially
for
that
something
that
we
can
at
least
discuss,
but
going
back
to
what
isaac
just
said,
yeah.
A
I
think
it
makes
sense
that
you
don't
want
to
be
creating
different
log
files,
but
you
might
be
reifying
different
packages,
which
already
happens
today
right.
The
idea
of
like
optional
dependencies
are
being
installed
for
folks
to
support
different
platforms,
I
think,
is
how
people
are
falling
back
to
that
behavior
today.
C
Oh
one,
one
other
thing
I
wanted
to
mention
this
is
this
is
pretty
far
afield
from
what's
been
requested
in
this
in
this
rfc,
but
jordan
tier
question
of
you
know:
I've
got
I've
got
version.
One
works
with
this
range
of
eslint
and
version.
Two
works
with
this
other
range
of
eslint,
and
I
want
to
be
able
to
just
say
to
people
like
look,
you
can
install.
You
know
my
thing
at
star
and
you'll
get
the
one
that
works
with
the
eslint
that
you
have.
D
It's
it's
more
like
so
my
so
my
plugin
has
a
peer
dependency
on
eslint,
six
or
seven,
which
means
I
don't
care
which
version
of
esl
they
have.
They
have
either
one.
But
what
I
want
to
say
is:
I
want
a
dependency
on
two
different
versions
of
this
package,
depending
on
which
eslint
version
they've
chosen.
So
I
don't
want
them
to
have
to
peer
depend
on
this
thing.
I
I
can
explicitly
depend
on
it,
but
I
know
that
like
eslint
6
needs
v2
and
es17
needs
v3.
C
So
that
in
in
an
ideal
world
right,
so
you
have
like
you
have
a
you,
have
your
thing.
Your
like
plugin
has
a
peer
dependency
on
eslint,
six
or
seven,
and
then
library
at
version
one
depends
on
eslint,
six
and
library.
At
version
two
depends
on
eslint,
seven
yep
and
your.
C
Peer
depends
right
and
you
wanna
take
library
version
one
or
two
and
then
get
the
one
that
works
with
the
es.
Lin
that
is
being
pulled
in
this
is
essentially
the
same.
I
think
that's
the
same
shape
as
the
react-dom
problem.
Where
you
have
you
have
two
things
in
your
tree.
One
of
them
depends
on
react
16.
C
C
You
can
get
yourself
into
a
state,
then,
where
we're
trying,
where
we
think
that
react,
dom
17
is
the
one
that
we
need
to
pull
in
for
that
dep,
because
it's
the
latest
and
greatest
and
everything
looks
wonderful
about
it,
but
then
it
conflicts
and
it
it's
not
a
conflict
that
we
see
an
easy
way
to
resolve
right.
We
have
to
like
walk
back
up
the
dependency
resolution
tree
well,
but.
D
E
C
C
So,
but
we're
not
currently
tracking
those
sort
of
extended
conflict
rules
and
then
re-evaluating.
That
is
something
that
is.
I
would
like
to
do
again,
like
that's
like
in
a
perfect
world.
That
would
make
a
lot
of
react.
Users
happy
the
work
around
now
is
the
root
project
has
to
specify
what
version
of
that
library
they
they
need
to
pull
in,
and
it's
a
little
bit
of
a
you
know.
We're
sort
of
putting
some
of
the
package
resolution
work
on
the
user,
which
is
not
our
goal.
A
Yeah,
just
in
mindful
yeah,
let's
move
on
so
pr
396,
this
is
pure
dependency
should
be
able
to
match
full
range
of
pre-release
versions.
I
feel
like
this
is
going
to
be
pretty
quick
I'll
share
the
rfc
in
chat
for
folks.
A
I
believe
this
oh
got
opened
a
couple
weeks
back.
Actually
what
card
did
you
want
to
go.
E
Yeah
I
mean
they
right
in
there.
They
admit
this
is
gonna,
be
effectively.
The
only
way
to
do
this
was
just
change
the
sember
spec.
This
is
just
not
how
pre-releases
work.
F
E
F
I
was
the
one
that
rose
the
the
rfc
here
so
yeah.
I
wasn't
too.
That
was
the
only
thought
I
had
it'd
be
nice
if
it
could
work,
but
it
seems
like
potentially
after
I
I
made
it,
it
seemed
like
potentially,
maybe
it's
not
how
pre-release
versions
should
actually
work.
Oh
sorry,
it's
not
how
peer
dependencies
should
be
used,
like
this
particular
use
case,
potentially
isn't
a
case
for
peer
dependencies.
F
Sure
so
I'll
give
maybe
the
everything
the
eslint
example,
and
it
depends
how
yes
in
this
case,
would
be
developed.
So
you
have
a
so
if
you're,
if
you're
the
developer
of
esl,
let's
say-
and
you
want
to
work
on
a
new,
a
new
version
and
you're
using
pre-releases
for
the
the
main
eslint
package,
and
then
you
have
plug-ins
which
depend
on
those
you
know,
versions
of
your
sling.
F
So,
for
example,
you've
got
eslin
four,
for
example,
and
you
have
a
plug-in
that
depends
on
as
a
peer
dependency
on
eslint4.
F
So
that
basically
means
that
either
they
said
either
simva
has
to
change,
or
we
can't
use
peer
dependencies
because
it's
just
totally
broken
on
npm7
and
you've
got
to
use
the
legacy
legacy
peer,
deps,
which
obviously
isn't
the
recommended
way
forward,
and
we
obviously
need
a
way
forward
and
to
decide
where
to
go
on
that.
F
It
could
be
yes,
yeah,
it's
either
during
development,
so
in
my
case
our
obviously
I'm
not
a
developer,
but
in
our
in
our
module,
we're
developing
internally
we're
testing
plugins
that
are
already
released
with
our
module
and
it
just
it'll
just
break
while
we're
while
we're
developing.
But
there
are
the
cases
where
these
prereleases
are
potentially
public,
and
so
other
people
want
to
test
them
in
a
more
open,
open
source
module.
F
E
C
It
seems
like
it
seems
like
regardless
of
sort
of
pre-releases
per
se.
This
feels
like
a
like
an
interesting
problem
with
it
like.
Basically,
what
you're
saying
is
there
are
cases
where
you
want
to
allow
pre-release
versions.
Sorry,
it's
not
like
pure
depths
per
se.
There's
cases
where
you
want
to
be
able
to
install
a
thing
that
it
with
a
range
that
includes
pre-release
depths
right,
where
we
sort
of
flip
on
that
include
pre-release
flag
in
no
december
there's
options
for
that.
C
C
They
have
plenty
of
big
fish
to
fry
the,
but
but
it
is
sort
of
on
the
long-term
roadmap
and
the
the
client
support
for
it
is
is
all
there
there's
two
ways
I
can
imagine
there's
sort
of
the
blunt
way
and
the
challenging
way
the
blunt
way
would
be.
We
add
a
flag
in
npm
called
include
pre-releases,
and
if
you
do
that,
then
every
sember
check
that
we
do
just
includes
prereleases.
So
you
get
it
it's
like
very
all
or
nothing
very
straightforward.
C
It's
it's
already
just
a
flag
we
can
pass
through
to
november.
So
we
would
just
do
that
everywhere.
The
second
thing-
and
we
only
we
only
actually
check
for
december
ranges
in
one
place
when
we're
picking
the
manifest.
So
it's
not
even
that
many
places
we
need
to
go
and
update.
The
downside
of
that
is
then
you're
going
to
get
all
pre-releases
everywhere
right,
if
you,
if
you
run
npm,
update
dash
dash,
include
prereleases
you're,
going
to
get
a
whole
lot
of
stuff.
Maybe
that
is
actually
broken.
C
The
other
thing
as
z,
zb
you're,
not
right,
as
that
was
suggested
in
the
chat
we
we
have
a
new
addition.
You
know
we
could
add
a
new
addition
to
the
december
range
syntax,
where
we
have
a
new
character
that
that
is,
you
know,
or
some
way
to
kind
of.
In
that
dependency.
Specifier
say
this:
one:
okay,
cool
got
the
right
name,
so
this
one
can
be,
you
know,
can
include
pre-releases
and
doing
that
it's
kind
of
maybe
good
news.
C
C
That
is
the
the
more
difficult
one.
Just
because
that's
I
don't
know
more
useful
and
expressive,
but
also
has
much
more
chance
of
side
effects,
and
when
we
get
something
into
the
you
know,
if
we
update
the
range
syntax
and
then
somebody
publishes
a
package
with
that
range
now,
it's
not
installable
by
versions
of
npm
that
don't
understand
that
range
they'll
see
it
as
an
invalid
stem
for
range
potentially,
which
may
be
good.
I
don't
know
that
may
actually
be
a
feature
rather
than
a
then
a
drawback,
so
yeah.
C
Those
are
those
are
kind
of
the
two
ways
we
can
go,
you
you
and
if
we
do
it
with
the
blunt
approach
of
a
an
npm
config,
you
can
still
very
you
know
you
can
target
what
you're
installing
you
can
say.
Npm,
install
foo
at
one
dot
x,
dash
dash
include
prereleases
and
you're
only
going
to
get
pre-releases.
For
that
thing
and
it's
you
know
child
nodes
so.
F
It's
when
the
is
when
npm
tries
to
resolve
the
pair
dependencies
and
tries
to
map
it
realizes,
for
example,
you
know
you
know
you
plug
in
pair
depends
on
on
on
4,
for
example,
4-0
the
pre-release
is
already
installed,
and
then
it
tries
to
install
the
one
that
matches
the
peer
dependency.
So
you
end
up
with
either
two
versions,
one
overrides
the
other
or
you
get
some
sort
of
compatibility
error.
C
Right
because
you
need
the
pre-release,
but
the
other
thing
depends
on
a
a
specific
version,
not
including
the
pre-release
yeah.
F
Or
there's
no
way
of
saying
that
it
includes
a
pre-release
like
because
that
goes
back
to
december
point:
the
there
is
no
way
of
actually
matching
every
every
version
within
a
you
know,
major
minor
patch
range
and
includes
all
pre-releases
within
that
range
right.
It's.
C
Yeah
we
could,
you
know
another
way
to
another
way
to
crack.
This
might
be
to
have
an
option
in
package.
Json
that
says
these
are.
These
are
the
dependencies
that
I
will
allow
pre-releases
on,
and
so
you
could
say
all
right.
Well,
this
this
plug-in
that
has
a
peer
dependency
on
something
could
just
set.
Could
just
say
I
allow
pre-releases
of
that
pure
dependency,
so
you
kind
of
opt
into
all
of
them.
C
C
Yeah,
if
it's
well,
unless
you
want
to
do
some
integration
testing
with
a
dedupe
dependency.
A
G
Yeah
so
specifically
on
this
problem
from
a
if
we're
scoping
that
the
problem
here
is
a
during
development
problem,
not
a.
I
want
to
go
to
my
broad
user
base
with
a
install,
please
pre-release
versions,
version
of
your
package.
I
have
used
disk
tags
for
this
similar
scenario
here.
It's
not
a
great
user
experience
right
now,
but
it's
again
because
it's
scoped
only
to
like
I
want
to
test
this
set
of
packages
together.
So
basically,
what
I
would
have
done
is,
I
will
depend
on
the
disk
tag
directly
in
the
package
json.
G
That
means
that
if
I'm
publishing
on
that
disk
tag
with
a
series
of
pre-releases,
all
I
have
to
do
is
either
update
my
lock
or
run
without
a
lock
for
a
little
bit
during
development,
and
I
just
end
up
getting
continually
the
new
pre-release
versions,
because
all
I'm
really
specifying
is
the
disc
tag
and
from
a
development
standpoint.
I
actually
think
that's
better,
because
you
don't
want
a
sever
range
of
pre-releases.
G
You
want
this
one
pre-release
that
we
just
published
that
we
have
to
lock
into
because
explicitly
in
summer
those
pre-releases
could
contain
breaking
changes.
You
can't
really
say
that
you
know
you
want
to
accept
all
pre-release
in
a
production
scenario.
You
can
only
do
that
in
development,
and
at
that
point
I
don't
see
a
strong
reason
not
to
just
improve
the
ux
around,
depending
on
disk
tags.
F
Maybe
it
becomes
slightly
more
complex,
then
I
wasn't
necessarily
suggesting
that
all
these
tags
become
get
pulled.
It
was
something
like
the
carrot
or
the
tilde
syntax
right
now,
but
including
this
tank.
So
you
wouldn't
get
breaking
changes.
If
you
wanted
version,
four,
you
know
allow
everything,
that's
version
four,
including
including
pre-releases
and
then
you'd
kind
of
get
that
that
compatibility.
Basically,
you
know
you
know
your
plugin
works
with
every
version
future
and
past
and
in
the
middle
you
know.
G
Yeah
sure
I
mean
I
think
I
understand
what
where
you're
going
at,
I
was
trying
to
take
sort
of
a
different
course
to
support
the
development
and
testing
use
case.
Because
again,
I
think
any
time
you
go
to
a
main
release
right,
a
1.0.0
as
opposed
to
a
1.0.0-1
you
now,
if
you,
if
you
include,
depending
on
a
pre-release,
you
are
in
a
locked
state
right,
you
have
locked
that
dependency
to
a
single
version
and
you
have
locked
it
to
a
version
that
is
explicitly
not
ready
for
production
use.
G
So
I
don't
think
that
you
ever
want
to
publish
a
a
main
version
where
you
depend
on
a
pre-release
version
of
one
of
your
dependencies
explicitly.
I
think
you
might
want
to
depend
on
a
disk
tag
that
will
move
forward
with
some
development
and
that
even
on
the
public
register,
I'd
say
that's
pretty
iffy
I
mean
that's
like
for
me
on
par
with,
like
a
production
dependency
depending
on
a
get
dependency
like
that
has
caused
tons
of
problems.
In
my
experience
from
debugging
and
the
other.
D
On
and
I
think
wes
you're
right,
I've
done
this-
the
enzyme
reacts,
16
adapter
still
depends,
there
are
still
supports
by
appear
dependencies,
react,
16.0,
pre-releases
and
must
do
so
until
I
make
a
breaking
change
to
drop
it.
Obviously
I
will
drop
it
as
soon
as
I
make
a
breaking
change,
but
you
know
it
is.
It
is
very
undesirable
to
public
to
explicitly
be
supporting
pre-releases
publicly.
G
And
in
that
case,
the
the
the
user
experience
to
me,
while
it's
not
super
great,
is
probably
again
incentivizing,
better
behavior,
so
the
the
user
experience
there
is.
You
have
to
do
1.0.0-1
or
1.0.0-2
right
and
like
to
me
that
extra
hurdle
is
really
they're,
probably
incentivizing,
better
behavior
out
of
module
authors
at
the
risk
of
yeah,
obviously
being
verbose
and
painful,
but
again
should
only
be
used
in
development,
and
at
that
point
some
compromises.
I
think.
A
So
I'm
just
gonna
quickly,
interject
and
and
say
we
have
about
10
minutes
left,
so
I'm
hoping
we
can
yeah
wes
is
getting
blown
away
and
and
jordan.
I
think
you
also
have
spotty
internet
today,
but
I
think
we
were
able
to
hear
everything
you
were.
You
were
getting
at
I'm
trying
to
take
his
best
notes,
as
I
can
but
feel
free
to
add,
notes
and
comments
back
to
the
rfc
itself.
A
I
think
we
should
leave
this
open
at
least
for
another
week,
if
you're,
okay,
with
coming
back
else
there
to
continue
talking
about
this
and
and
sort
of
the
options
that
we
have
available
to
you
and
maybe
also
like
what
we
can
do,
including
you
know
what
isaac
spoke
to
in
terms
of
like
I
include
pre-releases
flag
is
one
option.
It
sounds
very
similar
to
ideas
that
we
floated
also
with
include
staged.
A
When
I
I
spoke
about
the
fact
that
we
had
almost
like
a
similar
concept
ideated
about
a
year
or
two
ago,
yeah
gar,
I
see
your
hands
up
I'll.
Give
you
the
last
word
on
this
and
then
hopefully
we
can
move
forward.
E
I
would
just
ask
alistar
to
type
out
their
use
cases
as
much
as
they're
comfortable,
making
the
specifics
public
in
there.
So
we
can
have
a
discussion
in
the
comments
there.
So.
E
A
Awesome
thanks
for
that,
the
last
two
issue-
rfc
420-
don't
expand
tabs
by
default.
I'm
not
sure
if
that
user
is
here
on
the
call
I
might
punt
this
to
next
week.
I.
C
Actually
just
commented
on
that
great
it's,
so
we
preserve
indentation
in
package
lock
and
package
log
and
package
json.
The
one
way
we
could
maybe
tackle
this
is
just
create
an
indent
and
eol
config
items
and
if
those
are
present
then
npm
and
it
will
use
them.
A
Yeah
I
was
having
a
internal
conversation
with
luke,
cares
on
our
team
about
formatting
as
well,
and
he's
potentially
going
to
submit
an
rfc
for
for
essentially
configs
for
package
json
forming
since
we've
introduced
the
npm
pkg
set
of
commands.
Some
folks
have
asked
us
whether
or
not
we'll
provide
config
to
format
package.
Json
specifically,
I
think
this
lines
up
with
what
you
just
suggested
isaac,
so
yeah.
A
I'll,
hopefully,
get
luke
to
circle.
Back
on
that
wes,
I
see
your
hands
up.
G
Yeah,
well,
I'm
totally
a
fan
of
providing
this
option
and
I
don't
think
it
makes
too
much
of
a
difference.
This
is
specifically
one
of
the
features
I
was
hoping
we'd
land
in
the
packaging,
knit
library
that
we
were
working
on
in
package
pktjs,
because
I
think
there's
yeah
anyway.
I
think
this
is
where
we
start
to
stray
into.
G
Like
the
you
know,
we'll
do
we
have
to
add
a
new
feature
to
npm
just
to
support
every
like
you
see,
I
know
this
one's
pretty
popular,
and
so
it
makes
sense,
but
I
think
that
you
know
a
more
robust
experience
is
probably
a
better
long
term
than
continuing
to
add
features
like
this
npm
directly.
A
Yeah,
I
think
it's
just
that
when
we
go
and
touch
package.json
how
we
leave
it,
it's
like
we
don't
have
any
indication
of
of
how
you
want
your
packages
on
to
be
left
and
we
are
already
doing
certain
things
to
it.
A
G
Sort
of
what
I
meant
fixing
those
seems
great
right.
That's
why
I'm
sorry!
That's
what
I
try
to
mean
by
when
I
said,
I'm
not
opposed
to
this
edition
and
like
the
way
this
is
working.
I
just
meant
the
more
robust
problem
here
is,
like
people
have
opinions
about
how
they
want
those
files
written.
Maybe
they
have
order
of
keys
that
they
want,
and
like
stuff
like
that,
that
you
know
I
mean
I
think
that
would
just
be
a
a
long-term
maintenance
nightmare
to
try
to
accommodate.
G
A
My
goodness
we're
not
going
to
have
tabs
for
spaces
comments
in
in
the
chat
right
now.
I
can't
let
this
like
degrade
to
that
level.
C
Would
actually
be
pretty
straightforward.
The
the
json
stringifier
that
we
use
for
package.json
and
packagelock.json
both
accept
a
list
of
keys
to
prioritize
that.
E
A
Yeah,
so
I
just
want
to
try
to
get
to
the
last
item
at
least
give
it
five
minutes
here.
If
folks
have
any
other,
any
other
comments
feel
free
to
leave
them
there
in
the
rrc
itself.
The
last
item
that
we
have
here
422
the
audit
assertions
that
tierney
has
put
together,
was
a
last
minute
edition.
It
only
got
created
today,
and
I
know
that
he
wants
to
be
on
the
agenda,
so
yeah
feel
free
to
queue.
This
up.
B
Yeah,
there's
been
a
large
amount
of
discussion
already
tldr.
This
is
a
mechanism
for
counter
claims
in
npm
audit.
This
was
largely
spurred
by
discussion
of
dan
abramov
prior
to
his
blog
post
and
yeah.
It's
basically
just
a
proposal
for
a
catalan
method.
One
thing
I
will
say
is
that
it's
intended
at
being
consumed
by
maintainers
there's
some
nice
suggestions
in
there.
I
think
that,
like
you
know,
having
third
parties
also
be
able
to
make
claims
is
a
cool
thing
that
could
happen.
It
shouldn't
happen.
B
Initially,
I
don't
think
but
yeah
there's,
you
know
some
stuff
there.
Please
take
a
look.
If
folks
have
stuff,
they
want
to
say,
feel
free.
C
Yeah,
it's
it's
huge,
there's
also,
there's
also
some
stuff
that
that
was
shared
that
I
got
pointed
at
that
I'd
want
to
kind
of
bring
into
this
conversation
around
discussions
related
to
this
at
a
more
general
like
not
npm,
specific
level.
There's
there's
a
whole
specification
standards
body
project
going
on
to
specify.
Oh,
what
is
it
vulnerability,
vulnerability,
exchange
extension,
something
v-e-x
and
that's
that
also,
then,
is
sort
of
a
way
to
specify
like
here's,
this
vulnerability,
here's
a
note
about
it.
C
Here's
how
to
know
if
you're
affected
by
it
or
not-
and
we
could
we
could
piggyback
on
a
lot
of
that
and
you
know,
provide
a
much
better
experience
for
npm
audit
users.
I
think
that
the
the
big
thing
is
probably
what's
probably
going
to
have
to
change.
Is
it's
not
just
a
boolean?
It's
you
know
like
what
we
what
I've
seen
I
mean
very
recently
is
you
are
vulnerable
to
this?
C
If
you
are
calling
this
particular
method
and
if
you're
not
you
kind
of,
don't
have
to
worry
about
it,
and
so
it
we
can
provide
some
some
additional
context
for
package
authors
to
make
the
correct
decision
there.
We
can
also
have
a
big
discussion
about
how
to
validate
these
things,
and
you
know
who
to
allow
is
it?
Are
you
just
turning
it
off
because
you're
sick
of
people
posting
issues
on
your
repo?
Are
you
turning
it
off
because
it's
actually
you're
actually
not
vulnerable
like?
C
A
I
want
to
apologize
mike
who
joined
the
call
mike
mcdonald
here,
who's
been
kindly
waiting
this
whole
time.
Hopefully
it
will
join
us
again.
H
A
Fun,
thank
you.
So
much
actually
do
you
want
to
quickly
introduce
yourself
before
we
we
break
so
folks
know
who
you
are.
H
A
H
I've
been
doing
developer
tools
at
github
for
about
six
months,
working
on
dependabot
and
then
prior
to
that
I
was
the
first
pm
at
firebase
and
worked
on
google
cloud
serverless
things,
so
I
worked
with
miles
actually
quite
a
bit
in
in
the
past,
so
very
excited
to
work
with
you
all.
I
think
this
is
a
super,
interesting
and
fun
problem
to
solve
so
happy
to
come
back.
G
Can
I
give
a
quick
plug
for
the
collab
space,
so
so
this
specific
topic
is
was
going
to
be
is
going
to
be
still
the
the
primary
one
we
want
to
tackle
in
the
collab
space
first
up,
so
I
don't
know
if
everybody's
familiar
but
darcy
and
I
put
together
a
little
like
introduction
to
what
it
is
it's
on
youtube.
I
can
find
a
link
to
it.
G
We
had
our
sort
of
setup
meeting
and
then
we
are
working
on
planning
the
next,
but
I
think
we
were
going
to
do
bi-weekly
and
I
go
on
vacation
for
two
weeks
next
week.
So
I
don't
know
if
we're
gonna
have
one
until
I
get
back
at
least,
but
it's
open
jess
club
space,
specifically
targeting
package,
vulnerability,
reporting
and
remediation.
So
if
we
can
work
on
like
isaac,
you
mentioned
some
specifications
that
are
being
you
know,
shopped
around
at
the
you
know,
sort
of
industry
wide
layer.
G
I
think,
having
conversations
about
how
those
apply
to
javascript
would
be
excellent.
I
think,
especially
if
we
can
get
a
good
plan
for
how
we're
going
to
both
interface
with
those
groups
and
make
sure
that
we
have
a
seat
at
the
table
and
that
whatever
they
end
up,
formalizing
will
work
well
in
the
javascript
space,
since
we
have
it
probably
worse
off
the
worst
off.
G
Additionally,
I
think
we
should
maybe
take
tyranny's
proposal
here
and
add
it
to
our
agenda
over
there
for
our
first
meeting
to
talk
about
how
this
can
work
in
npm
and
if
there's
things
that
specifically
scope
to
npm
like
this
rfc
does
or
if
there's
things
that
we
need
to
be
discussing
at
a
higher
level.
Maybe
mike
you
know
you
not
typically
working
on
javascript
specific
stuff,
that's
sort
of
where
we
see
the
collab
space.
G
Helping
us
have
a
longer
discussion
period,
a
place
that
can
own
that,
because,
if
it's
in
the
npm
repo
we're
talking
javascript
specific
and
we're
going
to
make
some
decisions
there,
that
I
think
are
going
to
work
really
well
and
optimize
for
the
javascript
use
case.
But
I
think
that
might
miss
the
the
forest
for
the
trees.
Or
you
know.
I
don't
know
how
we
want
to
phrase
that,
but
basically
like.
G
If
we
don't
think
about
this
in
a
broader
context,
we
we
may
make
some
short
term
worse
decisions
for
just
the
javascript
ecosystem,
and
I
just
want
to
make
sure
we.
We
recognize
that
there's
a
lot
of
parallel
work
happening
here
and
and
we
should
make
sure
that
we
don't
we
don't
like-
forget
it
totally
about
the
specification
process
for
a
counter
claim
and
then
implement
something
and
then
have
to
like,
go
and
change
the
whole
ecosystem.
G
You
know
in
a
year
to
to
adopt
like
a
larger
specification,
so
anyway,
we're.
E
A
Yeah
I'll
add
links
in
the
notes
and
thanks
everybody
for
jumping
on,
hopefully
see
you
next
week
and
I'll
try
to
post
the
agenda
early
next
week.
Just
so
folks
know
it's
probably
going
to
be
a
deep
dive
on
this
on
this
area
for
sure.
So,
thanks
everybody
and
we'll
see
you
next
week.