►
From YouTube: Open RFC Meeting - Wednesday, Jan 22nd 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting 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.
GitHub Agenda Issue:
https://github.com/npm/rfcs/issues/91
Notes:
https://docs.google.com/document/d/1dFBNxdMQFlV_U8RTYley2ITFxBMGf6s0IJb0dbFFuRU/edit
B
B
Unfortunately,
we've
had
some
trouble
at
the
beginning
of
the
year
here
to
get
our
agenda
creation
script,
to
run
so
apologize
that
this
has
been
getting
sort
of
created
last
minute
again,
some
housekeeping
here
for
folks
that
are
on
the
call.
This
is
live
streams.
This
is
public,
so
just
be
mindful
of
a
sensitive
information.
B
The
point
of
these
calls
is
to
provide
a
means
mechanism
for
folks
here
at
NPM
to
work
closer
with
the
community
and
to
source
ideas,
features
and
help
to
address
bugs
the
community
brings
up
to
us
in
this
forum
and
hopefully
move
things
forward
together,
as
community
I've
done
my
best
today
to
try
to
group
a
number
of
the
issues
together.
So
we
can
quickly
move
through
the
agenda.
B
There's
a
number
of
outstanding
RFC's
that
we've
got
on
the
docket
essentially
either
need
to
be
ratified,
or
we
need
to
provide
some
feedback
if
we
don't
think
that
they
should
be
moved
forward
and
we
don't
plan
to
move
forward
with
them.
So
we
can
kick
things
off
actually
with
the
rc4
they're,
multiple
funding
sources
we
had
talked
about
this
two
weeks
ago.
I
know
that
Jordan
Harvin,
not
sure
if
he's
on
yep.
C
C
The
the
the
particular
decision
that
was
referenced
in
RFC,
but
that
Ryan
I
worked
out
in
more
detail
last
week
was
in
the
current
in
the
JSON
output,
is
not
going
to
change
in
a
braking
way.
First
of
all,
if
you
suddenly
start
putting
an
array
in
your
package
JSON,
the
JSON
will
contain
an
array
which
is
fine.
C
The
human
output,
however,
currently
is
keyed
on
package
names,
and
then
it
shows
the
URL
underneath
it.
However,
when
with
the
ability
to
have
many
funding
sources,
it
doesn't
really
make
sense
to
model
them
that
way,
and
so
we've
inverted
it
so
that
the
human
output
is
keyed
on
URL
and
that
lists
the
fender.
The
packages
underneath
them
and
the
only
open
question
I
have
to
work
out
with
that
which
I
can
talk
to
worried
about
is
like
because
it
shows
like
how
to
mesh
your
car.
C
The
current
packages
funding
information
with
nested
Pat
with
dependencies
funding
information
when
they're
the
same
but
but
overall,
the
still
the
the
intention
is
still
to
have
to
just
kind
of
invert
that
so
that
it's
basically
a
list
of
URLs
that
are
kind
of
with
a
nested
list
of
package
names
for
that
URL.
Underneath
it
yeah.
D
Yeah
and
that's
the
only
thing
that
I
would
like
to
have
in
the
in
the
RFC
tell
before
merging.
It
is
to
have
like
a
good
example
like
it
can
be,
like
a
white
will
look
like
in
a
small
tree,
but
like
also
how
it
will
do
like
with
the
big
one
which,
like
a
lot
of
duplication
and
like
so
just
to
have
example
there
and
have
the
people
looking
at
it.
And
so.
C
B
So
the
soon
as
the
are
the
earliest
that
I
think
that
we
could
probably
get
this
in
is
would
be
two
weeks
from
Tuesday
and
if
you
do
leave
you
up
that
that
work
and
it
is
in
a
good
place,
we
potentially
could
ship
a
minor
release
with
with
this.
With
this,
this
change,
if
you,
if
you
folks,
can
get
some
time
to
pair
on
that
in
the
next
few
days,
I
guess.
B
E
Yeah
I
can
do
that.
So
the
the
problem
that
this
is
trying
to
solve
is
that
today,
in
your
NPM
profile,
you
can
include
your
github
handle
or
your
Twitter
username
as
a
way
of
kind
of
helping
people
understand
who
you
are
within
the
broader
community.
But
the
problem
is
that
there's
no
verification
behind
this
you
can
put
whatever
handle
you
want
and
essentially
masquerade
as
whoever
you
want
to
masquerade
as
and
so
what
this
RFC
does.
E
C
Yeah
I
mean
in
spirit,
I,
think
this
is
amazing,
a
way
to
both
tell
NPM
like
prove
to
NPM,
which
other
accounts
I
am,
but
also
a
way
to
prove
to
other
people
that
I'm
in
which
NPM
account
I
am
so
like.
It
would
be
wonderful
to
end
up
in
a
world
where
I
can
both
attach
my
github
account
to
a
Twitter
account,
let's
say
to
NPM
plan
p.m.
C
account
and
also
go
to
my
github
account
and
attach
my
NPM
account
to
it,
because
at
the
point
where
those
two
are
linked,
it
opens
up
a
very
large
range
of
possibilities
to,
like
you
know,
for
freedom
of
information
and
security
of
so
on
and
so
forth.
Things
that
I
could
write
it
down
for
a
long
time.
Yeah.
A
A
C
And
also
like,
once,
you
have
this
link,
you
could,
for
example,
on
an
NPM
package
page
show
like
a
special
like
icon,
like
a
check
mark
or
something
when
the
git
repo
has
a
collaborator.
That
is
also
an
NPM
owner
right
way.
You
can
be
sure
that
the
git
repo
referenced
is
owned
by
the
same
person.
You
publish
the
package,
and
then
you
can
have
a
lot
higher
confidence
that
those
who
are
the
same,
whereas
I've
had
packages
of
mine.
C
A
But
if
you
want
to
have
a
repo
in
your
package
metadata,
you
have
to
be
a
verified,
github
account
and
it
has
to
be
again
hub
if
it's
a
github
repo,
you
have
to
have
a
verified
account
and
it
has
to
be
the
account
it
has
to
be
verified
as
somebody
who's
a
maintainer
on
the
project
yada
yada
yada,
so
somebody
did
that
it
would
just
eat
without
them.
Having
to
do
anything
like
in
the
package
metadata
on
the
website
and
in
the
registry
would
just
not
show
that
repository
potentially.
A
Are
all
these
are
all
great
ideas
for
future
RCS,
but
I
think
this
verified
account
linking
my.
My
only
question
is
like
how
much
and
I
don't
think
that
it's
necessarily
answerable
in
this
call,
but
my
only
question
is
like
how
much
backend
work
is.
Gonna
need
to
be
done
to
actually
implement
this.
It's
not
like
it's
something
to
CL
I
can
just
sort
of
do
on
its
own.
We
have
to
define
end
points
and
make
sure
they
work
and
be
an
OAuth
consumer,
etc.
A
B
So
maybe
I'll
just
we'll
give
you
some
time
after
this
call
to
review
that
and
actually
merge
this.
It
sounds
good
awesome
cool
that
will
unlock
a
lot
of
stuff
so
moving
on
another
RC
that
I
know
we
had
talked
about
on
the
last
call
and
I'm,
not
sure
if
we
will
was
able
to
make
it
but
I
know.
Wes
also
I
was
insight
into
this,
and
this
might
be
the
first
time
that
you're
saying
this
Issac
is
this
RC
for
signed
pact
against
I'm,
not
sure,
maybe
Wes.
B
You
can
speak
a
little
bit
to
the
intent
here,
we'll
and
or
we
can.
Maybe,
if
anybody
has
any
thoughts
on
this
I
think
this
is
something
that
we
wanted
to
do
personally
from
my
standpoint.
It's
definitely
something
I
would
love
to
see
us
be
doing,
but
yeah
maybe
was,
if
you
have
a
thoughts
on
this,
get
up.
I,
I.
F
B
A
A
A
The
first
is:
how
do
we?
How
do
we
handle
cases
where
there
are
multiple
registries
or
multiple
different
sort
of
registry
proxies,
because
we
may
have
in
in
cases
where
you
have
like
a
a
single
endpoint
that
proxies
to
the
public
registry
as
well
as
some
internal
registry
or
some
other
third-party
registry?
You
may
have
multiple
different
keys
for
the
same
Hosting
right,
so
you
have
you
have
one
packet,
that's
signed
with
the
public
registry
key
another
packing
mint
sign
with
my
internal
private
key
another
document.
A
A
A
Yes,
the
other
one-
and
this
is
always
so-
they
called
up
freshness
guarantees,
which
I
think
is
interesting.
So
an
attacker,
could
you
know
fetch
the
packing
and
hold
on
to
it,
wait
until
there's
a
vulnerability
and
then
keep
serving
the
old
one.
You
know,
because
if
you
get
man
in
the
middle,
do
you
man,
in
the
middle
of
the
signature
and
as
long
as
I,
just
prevent
the
packing
mint
from
changing
that
signature
stays
valid
right.
A
A
A
A
A
You
know
if
there's
if
the
signature
files
are
not
if
the
signatures
are
not
sort
of
just
bundled
into
the
the
packing
it
themselves
and
so
I
I
think
all
in
all
like
this
is
a
great
idea,
but
like
we
need
to
get
it
a
like
two
or
three
more
steps
closer
to
implementation.
Before
we
can
call
it
ratified
and
have
it
actually
be
a
proposal
that
we
so.
F
I
think
it
covers
a
little
bit
of
where
the
signatures
come
from,
so
in
this
I
think
it's
proposing
put
them
in
a
header
that
is
returned
with
the
document
itself,
which
I
mean
it
doesn't,
which
part
of
it
was
the
performance
not
requesting
the
signature
separately
was
that,
while
you
were
worried
about
no
only
doing.
A
A
That's
just
a
lot
of
PGP
right!
That's
that's
a
lot
of
calls
out
to,
like
you
know,
GPG
verify
or
whatever.
So,
if
we're
for
doing
that,
if
we're
doing
that
cleverly
and
we
and
we
can
kind
of
work
out
an
algorithm
for
doing
that,
that's
not
completely
terrible,
that's
fine
or
if
we
I'm
sort
of
load
to
make
it
opt-in,
because
if
then
we
may
as
well
not
bother.
A
Was
as
one
of
the
people
who
opted
in
I'm
sure
that
would
be
fine
with
you,
but
vast
majority
I'm,
just
saying,
like
the
the
overwhelming
majority
of
NPM
users
are
just
gonna,
do
whatever
the
default
is
right.
Even
we
had
integrity
checking
for
a
really
long
time
before
we
actually
just
made
it
not
opt-in
and
nobody
actually
did
it.
So
it's
it's
sort
of
like
and
we
can
look
at
also
the
history
of
ruby,
gems
in
Sipan
and
other
other
platforms
that
have
had
author
signing
it's
just.
A
F
So
so
I
I
could
see
that
being
the
future
I,
don't
think
that
should
block
what
we
have
today
and
I
actually
think
that
we
could
implement
to
move
forward,
get
some
people
trying
it
out
like
again.
We
would
obviously,
and
then
that
would
give
us
the
feedback
we
need.
If
it
is
this
performance
killer,
then
we
have
some
time
to
fix
that
or
you
know,
assess
and
decide
what
to
do.
Moving
forward
right.
No.
F
F
A
I
certainly
think
it's
it's
very
much
better
to
sign
packing
mints
than
sign
tarballs
right.
They,
although
there's
some
pros
and
cons
right,
there's
a
tarball
once
once
you
verify
the
signature
forgiving
thar.
Well,
you
know
it's
Valley
forever,
because
the
tarball
never
changes
with
the
pack
and
it
does.
F
A
Registry
signature
of
the
of
the
tarball
integrity.
What
we
don't
have
is
any
way
to
check
it.
They'll
bake
been
to
the
CLI,
so
the
signatures
are
there,
I
mean
if
you
look
at
it
it.
You
know
if
you
run
like
pro
Kochi,
manifest
on
on
something
you'll,
see
that
it
has,
you
know,
wouldn't
say:
NPM
signature
and
that's
just
signed
with
exactly
this
key.
This
NPM
registry
key
base
PGP
key,
but
without
any
tooling,
to
automatically
check
that
it
gets
kind
of
pointless
and
prior
experimentation.
That
happened.
A
A
F
There
are
two
separate
things
like
there's
a
lot
of
tooling
that
that's
all
it
really
needs
to
do
and
if
it
had
this
guarantee
that
would
be
nice.
You
know,
even
if
the
CLI,
you
know,
if
NPM
install,
let's
say,
did,
did
the
tarball
version,
not
the
Pakman
version.
Still,
maybe
that's
fine
as
long
as
the
tooling
we'd
want
to
build
around
just
the
PAC
Ament
stuff
still
had
some.
A
I
think
the
way
that
I
would
go
about
implementing
this
is
you
know,
assuming
that
we
had
some
assuming
we
can
work
out
some
way
to
in
in
a
node
program.
Given
a
signature
and
a
message,
you
know
whether
that's
like
a
short
integrity
body
or
how
should
the
document
or
whatever
verify
that
the
that
the
signature
matches
the
thing.
A
A
B
B
A
This
came
about
as
I
was
going
through
and
making
our
worst
able
to
build
ideal
build,
be
a
reify,
a
package
tree.
If
you
have
an
optional
dependency
with
a
build
script
and
that
build
script
fails,
it
needs
to
know.
Okay,
this
you
know
choke
Adar
doesn't
install
in
Linux,
so
I
need
to
remove
that
as
well
as
anything
that
was,
if
it's
an
optional
dependency,
remove
it
and
remove
all
of
its
dependencies.
If
they're
not
decided
upon
by
the
elds
long
story,
short
arborist
needs
to
be
running
lifecycle
scripts.
A
The
way
that
we
currently
create
the
environment
for
lifecycle
scripts
is
a
little
bit
ridiculous.
We
take
the
entire
the
entire
NPM
config
convert
all
of
it
into
environment
variables,
put
them
in
the
environment,
including
some
stuff.
That
should
really
just
be
it's
just
sort
of
an
artifact
of
how
we
generate
that
config
file
like
the
Arg
V
object,
which
some
folks
have
come
to
rely
upon.
A
Of
course,
that's
what
happens
whatever
whatever
is
exposed
is
public
API,
then
the
what
it
also
does
is
takes
everything
in
the
package
and
converts
that
to
environment
variables
as
well.
This
leads
to
some
really
absurd
cases
like
if
you
have
a
really
long
authors
list
in
your
package.
Json
the
the
NPM
CLI
scripts
themselves
have
stuff
in
the
in
the
environment
like
NPM
underscore
package
underscore
authors
underscore
275
equals
some
person's
name.
A
So
there's
no
need
for,
like
the
overwhelming
majority
of
that
stuff,
the
package
JSON
in
particular
like
it's
in
JSON.
You
can
read
it
and
a
lot
most
programs
that
depend
on
this
stuff
actually
do
there
are
since
I
proposed
this.
There
are
a
handful
of
cases
that
folks
have
brought
up
that
I
think
are
pretty
pretty
valuable
and
and
worth
addressing.
But
my
my
first,
you
know
my
first
sort
of
push
at
this
was
like
what,
if
we
just
didn't,
do
that
what
would
what
would
happen
there
and
the
or
what?
A
If
we
just
provided
a
much
more
minimal
set
of
things
like
the
packet
they'll
path
to
the
package.json
for
the
package
whose
lifecycle
scripts
are
actually
being
run?
And
then,
if
you
want
to
open
it
up
and
look
at
it
like,
you
can
do
that
real
easily.
It's
a
million
ways
to
read
json
in
JavaScript
for
config
options,
though
this
this
did
bring
up
a
handful
of
cases
and
they're,
actually
that
that
were
we're
kind
of
interesting
one.
A
One
use
case
of
Arc
V
was
in
the
is
pre
publish
or
is
publish
module
that
Rebecca
Turner
wrote
five
years
ago
in
published
right
two
things
about
that
one
is.
We
have
pre
published
only
as
a
lifecycle
script
now,
since
NPM
or
five
I
think,
and
so,
if
you
really
want
something
that
only
runs
in
the
actual
pre
publish
like
there
is
actually
a
more
straightforward
way
to
do
that.
A
A
The
other
issues
that
were
brought
up
I
think
can
be
addressed
by
just
taking
everything
that
is
not
a
default
config,
violet
value
and
putting
that
in
the
environment,
and
this
actually
the
use
case
that
this
bring
that
this
address
is.
We
have
a
lot
of
this
in
the
CLI
project,
ourselves,
let's
say:
I
have
a
post
version
or
a
pre
version
script
that
runs
test
and
then
a
post
version,
script
that
runs
npm,
publish
and
npm
published
means
an
OTP
file.
A
He
needs
an
OTP
config
in
order
to
publish
from
my
2000
are
off,
so
what
I
often
do
is
I
run
NPM
version
OTP
equals.
You
know
one
two,
three,
four,
five:
six,
if
that
config
value
is
not
being
placed
in
the
environment,
then,
when
the
sub
script
gets
run,
it's
not
going
to
have
the
same
arguments
in
its
CLI,
and
so
it's
not
going
to
have
that
that
config
value.
A
So
that's
basically
that
the
other,
so
the
other
thing
about
about
this
that'll
make
it
a
lot
simpler
and
just
kind
of
remove
a
huge
source
of
friction
and
bugs
in
management
and
development
of
NPM
is
the
just
copying
the
environment
from
the
parent
environment,
which
we
right
now
do
painstakingly
manually
in
NPM
life
cycle
and
less
like
that
is
the
default
behavior
of
processes
is
to
inherit
their
environment
like
there's,
no
need
to
require
that
you
have
to
provide.
All
of
that
for
all
is.
A
C
C
That'll
make
sense
I
just
you're
saying
it's.
The
default
behavior
like
I
think
the
default
link
bash
behavior
I'm
used
to
is
that
child
process
inherits
automatically
inherits
the
environment
from
the
parent,
but
I'm
wondering
if
like
are
there
any
wacky
zsh
options
that
could
disable
that,
or
is
that
true
in
PowerShell
or
git
bash?
Well,.
A
A
So
we
have
this
thing
where,
if
you
have
a
node
module,
slash
I,
believe
dot
hooks,
you
can
create
an
install
script
that
gets
run
for
all
installs
I'm,
not
sure
what
to
do
about
this,
because
the
way
that
it
I
mean
the
way
it's
being
handled
right
now
in
NPM
lifecycle
is
is
super.
Weird
I
might
just
make
a
way
for
run
script
to
like
take
up
arbitrary
command
as
its
as
an
argument.
Otherwise
yeah
this
this
hook.
A
C
A
So
there
is
a
difference
in
the
point
of
view
of
building
the
tree,
because
in
one
case
we
we
make
some
modifications
the
ideal
tree
before
before
reifying
it
and
or
sorry.
We
make
some
modifications
to
the
virtual
tree
before
building
the
ideal
tree
and
then
reapplying
it.
If
you
just
run
npm
install
we
just
take.
If
we
have
a
virtual
tree,
we
just
basically
take
whatever
is
in
the
package
lock
or
the
shrink,
wrap
and
lay
that
all
out
on
disk.
But
if.
G
You
didn't
have
that
right,
like
the
processes
are
the
same
you're
just
talking
about
a
step
that
would
be
really
different,
like
the
idea
of
I'm.
Speaking
to
the
idea
of
like
breaking
up,
install
like
root
or
install
a
single
package
like
which
is
a
node
of
the
tree
right,
like
I
still
root
is
a
node
of
the
tree.
Just
happens
to
be
the
root
node
right
link.
Those
two
actions
are
the
same.
G
A
Yeah
they're,
pretty
similar
I
mean
they.
They
appear
different
from
from
a
user
intent
point
of
view,
like
that's
kind
of
with
Jordans
getting
it
here.
It
sounds
like
because
in
one
case
I'm
saying
I
would
like
to
start
using
this
new
dependency
and
in
the
other
I'm
saying,
I
would
like
to
start
working
on
my
project
and
so
their
flag.
The
way
that
we
sort
of
filter
on
that,
although
in
the
second
case
in
the
case,
where
you
add
a
dependency,
we
also
install
the
rest
of
the
tree
like
yeah.
G
But
also
in
terms
of
like
the
hook
say
it
running
right
like
in
in
one
case,
if
I
want
to,
you
know,
start
working
on
my
projects
and
the
install
of
the
root
node
I'm
gonna
run
all
the
like
hook,
scripts
or
what-have-you
for
all
the
the
things
that
have
one
and
I'm
installing
a
particular
one.
I'm
still
gonna
need
to
run
all
the
you
know,
a
there's,
a
post,
install
script,
I'm
still
ready
to
run
that
particular
hook
right.
It's
like
the
hooks
would
still
run
in
both
situations.
Yeah.
G
C
In
the
top
level,
package.json
also
I'll
often
put
things
in
post
installed
that
are
like
things
that
I
want.
Other
developers
in
the
company
like
I
want
their
install
to
fail
if
they're,
not
throughs
right
so
like
impale.
Install
currently
doesn't
check
like
MPLS,
for
example,
and
so
I
might
add,
to
post
install
an
NPM,
LS
check
and
a
custom
error
message
saying
something's
wrong
like
don't
continue,
because
I
want
to
make
sure
that
both
in
CI
and
locally,
like
they're,
stopped
when
things
are
wrong.
C
I,
like
at
Airbnb,
we
had
a
post
install
script,
fit
like
after
on
post
install
created,
a
bunch
of
sin
links
and
the
rails
like
vendor
folders
from
legacy
stuff
like
like
and
I'd,
want
to
be
able
to
reviews
ignore
scripts
for
transitive
dependencies
in
some
way
and
still
always
run
those
top-level
post
installs
and
to
me
those
are
conceptually
different.
One
is
post
install
of
the
app
and
those
smaller
ones
are
post
install
of
the
package.
Yeah.
A
This
is
this
is
similar
to
the
kind
of
like
prepare,
pre,
publish
and
semantic
subtlety.
If
you
have
a
post,
install
script
like
if
you're,
if
you're
working
in,
if
I'm
working
in
tap
right
I
might
want
to
have
a
post
install
script
that
verifies
that,
like
I,
don't
know
something
is
set
up
properly
in
order
to
develop
on
this
project.
Yes,
when
you
install
tap
I,
don't
want
that
to
be
run.
Yeah.
A
B
A
A
This
implements,
which
is
or
makes
it
possible
to
implement
an
NPM
b7
which
is
and
him
install
output
scares
people
I,
don't
want
to
be
scary.
I
want
NPM
to
be
to
work
and
like
if
an
optional
dev
fails,
but
this
install
continues
like
it
should
be
fine,
so
the
the
rewrite
of
the
life
cycle
script
runner
will
have
a
way
to
to
control
whether
or
not
something
gets
dumped
to
the
output
and
then
the
Clyde
can
decide
whether
it
needs
to
be
quieter
or
loud.
I.
B
Know
I
removed
actually
the
RC
97
that
PR
from
the
agenda
just
because
we
had
previously
discussed
that
it
seems
like
that
itself
can
probably
get
closed
out,
doesn't
necessarily
need
to
be
move
forward
and
any
there
was
no
like
there
was
no
real
tangible
it.
This
should
have
been
probably
more
of
a
issue
or
a
thread
and
a
comment,
so
I
guess
just
as
an
action
item
our
takeaway,
let's
potentially
close
that
out
with
a
comment
to
what
you're
saying
yeah.
A
B
Yeah,
so
we
can
probably
close
that
out.
I
know
was
pretty
well
and
I
can
speak
to
that
and
I
just
closed
that
are
so
if
there
isn't
anything
else
on.
Those
I
would
like
to
skip
ahead
to
that
RC
I
need
to
because
we
have
Daniel
on
the
call
as
well.
I
actually
saw
that
then
jumped
on
Ben
code
jumped
on
quickly,
but
I
think
had
to
run
and
I've
tried
to
ping
him
just
for
everybody's
context
and
surveys.
B
Where
then
has
recently
launched
a
tool
that
they
used
over
at
Google
called
the
wombat
dressing
room,
it's
in
some
sense,
analogous
or
lines
up
with
I
think
this
RC
that
Daniels
put
together
for
what
we
would
like
to
see
in
terms
of
a
future
offering
from
NPM
and
I
know.
Wes
and
Jordan
have
also
been
a
heart
of
discussions
with
the
package
maintenance
working
group
for
essentially,
you
know
further
bolstering
the
offering
that
we
have
for
unmade,
builds
and
publishes
NCI
and
and
how
we
can
you
know,
make
those
more
secure.
B
E
So
basically,
what
this
does
is
it
provide
the
staging
area,
and
so
you
can
choose
to
publish
a
package
to
a
staging
area,
in
which
case
it's
not,
you
know,
live
and
free
photos
to
download
or
you
can
publish
into
production,
and
you
can
also
move
a
package
from
staging
to
production,
and
so
what
this
does
is
it
enables
to
kind
of
separate
use
cases.
The
first
use
cases
that
lets
you
have
your
CI
system
publish
to
staging
with
abandon
it
doesn't
have
to
wait
for
a
human
to
say,
yeah.
E
And
then
the
fourth
bit
was
to
have
an
off
token
that
can
be
scoped
to
the
staging
area.
Specifically.
So
what
this
lets
you
do
is
it
lets?
You
say
that
my
CI
system
can
publish
a
stadium,
but
it
can't
publish
to
production
because
the
auth
token
that
I've
given
it
only
has
permissions
off
on
staging,
and
so
we
think
that
these
four
foreign
improvements
would
provide
us
with
a
kind
of
an
MVP
to
staging
on
the
registry
and
that's
not
a
huge
lift,
but
that
opens
the
door
to
additional
improvements
in
this
area.
B
Yeah
I
appreciate
all
the
work
you
did
to
sort
of
outline
this,
as
we've
had
a
number
of
conversations
internally
and
externally,
with
Wes
Gordon
Issac,
we've
we've
commented
on
a
number
of
threads
out
there
again.
This
is
obviously
gated
or
blocked
by
any
other
feature,
work
that
our
team
wouldn't
have
in
front
of
us.
The
registry
teams
would
have
in
front
of
us
as
well,
but
we
want
to
get
this
out
so
that
we
can
have
discussion
here
in
the
open
about
whether
or
not
we
see
value
or
the
community
sees
value
in
this.
C
F
F
Definitely
I
think
this
will
unlock
a
bunch
of
workflow
opportunities
that
we've
been
looking
for.
You
know
to
help
build
more
concrete,
CI
integrations,
so
this
is
gonna
be
very
helpful
for
that.
One
thing
I
want
to
say
about
that,
and
this
is
going
to
affect
probably
a
lot
of
the
people
who
are.
You
know,
customers
of
other
registry
providers.
F
There
are
a
few
solutions
that
they
have
that
are
different
from
this
I
think
there
will
be
some
effort,
probably
to
get
them
on
board,
which
I
did
have
a
conversation.
We
had
a
conversation,
one
of
the
package
meant
in
certain
groups
about
writing
some,
like
compliance
test,
suites
I
think
this
would
be
a
great
thing
to
start.
If
we
wanted
to
do
that,
this
feature
would
be
a
great
one,
since
you
know
I
think
it
will
affect
a
lot
of
people.
F
So
if
there
was
some
like
open,
you
know
if
there,
if
your
ad
you're
building
this
it'd,
be
great.
If
there
was
some
work
on
having
like
an
open
test
suite
that
other
registry
providers
could
run
against
themselves
to
make
sure
they
are
complying
with
this
new
feature.
Obviously
that
has
nothing
to
do
with
the
RFC
process.
I
just
wanted
to
to
say
that
dead
piece.
B
That's
a
really
good
point,
definitely
something
that
we
should
put
on
our
radar
in
terms
of
even
a
way
to
have
some
sort
of
like
documented
chart
of
the
various
registries
and
their
implementation
of
something.
You
know
these
types
of
teachers
so
that
the
drift
doesn't
get
too
too
crazy
right
yeah.
That.
F
Would
help
to
be
honest,
say:
I
told
this
to
the
artifactory
folks
when
they
were
here
a
couple
weeks
ago.
I
said:
look
if
you
don't
implement
it
exactly
as
the
public
NPM
registry
like
we're
not
going
to
use
it,
so
you
need
to
be
more
in
sync:
I
actually
told
them
image
to
be
coming
to
these
meetings.
You
know
we'll
see.
I
said
that
links.
D
F
F
Maybe
we
can
work
better
on
that
in
the
future,
but
but
I
think
it
will
be
very
important
to
get
their
feedback
and
make
sure
that
they're,
mostly
just
to
make
sure
they're
aware
of
what
is
happening
so
that
you
know
when
all
these
people
who
are
using
alternate
providers,
get
to
that
point.
We
don't
have
you
know
a
huge
contention.
Point
sounds
good.
B
So,
based
on
the
fact
that
we
only
have
about
five
minutes
left
I
want
to
be
my
father.
There
was
only
a
few
two
issues
that
we
essentially
are
three
actually
sorry
that
we've
sort
of
skipped
over
here,
but
I,
don't
think
we're
gonna
have
to
really
get
into
them.
I'm
wondering
actually
actually
I
do
want
to
get
to
number
75
so
feature
prompt,
a
proper
module
type
as
part
of
NPM
minute.
I
want
to
speak
to
this
quickly
because
I've
reached
out
to
Wes
recently
letting
him
know
and
I'll.
D
F
Yeah
so
Darcy
and
I
chatted
about
this
sort
of
in
a
and
I'll
repeat
a
little
bit
what
I
said
there?
So
I've
worked
towards
some
of
this
totally
independently,
not
really
informing
people
just
kind
of
working
in
my
own,
because
it
was
something
that
I
arrived,
you
run
and
come
in
it
a
lot
and
I
wanted
a
little
bit
more
out
of
it.
So
I
wrote
one
that
is
create
package
Jason,
which
is
a
horrible
thing
to
type
NPM
in
it.
Pkg
is
much
better.
F
That
said,
I
think
we
should,
with
the
package
maintance
working
group,
discussed
because
I
think
there's
like
the
bare-bones
stuff,
which
is
just
like.
We
talked
about
the
Knitting
of
the
package
Jason
but
I
think
there's
a
lot
more
opinions
that
we,
as
the
package,
maintance
working
group,
could
add
that
might
be
beyond
just
what's
in
the
package.
Jason,
so
I
think
that
looking
at
where
that
package
would
live
in
the
in
the
breadth
of
things,
we
could
provide.
I
think
is
probably
important
because
I
personally
see
it.
F
You
know
having
other
files
licenses
and
and
and
contributor
code
of
conducts
and
stuff
like
that,
that
we
as
a
you,
know
the
node
community
sort
of
get
our
backing
behind
in
that
it
goes
beyond
just
NPM
in
its
current
scope,
so
I
think
maybe
there's
a
body
of
tools
that
we
could
build.
I
actually
brought
this
up
to
Darcy
and
I.
Don't
know
how
you
all
feel
about
this.
F
Maybe
this
is
worthy
of
an
RFC
but
move
the
NPM
init
functionality
itself
out
into
a
create
pack
package
and
just
have
a
default
NPM,
an
it
where
it
actually
does
and
Payman
it
create.
You
know,
runs
create
Annette
or
you
know
we
could
come
up
with
whatever
naming
there
would
want,
but
that
would
move
it
into
user
land
which
would
help
it
maybe
evolve
a
little
bit
faster
or
more
easily.
I,
don't
know
how
how
that
you
know
that.
G
F
G
B
To
be
mindful
of
time
here,
we're
pretty
much
coming
up
to
on
the
hour.
I
appreciate
everybody
jumping
on
today,
though,
and
if
there's
any
other
discussion
that
can
happen
async,
let
us
know,
love
the
feedback
that
we're
getting
and
appreciate
everybody
that
is
joining
these
calls.
Definitely
it's
super
helpful
and
useful
for
us
and
I'm
sure
I'll
will
continue,
have
conversations
in
the
various
other
open-source
working
groups
that
we
have
definitely
feel
free
to
circle
back
on
each
one
of
these
threads.