►
From YouTube: Open RFC Meeting - Wednesday, May 4th 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
There
we
go
and
we're
live
sorry
for
the
billy
folks.
Welcome
everybody
to
another
mpm
open
rc
call.
Today's
date
is
wednesday.
May
4th
2022
we're
going
to
be
following
the
agenda
that
was
posted
in
issue
583
of
the
npl
rc's
repo,
just
a
quick
reminder.
As
with
all
these
calls,
we
follow
a
code
of
conduct.
We
ask
you
to
please
be
kind
to
each
other,
while
on
the
calls
also
please
be
respectful
and
raise
your
hand
if
someone
else
is
spot
speaking
and
quickly,
announcements.
A
B
A
Well
as
some
features
and
fixes
that
we'd
like
to
get
into
the
next
major
version
of
benign,
so
I
think
that
they're
in
the
agenda,
as
well
as
many
folks
from
our
team,
are
going
to
be
attending
openjs
world
would
like
to
keep
that
on
folks
radar.
If
you
haven't
already
grabbed
a
ticket
and
are
interested
we'd
love
to
see
you
in
person
or
virtually
there's.
Also,
a
virtual
attendance
available
so
would
be
nice
to
collaborate
with
folks
there.
I
know
for
myself.
A
I'll
definitely
also
be
going
to
the
club
summit
as
well
as
roy
and
miles
barnes
from
our
team
will
be
speaking
at
the
conference,
which
is
which
is
awesome.
So
any
other
announcements
from
folks.
Do
you
want
to
share.
A
If
not,
we
can
dive
right
into
the
agenda
that
we
got
starting
with
issue
572..
I
believe
we
had
oh
sorry
check
out
the
rights
stock.
A
I
think
I
was
looking
at
the
wrong
one:
okay
572.
This
is
remove
access
public
for
npm
publish.
I
think
we
had
a
good
discussion
on
this
last
week
with
tierney
at
one
two
news
here.
I
don't
know
what
the
action
items
were,
but
my
guess
is
that
we
can
probably
just
open
up
a
backlog
issue
in
my
teens.
A
I
think
I
did
that
already.
Potentially,
I
think
I
added
to
the
v9
roadmap,
so
you
could
probably
close
this
any
thoughts.
Comments.
Jordan,
let's
see.
C
Yeah,
what
we
talked
about
was
that
I
thought
was
that
the
two
changes
that
would
make
it
helpful
is
this
change,
combined
with
asking
in
npm
in
it,
if
you're,
trying,
if
you're
gonna,
publish
it
and
then
having
the
default
value
in
npm.
Eight
for
this
config
be
true
right,
like
private,
for.
D
C
Private
false
is
the
default
in
npm,
eight
right,
whatever.
However,
we
word
it
right
and
then
in
npm
nine
flipping
that
so
that
by
default,
it's
private,
true
and
then
and
then
those
the
combination
of
those
two
things
will
mitigate
any
any
risk.
I
think
eventually,
of
implementing
our
572.
A
Yeah,
I
think
I
put
those
both
actually
into
the
v9
map,
but
one
needs
to
be
in
v8
that
add
npm
init
private
config
needs
to
be
added.
A
A
But
want
to
bring
this
up
again.
It
looks
like
somebody's
chimed
in.
A
C
So
that
was
why
I
think
that
was
why
I
brought
in
that
books,
because
I
think
that
that's
the
that's
the
best
way
to
come
up
with
what
with
to
answer
the
question
of
what
low-level
direct
thing
do
we
need,
because
nobody's
thinking
about
like
nobody's
mental
model,
is
going
to
be
like
command
line.
Args
for
this
it's
going
to
be
like.
C
I
want
to
update
this
transitive
dependency
to
get
rid
of
an
audit
warning,
or
I
want
to
upgrade
this
package.
So
you
know
I
want
to,
for
the
sake
of
deduping
or
to
get
some
new
feature
right
and
like
it's.
The
more
npm
can
translate
their
intention
to
the
dependency
graph
for
them
the
better,
and
I
think
it's
entirely
achievable
to
craft
command
line.
Args
to
do
that,
but
we
have
to
know
what
those
paths
are.
First.
D
That
to
me
seems
like
an
interesting
alternative
like
maybe
we
could
just
work
on
a
proof
of
concept
that
interacted
with
those
that
work
like
kind
of
a
holistic
experience
that
will
help
drive
the
low-level
api
design.
A
D
A
You
know
if,
if
we're
not
going
to
help,
you
manage
your
packages
and
management
includes
update
your
packages
in
a
reasonable
way,
then,
like
we're
not
doing
our
job,
so
I'm
totally,
okay
with
us
investigating
or
spending
time
doing,
a
poc
of
what
interactive
looks
like,
especially
for
update,
so
even
if
it
doesn't
apply
more
holistically.
I
know
that
was
pointless
with
keys
that
were
talking
last
week.
It's
like
okay.
We
want
to
introduce
interactive
against
a
whole
bunch
of
things.
C
D
So
it
can
be
as
simple
as
a
one-liner
right
like
using
npm,
exactly
gets
piping
all
these
into
another,
but
yeah.
It
might
be
like
a
good
way
to
to
approach.
Probably.
A
Oh
backlogger
ticket,
then,
for
this,
like
a
poc
for
interactive,
I
do
think
that
we
need
the
range
flag
before
that,
though,
because
there's
no
way
to
like
opt
into
updating
outside
of
the
the
current
range.
So
it's
almost
like
a
precursor
to
that.
D
It's
like
the
equivalent
of
the
npm
outdated
having
the
one
in
the
latest
yeah
yeah.
A
Yeah
yeah,
exactly
so
like,
even
if,
like
like
the
available
ranges
to
update
to
in
an
interactive
mode,
would
be
limited
unless
you
were
doing
basically
npm
install
right
and
yeah
so
which
is
not,
which
is
not
what
we
want
update
to
be
so.
A
Okay,
cool.
Any
other
comments
on
that.
Throughout
update
improvements
at
once.
Okay,
moving
on
to
jordan's
rfc
570
workspace
tag
version,
prefix.
A
C
Yeah,
I
think
the
only
open
question
looking
at
the
rrfc
again
is
single,
commit
or
multiple
commits
and
the
I
think
people
have
different
intuitions
so
but
like.
F
C
Done
right
totally
fair
yeah
but
yeah.
I
guess
what
I
would
my
assumption
when
I
run
a
command
at
the
root
of
a
workspace
on
multiple
child
workspaces
is
that
it
runs
all
the
commands
conceptually
in
parallel
or
like
ordered
by
dependencies,
but
they're
all
run
and
then
at
the
end
of
all
the
commands
being
run
is
when
it
would
do
get
operations,
so
I
would
expect
like,
but
I
can
see
the
other
like
so
so.
C
That
expectation
leads
me
to
say
one
commit
for
multiple
workspaces,
but
I
can
see
the
opposite
expectation
of
it's
seating
into
each
one
and
running
the
npm
version
command,
thus
creating
multiple
commits,
but
like
then
you
get
into
ordering
questions
and
because
it's
mental
conceptually
it's
happening
in
parallel
and
you'd,
want
that
ordering
to
be
deterministic,
and
so
you'd
have
to
sort
things
and
like
so.
It's
just
kind
of
I
don't
know,
what's
an
easier
approach,
but
either
way
I
can
see
people
wanting
both
behaviors.
A
Yeah,
the
easiest
way
forward
is
just
like
to
continue
like
that.
Right
now,
it
works
like
the
cd
approach,
where,
like
we're,
not
we're
just
going
in
there
and
running
an
empty
version,
and
if
you
don't,
if
you
want
to
manage
things
in
a
more
sophisticated
way,
then
you
can
just
opt
out
of
creating
a
commit
and
then
essentially
have
everything
in
a
single
commit
right
like,
and
we
have
that
build
like
that's
available
today
and
I
think.
C
That's
a
defensible
rationale
is
basically
like
to
to
manually
get
the
other.
Behavior
is
easier
when
the
default
is
multiple
commits
than
when
the
default
is
a
single
commit,
and
so
it
you
know
we
might,
although
npm
might
support
both.
Eventually,
this
is
the
current.
You
know
mvp.
That
seems
like
a
defensible
answer,
but
you
know
we
just
have
to
have
like
decided
it
yeah.
I
think.
A
C
Yeah,
it's
basically
just
a
an
additional
config
around
the
tag.
Prefix
that
applies
to
workspaces
and
whether
it
co-op
like
whether
it
replace
it
like
overrides
the
other,
the
existing
one
or
whether
it
composes
with
it,
is
a
different
question.
Composing
might
be
nice,
but
but
like,
and
then
the
name,
the
spelling
of
that
new
config
is
also
you
know,
a
bike
shed
so,
but
it
seems.
E
Yeah
the
we're
talking
about
our
release
process
today
and
this
and
the
tag
parameter
itself
need
to
be
able
to
be
templatized.
So
that's
just
going
to
have
to
be
part
of
this
work.
C
It's
currently
just
a
string
right
like
it's
just
a
structure.
Well,
it
doesn't
exist.
No,
but
I
mean
there's.
The
prefix
for
non-workspace
usage
is
just
a
string
right,
so
yeah.
It
does
make
sense
to
me
that
ins,
that
the
sim
that
a
holistic
solution
would
be
just
a
straight
up
template
for
the
tag
that
replaces
the
existing
config
and
includes
a
workspace
thing.
C
But
then
you
have
to
get
into
optionality,
because
when
there's
I'd
want
a
config
that
would
work
for
both
simultaneously
a
non-workspace
project
and
a
workspace
project,
and
I
would
want
a
space
between
the
workspace
name
and
the
version
name,
but
I
would
only
want
that
space
present
when
there
were
workspaces.
So
it's
not
quite
as
straightforward
as
my.
D
So
the
action
item
you're
creating
the
backlogging
tickets.
A
Likely
coming
in
b9,
unfortunately,
since
we're
eliminating
how
much
we're
trying
to
get
done
for
v8
right
now
and
notably
should
start
that
release
can't
it's
39
in
the
coming
months,
so
cool
moving
on
to
our
our
fc-569.
A
A
Oh,
I
think
this
is
just
yeah.
I
don't
think
this
is
this
person
is
trying
to
define
packages
with
the
same
name
and
reference
them
and
unfortunately
was
doing
that
from
different
registries,
so
I
just
told
them
to
investigate
scopes,
so
they
haven't
followed
up
and
unless
somebody
else
reads
into
this
something
different.
That
was
my
understanding
of
the
issue.
D
This
does
bring
about
a
similar
rfc.
We
had
from
eyes
a
long
a
while
ago,
I
think,
was
different
protocols
for
defining
different
registries.
A
A
A
Moving
on
to
rc
566
command,
specific
configuration,
which
I
have
not
been
able
to
update,
the
last
note
we
made
here
was
to
document
all
the
commands
with
subsequent
commands.
So
basically
doing
a
bit
of
an
audit
example.
Npm
install
might
run
npm
pack
for
get
dependencies,
and
we
want
to
know
this
and
have
this
mapped
out
as
part
of
this
rfc,
so
that
we
can
explain
to
folks.
A
I
think
reasonably
what
the
you
know
when
configuration
is
going
to
be
applied
to
what
command,
and
this
will
also,
I
think,
kind
of
allow
us
to
have
a
more
sophisticated
discussion
around
whether
or
not
we
want
cascading
configs
to
be
applied
in
those
cases.
A
My
personal
thought
and
opinion
is
no
that
essentially,
the
config
should
only
be
skipped
to
that
specific
command
and
if
you
happen
to
execute
another
command
when
running,
install
or
something
like
something
else
that
you
should
essentially
copy
over
the
config,
but
other
folks
might
have
differing
opinions
on
that,
and
I
know
that
we
do
share
today.
How
do
you
think
we
do
share
today?
The
the
config
object
between
those.
C
Well,
I
I
think
it
there
needs
to
be
a
like
audit,
in
other
words
like
a
differentiation
between
when
users
are
supposed
to
think
about
it
like
when
a
user
runs,
npm,
publish,
they're
supposed
to
be
aware,
or
they
are
allowed
to
be
aware
or
encouraged
to
be
aware
that
it
is
calling
npm
pack
right.
It's
not
quietly
doing
the
same
thing.
It's
actually
calling
npm
pack
and
so
pac-specific
config
should
of
course
apply
when
you
run
publish,
but
there
may
be,
especially
with
the
query
rsc.
C
There
may
be
a
bunch
of
things
that
are
like,
for
example,
doing
the
same
thing
as
npm
ls
or
something,
but
that
aren't
conceptually
calling
it
and
those
shouldn't
use
ls
specific
config,
and
so
I,
in
other
words,
I
think
that
it
we
need
to
be
very
deliberate
about
which
commands
conceptually
invoke,
which
other
commands,
and
only
for
those
should
the
config
be
like
passed
along
and
then
the
others.
That's
just
internal
implementation
details
and
it
would
be
relatively
easy.
A
A
If
not
we'll
move
on
to
the
rfc
564
dependency,
selective,
syntax
and
mpm
query
again,
I
haven't
had
time
to
update
this.
A
The
last
notes,
I
know
were
to,
I
think,
remove
blessed
attribute
names
from
the
top
level
and
nest
those
in
a
pseudo
selector,
and
this
I
think,
allows
us
to
not
have
cl
like
collisions
with
other
pseudo
with,
like
other
attributes
or
other
pseudo
classes.
A
So
I
know
that
that
was
one
of
the
things
that
I
brought
up.
That
needs
to
be
done
and
fixed
about
the
rfc
itself,
but
otherwise
I
think
it's
in
pretty
good
shape.
I
I
still
haven't
addressed.
Maybe
some
of
the
comments
that
jordan
and
I
see
we've
left
but
I'll-
try
to
get
the
to
those
by
next
week,
cool
any
other
comments,
or
did
anybody
have
any
feedback
on
free.
A
It's
definitely
something
we
want
to
get
to
soon.
It's
something
I
would
love
to
see
ship
with
v9
as
like
a
reason
to
update
and
check
that
out.
A
It's
kind
of
like
a
big
feature
that
was
landing
in
a
major,
so
I'm
gonna
do
my
best
here
to
to
clean
that
one
up
specifically
command's
specific
configuration
is
as
well
I'm
just
I
just
don't
know
if
it's
gonna
have
more
dragons
than
on
that
new
command,
so
cool
moving
on
to
five
five,
nine
expanding
behavior
of
before
to
support
date,
adjustment
and
such
essentially
relevant
relative
dates.
I
think
we
can
remove
this
off
the
agenda.
I
think
we're
everybody's
pretty
much
plus
one
so
long
as
it.
A
C
Yeah
I
mean
it's,
I
brought
up
new
date
syntax,
but
I
saw
I've
basically
said:
if
there's
any
gonna
be
any
changes
we
should
be
looking
at
temporal
and
temporal
durations
do
have
a
like
relative
date.
Syntax,
that's
different
from
what
the
unix
date
tool
is,
and
so
the
like
the
motivation
of
saying
well
on
windows.
C
You
can't
run
the
date
command,
also
is
sort
of
an
argument
not
to
use
the
dsl
from
that
command,
because
windows
users
won't
have
any
familiarity
with
it,
and
but
they
will
be
javascript
users
most
likely
and
they
will
eventually
be
familiar
with
the
temporal
syntax.
So,
like
the
concept
sounds
great
to
me,
but
the
like
the
exact
dsl
in
use,
I
think,
should
be
temporal
or
like
if
we're
gonna
do
it.
C
Oh,
I
mean
I'm
talking
about,
there's
like
these,
so
I
don't
even
know
them
off
the
top
my
head,
because
temporals
not
even
stage
four
yet
but
there's
there's
this
syntax,
like
that's
a
standard
thing.
That's
like
3r,
for
I
don't
know,
there's
like
it's
like
numbers
and
letters
and
it's
a
way
to
describe
a
relative
time
period
and
eventually
that
that
syntax,
I
or
you
know
that's
a
dsl.
C
I
expect
javascript
users
to
be
somewhat
familiar
with
and
it
seems
like
it's
probably,
I
believe
it's
based
on
a
more
reliable
standard
than
like
what
a
random
unix
tool
has
chosen
to
support
20
years
ago.
A
Is
using
like
objects
which
don't
map
quite
well
to
like
a
value?
And
so.
C
It's
right
here,
let
me
paste
the
link,
so
that
page
describes
the
iso
8601
standard
notation.
For
example,
p1
y1d
is
one
year
in
one
day.
C
And
it's
yeah,
I
mean
I'm,
not
I'm
not
saying
it's
intuitive,
but
it
is
a
stan,
a
cross-platform
standard
and
it
is
what
temporal
will
be
using
and
you
know-
and
it
is
also
not
uniquely
localized
to
english,
so
it
sort
of
avoids
being
anglo-centric
in
the
way
that
the
date
command
would
be.
C
And
the
p
the
p
could
be
optional,
like
npm
could
insert
that
but
like
by
by
basically
following
that
standard,
then
you've,
you
know
you've
delegated
all
the
design
decisions
elsewhere.
You've
avoided
internationalization
and
localization
concerns
and
you've
been
equally
inclusive
to
windows,
users
and
non-windows
users.
C
C
It's
still
finding
normative
changes
like
observable
changes,
so
it's
not
like
nobody's
gonna
ship
it
unflagged
until
that
settles
down,
but
my
hope
would
be
within
the
next
year
or
so
that
browsers
will
start
unflagging
it
and-
and
you
know
also
when
it
settles
down
polyfills
will
reliable
polyfills
will
become
available
and
endorsed
and
libraries
will
start
to
depend
on
them.
So,
like
the
the
landscape,
right
now
for
temporal
is,
is
pretty
shaky
on.
C
You
know
approachability,
but
that
is
going
to
change
as
soon
as
browsers
start
shipping
it
because,
like
moment
is
you
know,
people
are
trying.
You
know
the
moment.
Maintainers
have
told
people
to
stay
away
from
it
and
the
other
libraries
are
like
not
as
used
as
moment,
even
though
they
have
similar
functionality
and
like
the
existence
of
temporal
will
make
my
guesses.
It
will
make
most
of
them
obsolete,
and
so
everyone
will
just
use
that
so,
like.
A
Cool
owen.
B
C
C
A
Yeah
so
yeah
we
would
just
have
to
do
like
new
date
and
then
from
and
then
use
this
like
duration
value.
Just
like
these,
these
yeah
right.
C
B
C
It'll
probably
be
a
node
behind
a
v8
flag
like
it
remember
for
all.
I
know
it's
already
there,
but
it's
just
you
know:
it'll
be
a
node
unflagged
shortly
after
it's
in
chrome,
unflagged
and
then
a
few
years
after
that,
npm
will
be
able
to
rely
on
it
always
being
present
and
in
the
intervening
time
you
know
I
happen
to
know
somebody
who
makes
polyfills,
who
will
be
providing
a
polyfill
npm,
could
choose
to
use
and
then
drop
it
that
future
time.
A
A
Okay,
cool-
I
I
think
you
can
drop
this
from
the
agenda.
Then
you
can
just
back
backlog
a
ticket
for
it.
A
A
Okay,
moving
on
quickly
we've
got
about
15
minutes
left.
I
apologize
for
keeping
things
off
so
late.
Moving
into
rc
550,
improving
signature
verification.
I
know
you've
been
working
closely
with
philip,
I'm
not
sure
if
you
have
the
update
on
no.
E
Update
yeah
we're
just
we're
working
on
it.
It's
kind
of
in
the
early
phases
phases
we
might,
you
might
have
seen
piccochi
had
a
new
release
where
the
signature
is
in
the
manifest
if
the
integrity
checked.
So
at
least
we
can
have
that
as
a
signal
that
it's
ready
to
sign.
We
still
need
to
work
through
where
the
keys
I
mean
it's
in
the
rfc,
but
like
how
we
get
that
into
their
config.
What
does
it
mean
to
be
there?
When?
Is
it
used
just
some
of
the
subtleties
of
it?
E
It
shouldn't
take
too
much
longer,
but
just
questions
that
need
to
be
answered.
Initially,
this
is
going
to
be
a
separate
command.
Hopefully
it
can
be
baked
into
install
with
signaling
like.
If
I
provide
you
the
keys,
then
do
the
signature,
verification
kind
of
a
thing.
C
It
yeah
I
mean
if
the
if
the
default
flip
would
have
to
wait
for
v10,
then
you're
right,
there's
no
rush
to
implement
that,
but
it
seems
plausible
to
land
the
feet,
the
functionality
in
v8
and
then
be
able
to
flip
the
default
in
v9.
If
it
appears
like
there's
right
and
then
that
gives
people
an
escape
hatch,
if
it's
slow
for
some
people
or
if
it's
like
not
exactly
what
they
want
right
like
because,
because
within
v9
you
could
always
flip
the
default
back.
A
C
C
What
I
would
assume
is
that
if
you
have
no
audit
they're
all
off,
but
we
would
be
adding
new
subflags
like
no
audit
signatures,
no
audit,
you
know
vulnerabilities
or
whatever
you
know,
whatever
terminology
we
use
there
and
then
like
we
can
get
all
those
flags
in
and
then
the
the
defaults
can
be
whatever
we
need
them
to
be,
and
then
people
can
override
them
as
they
need
it,
and
you
know
like
eventually
we're
gonna
need
that
set
of
config
anyway,
right
and
and
maybe
maybe
it
would
be
simpler,
with
command
specific
config,
because
then
it
doesn't
need
to
be
added
except
under
audit,
so
like
maybe
that
maybe
the
priority
order
should
be
command
specific
config
before
a
lot
of
other
things.
C
It
seems
like
a
an
opportunity
miss
to
prioritize
v9
before
getting
in
as
many
non-breaking
things
as
possible,
because
it
is
in
npm's
best
interest
to
make
the
experience
of
migrating
across
majors
for
users
as
easy
as
possible
and
the
more
things
that
are
in
v8
and
can
be
toggled
to
pre
and
can
be
put
in
pmrc
to
protect
against
v9
breaking
changes.
The
easier
it
will
be
for
people
to
migrate
to
v9
and
keep
the
same
behavior
and
the
the
earlier
npm
will
be
able
to
get
feedback
about
functionality
and
like,
in
general,
the.
A
Idea
yeah,
the
idea
would
actually
be-
and
this
hasn't
been
widely
communicated.
But
we
would
start
to
cut
release
candidates
for
b9
here
this
summer
and
essentially
have
a
few
months
of
cutting
release
candidates,
while
not
essentially
cutting
v8
releases.
A
Unless
there's
like
a
major
security
issue,
and
that
then
allows
us
to
make
breaking
changes,
implement
new
features
and
sort
of
do
a
bunch
of
the
work
that
we
need
to
do
to
flip
a
bunch
of
bits
for
a
different
config,
which
is
why,
like
trying
to
land
like
extra
config
or
even
this
feature
and
v8
is
like.
But.
C
C
A
C
C
But
but
I'm
saying
that
what
this
will
end
up
in
is
that
there
will
be
a
bunch
of
new
features
that
have
never
landed
in
v8
that
have
landed
within
v9
during
candidates.
That
users
will
not
have
been
able
to
get
feedback
on,
but
they
will
not
be
able
to
use
and
lock
in
their
config
within
v8,
which
will
make
the
upgrade
to
the
final
v9
harder.
I'm
saying
that
that
I
that
I'm
suggesting
that
that
approach
to
doing
releases
without
like
it
is
not
actually
a
good
thing.
Unless.
C
C
Release
lines:
that's
fine!
I'm
not
saying
you
must
I'm
saying
that,
because
you
can't
v9
should
like
probably
wait
until
all
the
new
features
are
done
being
added
such
that
the
change
from
v8
to
v9
is
like
dropping
node
versions
and
flipping
defaults,
and
that
makes
it
a
much
simpler
release
process
for
you.
It
still
is
only
one
line
at
a
time
to
maintain
and
it's
much
much
easier
for
the
users
to
upgrade,
which
I
would
hope
are,
is
the
most
important
consideration.
A
I
agree,
but
the
yeah
it's
not
part
of
this
rpc.
We
can
have
that
discussion
somewhere
else
yeah.
This
is
essentially
a
net
new
command.
This
can
land
in
va
the
ins
whether
or
not
it's
a
part
of
install,
I
would
fight
for
not
including
v8
and
whether
there's
a
config
to
turn
it
on
for
install.
I
would
fight
to
not
include
nba,
is
what
I
I'm
basically
saying
with
all
that,
whether
atlanta's
new
signature
in
time.
A
This
is
being
contributed
by
you
know
a
team
within
github
their
time
to
do
this,
whether
or
not
it
lands
within
time.
The
time
frame
that
we
are
accepting
features
for
v8
is
questionable,
so
I
can't
I
can't
speak
to
that
in
terms
of
whether
this
is
like
complete
as
an
rfc.
E
A
Would
I
would
love
to
say
that
it
is
and
a
separate
rfc
or
our
consideration
for
whether
or
not
we
have
a
flag
for
doing
this
check
in
an
install
can
be
made?
I
think
that's
kind
of
like
where
I'd
like
to
draw
the
line,
so
I'm
not
sure
if
gary,
if
based
on
your
work
with
philip,
if
there's
anything
in
the
rc,
that
is
wrong
based
on
like
the
initial
work
that
you've
done
in
picacho
or
it
needs
to
be
changed.
But
maybe
we
can
just
ratify
this
like
this
command
by
itself.
A
Because
it
doesn't
speak
to
anything
about
install
yet
right,
yeah,
okay,
okay,
let's
backlog
that
as
a
to
do
to
ratify
it
by
next
week,
and
that
gives
yeah
hopefully
also
is
a
big
plus
or
a
big
thumbs
up
to
develop
in
his
work.
We
only
have
about
four
or
five
minutes
left.
I
want
to
get
to
another
item
here.
A
C
Yeah,
I
just
I
think
this
will
be
harmful.
I
think
that
that
if
we
get
the
ability
to
if
we
create
the
ability
and
tacitly
encourage
people
to
dynamically,
wait
a
little
bit
longer
before
getting
packages,
the
net
effect
will
be
that
security
problems
take
longer
to
be
discovered
and
then
and
we
will
be
back
to
having
no
gain,
and
so
in
other
words
I
it's
it's
not
that
the
functionality
being
requested
is
a
problem.
It's
that
the
motivation.
I
think
this
is
a
poor
solution
to
that
problem.
C
C
A
similar
risk
with
the
relative,
because
with
when
you,
if
you
can
encode
the
relative
one
in
your
config,
then
you
gain
the
ability
to
to
do
this.
It's
I
think,
but
I
think
in
both
in
the
in
the
relative
one.
The
motivation
is,
I'm
debugging
why
this
worked
yesterday,
and
so
it
like,
it
solves
the
motivation.
In
this
case,
the
motivation
is
like
we
think
about
this
later
yeah,
it's
like
thinking.
It's
like.
C
We
think
that
if
we
wait
longer,
somebody
else
will
suffer
the
vulnerability
and
we'll
find
out
about
it
in
time,
and
I
I
don't
buy
that
motivation
and
I
think
that
trying
to
ship
anything
that
solves
that
that
is
intended
to
solve
that
motivation,
I
think,
would
be
harmful
like
and
also
that,
like
anyone
with
this
concern
has
an
internal
registry
and
they
can
configure
their
internal
registry
to
like
hide
packages
that
are
less
than
a
week
old
or
whatever,
like
with
no
work
on
the
behalf
of
the
npm
team
so
like.
C
If
and
and
all
of
these
folks
like
they
can
ask,
you
know
they
can
make
a
pr
to
verdaccio
or
they
can
ask
artifactory
or
whoever
they're
using
to
implement
something
like
this?
If
that's
a
feature
that
is
that
desired
but
like
which
I
just
don't
see
anyone
who's
the
security
conscious,
isn't
solely
depending
on
the
public
registry
so
like.
Why
does
the
public
registry
need
to
support
this.
A
They
also
go
beyond,
I
think,
just
the
setting
of
per
package
rel
like
relative
dates.
A
F
Sure
I
just
mean
if,
if
you're
talking
about
installing
specific
packages
or
a
specific
set
of
packages
before
a
given
date,
then
there's
no
reason.
You
couldn't
just
know
what
those
versions
are
and
use
an
override
to
not
allow
something
newer
than
those
to
be
installed
like
I
don't.
I
feel,
like
this
use
case,
is
already
covered
in
kind
of
a
roundabout
way
right.
A
Right
because,
if
you
know
when
to
lock
in
I,
I
think
the
interesting
feature
is
doing
it
per
package
setting
like
that,
essentially
that
it's
almost
like
a
december
range
right
or
spec
like
wanted
information
that
we
would
pass
to
the
co-chair
of
pic
manifest-
I
guess,
but
also
they've
added
here,
which
I
think
is
kind
of
completely
expands.
This
is
they've
added,
like
policies
essentially
so
like
error
info
worn
to
this
this.
This
config,
which
I
think
is,
is
yeah.
A
And
yeah
yeah
yeah,
you
said
these
policies
should
be
set
by
the
registry
totally.
I
think
this
is
something
we
can
discuss
again.
I
don't
know
necessarily
like
how
and
or
why
we
want
to
have
before
specific
pulses
for
individual
packages,
but
I
think
that's
the
proposal.
That
is,
I
guess,
interesting.
At
least
for
me,
the
policies
are
something
that's
yeah.
I
don't
think
something
we
would
want
to
pull
in
and
then
the
reason
for
why
you'd
want
to
use
this,
maybe
there's
already
like
a
workaround.
A
We
can
provide
this
user
as
the
current
notes
feedback.
Maybe
you
can
tell
them
to
use
overheads
if
they're
they're
super
security
conscious
and
want
to
be
locking
in
and
or
use,
you
know
a
lock
file
and
just
don't
ever
update
your
dependencies
anyways.
I
apologize
we're
a
couple
minutes
over
already
and
essentially
that
time.
A
If
we
didn't
get
to
an
item
that
you're
hoping
to
talk
about,
you
can
catch
us
next
week
same
time
same
place
and
appreciate
everybody
jumping
on
today,
including
furry
friends,.