►
From YouTube: Open RFC Meeting - Wednesday, February 10th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Awesome
and
we're
live
on
youtube.
Thank
you.
Everyone
for
joining
again
an
open,
rfc,
npm,
open
rc
call.
Today's
date
is
wednesday
february
10th
2021.
for
the
folks
that
joined
a
little
late,
I'll,
just
copy
and
paste.
The
meeting
notes
doc
in
chat,
feel
free
to
add
yourselves
to
the
attendees
list.
A
A
A
Nope,
if
not
just
I-
I
guess
a
quick
reminder-
mpm7
went
ga
last
week
and
we
just
want
to
encourage
everybody
to
continue
to
use
that
give
us
feedback
as
we
continue
to
make
releases
happen
each
week
and
improve
you
know
the
features
and
functionality
of
npm.
A
We
have
a
very
short
agenda
today,
there's
only
three
items:
I'm
guessing.
The
last
item
will
essentially
just
be
a
quick
update
in
terms
of
the
workspaces
work
and
and
sort
of
you
know
us
kicking
that
off
improvements
to
workspaces,
since
we
had
a
pretty
good
discussion
about
it
last
week.
So
if
there's
nothing
else
from
folks,
I
want
to
dive
right
in.
The
first
item
is
pr
317?
A
A
I
saw
that
jordan,
you
had
commented,
I'm
not
sure
if
other
folks
have
had
a
chance
to
read
this
rc,
yet
essentially
publishing
setting
and
tagging
accordingly
to
december
version.
B
We
do
this,
I
do
this,
I
just
do
it
out
of
band
from
npm,
so
I
think
it's
generally
a
good
idea.
I
think
there's
some
caveats
here
which
make
building
it
into
npm
more
complicated
than
is
laid
out
in
this.
B
So
if
your
go,
if
the
goal
is
to
replace
the
behavior
that
people
are
doing
out
of
band,
if
the
goal
is
not
to
do
that
and
just
to
have
this
be
sort
of
a
basic
baseline
feature,
then
then
a
big
thumbs
up,
but
I,
but
I
know
like
we
have
a
bunch
of
logic
like
it-
includes
the
the
build
number
in
that
or
it
includes
the
get
hash
in
that
right,
and
so,
if
you
start
trying
to
layer
on
this
functionality,
on
top
of
pre-existing
common
workflows,
you'll
end
up
with
a
dis
tag
that
is
gibberish
right,
like
imagine
if
the
disc
tag
was
feature
dash,
foo
dash,
123-acdfg
right,
because
it
because
you
had
already
previously
configured
your
your
build
to
to
do
that
right,
so
those
disc
tags
get
get
really
wild.
B
They
also,
incidentally,
blow
up
your
your
pacument
over
time.
So
this
is
a
problem.
I'm
hoping
to
find
a
solution
for
at
some
point
as
well.
Since
I
said
I
am
doing
this.
B
But
right
now
it's
not
super
apparent
other
than
if
you
like
you
go
and
clean
them
up,
but
you
don't
know
who's
consuming
them.
So
you
have
to
be
very
careful
about
cleaning
them
up
and
like
there's
just
a
bunch
of
complexity
there
that
sort
of
explodes
as
soon
as
you,
if
you
were
to
start
doing
this
for
every
package
everywhere.
A
Awesome,
I'm
not
sure
roy
if
you
can
help
with
notes
or
somebody
else
as
well.
I
can
also
try
to
take
notes
as
we
go
along
here.
I
see
jordan
and
I
think
isaac
had
their
hands
up
first.
I.
D
Yeah,
so
my
my
only
comment
on
this
is,
I
think,
using
december
pre-release
tag
is
not
the
optimal
way
to
do
it,
just
because
pre-release
tags
kind
of
have
their
own
semantics
attached
to
them
as
part
of
december.
D
In
fact,
putting
the
putting
the
dis
tag
name
in
the
version
is
probably
not
great
at
all,
because
at
some
point
you
may
I
may
want
to
publish
something
as
beta
and
then
kind
of
upgrade
it
to
latest
once
it's
gotten
appropriate
testing
and
if
it's
in
the
version
number
now
I
have
to
do
us,
you
know
a
subsequent
publish
what
would
be
really
nice
would,
which
you
know
my
my
own
out
of
band
management
of
dis
tags
is
considerably
less
involved
than
what
west
describes,
but
we
do
have
a
number
of
packages
where
you
know
we
we
our
current.
D
You
know
the
current
latest
publishes
something
like
version
five,
but
then
oh
somebody
finds
a
security
bug
or
just
some
other
breaking.
You
know
thing
that's
broken
with
version
four,
so
I
I
want
to
publish
a
4.0.10,
but
I
don't
want
that
to
clobber
latest.
So
what
I
usually
do
is
I
create
a
get
branch
for
that.
You
know
for
that:
v4,
release,
branch,
update,
package.json
to
add
a
publish
config
with
tag
equals.
You
know
v4
legacy
or
something
and
then
go
ahead
and
publish
it.
D
What
would
be
really
nice
is
a
way
either.
You
know
in
the
in
the
either
config
for
that
project
or
even
in
package
json
to
say
if
this.
If
the
version
matches
this
range,
then
it
should
be
this
published
config
and
if
the
version
matches
that
range
it
should
be
that
other
published
config,
and
then
I
could
just
kind
of
have
one
thing
I
mean
the
tricky
bit
is.
I
still
have
to
go
and
edit
something
in
that
v4
branch
right.
D
Another
way
that
we
could
tackle
this
or
start
looking
at
it
is
to
actually
make
it
a
registry
side
config.
So
at
the
top
level,
pacument
right,
we
add,
like
a
new,
a
new
kind
of
like
you
know,
dis
check
default
thing
so
that
if
you're
publishing
it
and
your
tag
is
latest,
but
the
pacument
says
oh
version,
four
shouldn't
be
latest
version.
Four
should
be,
you
know,
legacy
v4,
then
it
will
swap
the
default.
D
So
those
are
those
are
kind
of
two
different
areas
for
exploration
I
think
might
be
worth
worth
looking
into
and
would
would
still
allow
us
to
kind
of
avoid
having
too
too
much
kind
of
churn
in
in
the
ecosystem
right,
because
we
don't
want
to
make
it
too
easy
to
have
a
zillion
different
disk
tags
like
you,
don't
want
to
use
the
get
sha
as
your
disk
tag.
D
E
And
then
bradley
sure,
okay,
so
the
part
that
the
use
cases
I'm
interested
in
solving
here
and
I'm-
I
actually
don't-
have
an
opinion
really
too
much
about
this.
The
way
it's
solved
is
there's
kind
of
two
things
one
is
like.
Isaac
mentioned
back
ports,
so
I
posted
this
package
safe,
published
latest
in
the
chat.
I
use
that
as
in
pre-publish
in
all
my
packages,
so
that
I
don't
have
to
do
per
back
port
changes
and
anytime.
I
then
do
a
back
port.
It
won't.
E
I
would
love
it
if
npm
had
this,
either
by
default
or
via
npmrc,
so
that
I
then
could
obsolete
my
package,
but
essentially
like
I,
even
an
opt-in
way
to
avoid
this
sort
of
accident
would
be
great
because
it
would
be
really
nice
to
have
fewer
foot
guns
so
that
authors
were
more
willing
to
backport
vulnerability
and
bug
fixes
and
things
like
that,
whereas
right
now
it's
sort
of
a
pain.
The
other
use
case
is
just
forgetting
the
tag.
E
So,
for
example,
I
have
packages
where
I
have
pre-releases
of
the
next
miner,
and
I
don't.
I
have
to
remember
now
to
explicitly
specify
the
tag
when
I
publish
them
so
that
they're
there
later
so
it's
not
actually
like
wrong
to
publish
them
as
latest,
but
I'm
not
ready
for
that
yet.
So
I
have
to
remember
to
do
that
and
separately.
Even
npm
has
at
times
forgotten
to
update
the
long
list
of
disk
tags
that
a
new
npm
version
should
update,
and
presumably
npm
would
like
to
automate
that
in
some
way
as
well.
E
So
something
registry,
science
sort
of
doesn't
excite
me
because
that's
outside
of
git
and
isn't
equally
portable
to
third-party
registries
and
so
on,
but
package.json
can
fix.
Config
seems
fine.
I
think
the
main
challenge
of
using
assembler
range
is
that
there,
I
don't
believe,
there's
an
easy
way
to
say
target
all
pre-releases
that
are
in
the
next
channel,
no
matter
what
the
preceding
version
is
like,
I
think
you
can
target
version,
one
dot.
E
You
know
next,
but
I
don't
think
you
can
target
every
next
ever
so
like
it
might
be
more
complicated
to
figure
out,
but
that's
sort
of
my
use
cases
I
would
like,
like
any
pre-release.
I
would
like
to
be
put
under
the
next
tag,
let's
say
or
of
any
version
ever
and
I
want
that
to
be
automatic,
and
then
I
would
love
another
thing
that
says
if
this
is
older
than
the
latest
version,
please
automatically.
E
You
know
either
pick
another
tag
or,
alternatively,
error
out
and
force
me
to
specify
a
tag
right,
which
is
what
safe
published
latest
does,
and
the
combination
of
those
two
features
would
satisfy
all
my
use
cases.
Somehow
that's
my
best.
Thank
you.
C
Sure
we
might
be
a
little
unique
in
this
scenario.
I'm
gonna
link
something
in
the
chat.
We
have
an
entire
build
system
based
on
disk
tags,
and
so
this
is
managed
out
of
band
using
kind
of
a
custom
set
of
stuff
that
acts
like
an
npm
registry
and
intercepts
things.
C
C
If
the
tags
are
hard
coded
into
a
package,
that's
gonna
get
very
awkward
for
us
because
we're
maybe
using
this
differently
than
most
people,
but
putting
the
environment
basically
into
the
version,
isn't
going
to
work
well
for
us.
We
we
don't
want
to
be
mixing
the
environments
when
we're
you
know
pushing
something
out
to
the
build
system.
A
Isaac,
I
see,
you
still
have
your
hands
up.
Did
you
remember
the
other
comment
you
wanted
me.
C
E
C
E
And
like
would
really
get
messed
up
if
it
made
tags
by
default,
but
I
do
believe
that
there's
some
things
some
behaviors
that
could
be
done
by
default.
That
would
be
more
restrictive
than
just
blindly
publishing
things
as
latest
like
it
does
now,
meaning
by
default.
It
could
error
out,
like
I
said
and
say
this
is
a
pre-release.
Are
you
sure
you
want
it
to
be
latest?
E
Do
you
know
do
this?
If
you
really
want
it
and
then
separately
or
like,
in
addition
to
like
either
as
a
follow-on
or
in
parallel,
yeah
and
like
you
could
do
prompts
and
like
then
like?
If
it's
not
a
cty
error
out
or
something
something
like
that,
but
but
the
the
other
feature
that
you
could
have
that
would
complement.
E
This
is
some
sort
of
config,
whether
it's
in
package,
json
or
npmrc,
you
know
probably
npm
config
is
nice,
because
then
it
can
be
done
with
environment
variables,
which
probably
fits
in
better
I'm
guessing
into
western
bradley's
use
cases
than
per
package
config,
because
it's
more
kind
of
controlled
by
the
infra
team,
but
but
either
way
something
that
then
says
instead
of
erroring
out
when
it
matches
these
criteria,
do
use
this
disk
tag
automatically
and
then
the
default
behavior
is
the
safe
thing
which
is
like
you
know.
Here
you
go.
E
Here's
an
extra
step
hit,
say
yes
or
rerun
with
this
flag.
If
you
really
want
it
to
to
be
latest
you're
good
and
then
like
you
can
configure
it
to
avoid
that
friction
to
match
your
exact
behavior,
like
that
seems
like
a
nice
middle
ground
here
that
enables
the
behavior
without
screwing,
over
existing
use
cases
and
also
without
with
it,
closes
up
a
little
bit.
The
existing
foot
gun.
B
Wes
yeah
I
like
that
big
fan.
I've
definitely
published
many
a
pre-release
on
latest
and
then
had
to
go,
follow
up
a
quick
release,
so
big
fan
of
that
specific
change,
configuring
it
sounds
good
if
we
could
do
that,
it
would
probably
still
be
usable
in
my
case.
Even
if
I
wanted
to
provide
some
more
custom
logic
right,
I
would
configure
yeah
if
it's
an
environment
variable
fine.
B
A
Yeah,
so
you
know,
jordan
said
it.
I
also
commented
just
in
chat
that
we
have
accepted
rfc
for
published
prompts
which
we
still
need
to
implement,
which
again
might
might
help
in
in
this
regard,
a
little
bit
if
those
were
like
configurable
in
some
way
as
well.
A
B
Multiple
disc
tags
with
one
publish
would
be
also
awesome,
so
some
mechanism
to
say
I
want
to
publish
this
under
these
three
disk
tags
would
be
helpful
to
my
use
case.
I
have
to
do
it
out
of
band
I'm
doing
it
out
of
band.
It's
not
doing
it
yet,
but
the
tool
I'm
working
on
will
be
doing
it
out
of
band
where
it'll
just
send
separate
commands
after
the
publish
to
add
the
secondary
and
tertiary
disk
tags.
A
Yeah,
so
we
send
multiple
after
publish
we'll,
essentially
update
multiple
disk
text,
but
you
can
do
that
in
a
single
npm
disk
tag
update
with
multiple
disk
tags
that
you're
updating.
So
it's
it
is
a
two-line
as
far
as
I
know
today.
I'm
not
sure
if
tag
supports
multiple
today,
if
it
doesn't
that's
potentially.
D
It
does
not,
and
I
think
actually
npm
just
tag
set.
You
or
npm
just
tag.
Add
you
have
to
you
know,
call
it
multiple
times.
You
can't
add
multiple
disk
tags
at
once.
D
Then
config
set
takes
a
multi,
can
take
multiple
key
value
pairs.
A
So
our
docs
are
wrong,
then,
as
far
as
I
know,
because
we
do
specify
that
you're
able
to
set
a
a
published
version
to
to
multiple
disk
tags
at
once
through
mpm
disk
tags.
B
Don't
say
that
you
can
assign
the
tag,
the
multiple
tags
to
a
single
version,
but
doesn't
specify
whether
it's
doable
with
one
command
or
not,
because
I
feel
like
the
way
I
read
it
when
I
was
looking
at
this
and
and
actually
tried
to
set
multiple
in
one
command.
I
think
my
reading
of
it
was
just
oh,
it
they're
just
commenting
on
how
you
can
structure
this
tags,
not
necessarily
the
specifics
of
that
comment.
Capabilities
of
that
command.
D
Right
right,
okay,
so
I
read
that
wrong.
I
think
I
think
you're
thinking
of
npm
config
set,
which,
as
of
and
conversion
seven,
does
allow
you
to
set
multiple
keys,
multiple
key
value
pairs
at
once
in
one
command
like
if
you
do,
npm
config
set
key
equals
val
key
2
equals
val2
it'll
set
them
both.
A
So
I
think
what
we're
talking
about
sounds
like
a
separate
rvc
yeah.
D
A
But
might
be
something
we
definitely
want,
because
we
would
use
it
ourselves
and
make
make
folks
lives
a
lot
easier.
E
Well,
it
kind
of
I
mean
this
is
speaking
from
the
things
I
want,
but
it
kind
of
sounds
like
we
have
three
rfcs
here:
one
is
publish,
prompts
one
is
making
the
tag
selection
for
latest
safer
by
default,
and
the
other
is
providing
some
sort
of
configuration
for
automatic
tag.
E
Selection
and
all
three
of
those
can
proceed
independently
and
incorporate
the
others
as
they
land,
meaning
anything
that
errors
out
can
become
a
prompt
when
it's
a
tty
and
anything
that
that
errors
out
can
be
overridden
by
a
config,
and
you
know
so
on
and
so
forth.
Does
that
seem
like?
Is
that
just
my
thinking,
or
is
that
other
folks
share
that.
A
I
think
you're
right,
the
most
actionable
is
obviously
the
the
rc
we
already
have
going,
which
is
publish,
prompts,
aren't
going
it's
accepted,
so
we
just
need
to
actually
queue
up
the
work
to
get
that
implemented
and
then
make
it
configurable.
A
I
guess
the
secondary
one
in
terms
of
the
setting
multiple
disk
tags,
I
think,
is
also
extremely
actionable,
like
potentially
queuing
that
up
for
the
registry
folks
to
allow
that
endpoint
to
accept
multiple
takes,
which
I
think
would
also
improve
the
experience
here,
the
last
of
which,
which
I
don't
think
we
have
an
rc
for
that.
This
is,
I
guess,
trying
to
like
improve.
Is
that,
like
the
those
defaults
are
the
automation
of
of
setting
tags
like
the
the?
E
Yeah
I
mean,
I
think,
my
my
the
the
one
pile
that
I
want
about
like
not
naively
publishing
things
to
latest
that
they
probably
don't
want
latest
that
I
think,
should
use
a
published
prompt
once
that's
available.
But
I
also
think
that
in
a
non-tty
or
in
the
absence
of
publish
prompts,
it
would
just
error
out
with
instructions
of
how
to
avoid.
The
error.
E
Right,
like
I
think
published,
prompts,
are
an
progressive
enhancement
that
should
not
be
required
for
any
functionality,
because
it
can't
work
in
a
non-tty
and
so
like
there's,
probably
a
butt
load
of
things
that
could
that
should
use
published
prompts
but
like
that,
don't
need
them
to
function,
and
I
think
the
rest
of
the
things
we've
been
discussing
are
in
that
category.
A
Right
yeah,
I'm
gonna,
have
to
read
through
this
a
little
bit
more
thoroughly
because
I
only
skimmed
this
rc
just
before
the
call,
but
it
sounds
like
you
know,
just
the
time
box.
The
conversation
it
sounds
like
this
is
something
we'll
leave
leave
for
next
week
as
well,
and
try
to
ideate
a
bit
more
feel
free
to
like
add
feedback
here
and
if
we
think
there's
a
separate
rfc
like
jordan.
A
If
you
think,
there's
a
separate
like
capability,
we
could
potentially
consider
or
like
we
should
improve
on
the
rfc
for
publish,
prompts
feel
free
to
queue
that
up
or
or
we
can
work
on
something
together
to
write.
Something.
A
If
not,
we
can
move
on
to
the
second
item
that
we
had
and,
and
probably
what
I
thought
would
take
up
more
time
today
is
essentially
rc
number
or
pull
request,
314,
which
I'll
share
with
folks
here-
and
this
is
the
registry
protocol
rfc,
which
is
spawned
out
of
the
common
thread
or
rfc
issue
that
isaac
put
together
originally
would
love.
If
you
could
maybe
detail.
You
know
this
a
little
bit.
Isaac.
D
D
I
see
there's
a
little
bit
of
there's.
There's
some
feedback
back
and
forth
with
zoltani
mentioned
like
doesn't
see
the
benefits
versus
using
direct
tarball
urls
I
mean
the
benefit,
is
you
can
have
december
range
right.
D
D
I'm
not
sure
what
that
like
moving
it
into
a
separate
field,
really
gets
us,
although
that
is
maybe
another
another
addition
that
we
could
do.
We
could
say
you
know,
there's
you
know.
Basically,
you
can
arbitrarily
set
any
specifier
type.
That's
a
second
rfc!
D
So
yeah
I've
got
some
some
feedback
to
sultan
kochan's
feedback,
but
I
I
think
it's
basically
what
we
discussed.
You
put
registry,
colon,
the
url,
a
hash
sign
and
then
name
and
optionally.
You
know
at
specifier
yeah,
so
it's
a
little
verbose,
but
it's
also
very
explicit
and
we
can
build
kind
of.
We
can
either
build
a
you
know
additional
like
custom
registry
per
package.json
thing
on
top
of
it
or
we
can.
D
A
For
sure,
and-
and
I
think
you
understated-
the
the
benefit
here-
major
benefit
is
the
I
think
december
part
of
this
so
wes,
I
I
don't
know
who
was
first
wesley
bradley
wes.
I
think
I
saw
your
hand
or
bradley
first
either,
but.
C
Bradley,
if
you
have
you
wanna
go
first,
you
can
doesn't
matter
to
me
sure
I'll
just
take
it.
So
I
like
it,
but
I
did
have
a
question,
especially
regarding
a
blog
post
as
of
yesterday,
so
this
would
let
you
specify
which
registry
to
pull
from,
but
is
this
gonna
give
away
for
registries
to
know
where
it's
expected
to
be
pulled
from
in
particular,
I
worry
that
with
this,
you
could
have
the
same
issue
that
you
had
with
this
dependency
confusion.
C
C
D
I
am
not
aware
of
any
npm
registries
that
cascade
into
another
registry,
for
a
thing
that
they
already
have
locally
and
there
may
be
some.
D
E
D
With
this
yeah
well,
it
kind
of
does
it.
It
at
least
gives
you
another
tool
for
mitigating
it.
Now,
on
the
one
hand,
yes,
it
does
leak
more
information
like
now.
Your
package
json,
which
people
are
just
putting
in
their
webpack
bundles
pretty
frequently,
will
include
the
the
url
of
your
internal
registry.
So
you've
given
an
attacker.
You
know
a
target.
You've
said
like
oh,
if
you
can
get
to
this
host
name,
then
you're
going
to
own
us.
D
On
the
other
hand,
you
were
already
telling
them
the
package
names
so
not
really
giving
them
that
much
more.
Assuming
that
internal
hostname
is
locked
down
between
behind
your
firewall
and
what
you've
done
is
you've
made
it
impossible
to
accidentally
fetch
the
the
internal
package
from
the
public
registry.
So
I
think
it
does.
Actually
it's
probably
like.
I
wouldn't
say
it's
a
unmitigated
win,
but
it
is
a
tool.
That's
probably
a
net
benefit
in
the
context
of
that
specific
attack
discussed
yesterday.
D
B
From
here
yeah,
because
so
when,
when
this
was
originally
brought
up,
I
was
already
aware
of
this
particular
behavior
and
in.
D
B
B
It
is
relevant
and
I
think
I
think
you
hit
the
nail
on
the
head
with
it-
prevents
some
other
types
of
confusion,
attacks
which
rely
on
going
to
the
public
registry.
When
the
engineer
thought
they
were
not
so
that's
great
totally,
it
does
not
fully
solve
the
the
particular
blog
post
reference
here
about
the
confusion
attacks
because
those
do
rely
on
registry
proxy
behaviors.
B
Unfortunately,
those
registry
proxy
behaviors
almost
entirely
exhibit
the
problematic
state
we're
in
right
now,
so
my
my
so
again
leaving
off
the
fact
that
this
doesn't
fully
solve
for
that
other
problem.
I
think
that
the
the
big
win
here
is
december
range,
and
I
think
at
that
we
just
we
could
just
call
it
good
as
far
as
leaking
more,
I
think
you
are
correct.
The
the
leak
of
the
name
is
the
key
to
the
the
problem
we
were.
B
If
we
wanted
to
do
something
like
that,
I
think
would
be
very
good
because
you
could
actually
avoid
the
leakage
by
moving
the
aliasing
out
of
the
package.json
and
into
a
config
value,
which
would
mean
you
would
not
be
able
to
install
it
without
those
config
values
set,
because
they,
the
alias,
would
be
ambiguous.
But
it
would
also
mean
that
if
somebody
packaged
up
their
package
json
into
their
webpack
build,
they
wouldn't
leak.
The
url
they'd
only
leak,
the
alias,
which
would
be
sort
of
a
nice
way
around.
B
You
know
that
if
we
thought
that
was
a
real
problem
also
it
would
mean
that
you
don't
have
an
extra
key
in
the
package
jason
if
you
move
the
alias
to
config.
B
So
I
think
if
we
wanted
to
do
the
alias
route,
that
would
be
what
would
get
my
vote,
and
I
feel
that
we
went
through
like
seven
different
topics,
so
I
was
trying
to
make
sure
I
tackle
all
of
my
comments
on
that,
but
I
think
oh
and
then
the
only
other
thing
which
I
think
is
important
to
consider
here
is
these
is
the
what
happens
when
these
are
published?
B
To
the
public
registry,
which
I
I
don't
recall,
seeing
that
tackled
in
the
rfc,
but
if,
if
we
expect
yarn
and
pnpm
to
be
able
to
install
these
because
they're
in
a
public,
you
know
in
the
public
registry
as
part
of
somebody's
tree,
we
need
to
make
sure
we
have
a
clear
answer.
There.
D
Yeah,
so
I
think,
as
far
as
like
what
happens
when
we
publish
them,
it
is
a
downside
right.
You're
gonna
have
something
that
can't
be
installed
with
npm
6
and
before
and
can't
be
installed
with.
You
know,
presumably,
some
versions
of
yarn
and
pnpm,
the
the
flip
side
of
that
is,
and
even
more
importantly,
even
when
you
have
npm
7,
you
can't
install
it
unless
you
have
access
to
that
registry.
D
D
A
Jordan,
I
saw
you,
had
your
hands
up
and
then
bradley.
I
think
you
well
that's.
C
No,
I
think
it's
actually
perfectly
fine,
as
is
it,
doesn't
specify
where
the
thing
actually
lives,
which
is
the
important
bit
and
the
thing
is
potentially
able
to
live
in
subdomains
with
unique
certs.
So
it's
all
good.
A
C
C
I'll
dig
up
it
and
put
it
in
the
zoom
chat,
but
I'm
gonna
have
to
drop
for
another
meeting.
Okay,
I
appreciate
it.
D
We
should
we
could
dig
into
that
for
sure,
but
I
think
the
from
the
point
of
view
of
the
cly,
a
different
sub
domain
and
path
is
a
different
registry
like
entirely.
C
I
think
that's
a
interesting
viewpoint,
necessarily,
but
at
least
for
s3
they
did
it
for
various
reasons
of
having
problems
with
security
on
path.
There
is
a
blog
post.
You
can
kind
of
spider
around
and
find
more
info
from
there.
Okay,
I
gotta
go,
have
fun.
Thank
you.
So
much.
A
B
My
only
point
is
that,
really,
when
this
lands,
if
it
makes
it
its
way
to
a
large
projects
tree
and
breaks
a
lot
of
people,
we
need
to
make
sure
we're
just
really
crisp
crystal
clear
about
the
expectations
of
using
this
and
and
that
it
will
break
installs.
If
you
do
not
have
access
to
to
that
registry
like
and
that's
the
only
part
that
I
think
is
missing
in
this
description.
A
So
could
you
say
that
one
more
time
wes,
I
was
taking
notes
there.
Sorry.
A
B
As
soon
as
this
go
goes
out
and
gets
included
into
a
very
popular,
you
know
dependency
and
breaks
people,
because
they
don't
have
access
to
that
registry.
B
For
whatever
reason
right
that
you
know,
we
need
to
make
sure
that
the
full
documentation
is
there
of
like
use
this
at
your
own
and
your
consumer's
risk,
like
you
know,
being
crystal
clear
about
the
ramifications
of
not
having
access
to
the
registry
or
you
know
having
a
it,
not
work
with
an
npm
six
right
like
those
those
things
are
not
in
the
rfc
and
and
will
be
incredibly
important
with
how
this
gets
messaged
once
it
goes
out.
A
A
A
Any
other
comments
on
that
isaac.
Did
you
want
to
follow
up
to
all
that
feedback.
D
No,
I
think
I
I
just
followed
up
to
the
comments
on
the
rfc
pr
itself
and
I
added
wes's
thing
about
being
crystal
clear
in
the
rc
and
the
docs
that
will
break
on
early
npm
versions
and
anyone
who
doesn't
have
access
to
that
registry.
Awesome.
F
F
A
That's
awesome,
thank
you
for
doing
that
roy
and
reaching
out
to
those
folks,
it's
great
when
pm
pm
and
yarn
maintainers
are
interested
in
this
and
obviously
we're
aligned.
So
that's
that's
great.
I
think
we
should
probably
leave
this
open
for
now
until
maybe
another
week
give
folks
a
little
bit
more
time.
As
you
noted
right,
maybe
mile
will
chime
in
with
some
feedback
as
well
in
the
pr
itself.
But
ideally
you
know
we
can.
A
A
Moving
on
to
the
last
item
that
we
had
on
the
agenda
today
and
then,
if
there's
some
time
left,
we
can
open
up
the
floor
for
other
conversations,
but
the
last
pr
117
or
the
last
rfc,
which
is
the
npm
workspaces
work
which
I
know
has
is,
is
something
that
we
were
speaking
to
last
week
quite
a
bit
and
whether
or
not
we
can
sort
of
like
decouple
the
work
itself
from
discussing
and
sort
of,
even
potentially
changing
the
way
that
workspaces
are
implemented
today.
A
So
I
think
just
for
I
guess,
a
quick
update
from
what
we
discussed
last
week
was
it
sounded
like
we.
We
thought
that
that
work
could
be
decoupled
and
if
there's
any,
underlying
changes
to
how
workspaces
are
actually
implemented,
we
can
actually,
you
know,
might
duplicate
some
work
there,
but
it
sounds
like
we
don't
want
to
stall
on
on
actually
getting
started
with
making
workspaces.
A
The
experience
of
using
workspace
is
better
by
allowing
you
to
run
commands
and
workspaces
today.
I
think
for
the
folks
that
were
there
is
that
a
good
summation
of
what
we
talked
about.
F
Yeah,
I
think
one
good
point.
I
remember
isaac
brought
up
in
one
of
the
last
discussions
on.
It
is
maybe
because,
right
now
in
the
rfc,
it's
still
describing
the
listing
workspace
is
using
a
named
argument,
and
I
know
it
was
floated
around
switching
that
to
a
positional
stat
and
just
so,
I
think,
maybe
maybe
that's
the
only
thing
that
like
can
still
still
open
to
some
discussion,
but
maybe
it's
just
something
we
want
to
tweak
when
we
start
having
a
poc
implementation
to
actually
try
out
so
but
anyways
yeah.
A
Maybe
you
could
explain
that
a
little
bit
or
if
you
can
share
a
reference
to
the
comment.
Well.
F
D
Yeah,
it's
it's.
I
think
my
my
comment
was
it's
actually
easier
to
just
make
it
a
top
level
command
called
workspace
or
ws
or
whatever,
and
then
and
then
we
can
be
a
little
bit
more
like
creative
about
what
goes
underneath
that
command
and
we
don't
have
to
worry
about
situations
where
you
configure
the
w.
A
Yes,
please
yeah
yeah,
let's,
let's
clean
up
the
rfc,
if
there's
points
like
that
that
have
been
made,
I
know
you
know
if
you
can
take
that
as
an
action
item
and
and
get
it
cleaned
up
at
at
least
for
next
week,
if
possible,
that'd
be
great.
D
We
need
we
need
a
thing
where,
like
every
time,
we
add
a
new
config
to
npm,
we
have
to
put
like,
I
was
gonna,
say,
put
a
dollar
in
a
jar.
A
A
Well,
this
is
something
for
people
that
don't
know
we.
We
support
infinite
config
today,
so
I.
E
I
just
have
one
quick
comment
on.
I
saw
isaac's
last
comment
on
the
rfc
about
being
clear
that
it'll
break
older
versions.
Would
it
be
nice
if
npm,
when
it
noticed
that
the
package
json
in
the
current
directory
has
a
registry
specifier?
If
it
also
warned,
if
you
don't
specify
engines.npm.
D
G
D
It
you
got
it
thanks
on
the
workspaces
thing,
I
wanted
to
bring
up
real,
quick,
a
request
for
on
request
for
rfc
jordan.
You
have
mentioned
a
few
times.
D
You
know
kind
of
wanting
to
rethink
the
some
somewhat
rethink
that,
like
semantics
in
the
data
model
of
like
what
is
shared
between
workspaces,
what
is
not
shared,
what
is
isolated,
and
I
think
that
there's
a
really
good
opportunity
here
to
just
like,
like
put
aside
all
implementation
details
and
talk
about
like
okay,
if
I'm
in,
if
I'm
in
this
project,
I
do
require
foo
and
I
get
a
shared
thing,
a
thing
that's
not
shared,
I
think
that's
shared
with
the
root
a
thing
that's
shared
with
only
other
packages
in
the
workspace
you
know
whatever.
D
That
is,
and
I
think,
if
we
can
kind
of
get
that
list
down,
then
that
will
help
us
know
like
what
are
what
are
the
cases
and
then
and
then
design
the
implementation
a
little
bit
more
thoughtfully.
So
we
have
now
is
really
simple,
which
is
great
like
that.
Got
us
out
the
door
super
quick
and
it's
it
was
really
easy
to
implement.
It's
easy
to
reason
about.
You
know
when.
D
Yeah,
which
is
just
like
it,
a
workspace,
is
a
link.
Depth,
basically,
is
how
it
works.
It's
like
an
automated
automatically
glob
based
linked
up.
E
Dependencies
are
shared
without
being
hoisted
by
and
by
hoisted
I
mean
moved
up
to
the
root
and
that's
it
and
then
any
additional
deduplication
that
doesn't
include
hoisting
is
totally
fine
like
npm
can
share
more
stuff
if
it
wants,
as
you
know,
but
I
want
the,
but
but
the
only
things
that
must
be
shared
are
peer,
deps
and
other
workspace
steps
and
the
the
reason
hoisting
needs
to
be
avoided
in
all
cases
is
because
nothing
should
be
able
to
require
something
that
isn't
in
it
or
it's
re
its
parents
package.json
right.
G
Well,
actually,
I
would
even
go
as
far
and
say
that
I
would
want
to
disable
the
like
standard
node
modules,
behavior
of
like
you,
have
something
in
the
root
folder,
which
would
be
like
your
workspace
entry
point
right
and
it
gets
shared
with,
like
all
of
the
child
package
jsons.
G
I
would
like
to
disable
that
for
workspaces,
because
I'm
running
into
a
problem
now
with
webpack
5,
where
we
have
like
webpack
in
every
package
json,
but
we
also
have
it
in
the
road
itself
and
webpack
itself
does,
like
instance,
off,
and
obviously
that's
no
longer
the
same
if
you
like,
if
you're
linking
dependencies.
So
here,
the
traditional
node
module
sharing
becomes
very
much
an
issue.
A
So
sorry,
just
so,
we
can
write
a
note
again
there
christian.
Can
you
rephrase
that
one
more
time.
G
So
think
about,
like
you,
had
a
like
a
packages
folder
with
like
your
different
packages,
in
that
you
would
want
to
have
like
that.
You
would
want
to
have
in
your
workspace,
like
you
would
have
like
one
like
root
level,
where
you
would
have
your
dependencies
right
like
something
like
something
you
would
use
for
for
development
purposes,
only
like
webpack
dev
server,
for
example,
and
now
in
every
repository
or
in
every
package.
G
You
would
have
something
like
build,
so
you
would
also
have
webpack
there,
and
this
breaks
now
because,
like
suddenly
webpack
gets,
is
fetched
from
like
the
root
level
in
cases
where
you
don't
want
it
to
be
fetched.
Just
because,
like
that's
how
no
modular
resolution
works.
G
And
that
is
yeah,
that
is
like
the
current
behavior,
and
that
is
very
nice
if
you
want
a
hoist
right,
but
it
gives
you
very
very
interesting
things
if
people
have
like
checks
in
their
code,
which
are,
like
instance,
off,
because
that
is
what
webpack
just
like
moved
to
in
version
five
and
it's
giving
us
like
all
kinds
of
very
weird
artifacts
in
like
a
linked
environment,
I
can
try,
I
think.
G
Oh
sorry,
we
had
in
like
the
webpack
repository,
so
you
can
follow
up
on
that.
It's
just
a
little
difficult
to
describe
in
words.
Sorry.
E
That's
okay
to
to
me
it's
seeing
what
I'm
hearing
is
that
let's
pretend
pure
dev
dependencies
existed
and
we
had
the
workspace
system.
I've
described
then
you'd
make
webpack
one
of
those
and
webpack
would
just
kind
of
be
shared
when
it
was
the
same
version
between
workspace
projects
and
when
it
would
not
be
hoisted
so
it
wouldn't.
So
you
could
have
some
projects
on
webpack
five
and
some
on
webpack
four,
and
they
would
have
the
same
webpack
five
and
they
would
have
the
same
webpack.
Four.
E
E
I
want
these
dependencies
shared
whenever
possible,
exactly
as
isaac
said
in
chat,
and
you
could
say
then
webpack
share
it
whenever
possible
and
it
would
still-
and
that
would
just
result
in
that
same
behavior.
In
other
words,
it's
kind
of
like
pretend
this
dependency
is
a
workspace
step
and
share
it.
E
D
Yeah,
basically,
I
I'm,
I
there's
a
lot
of
ways
to
solve
this.
I
think
that-
and
this
may
even
be
an
impetus
for
you
know,
moving
to
something
a
bit
more
like
pnpm
like
right.
So
we
just.
We
have
like
a
node
module,
dot,
npm,
slash,
webpack,
slash
5.0.3,
and
that
gets
sim
linked
into
all
the
things
that
are
using
a
webpack
that
can
use
it
and
we
kind
of
like
dedupe
as
much
as
possible,
and
everybody
who
wants
webpack
3
can
get
the
webpack
3
version
that
we
have.
D
We
can
solve
it
with
source
maps.
We
can
solve
it
with
nesting
and
hoisting
things
up
to
oh
sorry,
import
maps,
my
bad
as
well
wes.
We
can
solve
it
with
import
maps.
We
can
solve
it
with
putting
the
just
putting
the
dependencies
in
some
cases
in
the
root
node
modules.
But
the
point
is
like
we
need
a
way
to
say
I
want
webpack
and
I
would
like
it
to
be
shared
among
my
workspace
projects
and
let's
talk
about
like
okay.
D
So
we
have
that
need
what
is
the
best
way
to
express
that
in
package.json,
config,
etc,
and
then
we
can
start
talking
about
okay.
What
does
that
mean
in
terms
of
the
the
layout
on
disk
and
those
are
really
three
orthogonal
questions
right,
like
defining
the
need
to
finding
the
way
to
express
the
need
and
then
defining
the
way
to
meet
the
need.
I
I
And
it
seems
to
me
that
they
that's
unfortunate,
because
it
would
be
nice
to
be
able
to
have
that
as
your
default
and
then,
if
you
do
dash
dash
tag
during
publish
in
your
ci,
it
gets
the
tag.
That's
a
kind
of
a
guard
right
and
just
thinking
forward
about
this,
of
what
an
rfc
could
look
like.
I
We
would
have
to
have
some
extra
config
that
say:
hey
when
I
publish
just
don't
put
a
tag
you
throw
it
in
your
rc
file,
then
your
actual
publish
process
can
turn
that
back
off
on
the
command
line.
Right
because
it'll
take
precedence,
that's
one
part
right,
then
there's
the
multiple
tags
right.
So,
coupled
with
that,
you
can
all
we.
We
also
want
to
say,
dash
dash
tag
in
publish.
I
I
want
to
be
able
to
specify
more
than
one
tag,
also
an
npm
disk
tag,
because
those
are
kind
of
the
same
thing
taking
aside
ignoring
the
prompt
stuff
and
the
safeguards,
because
that
to
me
sounds
like
it's
its
own
thing.
Just
that
does
that
solve
a
few
of
the
problems
y'all
are
having.
If
that
was
one
or
more
rfcs.
E
B
Yeah-
and
I
think
it
solves
most
of
the
things
for
me
too,
I
didn't
even
think
about
the
no
tag
scenario,
but
that
definitely
would
be
a
great
addition
there.
I
just
put
in
the
issue
as
well.
Another
request
that
I
would
love
for
related
disk
tags
is
the
ability
to
save
exact
and
have
it
actually
save
exact,
because,
right
now
it
translates
the
dis
tag
to
the
exact
version
number,
not
the
this
tag
you
specified
on
the
command
line.
B
I
don't
west.
Can
you
repeat
that
I
lost
you
at
some
point:
yeah,
sorry,
I
so
npm
installed
dash
dash,
save
dash
exact,
and
then
you
do
foo
at
next.
B
It
doesn't
result
in
your
package
jason
saying
foo
colon
next.
It
results
in
whatever
the
diss
tag
pointed
to
being
saved
with
an
exact
version.
So
what
you
want
to
a
consumer
is
to
say:
hey,
follow
my
next
dis
tag
so
that
you
get
my
updates
as
they
roll
out.
But
the
only
way
to
do
that
today
is
to
manually
edit
your
package
json.
B
B
D
Well
so
this
is,
this
is
kind
of
tricky,
for
this
is
somewhat
tricky
for
reproducible
build.
I
I
think
we
used
to
save
whatever
the
spec
was
ancient
history
here
used
to
save
the
whatever
the
spec
was.
That
was
provided,
but
changed
at
one
point,
because
then
you
know
you
save
saving
it.
Saving
a
dis
tag
is
pretty
dangerous.
That's
basically
a
greater
than
equals
right
you
you,
then
somebody
publishes
a
breaking
change
on
their
dis
tag
and
everybody's
hose.
This
is
what
we're
seeing
you
know.
D
D
Right
right,
yeah,
changing
changing
our
save
behavior
for
for
dis
tag,
just
text
specified
on
the
command
line
or
or
in
anywhere
else
to
save
the
tag
rather
than
the
resolved
version
is
a
pretty
significant,
behavior
and
semantics
change.
I'm
not
saying
it's
like
good
or
bad,
but
it
is
definitely
significant
and
should
should
get
its
own
careful
analysis.
B
B
I
I
just
it
was
just
a
the
behavior
seemed
unexpected
to
me
just
and
I
was
trying
to
you
know
with
a
better
way
to
do
it.
If
we,
if
we
opted
for
another
flag,
just
to
make
it
easier
to
roll
out,
that's
perfectly
acceptable,
yeah
safe
back
would
be
good
yeah
right.
That.
A
Rfc
awesome
thanks
thanks
for
those
the
top-ups
there
car
so
just
be
mindful
time
we're
about
a
minute
after
so
I
appreciate
folks
staying
a
couple
of
minutes
late
and
want
to
encourage
everybody
to
provide
feedback
and
and
and
keep
pushing
along
these
rc's
and
we'll
have
a
couple
new
ones
in
the
week
or
two
that
I've
kind
of
alluded
to
to
come
that
are
in
the
same
area
in
terms
of
what
we've
been
talking
about
for
a
while
now
in
terms
of
strategies
and
modes
and
those
types
of
things.
A
So
look
out
for
those
in
the
next
couple
weeks
appreciate
everybody
jumping
on
today
again
and
and
hopefully
see
you
next
week,
ciao.