►
From YouTube: Open RFC Meeting - Wednesday, Oct 21st 2020
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
And
we're
live
on
youtube.
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
october
21st
we'll
be
following
along
in
the
agenda
that
was
posted
in.
I
believe
it
was
issue
number
263
and
I'll
spam
chat
as
usual,
with
the
hack,
md
doc
feel
free
to
add
yourselves
to
the
attendees
list.
Roy
are
you
gonna,
be
able
to
help
with
knowledge
notes,
or
I
can
just
as
well.
A
Okay,
I
appreciate
it
so
just
a
quick
announce,
our
acknowledgement
of
these
calls
and
all.
A
All
communication
that
is
sort
of
discussed
and
issues
and
our
rfcs
themselves
are
under
our
code
of
conduct.
Please
be
mindful,
and
as
people
are
speaking
raise
your
hand
if
you'd
like
to
add
something
the
you
know
outline
of
and
the
desired
outcomes
of
these
discussions
is
hopefully
to
move
rfcs
forward
and
to
interact
with
the
community
and
move
together
as
one.
So
we
have
a
small
agenda
apologize
for
it,
just
getting
generated
sort
of
last
minute
here
again
today.
A
Other
than
we've
shipped
another
patch,
or
we
shipped
two
or
three
patches
since
last
week
when
we
shipped
mpm7
so
as
of
yesterday,
I
believe
703
is
available
for
you
to
get.
If
you
want
to
get
it,
it's
in
the
usual
ways:
npm
install
sg
sgmpm7,
and
we
have
some
changelog
notes
in
a
blog
post
we
posted
yesterday.
I
appreciate
roy
and
isaac
jumping
on
and
getting
that
done,
we're
continuing
to
improve
docs
and
patch
up
the
the
things
we're
finding
from
the
feedback
that
we're
getting
from
people
that
are
using
it.
A
So
it's
it's
great
and
appreciate
everybody
filing
bugs
and
giving
us
feedback
any
other
announcements
that
folks
wanted
to.
A
You
know
15
also
went
out
yesterday.
Jordan,
that's
good.
1501
is
landing
today
if
it
hasn't
already
been
queued
up
by
beth,
and
that
should
include,
I
believe,
the
702
release,
so
it
will
already
have
the
couple
patches.
As
far
as
I
know,.
A
A
Awesome-
and
I
know
jordan-
we've
had
a
couple
comments
back
and
forth,
even
just
before
the
call
about
some
some
workflow
stuff
there.
So
we
can
discuss
that
offline
for
sure
so
digging
into
the
the
first
item.
If
there's
no
other
announcements
issue
235
so
mark,
I
appreciate
you
jumping
on
here,
and
maybe
you
can
just
give
us
a
quick
update
of
of
the
status
of
the
allow
alloying
server
generate
header
values,
rfc
that
I
know
you've
been
working.
C
D
Sure,
yeah,
to
be
honest,
it's
been
a
while,
since
we've
actually
raised
this
one,
I
I
think
for
the
last
discussion.
There's
kind
of
this
was
added.
I
I
added
this
rfc
off
the
back
of
the
existing
one,
and
I
think
we
came
to
the
conclusion
last
of
all
that
there
wasn't
really
an
actual
decent
use
case
to
warrant
moving
this
rrc
forward.
D
I
think
at
the
time
I
don't
think
isaacs
was
on
the
call,
as
it
was
on
the
call,
so
whether
he
had
any
input
on
this
or
not
yeah.
I
think
the
idea
was.
We
were
just
going
to
leave
the
pr
open
to
see
if
anybody
else
had
ideas
in
the
future,
rather
than
just
closing
it
out
right.
A
Yeah,
I
think
we
quickly
discussed
this
a
bit
as
well
in
terms
of
the
parsing,
I
think
isaac.
You
noted
something
around.
The
actual
parsing
of
the
header
object,
how
we
could
style
style
that
in
the
command
line.
I.
E
Yeah
yeah
yeah,
so
I
mean
this
is
kind
of
a
this
is
kind
of
a
follow-on,
so
it
feels
a
little
bit
premature
to
dig
too
deep
into
it
or
you
know,
sort
of
get
get
too
hung
up
on
the
finer
points
of
of
how
things
get
expressed
or
how
things
get
saved
in
the
config
file
or
whatever.
The
main
idea
here
is,
though,
assuming
as
I
understand
it,
correct
me
if
I'm
wrong,
assuming
we
have
some
way
of
specifying
arbitrary
headers
in
your
project
and
qmrc
file.
E
Should
we
have
some
way
for
the
server
for
the
registry.
To
say
here
is
a
header.
You
should
send
back
to
me
next
time
and
then
the
client
would
save
it
in
whatever
method
it
uses
to
to
specify
arbitrary
headers.
I
think
that
that's,
I
think
it's
a
good
idea
and
it's
kind
of
like
you
know,
once
we
have
the
first
one,
the
second
one's
relatively
straightforward,
but
yeah
it
does.
E
You
know
the
the
only
use
case
that
I
can
see,
for
it
is
a
server
generated,
app
id,
which
I
think
is
very
valuable.
You
know
the
other,
the
other
kind
of
classic
case,
which
maybe
we
you
know
could
just
be
an
entire
alternative.
Up
to
this,
to
this
whole
idea
is
a
cookie
jar
right.
That's
kind
of
the
classic
case
of
a
server
says:
here's
a
here's,
a
goober.
E
You
should
send
back
to
me
right
and
then
the
browser
sends
that
goober
back
to
the
server
every
time
it
makes
a
request,
and
so
it
feels
like
we
might
be
sort
of
reinventing
cookies
to
some
extent,
in
which
case
we
may
want
to
just
say
why?
Don't
we
just
use
cookies.
F
G
Should
because
we
could
have
like
sex
while
isaac
was
saying
that
I
actually
just
posted
a
comment
on
that
rfc.
It
is
like
cookies
and
that
actually
raises
all
the
privacy
concerns
that
cookies
do
and
gdpr
concerns,
and
so
on
and
so
forth.
So
that
may
be
something
that
warrants
more
discussion.
E
Yeah
I
mean,
at
the
the
other
hand,
on
the
other
hand
like
so
the
the
advantage
of
doing
it
using
cookies
is
that
we
can
kind
of
like
piggyback
on
all
of
that
prior
work.
Right,
we
can
say,
like
look.
Dude,
you
know
is
as
much
as
there
are
privacy
concerns
and
gdpr
concerns
like
there's
also
gdpr,
which
has
very
you
know,
specific
guidelines
on
like
how
you're
supposed
to
handle
that
stuff-
and
you
know,
proxies
all
kind
of
have
some
way
of
handling
cookies
and
and
so
on
and
so
forth.
E
There's
there's
kind
of
like
clearly
paved
semantics,
although
we
could
probably
design
something
more
elegant,
we
are
sort
of
starting
from
from
square
one
and
just
sort
of
aping.
What
web
browsers
do
might
be
a
little
bit
more.
A
So
in
terms
of
the
just
to
follow
up
on
that,
and
can
we
either
close
or
do
we
want
to
keep
open?
I
guess
for
now
and
remove
the
agenda
label
for
the
allow
server
generated
header
values,
which
is
like
the
follow-up
and
was
originally
ordered
before
this
yeah.
E
I
think
just
remove
the
remove
the
agenda
and
and
leave
it
open
and
maybe
make
a
note
that,
like
you
know
until
we,
you
know
two
basically
two
options.
One
is
like:
do
we
just
implement
cookies
in
a
cookie
jar
and
two
you
know
it
really
needs
to.
If,
if
not,
if
it's
not
just
implementing
cookies,
then
it
kind
of
needs
to
follow
up
on
1,
38.,
right,
yeah,
138.
A
Yeah
yeah,
so
that's
I've
now
reordered
it
so
138.
D
Well,
that
that
was
sort
of
mine
as
well.
Obviously,
so
I
can
do
a
refresh.
C
D
So
yeah,
so
the
original
idea
was
that
we
were
putting
trying
to
put
application
ids
into
the
package
json
files
somewhere
through
this
discussion.
It
was
realized.
It
would
be
a
better
place
to
put
into
either
a
local
mpm
rc
or
even
the
you
know,
the
global
npm
rc.
That's
the
way
the
rfc
is
now
being
written,
but
it
just
so
happened.
A
couple
of
weeks
got
to
start
to
actually
look
at
how
easy
it
would
be
to
actually
implement
this.
D
Given
that
I
think
the
last
we
discussed,
it
was
kind
of
almost
going
to
be
a.
You
know,
move
this
rfc
forward
and
it
turns
out
we've
it's
kind
of
already.
Does
it
in
the
existing
mpm
client
slightly
hacky,
in
that
what
goes
across
on
the
headers
on
the
wire
is
not
quite
as
we
would
want.
So
it's
not
very
pretty,
but
nevertheless
you
can
specify
a
headers
in
the
mpmrc
and
sure
enough
that
you
know
that
data
goes
across
the
wire.
D
E
Yeah,
so
my
my
suggestion
that
we
specify
it
as
an
array
of
strings
would
actually
be
not
ideal,
and
that's
what
I
see
currently
in
this
rfc
if
we
wanted
it
to
be
backwards,
compatible
with
npm
six,
so
we're
currently
like
in
npm
7.
E
We
changed
some
of
the
ways
that
we
handle
configs
in
order
to
make
it
a
little
bit
easier
to
reason
about
just
when
kind
of
managing
our
our
our
code
and
and
also
to
prevent
these
cases
where
you
have
a
config,
that's
being
respected
by
something
deep
in
the
stack
like
make
fetch
happen
and
if
it
gets
specified
at
the
npm
level
like,
even
though
we
don't
have
any
code,
that's
really
aware
of
it.
It
just
gets
passed
through
kind
of
blindly.
E
E
Now
we
are
in
npm
seven
simply
because
we
didn't
know
about
it.
We
we
don't
do
that
with
the
headers
config,
but
that
doesn't
stop
you
from
specifying
a
header
section
in
your
npmrc
file
and
putting
key
value
pairs
in
there
and
it'll
just
work
in
npm,
six
and
npm
seven.
It
won't,
but
we
could
just
put
that
in
the
config
object
like
there's,
there's
nothing
stopping
us
from
doing
that.
Really.
E
The
way
that
it
would
have
to
be
specified
is
or
ideally
be
specified
as
not
as
an
array,
but
as
a
as
actually
a
key
value
object,
which
again
is
not
necessarily
ideal.
E
I
don't
think
I
think
you
can
make
each
of
the
each
of
the
different
header
values
an
array
so
there's
ways
to
do
that.
We
we
could
have
like
multiple
values
for
for
headers
that
allow
multiple
values
so
yeah,
like,
I
think,
actually
passing
arbitrary
values
in
the
headers
like
from
your
config.
We
could
totally
do
and
we
could
do
in
a
way
that
sort
of
works
by
accident
in
npm6,
but
we
have
no
plans
to
break
it.
So
it'll
just
keep
on
working.
E
No,
I
mean
well,
it
would
just
keep
working
the
same
way
that
it
currently
would
in
v6
right
now,
you
would
be
passing
like
if
you,
if
you
specify
it
the
wage.
The
way
I
originally
proposed,
which
I
I've
since
come
to
realize,
is
a
bad
idea,
but
if
you
did
specify
it
that
way,
with
headers
being
an
array
of
strings,
you
will
get
a
header
with
a
key
of
zero
and
the
string
of
some
key
value
and
then
another
your
next
header
will
have
a
key
of
one
and
some
key
value.
E
E
So
so,
if
you
specify
it
in
the
other
way
that
I
proposed,
where
you
have
headers
as
a
brace
square
brace
section
and
then
underneath
that
you
have
key
value
key
value
value,
then
that
should
also
work
the
same
in
v6
and
v7.
E
Once
you
know,
once
we
kind
of
add
headers
to
the
list
of
included
config
values.
E
D
E
Okay,
I
mean
it
would
have
to
be
at
the
after
everything.
That's
at
the
top
level,
just
by
the
nature
of
how
ini
file
files
work.
E
But
yeah,
I
think
it's,
I
think
it's
worth
kind
of
blessing
and
saying
this
is
how
you
specify
arbitrary
headers,
and
then
we
just
move
it
straight
on
into
implemented.
Once
we
get
that
patch
in
yeah,
I
can.
E
Yeah
so
the
way
to
specify
it,
I
don't
know
how
we
would
best
kind
of
the
way
to
specify
the
command
line
or
in
the
environment
variables.
I
don't
know
if
we
have
a
way
to
do
that
for
key
value
objects
right
so
like
we
could
add
one.
It's
just
that's
that's
the
thing
that
we
have
to
kind
of
do
some
some
inventing
some
inventing
or
deciding
that
we're
not
going
to
do
that.
We'll
just
say:
headers
are
only
from
the
npmrc
file.
A
I'm
not
sure
what
you
mean
so
like
if
somebody's
already
doing
this
today,
like
they
are
doing
it
by
just
editing
the
mpmrc
file
right
right,
they're,
not
using
like
mpm
like
config
set
headers
like
there's
no
way
of
doing
this.
E
Yes,
there
is
no
way
to
do
this
and,
what's
really
weird.
E
E
It
seems
to
be
doing
that
or
maybe
just
the
config
is
doing
that.
E
Okay,
that's
a
that's
an
interesting,
interesting
thing,
yeah
I'll
I'll
paste.
My
little
dummy
test
in
the
also
be
why
mark's.
A
Okay,
cool
so
in
terms
of
moving
this
forward
then
or
or
changing
this,
do
we
just
want
to
change
the
implement
the
way
the
implementation
looks
and
then
potentially
queue
up
work
to
backlog,
work
to
to
support
this.
E
Yeah,
if
it's,
if
it's
just
you
know
like
a
parsing
fix
in
ini,
we
could
even
conceivably
fix
it
for
v6,
like
that's,
not
particularly
hard,
and
it
also
reduces
the
likelihood
that
anybody's,
depending
on
this
in
v6,
because
oh
it's
broken.
A
D
E
Setting
it
in
the
cli
config,
you
mean
yeah,
let's
just
remove
that
yeah
yeah
yeah
or
just
mark
it
as,
like.
You
know,
follow-up
rfc
yep,
once
you
know
once
we
have,
I
think
it'll
be
worth
worth
digging
into
once
we
have
some.
E
You
know
once
we
have
headers,
we
have
now
have
an
object
that
we're
explicitly
saying
like
this
is
for
users
to
set
and
so
being
able
to
set
it
on
the
environment
and
the
the
cli
is
kind
of
important,
but
that's
kind
of
a
whole
other
bike
shed
I'd
rather
not
have
derailed.
This
discussion,
yep.
A
Might
be
good
for
the
implementation
just
to
write,
something
like
and
document
that
this
is
not
configurable
via
npm
config,
so
that
we
know
that
we
need
to
write
that
in
because
somebody
will
eventually
say
like
this
doesn't
work
and
it's
not
bug
it's
a
feature:
okay,
cool.
So
if
we're
good
on
that
any
other
discussion
we
want
to
have
on
on
this,
if
not,
let's
move
on
to
issue
225
the
rrc
for
ads
support
to
plug-in
dependencies.
A
I
think
this
got
picked
up
again
this
week,
although
I'm
not
sure
if
there's
any
changes
since
we
brought
this
up
before.
A
I
know
marcel
was
able
to
join
us
last
week
and
I
think
we
think
we
can
potentially
remove
this.
I
think
this
had
to
do
with
generators,
and
I
know
wes
had
had
a
couple
questions.
F
A
B
Npm
to
support
or
build
here
yeah,
I
think
the
only
thing
we
mentioned
it
was
slightly
related
was
maybe
just
the
rework
on
having
something
like
a
liben
piano
exact
that
people
can
could
programmatically
like
consume
just
for
the
sake
of
like
projects
like
yemen
like
they
could
integrate
directly
into
it.
I
think
this
is
the
only
thing
we
might
want
to
signal
as.
A
Discussion
for
that
then,
maybe
or
I
forget
yeah-
that.
E
One
one
downside:
I
kind
of
I
kind
of
brought
this
up
somewhat
in
passing,
but
I
thought
about
it
a
little
bit
more
and
I
think
it
may
be
a
bigger,
a
bigger
concern
than
we
appreciated.
Last
time
around
npm
exec
uses
a
lot
of
npn
like
it.
It
has
to
rely
on
having
the
entire
config
infrastructure.
E
F
G
E
Yeah
you
get
the
like,
you
know,
150,
millisecond
or
so
tax
on
each
child
process.
Okay,
yeah.
F
Also,
spelling
out
has
a
bunch
of
other
interesting
problems
with
like
what
happens
if
your
shell,
your
your
shell,
changes
or
you're
doing
something
which
changes
you
know,
parts
of
your
shell,
then
now
you've
got
to
like
manage
all
of
this
other
you
know
check,
for
you
know,
find
the
binary
path
of
the
npm.
F
You
think
you
should
be
using
and
you
sure
hope
it
stays
there,
and
you
know,
especially
in
long-running
things
like
you
know,
if
you
have
a
service
that
needs
to
do,
some
of
these
things
shelling
out
is,
is
really
less
optimal,
not
to
pile
on.
Maybe
we
already
have
enough
reasons,
but.
E
F
Yeah,
it's
just
shelling
out
to
something
just
to
shell
out
again
is
can
add
layers
of
complexity
right,
I
mean
there's
reasons
why
people
I've
seen
tons
of
build
failures
at
work
where
it
is
like
well,
it
would
have
worked
had
you
called
it
directly,
but
you
called
npm,
which
called
yarn,
which
called
lerna,
which
called
npm
and
that's
what
broke
it
right
and
it's
like
that.
Many
layers
is
where
you
start
to
get
hard
to
debug
problems
with,
like
lots
of
extra
complexity,
sure.
E
Okay,
yeah,
just
it's
it's
going
to
be
getting
it
getting
it
exactly
right,
as
a
library
is
going
to
be
a
little
bit
tricky.
That's
all
it's
not
like
it's
not
as
easy
as
like
lib
npm
version.
You
know
where
we
have
a
relatively
straightforward,
like
task
to
perform.
A
Yeah,
so
I've
removed
this
specific
issue
from
the
agenda
for
for
next
week
and
there's
an
action
item
which
I
think
we
had
last
week
too,
to
I
think,
probably
create
either
a
separate
rf
rfc
for
this,
or
we
can
just
take
this
as
a
to-do
and
that
this
is
backlogged
for
the
team
to
eventually
have
a
lin,
lib,
npm
or
lib
exec
npm,
exec
yeah.
I
don't
think,
there's
anything
else
to
do
there.
A
So
this
is
the
like
scoped
yeah
per
package
per
organization
config.
I
noticed
once
you
gave
some
feedback
last
week
and
I'm
not
sure
anything's
happened
since
then
there
hasn't
been
any
updates.
The
actual
rfc.
A
And
was
this
feedback
you
had
also
given
in
last
call,
I
can't
remember.
F
We
just
we
chatted
about
it
last
week,
and
so
I
think
that
action
item
from
that
was
like
hey
just
just
like
write
up
an
example
of
like
a
scenario
where
this
hazard,
just
so
that
we
had
like
a
concrete.
You
know
thing
to
point
to
and
say
like
here:
it's
a
this.
This
really
can
happen
and
for
what
it's
worth.
I
I
tried
to
point
out
this
is
I
tried
to
write
one
that
wasn't
a
real
world
example.
F
I've
seen
just
so
that
you
know
I
didn't
expose
real
people
to
real
harm,
but
there's
like
probably
20
variants
of
this
sort
of
workflow
that
that
can
be
opened
up
by
the
config
not
being
respected
in
older
npms.
A
Sorry,
my
my
mouse
is
dying
here,
so
I
can
you
don't
mute
with
my
keyboard.
Okay
is
that
all
we
want
to
do
was
essentially
like
identify
that
there
is
or
like
outline.
There
is
a
hazard,
but
we
still
probably
want
to
move
forward
with
like
supporting
this.
A
G
That's
what
I
recall,
I
I'm
still
a
little
fuzzy
from
last
week,
but
well
I
mean
that
seems
right.
E
I
have
a
great
way
for
us
to
make
it
really
hard
for
anybody
to
do
it,
which
is
the
current
status
quo.
You
know
you
have
to
like
specify
the
the
the
registries
you're
using
at
each
command.
It's
like
it's
all,
very,
very
explicit.
I
mean
that
is
actually
ideal.
If
that's
the
goal.
G
G
If
we
make
some
sort
of
custom
protocol
like
overrideable
or
something
or
you
know,
whatever
bike
shed
the
name,
then
that
would
just
fail
in
an
npm
version
that
didn't
have
this
feature,
and
it
would
then
go
to
the
correct
registry
in
an
npm
version
that
did
have
the
feature
like
is
something
like
that
possible.
E
So
the
hazard
there
is
the
the
the
hazard
that
we
talked
about
with
adding
a
a
new
spec,
and
this
is
kind
of
the
thing
that
comes
up
any
time.
We
talk
about
adding
a
new
dependency
spec.
E
The
cost
is
that
it
splits
the
ecosystem
and
it's
what
we've
seen
with
you
know
it's
what
we
saw
with
like
the
the
hosted
package
shorthands
with
the
even
with
adding
file,
was
always
sort
of
supported,
because
it's
like
url
ish
and
so
that
that
one
was
added
a
long
time
ago,
but
yeah
when
we,
when
we
do
that
and
you
publish
something
that
has
that
specifier
within
its
dependency
sets
now
that's
a
thing
that
can't
be
installed
by
older
versions.
E
Now,
maybe
what
we
want
to
say
is
well
it's
hazardous
to
install
it
with
older
versions.
You
shouldn't
do
that,
so
you
know
the
fact
that
it
fails
becomes
a
switches
from
a
bug
to
a
feature.
We
just
have
to
be
very,
very
careful
about
it,
and
I
mean
we're
also
seeing
that
today
with
like
the
the
things
that
that
yarn
added
with
like
pack
and
workspace
now,
there's
there's
packages
out
there
that,
like
other
other
package
managers,
can't
install
without
adding
those
other
specifiers.
So.
F
But
really
quick
question,
I
don't
you
can't
publish
today
and
say
this
package
has
to
come
from
this
other
registry.
So
actually
I
don't
think
that
proposal
will
fracture
the
community
because
it's
not
like
people
are
configuring
that
in
a
published
package
anyway
right,
because
you
can't
control
your
consumers
where.
E
You
can,
if
you,
if
you
just
best,
buy
the
tarball.
Oh
well,
okay,
that's
that's
kind
of
like
the
the
current.
You
know,
state
of
the
art.
F
Or
yeah
or
a
git
repo,
I
guess
right,
but
both
of
those
are
generally
less
desirable
scenarios.
So
I
guess
my
point
is
by
by
adding
a
new
one
that
is
and
and
saying
you
can't
publish.
If
you
have,
this
kind
of
thing
was
where
I
was
going
to
go
with.
That
would
actually
be
maybe
a
reasonable
middle
ground.
E
So
I'm
not
like
committed
to
this
idea
at
all,
but
add
a
specifier
called
registry,
and
so,
if
you
do
registry
colon
registry
url
slash
package
name
at
version,
the
the
registry
protocol
would
kind
of
be
like
use
this
registry
and
then
do
a
you
know,
name
at
version
lookup.
E
And
so
you
could,
you
know
the
kind
of
the
implicit
like
essentially
just
doing
a
version
range
would
be
sort
of
like
a
shorthand
for
registry,
colon,
registry.npmjs.org,
versionrange
or
something.
F
E
So
the
reason
for
the
reason
for
trashing
it
is
is
the
the
fact
that
it
would
split
the
community,
and
so
it's
and
again
it's
not
it's
not
that
it
necessarily
will
it's
that
that's
the
the
hazard,
so
we
just
kind
of
have
to
be
very
careful
that
we
don't
get
ourselves
into
that
situation
where
there's
people
depending
on
it,
who
are
going
to
be
upset
if
we
remove
it.
But
the
fact
that
it's
out
there
is
causing
problems
for
other
users
so
so
quickly.
A
I
just
want
based
on
this
rc,
though
I
think
they
unfortunately
like
started
off
with
specifically
npm
rc
config
and
then
ventured
into
adding
something
into
package
json
when
potentially,
if
we
focused
on
the
npm
rc
configuration,
I
feel
like
that's,
where
you
probably
could
introduce
protocol
without
fragmenting
the
ecosystem.
Since
it's
specific
to
like,
like
configuration
that
we
potentially
could
support.
E
I
mean
really
it's
just
the
you
know
the
security
I
haven't
and
I
have
to
admit
I
have
not
had
a
chance
to
dig
in
to
the
the
example
hazard
that
you
proposed
that
you
presented
here
wes,
so
I'm
shooting
from
the
hip
a
little
bit.
I
apologize.
F
Totally
fine,
we
could,
but
we
could
bump
this
to
next
meeting
too
and-
and
you
know
to
be
honest,
it
really
is
hard
to
say
that
this
security
hazard
should
block
it
like
at
first.
I
was
actually
thinking
it
shouldn't
block
it,
but
it's
this.
It
is
so
clearly
going
to
happen
that
it,
I
think
you
know
it.
It
raises
the
concern.
F
So
if
yeah,
no,
I
don't
know
I
I
I
we
could
also
tool
around
it
in
other
ways
like
we
could,
you
know
I'm
sure,
there's
things
we
could
do
as
enterprises
with
you
know
hundreds
of
deployments
using
everything
back
to
npm3
like
sure,
but
like
we
can
make
the
make
it
not
worse
for
people
just
to
move
to
npm
seven.
Mostly,
then,
I
think
we're
just
doing
a
good.
You
know
thing,
but.
E
Yeah,
so
I
I
think
the
the
next
step
here
then,
is
to
dig
into
this
specific
objection,
the
the
specific
concern
and
decide
whether
it's
a
blocker
or
it's
something
we
can
address
or
it's
something
that
we're
just
comfortable
with.
You
know
those
are
kind
of
just
that's
the
exhaustive
space
of
responses
we
could
have.
If
it's,
if
it's
a
concern
that
should
be
a
blocker,
then
okay,
it
blocks
it
and
we
we
don't
do
this.
F
A
F
A
Feature:
okay
in
terms
of
what
we
should
do
here
then
like
is
this
something
we
just
continue
to
keep
bringing
up
like?
Is
there
something
meaningful
that
we
can
do
like?
Do
we
not
want
to
like
move
forward
on
this
right
now.
E
Yeah
yeah
leave
it
in
the
agenda.
I
will.
I
will
try
to
try
to.
You,
know
fully
fully
chew
on
this
security
thing
and
have
some
some
more
words
to
say
about
it,
and
then
we
can
bring
it
up
next
time,
cool.
A
So
moving
on
then
to
pierre
121,
the
proposal
for
adding
link
and
version
comment,
syntax
to
a
package
version,
and
I
think
roy.
You
brought
this
one
back
up
on
to
the
agenda
right.
B
Yeah,
I
was
just
doing
a
little
bit
of
how
the
cleanup
in
the
prs-
and
I
saw
this
one-
had
no
particular
label
not
much
in
terms
of
documentation
in
the
pr
itself
so,
but
I
saw
it
was
present
in
a
lot
of
previous
agendas,
so
might
as
well
just
bring
it
up,
and
I
think
it's
a
good
time
because
with
npn
7
out,
we
have
to
support
workspaces
and
to
me
with
to
me,
it
feels
like
a
lot
of
what
it's
proposing
kind
of
overlaps.
B
E
Way
the
use,
the
and
everything
I
just
said
about
splitting
the
community
by
having
new
specifiers
like
110
applies
here
like
this
is
a
great
example
of
that.
The
the
use
case
I
that's
this
is
targeting,
I
think,
isn't
really
very
well
addressed
by
workspaces,
though
the
idea
is
I
have.
I
have
these
kind
of.
I
have
a
package
that
I'm
working
on
and
I
don't
want
to.
I
don't
want
to
make
my
consumer
use
a
specific
version
of
the
thing.
E
What
I
want
to
do
is
say
you
should
be
getting
some
version
matching
5.x,
but
it
should
be
a
sim
link
to
your
checkout
of
version
5.x,
and
I
I
think
honestly,
like
there
are
it's
really
complicated
to
to
make
this
work
and
also
to
you
know,
to
kind
of
verify.
If
this
is
valid
or
not,
and
I
just
I
first
see
some
some
challenges.
E
If
this
does,
if
this
kind
of
thing
does
kind
of
escape
into
the
public
registry,
like
it's,
it's
a
weird
thing
to
install
a
package
and
have
it
say
well,
you
should
have
a
sim
link
as
this
dependency
like
it's.
It
feels
I
don't
know
like
it's
outside
of
that
dependence,
scope,
right,
yeah
and
the
file.
E
With
the
file
protocol
you
would
with
a
file
protocol,
you
would
be
specifying
the
path
that
it
needs
to
be
sim
linked
to
right,
and
in
this
case
it
doesn't
want
to
specify
that
it
wants
to
specify
a
version
but
also
specify
that
it
should
be
a
sim
link.
The
field
is
pretty
complicated,
yeah
like
if
I'm
giving
you
the
version
you
want
shut
up,
just
take
it
use,
do
do
your
code
and
if
you
need
a
specific
path,
well,
okay,
specify
that
and
I'll
give
you
that
path
or
fail.
A
Link
potentially,
which
I've
seen
some
discussions
brought
up
or
people
poking
us,
because
we
were
hoping
to
improve
npm
link
in
v7.
I
think,
as
far
back
as
a
year
and
a
half
to
two
years
ago,
we
were
saying
that
we
might
improve
that
experience.
What's
going.
B
E
Were
happening
and
link
was
pretty
broken
in
in
npm
six
in
a
in
a
a
bunch
of
cases
which
we
have
since
fixed
in
npm,
seven
largely
by
the
move
to
a
different
different
package,
lock
system,
a
tree
management
module.
That
knows
the
difference
between
a
link
and
a
target.
E
It
has
them
listed
as
two
separate
objects
like
the
list
goes
on
and
on
so
there
there
was
an
old
rfc
about
one
possible
way
to
start
improving
npm
link
and
we
we've
pretty
much
abandoned
that
we're
like
no
we're
not
just
gonna,
stash
a
whole
bunch
of
extra
metadata
in
a
new
lock
file.
Instead,
we
went
a
little
bit
deeper
and
changed
the
way
that
we
that
we
analyzed
the
file
tree
and
everything
else.
F
Can
I
can
I
I
don't
wanna,
so
I
have
two
things
that
not
to
derail
here
totally,
but
I
want
to
bring
it
back
a
little
bit
to
this.
I
actually
don't
think
that
they're
asking,
I
think
what
they're
asking
for
is
how
to
do
this
with
multi
repos
and
that's
the
problem
with
workspaces
here
is
workspaces,
are
a
like
look
here.
It
even
says.
D
F
F
I
don't
think
this.
This
gives
enough
details
to
make
a
clear
assessment
of
what
they're
asking
for,
but
like
the
fact
that
they
want
comments
to
me
means
they
have
out-of-band
instructions
to
give
to
their
user,
which
I've
seen
this
happen
in
projects
where
it's
like
check
out
these
seven
repos
next
to
each
other,
if
they're
not
next
to
each
other,
they
don't
work
right
and,
like
that's
a
com,
unfortunate
setup
but
common
and
to
me
what
they
want
is
what
I'm
I
kind
of.
Did
my
joke
multi-repo
workspaces.
F
I
I
really
think
like
this
is
the
ultimate
solution.
Here
is,
let
ace
a
user?
Maybe
they
can't
publish
it?
Maybe
they
can't
make
it
portable
infinitely
portable
to
all
other
machines,
but
I
want
to
set
up
on
my
machine
these
seven
packages
and
I
want
them
to
be
able
to
import
the
each
other,
and
I
don't
want
you
to
care
you
being
the
the
tool
author
or
you
being
my
teammate
to
care
where
I
put
them
on
my
file
system
right
and
that's
what
it's
to
me.
F
That's
what
they're
asking
for
in
this
pr
or
sorry
in
this
rfc
is
like
some
way
to
say,
like
I
want
to
be
able
to
get
this
thing.
I
want
to
be
able
to
give
some
instruction
to
my
maybe
teammates
on
on
how
to
get
this
thing,
but,
like
I
don't
want
to
have
to
have
a
hard-coded
file
path
in
there
right,
which
is
what
people
have
today.
F
Yeah
yeah
totally.
If
we
have
that,
then
we
just
we
can
set
up
a
a
master
repo.
I
should
I
should
not
use
that
term
a
a
primary
repo
that
imports
them
all
as
sub
modules,
and
that's
your
developer,
setup
right
and
like
fine,
but
that.
G
F
System-
okay,
maybe
I
haven't
seen
your
exact
setup
here
and
maybe
sorry
is
this
derailing.
This
conversation.
G
Like
so,
if
in
this
in
this,
in
the
the
comment
from
the
rfc,
it
looks
like
he's
saying,
I
want
this
other
depth
there
too,
on
that
right
branch.
So
if
instead
you
use
git
submodules,
you
can
make
a
folder
inside
your
repo
that
transparently
points
to
a
a
folder
on
a
repo
at
a
sha
somewhere
else.
So
and
then,
as
long
as
the
person
who's
using
who's
cloning,
your
repo
remembers
to
run
git
sub
module.
Update
then,
which
is
one
of
the
big
ergonomic
issues
with
it.
G
G
It's
just
like
a
sim
link
across
repos
and
git
has
supported
that
for
a
long
time.
It's
just
like
it's
a
pretty
gnarly
feature.
If
you
don't
abstract
away
as
much
as
you
can,
so
people
tend
not
to
dive
into
it,
but
in
these
basic
ways
we're
talking
about
you
can
do
it.
So
I'm
actually
using
this,
like.
I
started
using
this
a
week
ago,
because
I
have
a
package
called
list
exports
that
has
like
a
buttload
of
fixtures.
G
Like
example,
projects
and
I
didn't
want
to
repeat
that
data,
and
so
I
made
that
a
sub
module
in
a
not
yet
landed
pr
on
resolve,
so
that
I
have
a
bunch
of
fixtures
to
test
resolution
against
and
it's
pretty
automatic
like
you,
it's
you'd
have
to
try
pretty
hard
to
not
have
the
wrong
to
not
have
the
right
thing
happen
in
the
resolve
repo
once
that
lands.
F
I
will
definitely
try
this
out.
That
said,
I
have
tried
to
do
sub-modules
with
a
team
of
more
than
one
person,
and
it
has
always
been
a
pain.
So
so
maybe,
like
there's
trade-offs
the
reason.
I
really
strongly
think
that
support
in
the
package
installer
layer
for
this
sort
of
repo
agnostic
feature
right
is
that
there
are
tons
of
different
setups
and
lots
of
times
they're
not
like
intentional.
They
can
be
organic
setups.
F
Where
then,
suddenly
somebody
has
to
come
in
and
work
with
a
bunch
of
packages
together
that
they
maybe
don't
always
have
to
work
in
when
you're
debugging,
something
in
a
transitive
four
layers
down
like.
Sometimes
you
don't
have
the
you're
not
going
to
go
set
up
like
a
intermediary
project
that
pulls
it
all
in
as
sub
modules
and
whatever
you
just
want
like
an
ad
hoc
hey.
F
G
I
think
we're
talking
about
two
things:
two
different
things
like
the
problem
in
the
rfc
is
talking
about,
not
because
it's
an
npm
dependency
but
because
I
have
magic
stuff,
hard
coded
in
my
app.
I
need
another
git
repo
located
in
a
specific
location
on
the
machine.
G
G
You're
talking
about
west
is
one
that
I
am
super
on
board
with,
which
is
so
like,
for
example,
I
have
enzyme,
and
that
has
an
enzyme
adapter
and
like
three
internal
packages
that
are
all
in
the
enzyme,
monorepo
and
react,
and
if
I
want
to
test
enzyme
in
a
different
like
a
create
react
app,
I
have
to
npm
link
like
eight
things
and
you're
right,
every
npm
install
command.
I
have
to
redo
all
those
links.
G
It's
a
huge
pain
in
the
ass,
so
something
to
solve
that
problem
seems
like
a
really
good
idea,
but
that
to
me
feels
like
something
that
doesn't
require
package
json
changes.
It
requires
a
command-
that's
smart
enough
to
figure
out
all
the
appropriate
things
to
link
and
link
them
and
preserve
those
links
or
quickly
restore
them
so
that
this
actually
common
developer
workflow
can
be
made
not
a
nightmare.
But
that
seems
to
me
to
be
something
different
than
what
this
rfc
is
asking
for.
F
G
B
Yeah,
I
I
wanted
to
kind
of
add.
I
think
I
think
we
we
stumbled
upon
the
same
the
exact
same
conclusion
in
a
different
rfc
before
maybe
it
was
crist
in
anyways
it
was
a
different
one,
proposing,
I
think,
a
protocol
or
a
new
protocol,
or
something
and
yeah.
I
think
like
this
one
could,
I
could
definitely
see
something
like
maybe
an
npm
eject
and
like
and
a
specifier
for
that
that
kind
of
takes
it
out
of
your
node
modules.
B
F
That's
a
really
interesting
proposal,
so
I
think
if
you,
if
you
had
npm,
effectively
grab
the
repository
and
pull
it
in
it
might
work.
It
does
mean,
though,
that
if
you
are
so
most
of
the
time
for
me,
I
have
these
things
all
set
up
on
my
local.
So
again
like
going
back
to
okay.
So
today
I
was
trying
to
push
that
stupid,
create
package
for
the
pkg.js
org
and,
like
I
was
realizing
that
I
had
changes
in
four
repos
that
all
had
to
go
before.
F
I.
I
really
think
we
need
to
say
npm
here
is
where
you
can
find
this
package
for
now
like
I
I
already
have,
or
maybe-
and
here
could
be
a
a
git
repository
or
a
sember
version,
and
it
would
like
pull
the
registry
and
check
out
the
proper
tag
or
do
something
smart
but
like
it
needs
to
have
some
level
of
no
network
access.
A
So
just
to
be
mindful
of
time,
we
only
have
about
four
minutes
left
and
I
know
we
have
one
more
item
to
get
to.
Are
we
good
with
time
boxing
this
and
and
and
potentially
I
guess,
trying
to
give
feedback
in
the
thread
itself.
A
Comments
other
than
you
poking
in
there
right.
A
Yeah,
it
seems
like,
as
it
is
now,
it's
probably
not
something
that
we
want
to
support,
based
on
the
initial
feedback
of
not
like
trying
to
introduce
like
something
that
would
fragment
like
on
more
protocols
right.
So,
okay,
the
last
item
on
the
agenda
was
deprecated.
Packages
should
be.
This
is
rfc
155,
so
the
programming
packages
should
automatically
display
the
dependence
to
these
notifying
maintainers,
and
I
think
when
this
was
first
brought
up,
I
think
isaac.
You
just
said
this
is
a
good
idea.
E
Yeah,
I
do
I
I
think
it's
so
I
think
it
may
be
a
little
bit
more
challenging
than
I
originally
thought
just
because
you
know
having
having
done
more
of
these
installs,
especially
seeing
like
the
typical
gatsby
install
right
now
that
has
like
30
deprecated
modules
or
something
thanks
to
the
lab
switching
over
and
a
couple
of
other
kind
of
key
ones.
E
The
hazard
I
would
want
to
avoid
is
dumping.
You
know
thousands
of
lines
of
output
onto
the
user's
terminal,
so
it
it
may
be
worthwhile
to
just
like.
If
there
are
any
deprecated
modules
you
know,
output
like
a
you
should
run
npm,
explain
blah.
That
will
tell
you
what's
using
it.
A
So
that's
something
we
can
support
today
like
if
we
see
npm
install
we
could.
A
If
we
see
deprecations
from
npm
install,
then
we
can
also
add
the
run
explore
to
determine
what
actually
you'd
have
to
fix
to
right.
Right,
not
knox
explains.
E
Explain
yeah,
I
I
wouldn't
want
to
run
the
explain
for
them
automatically,
just
because
it
is
rather
verbose.
I
mean
it
gives
you
the
full
explanation
of
like.
Why
is
you
know?
Why
is
popper
in
your
in
your
tree,
which,
if
popper
is
used
by
three
different
things
which
all
are
you
know
pure
dependencies
of
gatsby?
It's
gonna,
it's
gonna
be
rather
elaborate.
E
E
E
We
could
also,
we
could
also
gather
up
all
of
the
deprec.
You
know
we
could
add,
like
a
add,
a
way
to
say,
like
just
give
me
an
explanation
of
everything,
that's
deprecated
in
my
tree
and
consolidate
these
things.
When
you
have
you
know,
50
years.
E
Yeah
or
we
could
just
say
like
there
are,
you
know
there
are
12
deprecated
modules
run,
run
npm,
explain
deprecated
to
yes
show
all
of
them.
E
More
yeah,
it
would
change
the
install
output
because
we
would
basically
remove
those
warnings
and
instead,
you
know
kind
of
consolidate
them
up.
A
A
Creating
an
rfc
for
essentially
consolidating
deprecated
warnings
and
then
suggesting
npm,
explain
with
a
flag
or
adding
npm
explain
to
support
a
flag
like
deprecated.
A
Okay,
let's
just
take
some
notes
on
that
and
I
don't
think
there's
anything
else
to
follow
up
there
unless
somebody
else
had
something
they
wanted,
because
I
know
we're
over
time.
A
Okay,
great,
so
I
appreciate
everybody
jumping
on
again
I
apologize
for
going
a
couple
minutes
over
and
feel
free
to
keep
adding
your
feedback
and
and
rfcs
to
the
npm
rfc's
repo
I'll
see
you
next
week.