►
From YouTube: Open RFC Meeting - Wednesday, Oct 14th 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
A
And
we're
live.
Thank
you.
Everybody
for
coming
to
another
npm,
open,
rc
call.
Today's
date
is
wednesday
october,
the
14th
2020..
A
A
I
apologize
that
that
code
generated
late
this
morning
and
again
just
to
do
a
quick,
a
couple
of
house
keeping
acknowledgements
all
discussions
on
this
call
and
in
rfc,
repo
and
and
all
the
repos
that
interact
with
community
is
governed
under
a
code
of
conduct,
and
we
ask
you
to
please
be
respectful
and
mindful
in
these
calls,
when
others
are
speaking.
A
Please
raise
your
hand
if
you'd
like
to
add
to
the
discussion
or
add
a
as
well
the
outline
of
and
sort
of
the
desired
outcomes
of
these
calls
is
to
work
closely
and
communicate
and
collaborate
with
the
community
and
hopefully
push
forward
the
proposals
that
folks
have
have
offered
to
us
quickly.
I
want
to
give
the
floor
for
any
announcements.
A
I
guess
I
can
say
that
as
of
tuesday
of
this
past
week,
I
guess
yesterday
it
feels
like
the
days
are
growing
long,
so
it
feels
like
almost
last
week
we
shipped
npm
seven.
So
there's
a
couple
blog
posts
that
were
posted,
you
can
get
it
by
running
npm.
I
g
npm
at
seven
or
next.
Seven
is
the
distance
that
are
currently
associated
with
that
release,
and
the
team
has
been
working
really
hard
to.
A
You
know
get
us
to
this
point.
It's
been
almost,
I
think,
over
a
year
that
we've
been
working
on
on
this
release
and
lots
of
lots
of
good
good
work
has
been
done
to
to
get
to
this
point
so
big,
big
congrats
to
the
whole
team
and
the
community
at
large
and
we're
continuing
to
working
on
on
that
release
as
well.
A
We've
got
potentially
a
patch
geared
up
here
towards
the
end
of
the
week,
which
I
should
should
know
to
quickly
fix
some
things
that
we've
seen
so
awesome.
So
if
there's
no
other
announcements,
let's
dive
into
the
first
item
here-
which
I
think
is
just
a
a
reminder
to
that-
we
need
to
merge
in
and
close
this
isaac.
A
This
is
pr
number
239
describe
how
npm-7
handles
pure
depth
conflicts,
so
work
actually
landed
just
before
the
release
to
make
this
so,
and
maybe
you
can
speak
to
that-
and
I
think
let
us
know
if
there's
anything
else
that
needs
to
be
added
here.
I'm
not
sure
if
anybody
else
has
those
added
comments.
B
Yeah,
I
think
the
there
there
were
some
suggestions
about
kind
of
how
we
could
format
the
error
messages,
some
other
good,
ui
ideas
that
I
think
are
and
also
a
question
about
whether
we
want
to
move
to
even
more
strictness
in
in
and
can
be.
Eight
honestly,
I
think
version
eight
might
be
too
soon.
B
But
I
I
do
agree
that
that's
a
really
good
goal,
but
both
the
kind
of
future
plans
for
how
strict
we
want
to
be
and
the
the
specific
kind
of
layout
of
the
error
message
a
little
out
of
scope
for
this
particular
rfc.
B
B
When
you
specify
force,
we
will
do
our
do
our
very
best
to
create
a
a
valid
resolution
and
fall
back
to
a
as
as
valid
as
possible
resolution,
basically
treating
non-peer
dependencies
as
a
sort
of
heuristic
and
when
all
else
fails.
Just
using
whatever
pure
dap
happened
to
be
placed
first,
which
will
be
deterministic.
B
But
you
know,
albeit
arbitrary,
when
it
is
not
your
dependency,
oh
and
so
then
it
adds
another
option:
strict
pure
depths,
which
will
instead
of
forcing
it
will
crash
on
any
error
it
finds
in
any.
You
know,
conflicts
in
any
pure
depths
and
by
default
we
will
force
if
it
is
not
your
fault
and
we
will
be
strict
if
it
is
your
fault.
B
So
if
there's
a
conflict
in
your
dependencies
in
your
peer
dependencies
as
a
developer,
you'll,
your
your
install
will
crash
and
you'll
have
to
deal
with
it
or
explicitly
decide
not
to,
but
when
you're,
just
installing
your
depths,
you
know
we're
going
to
try
and
make
the
install
work
as
best
we
can
yeah
and,
like
I
said,
there's
a
bug
that
makes
the
yard
the
yards
project
currently
not
work.
I
just
root
caused
that
this
morning
and
yeah,
but
the
software
development
continues.
A
B
Yeah
just
results
from
the
from
the
kind
of
ongoing
conversation,
the
feedback,
the
initial
spec
was.
We
would
only
force
by
default
if
we
could
find
some
non-arbitrary
indication
of
what
we
should
do,
but
in
practice
that
still
just
breaks
too
many
people's
installs.
So
we
can.
You
know
we
can
look
at
that.
As
a
you
know,
a
potential
future
rfc,
but
for
the
time
being,
this
is
this
is
what
it
is.
B
This
is
kind
of
where
it's
landing,
so
I
updated
the
rfc
text
to
to
match
what
we're
actually
doing
or
intending
to
do
anyway.
Minus
this,
you
know
modulo
these
two
bugs
we
found,
and
I
think
the
only
thing
we
left
to
do
is
to
merge
it
into
the
implemented
folder,
because
it's
it's
implemented
now.
A
B
Skipped
a
step
there,
but
yeah
we
kind
of
accepted
it.
You
know
verbally
and
we
generally
don't
hang
on
ceremony
too
much
so
not
to
worry.
C
A
Cool
so
next
item:
unless
there
was
anything
else
on
here,
roy
did
you
want
to
quickly.
C
I
just
wanted
to
go
on
a
tangent
here,
but
but
like
feel
free
to
stop
me
if
it's
too
much,
but
it's
just
that
all
things
that
isaac
mentioned
here
and
having
in
mind
that
we're
gonna
work
on
the
overrides
rfc
for
a
possible
really
soon
minor
version
right.
B
Right
so
yeah
having
it
having
it
automatically
save
the
override.
I
I'm
not
sure
if
that's
a
safe
thing
to
do
without
an
opt-in,
but
we
could
certainly
update
the
error
message
to
say,
like
you
know,
add
this
to
your
package
json
and
this
error
will
go
away.
C
Yeah
or
maybe
even
like
you
could
also
live
in
user
land,
but
maybe
like
some
interactive
experience
to
kind
of
like
try
and
solve
the
the
conflict
yourself
right.
B
Yeah
there's
there
will
be
a
lot
of
interesting
opportunities
to
explore
there.
I
think
the
the
hazard
of
the
hazard
of
adding
an
override
automatically
is
that
the
override
is
more
sticky
than
the
dependencies
themselves.
So
if
you
have
some
some
nested
dependency
conflict,
let's
say
that
we
warn
about
and
or
some
nested
peer
dependency
conflict
and
we
warn
about
it,
and
you
know
we
provide
some
override
implicitly.
B
If
we
then
save
that
to
your
package.json
and
then
sometime
later,
let's
say
the
developer
of
that
module
goes
in
their
project
and
npm
install
crashes
and
they
go
oh
geez.
I
gotta
fix
this.
They
fix
it.
They
bump
the
version
well
you're,
still
getting
the
override,
because
you've
saved
that
to
your
package.
Json
file,
yeah.
C
C
Yeah,
I
don't
know,
I
definitely
see
it.
I
definitely
see
how
it
can
be
like
yeah,
definitely
annoying,
I'm
speaking
more
from
the
point
of
view
of
avoiding
the
arbitrary
decided
resolution
right,
like
which,
oh
I
see
still,
even
even
if
it's
deterministic
like
it's
still
arbitrary,
like
folks,
might
want
to
lick.
It.
B
C
Yeah,
but
that
yeah,
I
don't
want
to
go
any
more
into
that.
B
E
This
actually
should
we
also
bring
up
with
overrides,
then
the
behavior
we're
just
talking
about
which
is
they
manually
install
with
an
override
that
is
overriding
the
new
manually
taken.
You
know,
install
command
like
that.
That
seems
like
something
we
never
talked
about
with
overrides.
E
So,
like
you
were
saying,
if
they
peer
resolve,
you
know
resolve
a
pure
conflict
by
adding
an
override
and
then
later
something
changes
and
they
say.
Oh
now,
I
need
to
fix
this.
I'm
actually
going
to
do
a
like.
You
know,
npm
install
react
at
you
know
19
or
whatever
the
new
version
is,
and
they
have
a
react
override
for
some
16
range.
Actually,
that
to
me
is
saying
that
we
should
complain
and
say:
look.
You've
got
an
override.
I
can't
install
npm.
E
B
B
Yeah
yeah:
well,
it's
a
little
bit
more,
it's
a
little
easier
to
to
handle
that
conflict
between
your
explicit
request
and
the
override
right,
because
we
can
see
it
at
the
root
level.
Before
we
even
start,
you
can
say,
like
hey,
you're,
trying
to
install
foo
at
one
and
you
have
an
override
for
foot
zero
or
whatever
the.
B
I
think
that
it's
a
little
more
hazardous
if
we
save
implicit
overrides
to
the
package
json
overrides
because
you
might
not
even
know
right
like
I'm
installing
you
know,
I'm
installing
standard
that
seven
layers
deep
is
overriding
some
version
of
eslant
and
I
don't
even
know
what
eslint
is
and
then
I
save
an
override
for
that
and
then
later
I
do
a
patch
upgrade
to
standard
which
fixes
the
peer
depths
and
I'm
still
in
broken
peered
up
land.
B
B
Something
that
was
honest,
yeah,
you
know
what
actually
we
could
maybe
save
the
explicit
override
if
we
were
just
like
super
super
super
explicit
about
it
right
so
like
right,
we
are
overriding.
This
particular
pure
dependency
of
this
specific
dependency
of
this
specific
dependency,
etc.
So
it's
an
exact
version,
yeah
exactly
so.
If
anything
gets
even
a
patch
upgrade.
The
override
just
is
irrelevant.
D
B
Yeah
yeah
yeah,
so
I
think
this
is
a
really
good
idea.
I
think
that
at
some
point
you
know
maybe
subsequent
to
implementing
overrides
more
or
less
as
we've
expected
already,
we
should
bring
up.
You
know
how
we
could,
how
we
could
kind
of
use
these
two
things
together,
the
the
implicit
pure
depth
forcing
and
the
the
overrides
feature,
because
I
I
feel
like
there
is
some
interesting
surface
area
there.
A
Awesome
great
so
moving
on
to
item
or
issue
rrc
238
they're,
creating
the
mpx
package
from
public
registry.
This
was
conversation
that
roy
had
put
on
a
radar,
I
think
about
a
month
back
and
just
want
to
bring
this
back
up
to
see.
If
we
can
close
out
this.
This
issue.
C
A
Yeah
the
impact
stuff
for
creation,
so
that's
issue
number
238
on
the
rfc
repo.
E
I
I
had
one
concern
that
I
hadn't
commented
on,
but
it
came
up
later,
which
is
there's
behavioral
changes
with
npx,
bundled
in
npm,
and
if
you
also
deprecate
the
package,
it
means
people
who
do
want.
The
old
behavior
also
lose
the
option.
Well,
they
don't
lose
the
option,
but
now
they
get
a
big
ugly
warning
that
says
it's
deprecated
if
they
actually
want
the
old
behavior
right
and
so
do
a
manual
global,
install
well.
B
D
B
B
B
So
yeah-
and
you
know
it's
also.
I
think
also
like
having
npx
as
an
explicit
global
install
is
a
little
challenging,
because
now
you
can't
upgrade
npm
you
can't
like
you
have
to
install
with
force.
If
you
already
have
npm
it's
it's
a
bit
strange.
B
It's
it
was
really
sort
of
like
that.
Standalone
package
was
really
sort
of
a
a
proof
of
concept,
and
then
it
got
pulled
into
npm
5
relatively
early
on,
and
it
hasn't
really
been
updated
very
well
because
it's
it's
sort
of
challenging
to
maintain
it
in
both
places.
E
I
mean
don't
get
me
wrong,
there's
there's
bugs
and
stuff
and
features
that
are
missing,
but
like
also
to
explicitly
break
via
a
deprecation
for
no
other
reason.
Other
than
like
you
know,
it's
not
being
touched,
isn't
super
valuable,
I
think
to
the
community
so
like
just
leaving.
There
is
probably
fine,
in
my
opinion,.
B
C
B
F
Silly
silly
question
here:
is
there
any
reason
why
you
couldn't
publish
another
semver
major
of
the
npx
package,
that
just
shells
out
to
npm
exec
and
just
call
it
a
day
with
a
deprecation
warning
that
would
require
close
to
zero,
ongoing
maintenance
and
would
at
least
like
mean
that
if
people
just
install
it
we'll
know
that
they're
getting
like
the
right
thing.
Instead
of
an
old
deprecated
version,.
B
Yeah
I
mean
I
I
think
there's
these
are
all
these
are
all
kind
of
interesting
solutions,
but
I
don't
know
my
my.
I
don't
have
like
a
rational
objection.
It's
just
like
deprecation
is
simple
and
tells
people
what
to
do
and
requires
effectively
no
maintenance
right,
because
then
we
just
keep
doing
what
we're
doing
now,
which
is
nothing.
D
B
Right
right,
so
then
the
the
question
then
becomes
if
we.
D
B
B
Engines.Npm
is
strict
by
default,
oh
because
the
reason
for
that
is
is
somewhat
historical.
There
hasn't
been
any
like
significant
really
changes
since
then,
although
with
pure
depth,
there
may
be
engines.strip
engines,
9pm
remain
strict
because
it
generally
indicated
that
something
could
not
be
installed
properly
with
some.
You
know
with
a
prior
version
of
npm,
so,
like
you
know,
we
introduced
the
bin
field
and
there's
no
point
installing
this
thing.
If
my
bins
aren't
gonna
be
linked,
and
so
on.
D
How
far
back
does
that
apply?
Is
that
true.
B
Well,
there
were
not
really
significant
changes
that
would
have
necessitated
that
between
about
npm
one
and
six
in
in
the
0.x
time
frame,
there
was
lots
and
lots
of
stuff
and
one
to
two
had
a
few
small
things,
but.
B
Yeah
so
well
summer
december,.
B
Yes,
npm
to
the
december
carrot
and
the
scopes
were
both
number
one.
However,
the
adding
adding
arguments
to
run
scripts
was
the
thing
that
was
actually
a
breaking
change,
because
that
changed
how
how
a
bunch
of
those
things
would
behave,
the
but
yeah,
I
guess
npm
two
is
a
is
probably
the
last
time
prior
to
seven,
where
it'd
be
like.
You
can't
install
this
with
this
old
version
with
an
older
version
of
npm,
because
we
use
carrot
ranges
or
or
whatever
we
use
scopes.
C
C
Yeah
just
moving
back
from
the
tangents
of
engines
but
like
if
we
were
to
really
still
support
in
the
npx
package.
Maybe
we're
just
better
off
refactoring
the
entire.
You
know
zak
into
a
living
pmsac
package
and
then
just
consuming
that
in
npx
and
calling
it
a
day
right.
D
B
B
The
part
of
the
challenge
of
maintaining
those
two
fields,
those
two
packages,
is
just
that
the
configs
end
up
being
pretty
major
right,
getting
getting
all
the
configs
proper
so
that
we
set
the
right
environment
variables
and
everything
else.
The
idea
of
npx
is.
It
runs
just
like
a
package.
Json
run
script
like
with
the
same
paths
and
environment
variables
and
so
on.
A
So
just
be
mindful
of
time
here
since
we're
only
two
two
issues
in,
and
I
know
that
there's
another
four
that
we
want
to
get
to
at
least,
although
we
I
think
this
was
good.
What
can
we
say
then,
like
in
terms
of
next
steps
here,
like.
B
Well,
I
think
I
think
it's
worth
an
rfc
to
talk
about
just
like
an
actual
rfc
to
to
capture
some
of
this
stuff,
and
if
anybody
has
any
ideas
other
than
just
like
deprecating,
the
whole
thing
cool,
let's
evaluate
it
and
then
probably
it'll
just
be
up
to
somebody
to
write
a
patch
that
has
an
npm
7
style
npx
as
a
standalone
thing.
D
A
Okay
to
do
so
a
couple
signals
there
so
action
item:
let's
put
the
deprecation
warning
there
and
then
what
was
the
time
frame
that
we
originally
had
in
this.
B
B
All
right,
so
we
have
two
things
that
seem
kind
of
related:
the
server
generated,
header
values
and
configurable
data.
A
To
http
header,
yes,
so
this
was,
I
was
hoping
mark,
would
jump
on
he's
been
championing
this.
Those
two
I
believe
and
had
updated
them.
I
think
both
rfcs
before
we
took
a
bit
of
a
break
from
agenda
other
agenda
items,
so
I'm
not
sure
if
anybody's
had
a
chance
to
look
at
those,
but
they
are
pr
number
235
and
then
also
pr138,
so
the
and
I'll
should
just
move
them
so
they're
back
to
back
here.
B
So
one
thing,
that's
interesting
that
I
didn't
realize
and
daddy
is
that
mike.
A
Yeah,
that's
mark
sorry
mark.
B
Yeah
he
brought
up
in
in
138
that
we
actually
do
pass
config.headers
through
to
make
fetch
happen
in
npm
v6.
B
So
if
headers
is
and
and
headers
in
npm
b6
expects
it
to
be
an
object
rather
like
a
key
value
object
rather
than
an
array,
I'm
not
sure
if
the
items
in
that
object
can
be
arrays,
because
http
headers
are
not
actually
just
name
value
pairs.
They're
sets
of
name
value
pairs,
so
I
think
we
may
be
able
to
get
most
of
the
way
through
the
implementation
of
this.
B
Just
by
passing
the
config.headers
in
on
the
flat
options,
object
and
then
specifying
it
as
kind
of
a
section
in
the
ini
file,
because
that's
I
and
I,
if
you,
if
it
sees
a
brace
section,
it
uses
it.
It
treats
that
as
a
sub-object,
so
you'd
be
able
to
put
that
in
your
in
your
npm
rc
in
a
pretty
straightforward
way,
with
just
key
values,
in
which
case
this
is
already
about
99
implemented.
B
B
The
the
interesting
thing,
one
of
the
most
interesting
things
about
that,
though,
if
we
do
go
that
route,
we
don't
currently
have
a
way
to
say,
like
headers.foo
equals
bar
in
the
cli.
So
I
think
all
that
we
can
do
on
the
cli
is,
is
parse
either.
B
B
I
don't
think
there's
a
way
that
we
can
say
that
it
wants
to
be
an
object
or
parse
it
into
an
object,
so
that
may
require
some
some
additions
to
our
command
line.
Argument
parsing.
If
we
wanted
to
be
able
to
do
that,
I
don't
know
that.
There's
really
a
precedent
for
that.
In
kind
of
the
world
of
cli
argument,
parsing.
A
Yeah
I
mean
we
don't
suppose
he
doesn't
specify
that
here
right
in
terms
of
how
you
would
do
that
with
the
command
line.
So
would
we
just
have
to
ensure
that
there
was
like
docs
associated
with,
like
the
fact
that
this
is
you
have
to
be
updating,
npm,
rc,
directly
versus.
B
Yeah
I
mean,
or
or
we
could
just
you
know,
figure
out
a
like
spec,
a
reasonable
way
to
parse
it
and
add
it
to
the
client.
I
I
like,
I
like
maintaining
that
constraint
that,
like,
if
nothing
else
and
for
consistency
that
like,
if
you
can
put
it
in
a
config,
you
can
put
it
anywhere
the
tricky
thing
being
that
environment
variables
and
clis
can
only
be
keys
with
string
values.
So
we
would
have
to
do
something
to
know
that,
like
you
know,
it'd
be
header,
equals
foo
equals
bar
or
something.
B
And
then
you
can
specify
that
multiple
times
I
don't
know,
there's
a
we
don't
need
to
like
debate
it
ahead
of
an
rfc,
but
I
think
that
that's
sort
of
a
you
can
put
an
action
to
me
to
add
support
for
key
value
objects
in
in
the
cli
arguments.
B
B
It
would
be
the
the
suggestion
I
made
a
couple
hours
ago
on
pull
requests.
138.
A
Okay,
so
in
terms
of
this,
then
do
we
just
need
to
get
mark
to
update
the
rfc
before
we
can
accept
it.
B
I
think
there's
a
little
bit
of
investigation
too
to
just
kind
of
see
what
is
what
does
npm
6
do
with
that
like?
Is
it
currently
already
possible
to
just
send
arbitrary
headers,
and
if
so,
we
need
to
put
back
support
to
npm
7.,
so
there's
probably
a
round
of
tweaks
on
the
rc
itself,
yeah,
not
big
ones,
but.
A
Check
so
moving
on
then.
B
I
mean
if
this
already
works
in
npm,
what
six,
maybe
even
five
I'm
sure
mark,
would
be
thrilled,
because
they're
they've
got
a
lot
of
enterprise
customers
unlikely
to
upgrade
to
npm
seven.
You
know,
while
it's
still
in
beta
or
rc
or
kind
of
even
just
early
yeah.
A
A
B
A
So
the
rrc
adds
support
to
plug
in
for
plug-in
dependencies.
I
know
that
roy
had
been
involved
in
this
discussion,
trying
to
rock
a
bit
about
the
ask
here
and
added
this
to
the
agenda.
Did
you
want
to
maybe
speak
a
little
bit
to
it
or.
C
Yeah,
it's
kind
of
an
interesting
ask,
and
I
just
follow
up
in
the
comments
there
and
the
end
of
the
day.
The
kind
of
short
version
that
I
managed
to
get
out
of
them
is
the
that.
What
what
they
really
want
is
some
way
to
be
able
to
install
something
without
touching
anything
that
is
inside
the
node
modules,
because
they
have
something
running
from
the
current
node
modules.
They
just
want
to
preserve
that
there
and
just
being
able
to
run
something
without
touching
their
local
node
modules
folder.
C
So
basically,
they
just
differ
into
the
global,
because
that's
kind
of
the
first
yeah
doesn't.
C
C
G
C
Maybe
maybe
the
answer
is
just
use
npx
instead
and
I'm
kind
of
inclined
to
say
so
from
what
I
learned
from
working
in
the
in
the
independent
this
past.
Well,
when
we
were
just
rewriting
the
npx
right,
I
think
if
we
define
packets
using
the
dash
dash
package
options,
it's
always
going
to
be
global.
Am
I
right
isaac
or
or
it's
still
preserved?
No,
it's.
B
Not
it's
not
global,
it's
kind
of
it.
It
unpacks
and
installs
it
into
your
cache
folder
and
runs
it
from
there.
Oh
okay,
so.
B
Yeah,
so
it
can
be
run
by
npx
and
you
can
even
have
multiple
versions
of
them
because
they're
all
they're
cached,
based
on
a
hash
of
the
result,
value.
E
E
I
think
there's
some
fundamental
misunderstanding
that
is
backing
this
request,
so
unless
you're
lazy,
requiring
or
reading
file
directly
from
it
during
your
long
running
process,
swapping
the
files
out
underneath
an
already
existing
node
thing
isn't
actually
going
to
break
anything.
So
if
they're
in
a
yeoman
generator-
and
they
are
reading
templates,
so
their
example
was
like
ioma
generator.
So
so
so,
if
they're
reading
templates
then
yes,
totally
swapping
the
template
out
from
under
the
process
could
mean
that
the
version
that
started
is
not
the
version.
E
That's
there
when
you
read
from
it
right,
but
like
yeoman,
doesn't
even
like
yeoman
generators.
Don't
install
other
generators
in
the
place
where
the
generator
is
being
run
from
anyway
right.
What
they
do
is
you
say,
I'm
a
general
generator
foo
and
I
depend
on
generator
bar
and
when
you
do
install
you
know,
install
global.
It
pulls
those
two
and
puts
them
in
your
global,
like
that's
the
way
that
people
typically
interact
with
yeoman
on
that
and
those
are
static.
E
And
then,
when
you
run
the
generator,
it
runs
in
your
where
you're
generating
the
code
to
so
adding
an
install
there
won't
affect.
I
think
what
they're
s
they're
seeming
to
think
now,
if
they
are
doing
something
like
that,
which
you
could
obviously
hack
together.
There's
other
reasons
why
that's
a
bad
idea
and
they
should
probably
just
take
a
different
approach
with
the
way
that
they're
setting
up
their
application.
E
So
I
don't
know
that
it
makes
a
lot
of
sense
to
have
a
feature
that
enables
hot
swapping
file,
read
like
things
that
you're
going
to
read
from
the
file
system
in
the
node
modules
at
runtime.
Like
that
right,
that's
really
the
ask,
and
I
don't
know
that
that
actually
is
like
a
good
practice,
so
so
adding
features
to
to
support.
That
seems
also
slightly
problematic.
D
Jordan
yeah,
I
mean
I
wanted
to
step
back
a
bit
and
say
in
general,
there
are
not
infrequent
requests
for
new
kinds
of
dependency
categories
and
I
feel
like
they
tend
to
fall
in
a
couple
distinct
buckets
one
is,
I
want
dev
variants
of
all
of
the
other
categories
which,
to
my
mind,
is
reasonable,
but
isaac
has
horrified
in
horrified
tones
explained
why
that
would
be
complicated,
and
so
things
around
that
you
know
kind
of
dev
versus
production.
Stuff
is
one
bucket.
Another
bucket
I've
seen,
which
I
think
is
worth
exploring
further.
D
Is
there
was
like
a
bin
dependencies
request,
which
was
essentially
like
things
that
I'm
gonna
run
as
command
line
tools,
and
I
don't
actually
need
them
or
want
them
in
my
node
modules
or
colliding
with
them
sort
of
like
a
package,
isolated,
global
dependency
pool.
D
You
know
so
things
around
those
use
cases,
and
then
the
third
bucket
is
kind
of
this
one
where
somebody
has
a
use
case.
That
seems
that
may
or
may
not
be
appropriate
or
a
good
practice
or
whatever,
but
it,
but
either
way
is
niche
and
rare,
and
they
are.
D
D
So
this
to
me
feels
like
that
exact
case,
which
is
which
has
already
been
covered
of.
Like
you
know,
west
set,
or
you
know,
there's
like
alternative
approaches
that
that
would
probably
avoid
the
shark
edges
and
it
definitely
seems
like
we
shouldn't,
like
npm
shouldn't,
be
in
the
business
of
supplying
features
for
edge
cases
ex,
like
as
a
general
rule,
and
that
it's
cool,
if
the
use
is
you
know,
doesn't
have
a
lot
of
impact
and
disruption
and
is
totally
reasonable
and
everyone's
like.
D
Oh
yeah,
that's
a
good
idea,
even
though
I
don't
have
that
use
case
like
it
seems
fine
to
make
case-by-case
exceptions
to
those
like,
like
the
app
id
thing
that
we've
been
talking
about
totally
reasonable,
totally
niche,
but
doesn't
disrupt.
Things
sounds
good
right,
but,
like
the
this
feels
like
it
would
be.
In
the
bucket
of
things
that
would
be
very
disruptful
or
disruptive
to
like
the
ecosystem
and
the
tooling
and
like
the
the
benefit
it
would
provide,
is
at
best
like
very
res,
like
it
would
be
restricted
to
a
very
small
number
of
use.
D
B
Yeah
in
in
general,
you
know
having
different
like
overriding
some
of
these
like
global
style
and
other
parameters,
install
parameters
tree
building
parameters
for
specific
dependencies
that
gets
that
breaks
my
brain
a
little
bit
to
think
about
how
we
would
do
that,
I'm
I'm
I'm
not
willing
to
say,
there's
no
use
for
it
or
that
it
there's
always
a
better
approach,
but
it
certainly
is
is
not
true
not
as
trivial
as
it
looks.
A
So
quick
note,
marcelo
or
marcelo,
I'm
not
sure
how
to
pronounce
your
name,
I'm
actually
just
joined,
and
this
is
their
proposal,
our
rfc,
I'm
not
sure
if,
if
you've
been
following
along,
but
would
love
to
get
your
a
quick
synopsis
of
sort
of
the
issue
that
we've
been
discussing,
which
is
the
issue
225.
A
G
Yeah
I
I
have
been
following
the
meeting
and
it's
kind
of
I
heard
about
you
know
the
proposal
about
an
ampfish
npx
and
that
would
be
some
solution.
Yeah.
We
could
currently
human.
This
was
kind
of
static,
but
we
wanted
to
add
a
way
of
kind
of
installing
another
generators
in
runtime.
G
So
so
we
implemented
a
kind
of
hiding
global
style
repository
and
then
we
load
the
generators
from
there.
So
our
npc's
idea
was
something
that
could
be
done.
In
my
opinion,.
C
E
Could
I
ask
a
probing
question
on
at
on
adding
this
feature?
Is
there
do
you
have
like
maybe
some
links
we
could
go
and
add
to
the
context
so
that
people
can
go
read
about
the
change
in
yeoman,
because
I'd
be
interested
in
just
knowing
what
the
use
case
is
for
like
a
at
runtime
install
of
another
generator
like
I'm
sure
it
probably
makes
sense,
and
I
just
don't
know
you
know
why
so
it'd
be
great.
If
I
could
learn
why.
G
E
I
think
having
that
link
might
help
me
understand,
because
I'm
not
I'm
just
generally
unfamiliar
with
jhipster,
and
why
my
and
my
yeoman
experience
is
maybe
a
few
years
old
now
so
also
that
might
be
something
where
I'm
missing
enough
context
to
be
able
to
fully
understand
the
ask
just
because
I
did
read
this
and
I
and
I
kind
of
follow
along,
but
I
it's
still
you
know,
I
think
I'm
still
missing
some
reading
some
code.
I
think,
would
definitely
help
me
understand
more
more
clearly.
G
A
So
I
think,
there's
a
couple
things
to
follow
up
there
and
maybe
if
we
can
take
a
couple
couple
pieces
of
this
feedback
and
actually
add
it
back
into
the
issue
itself,
the
rrc
and
then
to
your
point
right.
You
might
wanna
again
have
that
conversation
about
what
we're
gonna
do
with
mps
going
forward
and
there
might
be
some
work.
We
can
do
there
to
support
that
yeah.
C
A
Sure,
just
mindful
of
time
we
got
about
seven
minutes
left,
so
I'm
gonna
try
to
quickly
move
on
to
the
last
two
items.
One
should
be
pretty
straightforward,
since
I
think
there
was
general
consensus
around
the
rc
when
it
was
first
proposed-
and
I
just
wanted
to
see
if
we
need
to
take
some
action
on
that.
That's
rc,
217
added,
adding
essentially
per
per
package
registry
or
through
packet
organization
registry,
config,
yeah.
I'm
not
sure
what
the
next
steps
are
here.
C
B
Well,
we
can't
do
it
enough,
it's
hatch!
No,
because
it's
a
it's
new
api,
but
because
it's
strictly
in
config
it
doesn't
change
the
like
dependency
interface.
I
think
I
think
it
could
be.
It
would
be
a
patch
version
to
both
picoche
and
arborist.
B
B
That
different
registry,
but
but
it
won't
hurt
anything
right
like
it'll,
just
keep
behaving
the
way
it
does
now,
because
unknown
configs
are
just
ignored.
B
E
Although
it's
a
lot
easier
to
avoid
the
hazard
that
we
have
the
comment-
and
there
were
comments
pointed
out
from-
I
think
one
of
our
previous
meetings-
if
it's
in
a
major
right,
because
if
you
can
just
say
like
7.00
above
supports
this
new
thing,
and
I'm
just
going
to
put
that
in
my
engines
and
I'm
going
to
require
you
know-
I'm
gonna
add
a
check
for
7.0
and
above
if
you
have
to
have
it
as
like
a
you
know:
minor
release
somewhere,
everybody
who
is
like
gotta
debug
these
problems
when
they're
suddenly
pulling
the
package
from
some
place
they
didn't
expect,
has
to
remember
which,
which
minor
was
that
added
in
right.
E
It
just
increases
the
likelihood
of
the
impact
of
that
hazard
actually
surfacing
for
folks,
I
think
maybe
I'm
wrong,
but.
B
I
mean
I,
I
think
in
I
think
in
the
general
case,
you're
you're
right.
You
know
it's
it's
easier
to
kind
of
wrap
your
head
around
things
changing
or
being
different
in
a
major,
but
in
this
case
like
there
are
workarounds
they're,
just
really
tedious,
so
whatever
people
are
doing
today
to
get
around
this,
like
specifying
the
registry
manually.
B
You
know
applying
the
registry
to
the
scope
and
then
basically
you
have
to
apply
the
custom
registry
to
your
scope
and
then
kind
of
override
it
when
you
don't
want
to
do
that,
so
you
would
just
have
to
keep
doing
that
if
you're
using
7.0
or
you
know
whatever
miner
was
before
that
that
fix.
So
it's
it's
more
of
like
a.
I
think
it's
very
it's
a
very
strong
argument
for
like
in
your
dev
environment.
You
get
this
feature
and
it
really
doesn't
impact
anybody
outside
of
your
dev
environment.
C
E
I
definitely
don't
think
it's
worth
blocking,
because
this
is
such
a
valuable
feature.
I
I'm
just
picturing
the
rce
that
is
going
to
be
reported
at
every
single
major
company
when
their
one
dev
says.
Oh,
I'm
using
npm
7.1,
I'm
going
to
add
this
great
new
feature
that
pulls
my
single
package
from
my
custom
registry
and
then
like
their
teammates,
going
to
be
like
npm
install
and
at
npm
7
and
suddenly
they're
going
to
get
code
from
public
npm.
E
B
B
E
B
It's
it's
actually,
it's
less
of
a
hazard
than
you
think.
I
just
remembered
why
so
the
issue
here
is
they're
using
an
internal
registry,
but
they
have
one
particular
package
that
they
want
to
publish
to
public
npm
or
some
small
subset
of
packages
that
they
want
to
publish
open
source,
and
in
that
case
it's
what
they
want
to
be
able
to
do
is
have
that
package
be
scoped
to
the
public
registry,
so
go
ahead
and
remembering
correctly.
D
Yeah
so
isaac,
it's
also
the
reverse.
So
the
use
case
at
least
airbnb
had
when
I
left
a
year
ago,
is
everything
under
their
internal
scope
was
always
from
the
internal
registry,
and
we
could
easily
use
the
per
scope
registry
stuff
to
make
that
happen,
and
the
and
the
internal
scope
was
squatted
on
public
npm
so
that
there
wasn't
any
risk
of
conflicts.
D
However,
there
were
some
packages.
There
were
packages
that
predated
the
internal
scope,
and
the
internal
registry
had
some
sort
of
regex
to
say
well,
this
package
goes
internal
and
the
other,
and
otherwise
it
goes
external
and
it
was
something
like
airbnb
dash
or
something
right,
something
easy
to
figure
out.
But
then
we
also
had
an
internal
like.
D
We
also
have
external
packages,
airbnb
dash
prop
types
or
a
bunch
of
others,
and
those
needed
to
go
public,
and
we
also
have
internal
packages
like
esl
plug-in
something
or
other
that
doesn't
start
with
the
airbnb
prefix,
because
eslint
doesn't
allow
that.
So
we
actually
have
both
cases
where
we
had
to
have
very
complex
rules
there,
and
it
would.
I
I
think
west's
point
is,
regardless
of
the
the
degree
of
the
hazard
or
the
likelihood
of
of
the
use
case.
D
You
know
some
use
cases
are
going
to
have
a
huge
hazard
and
some
are
going
to
have
a
smaller
none
but
like
it
does
seem
like
it's
good
that
the
that,
if
you
do
the
correct
thing-
and
you
add
the
engine's
npm
field-
that
it's
good,
that's
great
right,
like
that's
the
correct
way
to
do
it,
but
it
does
seem
really
important
that
we
find
a
way
to
make
it
fail
loudly
in
earlier
versions
of
npm
and
not
just
7.0
or
likes
like
like
it
should
fail
on
npm,
six
or
five
or
four
or
one
like
it.
E
Right
because
remember
we're
not
super
worried
about
the
power
users
who
know
what
configs
to
check
and
exactly
how
to
do
it
we're
worried
about
the
people
who
don't
understand
what
this
setting
means
and
and
accidentally
think,
oh
yeah.
This
is
the
right
way
to
use
this
and
add
it
to
a
project
right.
So
it's
the
default
that
matters
the
most.
B
Can
can
I
ask
you
to
sort
of
elaborate
on
the
the
hazard
in
a
comment
on
the
rfc
pr.
E
B
A
Fine
yeah,
like
maybe
maybe
six
if
we
decide
that,
that's
what
we
wanted
to
do.
B
D
It's
kind
of
that.
That's
why
I'm
thinking
we
should
do
some
design
work
to
pick
something
that
just
will
fail
on
every
version
of
npm.
That's
ever
existed
because,
yes,
I
I
know
you're,
not
gonna,
update,
npm,
six
or
older
right,
but
like
we
can
surely
pick
something
that
was
always
invalid
in
the
first
place
like
this
is
reminding
me
of
like
javascript
spec
work
right
where,
if
you
come
up.
D
Always
invalid
syntax,
then
you
can
literally
do
anything
you
want
because
it
can't
have
possibly
worked
before
and
right
like
or
you
can't
have
done
the
wrong
thing
and
that's.
I
think
what
we
need
to
come
up
with
here
is
something
that
can
can
never
have
done
the
wrong
thing,
and
then
we
don't
have
to
worry
about
adding
a
warning
or
whatever
it's
just
either.
It
fails
really
loudly,
perhaps
with
an
inscrutable
but
googlable
error
message.
You
know,
or
it
works.
E
There
is
there
something
like
that,
though,
because
I'm
thinking
like
it's,
the
lack
of
the
config
being
respected,
which
is
the
problem
right,
so
the
only
way
would
be
is
if
the
config
lived
in
a
different
file
that
was
not
loaded
before
or
something
right
like
otherwise.
Well,
no,
even
then
right
because
it's
the.
D
You
know,
uses
fancy
config
colon
package,
name
that
can't
possibly
work
right
like
or
something
like
that,
like
there's
all
sorts
of
really
gross
terrible
things
we
can
come
up
with,
because
the
whole
point,
though,
is
that
this
is
a
power
user
feature.
So
it's
actually
okay,
if
it's
gross
as
long
as
it's
straightforward
once
you
understand
the
grossness
like
and
as
long
as
it's
true,
it's
achievable
to
see
the
grossness
and
then
somehow
figure
out
what
that
does
right,
like
googling
or
band
pages
or
whatever
so
like.
D
A
It
sounds
like
and
just
to
be
mindful
we're
over
time,
so
jordan
and
wes,
if
you
can,
provide
your
your
comments
back
and
I
apologize
I've
been
taking
most
the
notes,
so
I
have
paraphrased
quite
quite
a
few
folks,
so
definitely
feel
free
to
go
back
and
make
sure
that
these
notes
reflect.
You
know
the
sentiment
for
for
y'all
as
I've
as
I've
tried
to
to
document
it.
So
I
just
wanted
to
quickly
wrap
things
up.
A
Then
there
feel
free
to
keep
adding
rfcs
and
also
like
commenting
and
pushing
along
the
ones
that
we've
got
open
here
and
thank
you
for
for
jumping
on
again
today
and
we'll
be
back
next
week
with
another.
One
of
these
calls
thanks.
Everybody
bye-bye.