►
From YouTube: Open RFC Meeting - Wednesday, Feb 19th 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/101
Notes:
https://docs.google.com/document/d/1D2EhxOm6zmjL9ONLUUTM2rT1iOGi0uaz_BSCWW7COls/edit
A
Should
be
live
on,
YouTube
welcome
everybody
to
another,
open,
RC
call,
MP
I'm,
open
RC
call.
Thank
you.
Everybody
for
jumping
on
today
and
joining
us
quickly
feel
free
to
add
yourselves
to
the
attendees
list.
Also
notes.
This
is
a
publicly
stream
call
on
YouTube,
so
be
mindful
of
everything
you
say
we'll
go
through
some
quick
introductions,
but
I
also
want
to
note
this
calls
run
under
the
code
of
conduct
which
can
be
found.
A
A
link
can
be
found
in
the
RCS
cab
projects,
Gabe
comm,
/,
MGM,
/,
five
seas
and
just
be
mindful
and
be
respectful
throughout
the
call.
The
desired
outcomes
and
intentions
of
this
call
is
just
to
close
the
communication
gap
with
the
JavaScript
community
in
the
community
and
the
MCM
community,
and
hopefully
move
initiatives,
features
and
and
feedback
forward
and
ideally
give
the
community
another
opportunity
to
interface
with
folks
here
at
NPM
quickly.
I
want
to
give
anyone
the
floor.
If
there's
any
announcements
that
anybody
has
feel
free
now
to
to
note
that.
A
So,
let's
quickly
do
a
round
of
introductions:
we've
got
a
few
people
need
met
new
people
on
the
call
that
haven't
been
before
I'll
start.
My
name
is
Darcy
Clarke
I'm,
the
engineering
manager
for
community
and
open
source
at
NPM
I
worked
with
fire
a
number
of
the
folks
that
are
on
this
call
and
then
I
think
we'll
go
around
here.
Roy.
Do
you
want
to
about
care.
A
B
A
A
H
I
A
J
A
M
A
So
I
appreciate
everybody
doing
a
bit
of
intro.
We
won't
do
that
every
time
I
apologize
for
stealing
some
extra
time
at
the
beginning.
Here,
if
you
haven't
already
feel
free
to
add
yourself
to
the
notes,
doc
and
if
anybody
wants
to
rearrange
or
change
or
add
something
to
the
agenda
feel
free
to.
Let
me
know
now
otherwise,
we'll
keep
going
and
start
with
the
first
PR
RC
number
96,
which
is
public
confirmation,
prompt
and
I
believe
this.
C
Sure
yeah,
this
RC
is
basically
a
compilation
of
like
multiple
requests.
We
saw
from
the
community
and
basically
boiled
down
I'm
having
a
confirmation
step
when
publishing
your
package,
so
that
people
can
have
a
just
a
last
look
glance
for
the
files
that
are
going
in
the
package
before
it's
published
in
the
registry
right.
C
It
is
a
kind
of
experience
we
already
have
when
we're
using
a
one-time,
password
and
you're,
not
providing
it
the
first
time
you
invoke
the
commands,
you're
gonna
be
poked
about
it,
and
it
gives
you
a
little
time
to
to
review
the
files
that
are
going
into
the
package
and
need
to
cancel
it.
So
it's
kind
of
a
nice
experience
for
the
folks
that
are
using
it
and
it's
kind
of
expanding
that
to
the
so
the
rest
of
maintainer
might
not
be
using,
and
one
of
the
ideas
is
also.
C
M
No
I
am
yeah
I,
just
I
mean
maybe
this
isn't
worth
talking
about.
New
York,
City
called
but
like
with
that,
prompts
also
happen
in
an
on
TTY
like
with
to
vector
off.
That
makes
sense
that,
like,
if
you
don't,
provide
it
upfront
and
you
run
it
like
in
CI
or
something
that
it
errors
out
and
but
like
I
assume,
it's
gets,
the
prompt
there
too
I
haven't
tried
it.
So.
Similarly,
I
would
assume
that
this
confirmation
would
print
the
same
information,
but
not
actually
pause
and
wait
for
the
prompt
on
a
non
TTY.
Yeah.
C
M
B
B
B
Yeah,
probably
it
started
doing
that
after
you
turned
on
to
factor
off
the
the
thing
is
like
it:
it'll
just
be:
like
ham
I'm
publishing
your
pack
I'm
publishing
your
your
password
files
just
want
to
let
you
know
like
can't,
stop
it.
So
so
my
my
concern
with
this
you
know,
apart
from
the
the
headless
issue,
is
just
making
sure
you
know.
Maybe
we
need
to
like
have
some
thinking
around
whether
this
should
be
opt-in,
opt-out
or
you
know,
opt-in.
B
If
you
don't
have
or
opt
out,
if
you
don't
have
to
factor
off
their
off
the
end,
if
you
do
have
to
factor
out
their
what,
because
what
I
don't
want
to
do
is
like
I
I,
don't
want
to
actually
have
this
myself
when
I'm
publishing
packages,
I
am
very
restrictive
about.
You
know
what
I
put
in
my
files
list.
So
it's
it's
more
likely
that
I'm
not
publishing
something
I
need,
then
the
opposite
and.
B
So
I
would
definitely
and
I
have
to
factor
auth
but
I,
often
kind
of
set
a
note.
My
OTP
just
right
when
I
run
that
you
can
publish
I,
don't
even
get
that
prompt
and
it
is
an
efficiency.
You
know
it
is
a
slowdown
and
I
I
worry.
If
we
just
you
know,
there's
kind
of
a
alert
fatigue
that
can
happen
where
you
just
get
in
the
habit
of
yes,
a
lot
so
I
don't
know
my
senses.
This
should
probably
be
either
either
opt
in
or
opt
in.
J
For
this,
I
would
probably
go
the
right
way
of
having
it
as
a
general
MPI
mousey
config
file
setting
sir
anywhere.
If
you
want
you
can
enable
it.
If
you
don't
it's
the
behavior,
as
is
current,
but
I
would
also
ask
how
does
this
maybe
relate
to
things
like
pre
releases
and
things
like
that?
Is
it
just
simply
a
setting
in
order
to
prevent
you
accidentally
publishing
files?
You
did
not
mean
to
you,
or
is
it
a
case
of
wanting
to
do
a
pre
release
and
sort
of
publish.
B
M
J
B
B
Default
is
to
stop
and
prompt
you
anyway
right.
So
imagine
if
it's
if
it's
optic,
if
it's
up
to
it,
if
it's
opt
out
to
be
prompted,
then
I
set
up
to
FA
and
I
type
in
p.m.
publish
and
it
stops
and
says:
okay
open,
you
know,
enter
your
to
FA
password
and
then
it
stops
again.
It
says
be
really
over
the
publish
this.
What.
B
J
So
you
get
you'd
first
got
the
listing
of.
Would
you
like
to
publish
this
here's
the
ID
nerd
the
file
listing
the
manifest
whatever
you
want,
or
maybe
it
just
says,
I
put
the
table.
All
here
go
check
it
I'm
Dan
occurs
to
if
a
prompt,
of
course
you
can
disable.
Both
I
would
possibly
are
on
the
side
of
keeping
it
disabled
by
default.
I
Took
questions
then,
okay,
so
two
FA
is
on
the
server
side,
so
the
client
probably
doesn't
know
it
beforehand.
But
that
said,
shouldn't
OFA
be
the
default
at
some
point
sooner
rather
than
later,
and
also
if
this
is
completely
opt-in,
then,
is
the
real
value
in
it,
because
if
you're
going
to
have
to
take
action,
you
may
as
well
go
and
use
something
other
than
in
the
end,
but
a
wrapper
around
in
the
end
to
do
pub.
There's
something
like
for
the
other
tools
that
help
to
confirm
and
just.
B
B
The
then
the
other
question
of
like
do.
We
make
it
opt
in
or
do
we
make
it
opt
out?
It
sounds
like
everyone's,
but
you
know
I'm
not
hearing
any
disagreement
on
like
if
it's
headless
or
if
you
do
that,
that's
yes,
then
then
we
just
sail
on
through
the
reason.
The
argument
for
making
it
up
in
would
be
just
minimizing
disruption
of
existing
workflows.
B
The
argument
for
making
it
opt
out
is
no
matter
how
much
marketing
I
mean
if
we,
if
we
spent
n
pm's
entire
marketing
budget
on
just
telling
people
to
set
this
flag,
we
would
get
like
1%
of
our
users
to
do
it.
Like
it's
there's
no
amount
of
marketing.
We
could
do
to
tell
people
to
do
that.
That
is
not
disruptive
to
their
workflows
right.
That's
the
only
thing
people
actually
respond
to
so.
J
D
Dovetails
on
that
idea,
so
it
was
suggested.
I
don't
know
if
it
was
a
lot
Farsi
or
if
it
was.
If
it's
in
the
current
RFC's
comments
that
NP
mv7
have
this
as
an
opt-in
feature,
so
that,
if
you
want
this,
you
must
explicitly
say
like
yes,
please
I
would
like
this
and
then,
if
you're,
managing
a
team
with
people,
you
can
tell
them
sort
of
update
their
at
PMI
fees
and
such
and
then
in
the
next
major
version
bump.
D
C
D
Say
like
that,
don't
actually
particularly
want
this
thing,
which
I
think
gives
people
time
to
sort
of
update
their
existing
workflows
or
sort
of
quells.
That
thing
where
it's
like
see,
people
say
like
you
broke
my
workflow,
but
it
said
we
gave
you
an
amount
of
time
to
say
like
hey.
This
is
a
thing,
so
it's
kind
of
on
you
now
that,
instead
of
on
us,
rather
and
so
I
I,
think
it
I
think
that's
satisfies
things.
B
It
gives
us
time
to
collect
data,
I
mean
if
we
make
it
we
make
it
opt
in.
You
know
in
pm7
that
that
feels
like
the
safest
option
for
me
and
then
and
then
we
can
see
right.
We
can
get
some
feedback
from
folks
who
are
using
it.
We
can
start
being
a
little
bit
noisy
and
say
you
know
this
is
not.
This
is
not
going
to
be
like
you're,
not
it's
going
to
prompt
you.
India
mate,
FYI,.
C
C
There
is
just
what
one
the
one
concern
with
making
it
opt-in
is
that
one
of
the
things
that
this
RFC
was
trying
to
address
is
precisely
trying
to
motivate
people
and
enable
to
FA.
So
the
idea
was
precisely
to
give
the
folks
that
don't
have
to
FA
enable
will
be
able
to
print
a
warning
message
or
something
like.
Oh,
you
don't
have
to
FAA.
We
recommend
that
to
every
publisher
at
NPM.
Please
do
that
now
and
then
point
to
a
link
where
people
can
just
set
it
up
on
the
website
right.
A
F
F
Instead
of
ever
doing
the
local,
which
means
this
feature
doesn't
touch
you
right,
so
I'm
definitely
thumbs
up
for
doing
it
definitely
thumbs
up
for
making
it
opt-in
to
start
and
definitely
like
the
future
should
be
nobody's.
Seeing
this
prompt
ever
because
they've
moved
on
to
a
nice
CI
workflow
with
stage
the
staging
feature
which
we
should
talk
about,
I
think.
A
And
if
there's
any
other
feedback
feel
free
to
add
to
the
RFC
or
the
issue
itself,
so
moving
on
so
PR
number,
92
or
FC
United
to
add
stage
and
workflow
for
CI
and
human
interoperability,
this
was
an
RC
that
was
kicked
off
by
Daniel
on
our
end,
our
product
person
I'm,
not
sure
to
make
us
and
Jordan
and
Isaac
there's
been
a
lot
of
conversation
on
this.
Even
in
the
last
few
days,
Wes
you
were
the
last
person
to
comment.
Would
you
like
to
pick
up?
Where
are
things
sure.
F
Yeah
happy
to
so
I
think
so
on.
The
last
call
I
was
a
little
bit
concerned
about
the
developer.
Experience
around
this
and
I
pushed
a
little
bit
for
people
installing
from
the
staging
area
on
further
thought
and
then
having
a
few
discussions
with
some
of
my
teammates,
particularly
ones
that
manage
our
artifactory
instance,
which
is
our
registered
proxy.
F
There
is
some
I
think
fairly
large
problems
with
some
of
the
stuff.
I
was
questioning
what
you
know
the
developer
experience
around
on
the
last
call.
So
what
I'd
really
like
for
us
to
focus
on
and
I
think
Jordan
had
some
really
good
input
here
in
the
issue
as
well
is
this
is
not
a
way
for
you
to
distribute
pre-release
versions?
There
is
a
feature
for
that.
It
is
pre-release
versions
and
dis
tax
right.
F
So
if
you
want
somebody
to
be
on
a
beta,
you
know
track,
have
a
dist
tag,
called
beta
and
publish
pre-release
versions
and
have
people
coupled
to
that
I
think
that's
gonna
be
a
much
better
workflow
and
the
install
from
the
staging
area
to
me
should
be
really
relegated
to
a
sanity
check
and
that
sanity
check
is
just
for
the
publisher
right.
So,
and
this
is
where
it
goes
in
to
what
Jordan
was
was
saying.
F
F
I
brought
up,
I
think
two
editions
and
then
I
think
there
was
two
other
editions
that
came
out
of
that
that
we
could
make
one
was
the
it
doesn't
touch
package,
Jason
or
package
lock
when
you
install
from
a
staging
and
I
think
that
resolves
my
big
developer
experience
concerns
before
which
were
that
you
suit
you
do
that,
then
it
promotes.
Then
the
tarball
is
gone
so
isaac.
I
record
made
a
suggestion
as
a
possible
solution
there,
which
is
just
redirecting
the
tarball.
F
F
Obviously
we
can
disagree
on
that
and
have
that
conversation,
but
I
I
would
definitely
put
my
vote
on
make
that
not
the
point
of
the
staging
area
and
then
the
other
one
was
o
explicitly
opting
into
installing
only
a
single
staged
version
at
a
time,
so
that
would
be
making
these
to
include
staged
flag,
not
work
on
a
generic
install.
It
would
only
be
functional
when
you're
installing
so
it'd
be
like
NPM
I
staged
package.
F
M
I
mean
so
I'm
sure
that
the
this
RFC
came
from
multiple
different
use
cases
and
ideas
right,
but
within
the
package
maintenance
working
group,
the
entire
purpose
of
this
feature
is
I.
Don't
I
want
to
factor
on
on
my
applications,
but
I
don't
want
to
trust
non,
a
nonhuman
to
publish
a
thing.
How
do
I
do
that
and
like
current
workarounds
or
things
like
use,
NPM
pack
and
you
save
the
tarball,
and
then
you
trust
a
human
to
download
it
and
publish
it
later,
but
that's
still
more
trust
than
we
were
comfortable
with
recommending.
M
So
the
entire
purpose
was
to
be
able
to
make
a
secret
publish
from
within
CI
without
requiring
to
factor
and
because
it
doesn't
require
a
two-factor,
it's
critical
that
it
be
inaccessible
to
anyone,
perhaps
who's,
not
an
owner,
but
not
just
installable
and
then
later
on,
the
web
or
through
the
CLI,
with
it
with
two-factor
prompt
or
some
place
where
a
human
is
involved.
The
human
can
essentially
promote
that
or
you
know,
and
make
that
be,
the
real
version.
M
I
think
it's
just
like
I'm
there
I
was
basically
very
surprised
to
see
the
what
I
see
is
a
total
shift
in
direction
for
the
purpose
of
this
feature
to
be
about
what
pre-release
has
already
do.
You
know
if
the
concern
is
about
version
churn
like
make,
you
know,
we
can
add
redirection
to
pre
releases
and
make
pre
releases
more
easily
unpublishable,
like
there's
lots
of
solutions
to
that,
but,
like
that
hasn't
been
necessary
so
far,
because
you
can
put
a
cember
string.
M
That
includes
all
the
pre
releases
and
that's
what
people
generally
do
when
they're
doing
that
so
like
I
guess
it
just
feels
like
the
purpose
of
this
has
been
conflated
with
some
valid
pain
points.
People
are
having
with
testing
multiple
tightly
coupled
packages
and
I
think
that
it
would
be
worth
evaluating
those
a
little
separately
sure.
B
Yeah,
so
I
want
to
talk
a
little
bit
about
why
why
it
is
that
this
is
actually
a
valid
use
case
to
to
use
this
as
a
sort
of
a
pre-release
channel.
Yes,
we
do
have
dist
tags,
you
can
tag
something
with
or
you
can
publish
something
with
just
tag
equals
next
and
then
install
that
that
pre-release
version
in
order
to
just
sort
of
get
a
user
to
beta
test.
Something
for
you
and
people
do
do
that
today.
B
The
one
of
the
points
of
feedback
that
I've
heard
in
the
in
a
node,
tooling,
group
and
and
in
a
couple
of
other
places
where
we
discuss
these
sorts
of
things,
is
the
problem
that
the
the
thing
that
you
published
with
the
pre-release
disk
tag
when
I
go
okay,
this
one
looks
good
I
want
to
publish
it,
it's
not
the
exact
same
artifact
and
it
never
can
be.
I
have
to
run
another
NPM,
publish
and
I
haven't
verified
that
new
artifact
in
in
context
in
that
environment.
B
So
one
of
the
ways
that
people
get
around
doing
that
is
they
don't
use
a
pre
released
tag
on
the
version
they
just
sort
of
publish
it
with
a
different
disk
tag.
So
it's
you
know,
version
version
200,
but
it's
still,
you
know
tag
equals
next
and
then,
if
there's
a
problem,
I
have
to
bump
the
bumper
patch
a
bunch
of
times.
Also,
if
you're,
if
you're
installing-
and
you
have
a
if
I-
have
a
pre-release
that
I
want
to
do.
Let's
say:
I
have
a
I
have
a
version
200,
that's
on
my
next.
B
This
tag
and
I
have
people
who
have
installed
from
next,
and
now
they
have.
You
know
that
the
version
range
that
they're,
depending
on
is
carrot.
2.0,
there's
no
way
for
me
to
publish
a
pre-release
version
of
201
on
the
even
you
know
in
such
a
way
that
I
can
say
to
a
select
group
of
people.
Hey
pull
this
specific
version
without
also
hitting
everybody
else,
who's
already
on
that
on
that
disk
type
train,
and
this
would
basically
give
them
another
way
to
do
that.
B
It's
pretty
common
to
want
to
publish
a
bunch
of
packages
and
then
sort
of
do
it
almost
as
a
transactional
sort
of
meta,
publish
right
so
I
have
a
new
version
of
battle.
I
want
to
ship
everything!
That's
in
my
battle,
mono
repo
and
if
anything
fails
to
publish
or
if
there's
any
CI
failures
in
any
of
them.
I
want
to,
like
you
know,
fix
that
before
I
actually
make
it
open
in
public
to
the
world.
B
So
we
can,
we
can
do
that
if
it's,
if
it's
possible
to
install,
then
you
know
you
can
actually
run
your
your
your
pre
released
or
sort
of
staged
versions,
stage
publishes
in
CI
and
and
get
that
level
of
confidence
and
then
know
that
that's
the
exact
same
artifact
that's
being
pushed
out
into
production.
The
third
thing
I
wanted
to
mention
just
I
mean
this
is
not.
B
This
doesn't
really
speak
to
you
know
the
the
goodness
or
badness
of
any
particular
approach,
but
just
like
if
we
want
to
get
this
done
in
a
short
amount
of
time
and
deliver
this
value
in
2020
having
a
part
of
the
packing
mint,
which
is
only
available
to
publishers,
forgets
is
really
going
to
throw
a
monkey
wrench
in
a
lot
of
a
CL
business
logic.
So,
as
of
today,
scoped
packages
will
will
check
your
auth
and
unscoped
packages
never
do
because
they
can't
be
private.
B
So
now
this
would
be
basically
introducing
if
we
said
only,
publishers
can
install
stage
versions
and
you
you
have
to
be
off.
Okay.
Now
my
CI.
That's
doing
this,
that's
doing
the
the
checkout
and
test
of
my
my
meta
publish
has
to
be
off
which,
okay,
we
can
that's,
that's,
probably
reasonable,
you're
making
changes
anyway,
but
on
the
server
side.
Now
that
means
we
have
to
be
checking
off
for
any
URLs
that
look
like
a
that
looked
like
it
might
be
from
staging
and
I.
B
Don't
know,
I
I'm,
not
convinced
that
this
is
actually
any
kind
of
security
issue
and
I'm,
not
convinced
that
it's
even
a
developer
experience
issue
if
staged
versions
are
are
just
you
know
radically
be
prioritized
right
if
we
just
say
like
a,
you
have
to
opt
in
and
be
you're
only
going
to
get
that
version.
If
there's
no
published
version
that
matches
the
December
range
you've
given
it,
and
given
that
you
know
effectively,
the
only
way
that
you
can
get
a
staged
version
is
like
to
explicitly
say:
this
is
the
one.
B
The
the
third
thing
or
the
last
thing
is
the
package
lock
and,
and
this
one
I'm
I
feel
pretty
strongly
that
if
you
install
something
it
should
go
in
your
package
lock
like
the
resolved
value,
should
be
that
URL
and
that
URL
should
be
something
that
we
can
allow
you
to
put
in
your
package.
I
mean
effectively.
What
you'd
be
saying
is
if
I
do
install
include
staged,
then
I'm
also
doing
no
safe
right,
like
yeah.
A
So
just
be
mindful
of
time
and
I
wanted
time
box
this
for
another
five
minutes:
Emilia
has
had
the
hand
up
for
a
while
same
with
Jordan
and
then
Tom
I
think
is,
after
that,
so
so
just
time
box
this
for
another
five
minutes
as
I
know,
there
was
a
at
least
two
other
key
points
when
I
get
to
you
in
this
call
today
so
I
mean
I
feel
free
to
go.
Okay.
J
When
which
was
essentially,
if
you
have
a
some
sort
of
silica
dependency
in
your
lono
package
graph,
then
you
would
get
install
errors.
No,
you
would
get
published
errors
because
you'd
be
publishing
a
package
that
depends
on
another
package
which
depends
on
yourself
which
isn't
currently
published,
or
some
combination
thereof,
and
the
way
that
we
ended
up
fixing
this
was
to
actually
sort
of
abuse
disk
tags,
so
it
might
be
worth
bringing
in
the
maintainer
of
learner
for
this
particular
RFC
and
raising
it
to
them.
M
So
a
few
things
the
you
were
talking
about
the
use
case
of
like
testing
all
the
things
together
and
publishing
as
a
transaction
staging
works
for
that,
whether
you
can
install
them
or
not.
The
use
case,
for
that
is
people
installing,
through
a
mono
repo,
they're
publishing
from
the
same
straw.
So
they
don't
need
to
publish
one
and
then
test
against
that
and
then
post
the
next
one
it
tests
against
that
the
CI
test
before
anything
is
staged
or
published,
gives
the
is
a
hundred
percent
of
what
they
need.
M
All
they
need
at
that
point
is
to
make
sure
that
all
the
publishers
work
and
they
may
have
separate,
build
jobs
that
test
each
individual
package,
but
like
the
way
they're
already
do
it.
The
only
way
you
can
test
things
in
a
mono
repo
is
by
doing
linking
in,
like
you
know,
solving
that
NCI
unrelated
to
publishing,
so
anyone
who's
got
a
monitor
if
it's
already
fixed.
M
That
and
like
the
only
thing
that
that
totally
makes
sense
here
is
that
they
want
like
to
publish
five
packages
or
zero
like
a
transaction
of
packages,
but
that
doesn't
require
install
ability,
and
then
it's
to
your
point,
if
you
can
install
it,
you
can
save
it.
That
seems
reasonable.
I!
Don't
have
a
contradiction
to
that,
but,
like
I
also,
don't
think
that
these
should
be
installable.
I.
M
Think
that,
like
you,
said
earlier
about
the
you
know,
if
you
want
to
tell
certain
people
to
be
able
to
publish
things
without
having
it
exposed
to
the
people
on
a
certain
distant
is
tags
available.
Just
make
a
new
one.
Next
to
next
fifty-eight
like
I,
think
that's
fine,
so
I
just
I
really
think
it's
important
that
staged
things
not
be
installable.
I
The
way
I'm
looking
at
it
right
now
is
that,
if,
in
the
initial
version
of
the
staging
area,
things
that
are
not
an
installable
does
get
the
feature
of
TFA
out,
and
that
is
a
super
major
benefit
to
me
personally,
whether
it
stays
install
boom
or
not
installable
after
it's
out,
I
don't
have
a
strong
opinion,
but
something
just
that
I
am
thinking
about.
Is
that
as
soon
as
it
is
out,
people
are
going
to
ask
to
make
it
insoluble,
and
there
will
be
two
primary
reasons
for
that.
I
I
So
a
lot
of
people
have
learned
to
work
around
that,
but
in
terms
of
how
easy
it
is
to
use
the
feature,
I
think
the
staging
area
would
kill
both
of
these
things,
because
it
would
be
so
much
easier
to
work
with
so
yeah.
That's
that
so,
like
I
said,
if
we,
if
the
initial
release
allows
you
to
stage
things
but
does
not
allow
you
to
install
them,
I
would
be
very,
very
happy
and
then
whatever
happens
next,
we
can.
We
can
maybe
debate
later
as
well.
Yeah.
A
So
just
mean
mindful
that
we
are
at
time
here
and
I
know
that
when
we
originally
talked
about
this,
we
want
to
flush
out
in
the
RFC
all
the
use
case,
which
may
help
with
the
discussion
and
driving
like
the
intended
outcomes
of
this
RC,
which
I
think
needs
to
get
picked
up
in
champion
by
somebody
I
think
internally.
Here
as
Daniel,
it's
actually
no
longer
with
us,
but
icicle
I'll,
give
you
a
chance
to
rebuttal
and
I
think
we
should
move
on
yeah.
B
You
know
deterministic
and
reliable,
workflows
well
and
then,
let's
just
like
set
up
the
heuristics
so
that
that
isn't
a
thing.
So
the
bad
thing
doesn't
happen
right,
like
that's,
that's
actually
totally
feasible
without
going
the
the
hard
step
of
saying
that
it's
just
not
installable,
which
is
also
technically
more
challenging.
A
Okay,
I
think,
like
there's
a
lot
of
conversation
to
be
left
said
in
that
top
like
in
this
RC
again.
I
think
the
use
cases
that
we're
all
trying
to
solve
for
needs
to
be
really
flushed
out
so
that
we
can
properly
identify
whether
or
not
the
solutions
gonna
solve
for
that
and
then
also
potentially
will
trim
down.
A
J
So
the
idea
behind
the
standardize,
browser-based
login
mechanism
is
NPM,
does
already
feature
a
standardized,
browser-based
login
mechanism,
accepting
it's
in
MPM
and
enterprise.
Only
the
reason
why
this
is
important
in
a
nutshell,
is
it
what
we're
looking
for?
Is
a
standardization
around
this
floor
so
rather
than
entering
your
password
into
the
CLI
you're,
actually
directed
as
a
developer
into
the
browser
to
login,
which
enables
better
security
over
all?
J
This
then
ties
into
private
registries
so,
for
instance,
vidiseo
and
artifactory,
where,
if
you're
look,
if
your
private
registry
is
set
up
with
say,
get
lab,
authentication
or
google
cloud
or
whatever
it
might
be,
then,
in
order
to
do
Roth
with
those
you
need
a
browser-based
flow,
you
can't
really
do
it
through
predefined
tokens.
It's
a
horrible
user
experience.
J
D
Go
I'm
all
for
this
idea
is
I
just
wanted
to
throw
a
little
support.
This
I
think
we
have
a
few
internal
dependencies
that
manage
this
inside
CLI
in
terms
of
like
the
code
paths
to
get
to
this
particular
behavior,
and
it
would
be
really
nice
if
we
were
able
to
get
to
London
champion
them
in
v7
I
think
they
would
be
perfect.
A
F
I
talk
just
before
I
definitely
want
there
to
be
a
flow
I
think
that
was
about
to
get
into
the
details
of
what
that
flow
looks
like
and
I
wanted
to
post
a
link
which
I
just
got
like
10
minutes
before
this,
but
there
is
a
ooofff
spec
for
browser-based
applications,
which
I
think
might
be
pretty
applicable
to
those
details.
We
might
want
to
look
at
this
as
opposed
to
the
more
traditional
oil
flows
which
require
you
to
have
a
client
secret
that
you
actually
protect.
F
One
of
the
sort
of
maybe
bigger
flaws
in
the
current
way
is
that
you
can't
protect
your
token
from
other
npm
installs
operating
on
the
same
machine
right
like
today,
as
if
it's
in
your
npm
RC.
If
you
are
doing
that,
that
way,
any
post
install
script
can
just
scrape
it
right.
I
think
if
I'm
correct
this
flow
would
help
us
not
have
those
same
problems.
B
So
if
you
I'll
take
a
look
at
this,
but
and
that
may
shed
some
light
on
some
of
the
questions
I
had
raised,
but
I
think
any
I
mean
here's
the
thing
like
if,
if
the
bad
guy
is
on
your
computer,
it's
not
your
computer
anymore
right
like
if
you
have
a
token
anywhere.
If
you
have
a
secret
anywhere
that
allows
you
to
do
anything
without
like
prompting
you
for
a
password
each
time
or
what
have
you
then
that's
a
thing
that
can
be
scraped
and
abused,
and
you
know
perfect.
Security
is
impossible.
B
We
raise
the
bar
whatever
whatever
so
so.
It
may
be
that
we
can
make
things
a
little
bit
hard
more
hardened
and
the
device
flow.
The
oauth2
device
blow
was
appears
to
be
actually
very
similar
to
the
web
flow
that
we
have
in
place
with
the
with
some,
like
you
know,
very
sort
of
surface
level,
details
about
like
which
URL
you
post
to
and
which
you
are
all
you
you
get
to
get
the
response.
I
think
we
made
our
web
off
the
way
we
spected.
B
J
J
To
open
in
a
browser,
so
it
gives
you
a
the
response,
gives
you
a
verification
you're
out
to
open,
but
when
you're
actually
doing
the
initialization,
the
very
first
step,
the
client
ID
as
far
as
I
know,
is
the
euro
to
pull
one
or
it's
the
device
code
in
the
response?
It's
the
thing
to
pull
one
right
right,
so
yeah.
B
J
B
The
it
does
imply
some
changes
in
the
implementation,
though,
and
there's
already
got
to
be
some
pretty
significant
changes
to
port
the
our
existing
web
flow
into
the
Public
Registry
from
from
how
it
lives
in
NK,
Marcy,
Erna
and
Kimmy.
So
I
like
this
I,
don't
see
anything.
That's
like
a
major
blocker
I
think
they're
just
kind
of
some
open
questions
that
we
need
to
get
answered
and
though
they
seem
entirely
interval.
B
It's
still
gonna
end
up
with
a
situation
where
you
have
an
access
token
that
goes
in
an
MP,
MRC
file
right
and
like
that.
So
from
a
from
a
security
point
of
view,
it's
better
than
having
a
user
enter
a
password
because
there's
other
things
that
we
can
do
at
login
time
and
if
we
have
a
refresh
token
and
there's
a
there's,
a
shorter
expiration
on
the
actual
access
token.
Maybe
there's
some
additional
step.
We
can
prompt
the
user
for
when
it
when
it
expires.
B
J
I
think
the
benefit
of
having
the
Refresh
token
is
that
then
there's
actually
some
logging,
server-side
saying.
Oh,
the
user
has
attempted
to
do
this.
We've
refreshed
token
such
that
if
you
get
a
man-in-the-middle
attack
on
your
network
and
your
access
token
is
stolen.
That
way,
then
the
access
token
only
lives
for
a
small
amount
of
time.
It's
not
so
much
about
if
your
computer
gets
are
hacked.
B
I
see
so
they
would
so
they
would
steal
the
let's
say:
steal
the
access
token,
but
not
the
Refresh
token,
and
if
they
did
steal
both
we
could.
Even
you
know
every
time
you
refresh
you
get
a
new
refresh
token.
So
then,
if
you
try
to
then
refresh
it
will
fail.
Yeah,
yeah,
okay,
there's
some
benefits
there,
there's
just
just
some
typing
to
do.
You
know
some
small
small,
simple
questions
to
answer
and
then
some
typing,
the
server
side
is
going
to
be
the
harder
part
yeah.
J
J
A
So,
just
to
be
mindful
of
time,
we
have
got
three
minutes
left.
I
know
that
these
two
specifically
this
is
why
I
put
them
together
in
93
and
71
verified
account
linking
essentially
go
together,
and
there
hasn't
been
much
conversation
beyond
immunity.
As
common
there.
I
want
to
put
number
506
bug
number
506.
A
A
Identifying
packages
or
putting
packages
and
in
the
case
of
what
seems
to
be
community
feedback
to
how
we're
placing
blame,
if
maybe,
is
an
action
item
you
can
just
respond
there.
That
would
be
enough,
I,
think
and
just
before,
since
we
only
have
a
couple
minutes
left
I
did
want
to
get
to
PR
number
103,
which
was
recently
opened
by
a
boy
in
terms
of
workspaces.
He's
been
doing.
A
Work
with
community
has
poked
some
folks
that
are
on
this
call,
as
well
as
folks
from
Lerna
and
yarn
around
the
work
that
we're
curing
up
for
to
support
workspaces
in
MPM.
So
Roy,
you
might
I'll
give
you
the
last
minute
here
so
just
at
least
propose
this
and
I
know
that
we
won't
have
much
time
to
talk
about
it,
but
we
can
a
sink,
have
conversations
for
sure.
Yeah.
C
Is
basically
a
better
way,
a
better
workflow
to
work,
manage
multiple
package
write
that
tend
to
work
together.
So
basically
that's
what
we're
trying
to
propose
three
three
main
implementations,
basically
being
able
to
support
the
configuration.
This
is
already
there
so
mostly
in
able
to
support
workspace
definition
that
yarn
set
up
already
in
order
to
be
aware
for
any
p.m.
the
CLI
to
be
aware
of
a
workspaces,
then
being
able
to
install
it
right.
C
So
we
want
to
be
space
efficient,
so
use
most
of
the
things
we'll
try
to
hoist
the
top
and
we're
gonna
link
all
the
packages
that
are
siblings.
In
that
workspace.
All
the
sub
packages
that
are
already
there
are
Boris
will
be
aware
of
them
and
we'll
just
link
them
around
and
things
that
are
used
like
period
apps.
They
get
hoisted
in
negatively
into
child
workspaces
and
last
is
being
able
to
run
multiple
commands.
A
Awesome,
that's
a
good
summary
in
one
minute.
Well,
because
we're
at
time
I
appreciate
everybody
jumping
on
today.
Apologize
we
got
kicked
off
late,
but
just
won't
be
mindful
that
we
are
at
the
hour
and
want
to
encourage
everybody
to
come
back
out
in
two
weeks
from
now
and
continue
to
have
conversations
and
propose
things
to
us.
Westby
of
one
found
that's
business
yeah
so.
F
L
A
Ya,
we're
not
we're
not
getting
through
the
backlog
is
what
you're
saying.
Okay
all
I'll
propose
in
new
thread
on
the
RFC's
project,
a
new
issue
and
pull
for
the
time
and
day
and
we'll
try
to
queue
this
up
to
be
a
weekly
meaning
for
sure.
I
agree
we're
not
getting
through
the
backlog
for
sure
so
and
if
folks
are
finding
this
useful,
then
that's
actually
really
exciting.
For
us
on
our
end
and
I
appreciate
that
so
yeah.