►
From YouTube: Open RFC Meeting - Wednesday, April 27th 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
Awesome
and
we're
live
on
youtube.
Thank
you.
Everyone
for
joining
another
npm,
open
rfc
call.
Today's
date
is
wednesday
april
27th,
2022
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
578
on
the
mpmrcs
repo
I've
shared
the
meeting
note
stock
in
the
chat
so
feel
free
to
add
yourselves
to
attendees
as
usual.
This
call
and
all
comms
associated
with
the
npm,
rcs
and
org
are
covered
under
code
of
contacts.
We
ask
folks
to
please
be
kind
as
each
other
speaking.
A
Please
raise
your
hand
if
you
have
a
comment
and
we'll
call
on
you
and
also
want
to
quickly
shout
out
and
give
a
couple
announcements:
npm
v9
we're
going
to
start
to
potentially
cut
release
candidates
in
the
coming
weeks
and
months,
and
so
there's
a
few
breaking
changes
that
we've
got
queued
up
there,
mostly
config,
related
that
we
want
to
put
on
folks
radars,
and
so
we've
got
a
tracking
issue
there
for
for
folks
to
check
out
that
which
I've
linked
in
the
meeting
notes.
A
Docs
also
want
to
mention
the
js
worlds
conference
is
coming
up,
quick
that
will
be
happening
in
june.
I
know
myself
and
roy
from
our
team
are
definitely
going
and
we're
trying
to
schedule
and
coordinating
more
folks
from
our
team
also
to
go,
and
that's
on
me
to
to
try
to
schedule
so
time
on.
A
A
Fpm
has
been
able
to
participate
in
the
club
summit,
which
usually
happens
just
after
the
conference,
and
we've
been
able
to
run
a
session
where
we
collaborate
and
contribute,
or
collaborate
with
contributors,
be
able
to
sort
of
surface
new
ideas
for
the
cli,
and
it's
always
been
a
nice
nice
working
group,
essentially
in
person
working
group,
so
hopefully
we'll
be
able
to
do
that
again
and
have
it
on
our
raiders
to
ideally
contribute
to
the
collab
summit.
A
I
know
a
bunch
of
folks
on
our
team
contribute
to
different
working
groups
as
well
to
the
node
project.
Specifically,
so
yeah
did
any
other
folks
have
announcements.
They
want
to
share.
A
If
not,
we
can
just
jump
right
into
the
agenda
and
luke
I
saw
you
just
joined
so
copy
and
paste
the
meeting
notes
again.
The
first
item
that
we
had
was
number
rfc
number
572.
tierney.
I
think
this
is
your
issue
essentially
bringing
up
the
idea
of
removing
the
access
public
or
the
access
flag
with
the
value
public
for
initially
published
scoped
modules.
B
Yeah
this
feels
like
an
artifact
that
does
not
match
how
the
npm
cell
kind
of
works
now,
and
particularly
this,
is
especially
annoying
when
publishing
scope
packages
from
workspaces,
which
generally,
I
think,
is
probably
how
people
are
going
to
end
up
using
workspaces
and
so
like
people,
probably
weren't
publishing
scope
packages
as
much
or
at
least
the
barrier
was
a
bit
higher
and
I
think
with
workspaces,
that
barrier
will
become
lower
and
workspaces
and
the
intersection
of,
like
that
kind
of
being
general
advice
that
people
are
giving
for
how
to
do
published
securely.
B
So
I
think
you
know
this.
This
makes
sense
as
a
an
approach
to
just
drop
this,
because
it's
not
really
necessary,
or
at
least
I
I
don't
particularly
think
it's
necessary
yeah,
and
it's
also
not.
It
is
mutable,
which
is
nice.
So
if
someone
does
accidentally
publish
something
public,
they
can
make
it
private
yeah.
I
I
think
this
should
be
their
fault.
A
I
don't
know
who
is
first
car
or
jordan,
which
one
do
you
want
to
go
first,
you
can
go
ahead.
Sure
you're,
both
too
nice.
C
I
don't
see
any
rationale
for
scoped
modules
being
treated
differently
than
unscoped
modules
here,
so
it
makes
sense
to
make
them
match.
That
said,
it
is
a
huge
mistake
that
npm
had
npm
init,
for
example,
has
always
defaulted
to
a
package.
Json,
that's
publishable.
It
should
start
with
private,
true
and
similar,
and
similarly,
because
of
that
mistake,
npm
publish
on
an
unscoped
package
also
can
accidentally
publish
something
you
don't
want
published.
C
I
don't
have
any
personal
objection
to
what
toonie's
suggesting
here,
but
it
might
be
better
to
make
first
make
npm
in
it
default
to
private,
true
and
then
make
all
npm
publishes
default
to
publish,
including
for
scoped,
because
then
we've
made
sure
that
the
that
everything's,
the
same
and
there's
no
weird
boundary
between
scoped
and
unscoped,
but
also
the
default,
is
the
safe
thing
which
is
if
you're,
not
thinking
about
it.
You'll
make
an
unpublishable
package
and
then
once
you've
removed
private,
true,
which
you're
always
going
to
do.
C
B
Yeah,
I
just
to
quickly
respond
to
that.
I
think
I
think
that's
fine.
I
think
I
generally
agree.
I
I
don't
have
an
issue
with
that.
I
don't
know
if
I
agree
with
it,
I
don't
have
an
issue
with
that.
I
I
don't
I'm
I'm
kind
of
unopinionated
on
that.
I
I
do
appreciate
how
low
a
barrier
it
is
and
how
few
steps
it
is
to
publish
something,
I
think
that's
the
strength
of
the
ecosystem
for
new
new
people,
especially,
but
I
I
can
also
see
how
that
can
be
problematic.
B
If
I
actually
like
don't
have
registry
configured
and
create
something
new
internally
and
then
oops,
I
publish
my
internal
package
publicly.
I
think
that
this
can
this
change
could
land
without
or
like
and
then
have
that
change
as
a
follow
a
fast
follow.
If
you,
if
you
wanted
to
work
on
that,
jordan.
C
Sorry,
the
private
thing
yeah.
I
can
write
yeah
rfc
for
that
sure.
D
Well,
just
to
give
a
little
of
why
this
fence
post
is
in
the
road
explanation
when
suko
packages
were
introduced.
This
was
before
github.
This
was
npm
trying
to
solve
private
packages,
and
we
couldn't
make
unscope
package
is
private,
but
scope
packages
can
be,
and
so
the
idea
was
scope.
Packages
are
where
you
go
to
make
packages
private.
D
I
don't
think
that's
the
case
anymore,
I'm
in
agreement
with
this,
but
I
do
think
it's
important
to
understand
why
it
was
there
so
that
when
we
were
removing
it,
we
understand
what
changed
and
what
changes.
If
you
want
to
make
private
packages,
you
use
the
github
registry
now,
because
it's
access
control
is
leaps
and
bounds
beyond
what
the
npm
registry
can
do
so
yeah.
I
think
it's
it's
because
of
github
registry.
B
I
I
would
definitely
yeah
that
that
totally
makes
sense-
and
I
would
I
perhaps
outside
of
a
meeting-
wouldn't
frame
it
as
github
registry,
because
there's
a
ton
of
registry
products
like
this
and
they're
all
relatively
advanced,
or
at
least
I
personally
wouldn't
do
that,
but
yeah.
I
think
that
I,
I
think
it
private
private
registries
are
the
correct
avenue
rather,
and
I
mean
that
also
made
sense
complete,
like
I,
my
guess
and
like
this
is
a
completely
uninformed
guess
I've
never
talked
to
anyone
about
this.
B
I
have
no
clue
it
was
that
this
was
part
of
an
upsell
and
that
totally
makes
sense
and
that's
valid,
and
I
I
I
yeah
I
I
think
it
is
an
artifact
that
does
not
need
to
exist
anymore,
of
how
kind
of
npm
historically
approached
private
packages
so
go
ahead.
Phone.
E
Kind
of
a
side
thought
I
think
this
change
makes
sense.
Something
we've
been
thinking
of
on
improving
security
on
npm
is
adding
support
for
some
kind
of
build
or
also
signatures,
and
pushing
these
to
some
transparency.
Ledger,
for
example,
the
sixth
store
ledger,
which
is
off
a
third-party
database.
A
I
was
just
gonna
say
there
is
a
there,
isn't
unpublished,
policy,
at
least
for
the
the
registry
today,
which
gives
certain
parameters
for
you
to
quickly
unpublish
a
package.
Potentially
that
has
it's
extremely
limited
in
scope
in
terms
of
the
conditions
which
you
apply
to
unpublish,
but
there
is
the
ability
to
essentially
you
know
quickly
back
out.
If
there
is
some
some
you
know,
I
would
imagine
when
people
are
publishing
initially
without
with
this
turned
off,
then
it
would
be.
A
You
know
if
a
mistake
is
made,
you
can
quickly
pull
back
from
pull
back
from
that.
So
I'm
wondering
philip
also-
and
this
is
probably
a
side
discussion
but
like
hopefully
that
means
an
unpublished.
Action
also
would
remove
any
kind
of
information
from
whatever
their
likes
secondary.
Third
party
ledgers
are
gonna,
hold
certain
information.
I
guess.
A
B
A
B
I
would
like
yeah
I
was
going
to
ask:
can
this
be
dropped
in
v9
just
to
get
it
kind
of
out
the
door
as
a
because
I
think
I
do
think
that
is
a
major
change.
I
think
that
people
will
have
scripts
that
include
this,
so
I
would
prefer
to
get
it
out
for
v9
and
the.
C
Other
thing,
I
was
also
telling
you
the
other
thing
I
just
commented
on
my
my
newly
filed
one
is:
we
could
make
it
a
whether
the
initial
package
json
should
be
private
or
public.
C
We
could
make
that
be
a
prompt
question,
which
then
means
it's
also
settable
by
npm,
config,
and
so,
given
that
we
could
actually
add
that
in
npm,
8
defaulting
to
public
and
change
the
default
in
npm
9,
and
that
way
folks
who
didn't
want
you
know
folks
would
be
able
to
set
the
npm
config
value
and
have
it
work
in
npm
8,
and
they
would
protect
themselves
from
the
default
change
going
to
v9
in
either
direction.
B
C
Yeah
and
we
could
do
the
same
for
whether
scoped
packages
default
to
being
public
initially,
that
could
be
an
npm
config
value
as
well,
with
the
default
changed
in
general.
I
love
that
technique
of
shipping
all
new
functionality
in
a
minor
and
then
have
the
breaking
change,
just
be
flipping
the
default,
because
then
people
can
insulate
themselves
from
the
breaking
change.
Pretty
trivially.
A
Quickly,
I
was
trying
to
see
if
we
had
a
config
already
for
this.
I
was
just
trying
to
quickly
go
through
the
init
config.
A
B
Don't
so
I
I
assume
there
probably
isn't,
because
you
can
in
it
with
a
scope
and
then
that
defaults
to
private,
and
so
that
was
probably
the
kind
of
stop
gap
feel
for
that.
A
B
B
Any
other
comments
feedbacks
before
we
move
on
just
to
to
guard
this
point
also
just
remove
I'm
honestly.
I
don't
know
if
that
command
isn't
even
needed
anymore,
that
flag,
but
remove
the
necessity
for
the
flag
too,
for
access.
F
D
You
still
need
to
know
the
flag.
Absolutely
is
a
good
addition,
those
two
things
being
things
we
put
out
there
during
a
knit,
I
think,
are
security
wins.
So
you
know
in
my
package,
json
I've
turned
that
on
or
off
I
don't
have
to
worry
about
command
line
flags
or
anything
very
explicit,
always
explicit.
B
Can
you
can
you
access
public,
a
private
or
private,
equals
true
module
or
private
golden
true
module?
Can
you
publish
something
that's
marked
as
private
in
your
package,
json.
C
I've
always
thought
access
is
different
from
private,
true
and
that
private,
true,
just
publish,
will
bail
out
immediately.
When
you
don't
have
private.
True,
then
npm
publish
works
and
then,
if
only
if
the
package
is
scoped
access
kicks
in
and
when
you
specify
it
explicitly,
it
changes
whether
it's
private
or
public,
and
I
think
you
can
make
a
private
package
public
and
vice
versa.
Yes,.
B
B
A
So
roy
you
just
asked
to
enumerate
the
changes
or
that
we'd
like
to
make.
So
it
sounds
like
one
we're
going
to
make
init
default
to
private.
True
in
npm
v9
we're
going
to
remove
or
well,
and
then
I
think
that's
that's
it
make
also
the
config
init
config
to
be
so
in
its.
B
B
B
If
you
want
this,
actually
that
actually
won't
break
anyone
who
that
actually
might
not
be
a
breaking
change
to
drop
this,
because
if
you're
access,
publish
or
public
it'll
still
work,
but
you
just
drop
drop
that
code
and
then
the
the
private
is
separate,
because
private
is
different
than
access,
as
we
just
talked
about
because
accesses
for
the
scope
packages
only
yeah,
so
it's
it's,
it
would
just
be
like
it
is
private
or
something
or
no
just
the
private
field
in
in
it.
Right,
like
that's,.
G
B
G
A
B
B
So
we
we
don't
remove
access,
control,
that
flag
state,
so
the
requirement
on
initial
publish
stays.
But
if
the
feature
state
feature
stays
available
because
it's
still
feature
the
register.
A
B
Which
then
still
doesn't
change
the
dx
and
actually
might
allow
that
to
be
a
minor?
Because
if
your
pass
x
is
public,
it'll
still
get
passed.
And
if
you
don't
it
like
yeah.
A
Cool,
are
we
good
mood
on?
Well,
you
got
all
the
notes
done
appreciate
you
taking
notes
again.
I've
also
added
a
couple
items
to
the
actual
tracking
ticket
there
for
v9
moving
on
to
571
the
rfc
again
tuning
making
the
update,
useful
npm
update
useful
for
modern
package
management.
B
Yeah
I
just
consistently
have
for
years.
I've
been
disappointed
by
npm,
update
and
always
have
to
like
re-remember
the
dance
between
outdated
and
update
and
how
and
then
I
just
give
up
and
delete
every
delete,
my
known
modules
and
then
reinstall
and
it's
all
fine
so
that
that
has
been
well.
No,
that's
not
true,
because
sometimes
there's
a
version
that,
like
it
doesn't
install,
won't
bump
the
versions,
and
so
I
have
to
like
do
weird
stuff
and
it's
annoying
yeah.
B
I
I
just
want
npm
update
to
allow
me
to
kind
of
go
through
and
actually
have
a
meaningful
update
path
for
all
of
my
packages.
So
I
can
run
that
in
action
daily
and
tell
me:
okay,
cool
here's,
the
changes
you
need
and
have
that
automatically
create
a
pr
or
not
do
that
and
I'm
good,
and
then
I
can
turn
off
dependable
or
well.
I
don't
have
to
turn
off
dependable.
I
I
can
do
work
before
depending
buck
gets
to
it,
so
dependable
doesn't
have
to
do
work.
D
So
update
stays
within
the
semver
ranges
of
anything
in
your
tree
right
and
that's,
you
know
its
contract.
What
you're
looking
for
is
similar
to
there's
another
project
that
I
helped
them
with
batch
requests
to
the
registry,
something
that
will
bump
your
dependencies
right.
Yeah,
npm
check,
updates,
yeah.
You
want
something
that
that's
an
update
that
works
on
your
package.json,
that
we'll
look
for
latest.
B
Yes,
yeah.
I
basically
want
to
all
of
the
stuff
that
dependable
vomits
into
my
project
in
prs.
I
want
to
be
able
to
do
that
from
the
cli
and
be
I
want
to
be
able
to
manage
that
from
like.
I
want
to
be
able
to
do
those
updates
and
have
that
be
incremental
as
part
of
my
process
and
not
have
to
rely
on
a
automated
pr,
workflow
or
you
know,
external
tooling.
I
want
that
to
be
able
to
be
in
the
package
manager
and
I
think
that's
you
know.
D
B
I'm
not
I'm
not
sure
about
how,
because
I
don't
think
install
actually
will
install,
will
still
respect
december
ranges
like
if
there's
a
major
of
low
dash
right
install
is
not
going
to
tell
me
that
you,
if
you
install
the
mesh
at
latest
it'll,
install
load
right
right.
Yes,
okay,
yeah,
so
I
I
want
to
be
able
yeah,
I'm
talking
about
normal
npm,
install
yeah,
so
you're
talking
about
updating
to
the
latest
version.
I
basically
want
npm
update
or
whatever
command.
I
don't
care
what
the
command
is.
B
I
just
want
a
command
to
tell
me:
hey
here's,
here's
your
packages
and
we've
updated
them
like.
I
want
to
be
able
to
do
that
at
once,
outdated
kind
of
does
this.
I
think
I
think
it's
to
some
extent
it
does.
It
will
tell
you
like
what
the
latest
is
and
what
the
current
one
is.
B
You
have
and
if
that's
a
difference
or
not-
and
I
think
if
it
follows
your
silver
range,
it's
like
if
you'll
get
updated
when
you
run
a
bmp,
I
I
don't
want
to
have
to
like
run
npm,
outdated
and
then
npm
install
at
the
version
and,
like
maybe
I
might
be
screwing
that
up
somehow
and
I
don't
know
how
and
I
don't
care
so
like
that's
the
the
I
want
to
avoid
having
to
like
have
that
institutional
knowledge
of
like
here's,
how
this
stuff
works,
and
I
just
want
mpm
to
kind
of
resolve
it.
C
That
does
what
we
want
are
of
extreme
minority.
The
most
people
actually
need
to
see
something
like
the
npm,
outdated
output
and
as
tyranny's
saying,
then
they
would
have
to
manually
translate
that
to
a
command
and
an
interactive
update
would
give
them
the
ability
to
do
that
without
having
to
make
those
translations
in
their
head.
A
Again,
we
would
have
to
include
the
ability
to
also
go
beyond
the
current,
like
update
functionality,
to
update
outside
of
the
range
right.
So
that's
the
that's
the
other
key
right
so
that
that
independently
of
an
interactive
mode
probably
has
would
have
to
be
added
to
update
rights,
which
is
why
I
know
we
floated
a
couple
and
chat
here
float
a
couple
other
names
for
a
command
just
because
it
you
know,
potentially
there's
no
sub
commands
that
we're
going
to
be
able
to
add
to
update
the
way
that
it's
designed
right
now.
Right.
C
C
Do
you
like,
especially
if
they're,
trying,
if
they're
just
typing
npm,
update
dash,
I
with
no
arguments
like
that's
a
little
different
because
they're
that's
just
their
depth
tree
you're
kind
of
just
showing
them
their
direct
depths?
And
that
being
like?
Do
you
know
here's
all
the
in-range
updates?
Do
you
also
want
to
do
you
know
here's
the
ones
that
have
out
of
range
updates?
You
want
to
do
those
two
but
like
if
I
type
npm.
C
A
Philip,
I
see
your
hands
been
up
for
a
while.
Did
you
want
to
chairman.
E
Yeah
I
worked
on
dependable
for
almost
three
years,
so
I
can
talk
about
this
for
hours.
If
anyone
actually
wants
to.
E
E
What
dependable
does
in
your
package
today.
So
so
you
can
tell
depending
what
go
and
update
every
version
december
range
to
the
latest
available
and
it
will
keep
the
same
symbol
syntax,
for
example,
and
that
will
then
also
update
the
log
file
or
you
can
keep
it
prevent
it
from
changing
the
package
json,
which
essentially
is
just
a
log
file
update
and
there's
a
bunch
of
strategies
we
ended
up
with
which
are
like.
You
can
also
tell
it
to
widen
the
range.
E
So
you
won't
necessarily
bump
the
major
version,
but
it
will
like
make
it
more
wide,
which
is
usually
what
you
want
for
libraries,
so
that
there's
probably
a
bunch
of
things
to
consider
there
for
apps
versus
libraries.
You
usually
have
a
very
different
versioning
strategy.
B
B
This
tooling
should
fundamentally
allow
other
tools
to
build
on
top
of
it,
because
I
think
that
automation,
stuff
is
very
important,
and
I
I
think
the
underlying
tooling
needs
to
be
able
to
support
that
yeah
and
to
to
just
address
my
headsets
like
dying
to
address
jordan's
point.
I
I
think
the
the
interactive
stuff
I
I
really
agree
that
that
should
be
a
thing
and
I
from
what
I've
you
know
talked
with
with
other
people.
I
think
everyone
generally
agrees
that
that
should
be
a
thing.
B
B
Now
that
we
have
this
done,
let's
get
into
interactive,
I
think,
is
probably
the
the
best
path
forward
in
just
terms
of
figuring
out
what
we're
actually
doing
and
then
then
going
down
the
interactive
path
as
well,
because
I
don't
think
outside
of
in
it
there's
not
a
ton
of
interactivity,
and
I
know
I
know
I
think
I've
seen
you
know
mentions
here
and
there
of
potentially
changing
interactivity,
dx
and
so
letting
that
mature,
if
possible,
would
be
ideal.
So
we
don't
have
to
redo
it
twice.
B
F
Yeah,
maybe
I
can
just
make
note
on
the
interactivity,
because
yeah
it's
definitely
something
I
been
pushing
like
against,
because
we
have
so
much
stuff
to
figure
out
yet,
but
when
we
do
push
forward,
I
really
wanna.
I
really
wanna
like
a
holistic
push
like
to
have
some
an
end.
F
Experience
similar
to
like
the
github
cli,
which
I
think
is
like
beautifully
put
together
like
interactive,
is
really
consistent
across
all
the
different
commands
and
like
everywhere
that
can
benefit
from
interior
activity
like
that,
then
it
can
be
added
but
yeah
to
me.
I
think
it
just
reports.
Would
you
just
say
like,
let's
start
with
focusing
on
like
just
improving
the
base,
the
base
update
functionality
and
then
once
we
the
day
we
get
to
talk
about
interactivity.
Let's
try
to
to
have
a
holistic
way
of
thinking
about
it.
A
Yeah
I
feel
like
we
did,
have
an
rfc
for
interactive
flag
at
one
point,
or
we
had
the
discussion.
Maybe
a
year
or
two
years
ago
and
similar
you
know,
thought
was
had
like,
let's
maybe
hold
off
on
this
until
we
can
do
it
across
multiple
commands,
at
least
to
try
to
figure
out
what
that
looks
like
I
do
yeah.
A
Potentially
it's
not
great,
but
I
think
at
least
we
could
potentially
also,
at
the
same
time
indeed
add
something
like
a
range
flag
or
an
out
of
range,
some
flag
to
npm
update
to
allow
it
to
capture
like
the
essentially
latest
updates
right,
like,
which
is
what
a
lot
of
people
have
been
asking
for
us
for
a
long
long
time.
B
Yeah,
I
don't
really
understand
how
the
range
would
apply
to
that
because,
like
you're
running
npm
update
across
your
entire
package
jason,
and
so
the
ranges
are
going
to
be
different
for
every
package.
A
B
B
A
Exactly
and
it
might
even
map
to
maybe
and
philip
would
know
this
might
map
to
kind
of
what
dependable
had
done
with
ranges
right
and
like,
or
you
know
like
now,
you
can
specify
specific
ranges
that
you
know
of,
especially
when
you're
using
let's
say
that
range
flag
with
a
specific
package
that
you're
updating,
so
you're,
saying
like
which
range
is
out
of
the
current
specified
in
the
package
json
that
you're
willing
to
go
up
until
so.
A
Let's
say
you
don't
know
what
the
specific
version
is
that
you
want,
but
you're
willing
to
go
up
to
like
a
known
good
version
essentially,
and
you
can
use
that
range
potentially
to
update
up
until
that
range
right,
and
so,
like
that's,
why
I
said
star,
which
would
essentially
give
you
latest
as
the
highest
range
that
you
could
update
to
or
highest
version.
You
could
update
to
go
ahead.
D
D
If
it's,
you
know,
let's
say:
you've
got
a
pinned
version
and
you
to
tell
it
to
update
everything
your
package
json
up
through
the
miners.
What's
the
version
that's
saved
now
so
npm
update,
save.
D
Update
update
won't
do
anything
if
it
if
you've
got
a
pinned
version.
If
you
say
your
version,
100
update
won't
install
one
one,
but
if,
with
this
new
thing,
you
tell
update
hey,
update
everything
in
my
package,
json
up
to
you
know
in
the
miners,
so
one
one
will
get
installed.
Should
it
then
do
a
carrot?
Should
it
pin
the
new
version
it
used.
A
B
C
I
would
expect
the
save
prefix
to
only
kick
in
when
there's
not
an
existing
entry
in
package.
Json
like
the
save
prefix,
is
when,
like
I'm
installing
something
new,
but
if
it's
already
in
package
json
then
whatever's
in
there
is
the
prefix
that
should
be
used,
and
obviously
I
can
override
that
by
passing
a
range.
C
B
G
E
A
E
Yeah,
the
strategy
is
just
for
what
to
do
with
the
version
in
the
package
json
after
it's
updated,
so
we
kind
of
it's
got
loads
of
logic
that
we
can
delete.
That
would
be
awesome.
E
A
Yeah
toony,
like
I
would
love
to
flush
out
more
like
of
this
idea
like
in
this
rfc
like
if
we
can
capture
some
of
like
the
notes,
flush
out
some
of
the
ideas
that
we've
got
here
like
like
as
an
incremental
step,
can
we
introduce
new
flag
which
just
gets
you
that
immediate
need
that
I
think
a
lot
of
people
have
which
is
like?
How
can
I
update
my
dependencies?
A
A
I
think
we're
all
on
board
like
I'm
on
board
to
like
do
something
here
and
then
the
longer
tale
of
this
is
okay.
Interactive
mode,
eventually
pulls
in
kind
of
like
the
npm
outdated
view
allows
you
to
select
and
then
apply
essentially
that
selection
against,
like
this,
these
other
types
of
flags
and
capabilities
right,
so
cool,
yep
cool.
I
just
want
to
quickly
move
on.
We
only
got
about
15
minutes
left
and
I
did
quickly
at
least
in
the
ordering
here
at
the
top.
I
did
pull
up.
I
know
folks.
A
Rc
but
let's
quickly
get
to
570.
First,
this
is
jordan.
Your
workspace
tag
version
prefix.
You
want
to
speak
to
us
a
bit.
C
Yeah
sure,
let
me
pull
it
up,
so
I
think
I
filed
this
because
I
saw
a
comment
somewhere
there
we
go
yeah.
So
gar
commented
that
we
don't
have
a
solution
for
get
tagging
of
workspace
version
bumps,
and
so
I
wrote
up
just
rfc
to
make
that
easy,
the
essentially
whenever
I'm,
whenever
I'm
using
a
monoreef
multi-repo
like
multi-package
repository
whatever
term
you
want
to
use
for
it.
C
I
I
pick
my
own
convention
for
version
updates
to
a
single
sub
package,
which
is
that
I
put
brackets
and
then
I
put
the
name
of
the
sub
package
and
then
I
do
a
space
and
then
I
do
whatever
I'd
normally
do,
which
is
v1.2.3
or
whatever.
There's
nothing
about
that
convention.
That's
necessary,
necessarily
special,
but
it's
just
what
I'd
happen
to
do,
and
so
the
suggestion
is.
C
We
add
this
new
config
that
defaults
to
something-
and
I
suggested
my
convention
just
because
I
haven't
seen
anything
different
and
that
way
we
can
enable
npm
version.
Behavior
inside
workspaces
and
people
have
the
ability
to
override
it
to
do
whatever
prefix
they
want
and
there's
already
a
tag
version
prefix
like
I've
set
up.
I
in
all
of
mine-
I
have
it
add
the
letter
v
to
the
tag
and
and
to
the
commit
message.
I
think
the
tag
is
defaulting.
C
D
Yeah
we
actually
looked
into
this
a
lot
recently
getting
release.
Please
set
up
in
the
cli
for
the
workspaces
and
they
kind
of
are
all
breaking
changes
all
over
the
place
and
what
they
tagged
it
at.
But
it
seems
to
me
across
the
ecosystem
that
normalizing
the
package
name.
Removing
special
characters
is
important
to
some
people,
so
we
might
want
to
make
the
default
a
snake,
cased
scope
package
name.
So
no
at
scope
dash
package
name.
If
the
package
has
that
or
hyphens
in
it,
that's
fine.
A
D
Package
well
in
his
example
here
he's
got.
This
is
a
variable
like
yeah.
What
would
that?
What
would
that
be
like
escaped
name
or
like
snake
name?
I
don't
know
that's
that,
doesn't
make
a
lot
of
sense
of
how
to
make
that
a
template,
but
I
do
think
it's
important
that
you
be
able
to
have
a
a
normalized
version
of
your
package
name
and
that
tag,
because
I've
seen
a
lot
of
them
out
there
strip
out
special
characters.
I
don't
know
why.
A
Right
and
it's
another
thing
that
we're
like
logging
and
we
want
to
be
concerned
about
any
sensitive,
I
guess
package
or
workspace
names.
Potentially
I
don't
know.
A
A
C
D
C
C
Yeah,
it
just
seemed
like
the
sort
of
thing
that
needs
to
be
solved,
and
this
seemed
like
a
way
to
do
it.
I
I
don't
want
to
put
commit
myself
to
pushing
it
too
hard,
but
if
there's
small
things
I
can
do
to
help
move
it
along.
I'm
happy
to
do
that.
Yeah.
A
Is
there
always
a
scope
car
in
your
examples
here
right?
So
that's
the
other
thing
to
know
right.
So
then
it
gets
kind
of
interesting
templates
are
conditional.
Templates
templates
are
also
even
more
yeah
problem.
I
would
say.
B
B
Although
I
kind
I
do
actually,
I
mildly,
disagree
about
version
the
multiple
commits
I
actually
think
it
should
be
or
sorry.
I
think
it
should
be
multiple
comments.
Not
one
commit.
B
C
Okay,
yeah,
I
mean
if
it
if
it
already
makes
separate,
commits
for
each
sub
package.
Then
of
course
that's
what
it
would
continue
to
do.
That's
what
I
would
do
myself
anyway,
but
I
also
would
never
be
running
a
version
command
on
more
than
one
package
at
once.
So
so
I
don't
care
either,
but
which
one
it
does
either
way.
C
Sorry,
but
just
one
thing
to
add:
I
I
know
that
there
are
people
who
do
against
my
personal
preference.
They
like
publish
multiple,
like
they
bump
multiple
packages
at
once,
and
so
they
would
probably
want
to
version
them
all
at
once
and
they
might
not
want
like
15
commits
when
they're
publishing
15
packages
every
time
one
package
has
a
change.
I
don't
have
a
lot
of
empathy
for
that
problem,
but
I
think
they
will
complain
so.
A
D
A
Yeah,
okay,
I
mean
I'm,
I
plus
one's
roy's
comment
here
in
the
thread
itself
for
the
the
format
like
the
workspace
name
and
then
the
workspace
version.
That's,
I
think,
that's
a
good
way
forward,
so
we
can
probably
queue
that
up
right
and.
F
A
A
Cool
okay:
we
can
backlog
this.
I
just
want
to
give
some
time
here.
With
around
eight
minutes
left,
I
pulled
up
philip,
your
rfc
for
the
improving
package,
signature
verification.
A
I
know
we've
been
doing
some
work
behind
the
scenes
to
to
make
this
happen,
but
I
also
want
to
just
hear
from
you
if
there
was
any
updates
on
on
this
rfc.
A
If
you
saw
or
you
knew
of
anybody
that
had
any
like
pushback,
otherwise
I
think
we
probably
can
potentially
land
the
rfc
as
it
is
or
potentially
I
know,
there's
one
comment
about:
potentially
nesting
the
signature,
verification
under
npm
audit,
I'm
not
sure
if
that
has
changed
the
rfc
at
all
from
the
first
time.
Last
time
I
checked
it.
E
I
did
update
the
rfc
then
match
the
audit
command,
but
I'm
not
sure
I
could
go
either
way
on
that.
No,
not
really
wedded
to
having
either
having
a
separate
or
nested
yeah.
C
E
Cool
yeah
yeah,
there's
no,
I
haven't
had
any
any
pushback.
There's
no
further
comments
in
the
rfc.
I've
done
some
implementation
to
test
the
performance
of
it.
Just
getting
the
pacuments
is
definitely
the
slowest
part.
I
know
doing
the
crypto
to
start
verifying
signatures
super
quick,
so
I
think
folding.
Some
of
this
into
install
could
be.
E
C
And
those
signatures
are
not
stored
in
in
the
log
file.
E
C
Then
the
other
only
other
question
I
had
is:
I
know
where,
for
now
it's
just
being
added
as
a
separate
command,
but
is
there
short
of
manually
adding
like
a
post,
install
script
or
something?
Is
there
a
config
I
could
use
to
like?
It
currently
runs
audit
npm
audit
after
my
installs
and
there
is
a
config.
E
A
E
Yeah
I
checked
like
400.
Packages
takes
under
half
a
second
to
actually
do
the
crypto.
So
that's
so
that
that
part
is
so
fast.
A
The
fact
that
there
may
be
new
signatures,
I
know
that
that's
we've
we're
considering
what
happens
the
next
time.
We
want
to
rotate.
No
key
you
want
to
introduce.
You
want
resign,
a
package,
it
almost
seems
like
it's
impossible
to
cash
or
store
the
signature
locally.
Then,
because
you
at
any
time
the
the
key
or
the
signature
could
have
been
updated.
A
new
signature
could
have
been
added
to
the
the
pacument
is
that
is
that
not
accurate.
E
Yeah
I
mean
in
the
case
of
disaster,
we
might
need
to
redesign
packages,
but
ideally
we
don't
need
to
do
that
and
if
we
rotate
a
key,
we
only
start
double
signing
a
new
package
releases,
so
once
you
download
them,
I
think
the
signatures
should
stay
as
they
are.
The
thing
that
might
change
is
the
public
keys
that
are
available
like
the
old
one
might
expire
and
we've
added
a
new
one.
So
I
think
that
end
point
needs
to
be.
E
I
can't
catch
you
too
long,
okay,
okay,
I
think
we
can
catch
it
for
some
time
and
then
double
sign
when
we
rotate
it.
That's
the
current
plan.
A
Okay,
we
can
have
somebody
from
our
team,
like
probably
reach
out
or
chat
with
you
about
using
our
burst
to.
A
Yeah
yeah
to
fix
any
kind
of
like
all
next
that
you're
experiencing,
because
we
should
already
have
that
information
in
an
arborist
node.
As
far
as
I
know,
somebody
on
the
call
can
correct
me
if
I'm
wrong,
if
it's
not
living
in
the
note
itself,
like
the
pacument
information
for
like
the
dist,
because
the
npm
signature
lives
inside
the
disc
right
now,
and
the
proposal
is
to
keep
it
there
or
in
some
place,
yeah,
okay,
cool
cool,
any
other
comments
or
notes
on
that.
A
One
specifically,
I
think
it's
something
that
we
could
probably
ratify
between
now
and
the
next
time
we
chat
so
that
you
just
know
that
we're
all
good
and
in
the
future
we
can
open
up
a
new
proposal
to
add
it
to
install.
A
Potentially,
if
there's
no
major,
you
know
huge
performance
ball
next
for
it,
it
would
have
to
go
in
a
major
version
of
the
cli,
and
then
we
would
probably
introduce
a
new
flag
similar
to
like
we
have
with
mpm
fund
or
audits,
etc,
like
where
you
can
opt
out
of
the
signature,
verification
by
default.
B
B
A
Sure
so
it's
just
always
interesting,
because
we've
got
so
many
config.
We
want
to
be
mindful.
We
just
continue
to
grow
them,
but
we
I
want
to
keep
track
of
all
of
them.
So
if
we
add
something
like
include
include
signature,
verification
for
install.
A
I
wish
there
was
infinite
time,
but
yes,
the
rc,
I
believe,
you're
talking
about
is
command
specific
config.
C
Yeah
I
mean
that
that
seems
like
it
drastically
reduces
the
problem
of
command
explosion
of
config
explosion,
because,
like
there's
a
bunch
of
things
that
could
be
added
to
one
command
that,
then
everyone
else
doesn't
have
to
suffer
through.
Yes,.
B
B
A
Yeah
cool
we
will
get
to
that
next
week,
then
for
sure
I'll
make
sure
that's
a
top
priority,
because
we
do
want
to
get
that
queued
up
for
v9,
essentially
like
if
we
can
support
command-specific
config.
It
saves
a
lot
of
folks
a
lot
of
headaches
and
I
think
really
it
does
modularize
things
a
lot.
So
thank
you,
everybody
for
jumping
on
today,
apologize.