►
From YouTube: Open RFC Meeting - Wednesday, Nov 4th 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
on
youtube.
Thank
you.
Everyone
for
coming
to
another
npm
open
rfc
meeting
today's
date
is
wednesday
november
4th
2020.,
if
you
haven't
already
feel
free
to
add
yourself
to
the
hackmd
meeting,
notes
doc,
that
I've
shared
in
chat
and
we'll
be
following
along
in
the
agenda
that
is
pasted
there.
That's
from
issue
number
two
saying
four
from
the
npm
rfc's
repo
and
just
quickly.
A
I
want
to
note
that
any
correspondence
in
these
calls
and
on
the
rc's
themselves,
so
it's
all
under
a
code
of
conduct,
please
be
kind
and
mindful
of
each
other
as
we
speak
and
discuss
the
rfcs
themselves
and
please
raise
your
hand
if
people
are
talking
and
and
be
mindful
and
just
kind
in
these
discussions,
I
wanted
to
give
the
floor
to
anybody
for
any
announcements
that
they
might
have.
A
I
know
that
at
least
for
our
team,
we
shipped
another
patch
release
of
fpm7
yesterday,
so
that
is
7.08.
A
So,
if
you'd
like
to
get
that,
you
can
get
in
the
normal
ways.
Npm
install
dashi
npm
at
seven
to
grab
it
and
we're
continuing
to
have
a
cadence
of
almost
two
releases
weekly,
so
usually
tuesdays
and
fridays
have
been
the
cadence.
The
last
couple
couple
weeks
at
least
trying
to
address
the
feedback
of
everybody.
A
That's
using
mpm7
today
so
appreciate
the
usage
and
the
feedback
that
we're
getting
and
yeah
we'll,
hopefully
eventually
get
back
to
a
bi-weekly
cadence
once
once
things
settle
down,
probably
closer
to
the
end
of
the
year.
But
right
now
we
were
sort
of
cutting
at
releases
as
as
fast
and
furious
as
we
can.
So
that's
the
big
announcement
from
our
end
anything
else
that
I'm
missing.
A
Nope
cool,
so,
let's
jump
into
the
agenda.
The
first
item
on
the
list
is
rc
273,
npm,
workspaces,
config
management.
This
was
queued
up
by
roy
who's.
Also
coined
this,
I
think,
is
workspaces,
v3
and
I'll.
Let
him
maybe
speak
about
it.
A
little
bit
more
and
maybe
maybe
discuss
why
it's
good
to
have
these
things
in
threes
are
the
best
things
come
in
threes,.
B
Sure
yeah,
I
just
made
the
joke
during
our
stand
up
that
as
a
good
90s
kid
every
blockbuster
needs
to
come
in
a
trilogy
right.
So
I.
A
B
A
third
part:
three
rfc
for
the
workspaces,
but
no
that's
just
a
joke
like
there
might
have
more.
We
never
know
so
yeah.
Basically,
this
one
is
one
of
the
few
feedbacks
that
I've
kind
of
seen
around
for
workspaces
already
so
trying
to
tackle
the
specific
scenario
of
users
that
do
not
want
to
necessarily
tweak
their
package
json
files
themselves.
B
Like
a
lot
of
I
know,
a
lot
of
people
are
comfortable
with
just
using
a
workflow
where
you
npm,
install
npm
uninstall
and
let
the
client
take
care
of
the
package
js,
and
it
was
more
metadata
that
you
don't
want
to
touch.
So
this
is
kind
of
providing
that
for
the
workspaces
configuration
so
basically
enabling
people
to
add
list
remove.
B
B
The
rfc
is
a
very
short
one
and
start
collecting
feedback,
but
yeah
not
sure
about
the
order
of
the
work
if
we
might
end
up
working
on
this
before
the
second
one,
but
I
think
the
second
one
has
been
more
has
had
more
feedback,
so
probably
more
actionable
than
this
one.
So
this
one
will
probably
sit
for
a
while
to
collect
some
feedback
too
see
what
people
think
of
it.
And
yes,
it's
a
very
lightweight
one.
On
purpose,
we
I
want
to
gather
feedback
from
the
community.
A
B
B
Well
yeah,
I
was,
I
was
I
kind
of
had
some
ideas
about
that
too,
like
I
might,
I
might
update
the
rfc
later
on
with
them,
but
basically
like
enabling
you
like,
enabling
a
way
to
declare
analyze
or
a
group
by
adding
a
an
argument
like
group
and
then
a
name.
So
that's
that's
the
thing
you're
defining
would
go
under
that
group,
but
that's
a
separate
one.
I
just
wanted
to
surface
the
base,
the
very
basic
functionality
for
managing
the
the
workspaces
key
in
the
package.json.
C
Then
what
the.
C
C
If
my
glob
pattern
is
packages
star,
which
is
likely
to
be
the
most
common
and
then
I
want
to
explicitly
ignore
packages,
slash
tests
or
packages
slashed
example
or
something
what
happens
if
my
glob
is
packages
star
and
I
do
workspace
rm
packages,
slash
test.
C
C
Add
packages
star:
do
you
add
the
glob
pattern,
or
do
you
blow
up
the
glob
and
probably
lose
my
intention,
which
is
that
all
future
packages
in
that
folder
will
be
added
so.
C
C
The
question
I
would
ask
myself
is:
what
would
I
do
with
the
config
manually
and
what
I
would
probably
do
is
add
glob
patterns
like
everywhere,
I
can
and
use
like
a
bang
or
something
to
exclude
the
things
that
I
knew
I
didn't
want
in
there,
and
I
you
know
like
thinking
of
the
few
current
use
cases
I
have
pretty
much.
All
of
them
would
be
packages
star
and
all
of
them
would
have
some
form
of
bang
packages,
slash
tests
or
something
like
that.
C
You
know
if
you
would
have
example
repos
in
there
that
I
don't
want
to
you
necessarily
be
included
or
whatever
and
similarly,
but
then
like
the
additional
wrinkle.
Is
that,
like
I
actually
want
my
packages,
slash
tests
to
be
considered
a
workspace
for
installing
but
like
I
might
not
want
them
to
be
publishable
and,
like
it
kind
of
there's
a
lot
of
questions.
I
think
that
that
are
unanswered,
that
this
starts
to
dip
into,
which
is
like
the
usability
around
these
things.
C
Right
so
like
ls,
makes
perfect
sense
to
me,
but
like
like,
when
I
use
lerno,
what
I
usually
do
is
I
say
that
a
bunch
of
things
are
packages,
but
I
want
bootstrap
to
only
do
like
to
not
do
the
root.
So
like
I
in
learn,
I
have
root
as
one
of
the
packages
because,
like
usually
my
like
repo
docs,
are
in
the
root,
and
I
want
to
lint
those
as
part
of
my
like
run.
C
All
the
workspaces
test
commands
command
right,
but
I
want
bootstrap
to
ignore
the
route,
because
npm
and
stall
already
populated
that
and
things
like
that
and
there's
a
way
in
learn.
I
can
do
that
and
similarly
like,
if
I
wanted
to
run
a
workspace,
publish
everything
command
I
would
want
like.
I
would
want
it
to
be
a
little
smarter
than
like.
Don't
just
you
know,
looking
at
the
private
truths,
I
would
want
to
be
able
to
like
target
things
more
granularly,
and
I
I
don't
know
it.
C
B
I
know
that's
great,
I
think,
and
that's
the
reason
why
I
opened
it
right.
So
it's
great
thank
you
yeah,
but,
to
be
honest,
I
don't
know
it
might
be
that
we
end
up
in
a
position
where
maybe
adding
remove
just
does
this
very
simple
thing
of
adding
and
removing
entries
from
that
array
and
that's
like
kind
of
solve,
like
you
know
the
problem,
the
problem
field
for
80
of
users
and
the
other
20
so
like
it's
probably
easier
to
manage
manually,
but
I
want
to
have
that
conversation.
That
is
a
very
good
point.
D
I
think
that
the
you
know
if,
if
we
were
going
to
say
that
you
know
we're,
never
adding
any
more
config
to
package.json
other
than
like
a
list
of
packages
or
that
list
of
packages
is
never
going
to
be
any
more
sort
of
fancy
than
it
currently
is
just
like
a
list
of
globs
then
add
and
remove
just
as
a
way
to
add
and
remove
things
to
that
list,
so
that
you
know
you,
don't
you
don't
like
misspell
the
word
workspaces
or
something
is,
is
pretty
reasonable.
D
I
think,
though,
if
we're
going
to,
we
need
to
kind
of
be
cognizant
of
the
fact
that,
if
we're
going
to
add
new
sub
commands
that
are
sort
of
blessed
ways
to
modify
this
thing,
that
we
have
a
clear
understanding
of
what
configs
we
want
it
to
to
be
to
be
having
there,
you
know
what
I
mean,
because
we
don't
want
to
kind
of
paint
ourselves
in
a
corner
with
that
another.
D
You
know
the
the
counter
argument
to
my
counter
argument
is:
maybe
we
want
it
to
be
simple,
and
if
we're
talking
about
adding
a
config,
that
means
we
have
to
have
a
much
more
complicated
command
semantics
like
maybe
we
should
just
not
add
that
config
or
not
have
the
command
the
the
helper
commands
know
about
it.
So
it's
like
look.
If
you
want
to
go,
do
something
fancy?
That's
fine!
You
just
you
have
to
add
a
json
in
your.
You
know
in
vim
or
whatever.
E
A
Okay,
I
apologize
cool.
No,
I
appreciate
roy
you
bring
to
us
this
this
up,
and
this
definitely
makes
sense
sounds
like
there's
already
like
some
good
good,
like
details
about
this.
That
would
maybe
round
out
the
workspace
implementation
so
yeah.
D
Well,
if,
if
a
simple
added
remove
doesn't
meet
some
use
case
great,
what
what
kind
of
config
setup
in
package
json
would
meet
that
use
case,
and
you
know,
is
that,
is
it
too
complicated
or
is
that
you
know,
should
we
just
say
like
look,
you
got
it
like
tough,
you
don't
get
to
use
packages
star
if
you
want
to
have
fancy
ignore
stuff,
or
do
we
want
to
maybe
like
tweak
the
the
settings
that
we
let
you
put
in
package
json
and
then
kind
of
circle
back
and
say:
okay,
now,
how
do
we
add
a
helper
command
to
do
that
efficiently,
yeah.
A
D
C
D
A
Oh
cool
we
do
have
like
there
is
precedent
for
files
in
like,
in
terms
of
files
to
ignore,
like
files
to
include
yeah.
B
D
C
Inspired
programmatically
alters
the
files
field
currently
right
so
like
what
happens,
if
you
do
workspace,
add
after
I
have
packages
star
and
bang
packages
slash,
you
know
example
dash
star
and
then
I
do
workspaces.
Add
packages
example
dash
special
right
like
is
there,
I
don't
think,
there's
a
bang
bang,
I
don't
know.
Maybe
that
works
but
like
it
would
seem
really
unintuitive
to
me.
B
C
Ibm
files
add
yeah,
and
I
think,
if
you've,
if
we've
solved
or
answered
all
these
questions
for
one
of
them,
certainly
it
answers
the
answers
them
for
the
other
one
yeah,
but
it
seems
a
difficult
problem
to
solve,
because
the
thing
that
people
will
expect
is
not
always
going
to
be
universal
and
the
thing
that's
pragmatic
to
implement
is
not
always
going
to
match
the
things.
People
expect
right.
B
B
Yeah,
it's
just
about
managing
the
the
key
workspaces
in
your
package,
jason,
so
yeah.
It
will
probably
cater
to
the
to
the
public
that
really
don't
want
to
deal
with
any
of
the
internals
right
now.
Just
show
me
the
commands.
I
just
run
it
and
use
them
right,
but
yeah,
so
it
is
very
much
a
reality
that
we
might
just
decide
that
this
is
not
worth
implementing
right.
So
I
pointed.
D
D
Or
not
implementing
now,
like
you
know,
until
the
until
the
feature
is
a
little
bit
more
mature.
I
think
that
there
are,
you
know,
there's
other
things
besides
just
adding
removing
and
listing
workspaces
which
which
we
should
probably
put
under
that
same
npm
workspaces
command.
D
You
know,
like
we're,
you
know
running
tests
to
running
tests
within
a
given
workspace,
for
example,
or
just
rebuilding
a
particular
workspace,
so
yeah-
and
I
I
think
you
know
if,
if
adding
and
removing
like
as
long
as
like
the
first
step
is
make
it
semantically
do
what
you
say.
So
if
I
do
npm
workspaces,
add
packages
star
and
then
follow
it
with
npm
workspaces,
remove
packages
test
that
should
take
me
into
a
state
where
everything
in
packages
other
than
test
is
listed
as
a
workspace
right
right,
then
the
next
step
is
okay.
D
You
know,
we've
just
created
a
you
know
a
glob
pattern
and
also,
if
I
add
a
new
thing
to
packages
that
isn't
named
test,
it
should
automatically
be
picked
up.
A
follow-on
kind
of
enhancement
to
that
is
make
it
so
that
if
I
read
the
package.json
file,
I
will
understand
that.
That's
what's
happening,
you
know
to
your
to
your
subsequent
point.
Jordan,
like
you,
don't
want
to
have
you
know
kind
of
nightmare
of
of
programmatically
generated
globs.
D
You
know
if
you,
if
you
look
at
if
you
look
at
the
the
actual
like
regexes
and
gloves
that
are
programmatically
generated
for
stuff,
like
npm
pack
list
and
and
no
december,
and
some
of
these
other
things
like
it'll
it'll
make
your
hair
curl.
So
we
definitely
don't
want
to
like
expose
that
to
users
who
are
just
trying
to
get
their
work
done.
C
A
Right
so
I
just
posted
in
chat
based
on
the
rfc
for
workspaces
v2,
so
I
just
stole,
like
the
workspace
filter
that
you
have
there
roy.
So
what
would
happen
in
the
case
of
like
npm
in
it?
Wouldn't
that
be
like?
Could
you
in
it
a
new
workspace
like
with
that?
Maybe
no,
I
don't
modify
in
it
to
support.
A
D
We
could
also
do
I
mean
if
we
had
an
ad
command
or
we
just
had
some
some
way
that
we
understood
how
we
programmatically
add
a
workspace.
We
could
add
a
npm
workspace,
init
command,
which
then
yeah
you
know
lets
you
will
will
like
run.
You
know,
create
react
app
or
whatever
init
runner.
You,
you
suggest,
ask
you
for
the
name
of
the
workspace
to
be
added
and
then
do
all
of
its
stuff
within.
C
Floodgates
of
all
of
the
existing
valid
use
cases
for
well,
I
have
these
17
bespoke
commands.
I
want
to
run
in
specific
workspaces.
How
do
I
do
that?
Does
it
I-
and
I
forget-
maybe
this
was
answered
in
the
original
rfc
but
like
if
I
want
to
run
an
arbitrary
command
in
a
specific,
alias
or
a
specific
pattern,
or
something
like
how
do
I
do
that.
D
D
This
would
be
adding
an
init
sub
command
to
the
npm
init
or
to
the
npm
workspaces
right.
But
then
you
have
to.
B
No,
but
I
think
you
might
be
touching
this-
the
point
of
the
second
workspace
that
that
brings
all
the
commands,
but
enabling
workspace
flag.
Like
the
rsc
pointed
there
workspace,
and
then
you
put
on
the
name
of
the
workspace,
you
want
to
run
the
command
on
and.
C
C
Already
gives
me
for
learn,
and
so
that's
sort
of
what
I
want
for
npm
workspaces
is
run
this
arbitrary
shell
command,
that
npm
has
no
business
understanding
or
dealing
with
in
the
appropriate
directories
that
match
my
workspace
config
in
parallel.
You
know
with
appropriate
output
and
exit
codes,
like
that's.
C
Weird
to
me
at
all,
it
seems
totally
like
something
you'd
want,
but
like
and
and
then
of
course,
the
next
step
is
somebody
trying
to
volunteer
me
to
write
an
rfc
which
is
fine
but
like
the
I
guess,
what
I
mean
is
that
that
seems
like
the
that
it
would
sort
of
obviate
all
the
questions
around
well.
C
D
D
It
is
also
there
so
there
is
a
npm
explorer
command
which
will
take
an
arbitrary
you
can
run
npm
explorer
foo
and
that
will
drop
you
into
a
sub
shell.
Underneath
your
foo
package
right
like
in
that
folder
and
if
you
run
npm,
explore
food
dash
dash
cat
readme.json,
it
will
or
read.md
like
it'll,
do
that.
D
True,
but
what
I'm
saying
is
like
the
the
precedent
for
like
go
into
this
folder
and
then
run
this
arbitrary
command
like
we
have
code.
That
does
that
it's
not
like
it's
not
like.
That's
a
you
know
completely.
Ridiculous
idea
is
what
I'm
saying
right.
A
Cool,
so
I've
been
trying
to
take
notes
here
at
the
same
time
as
jumping
in
so
apologize.
If
my
my
note
taking
is
off
I'll,
have
to
clean
them
up
after
this
but
yeah.
This
is
a
good
start
to
the
conversation.
Obviously,
if
folks
can
can
add
some
some
comments
and
some
feedback
actually
in
the
rca
itself,
that'd
be
great.
I
know
this
is
sort
of
planning
for
the
the
future.
This
might
be
something
we
keep.
A
You
know
in
the
next
couple
months,
so
yeah
appreciate
any
feedback
on
it.
So
yeah.
Let's
move
on
to
the
next
rc,
though
number
272,
adding
prefer
dev
field
to
package
chase
pacu
json
by
guindon.
A
I
do
not
think
they
were
able
to
join.
I'm
not
sure
if
anybody's
had
a
chance
to
look
at
this
I'll
paste,
the
link
to
the
rfc
since
it
was
opened
yesterday.
C
I
I
didn't
comment
this
on
it.
I
looked
at
it
yesterday
but,
like
my
immediate
question,
is
that
some
things
like
it's
the
there's
a
lot
of
things
that
should
be
dev
depths
but
like
are
also
dependencies
of
other
stuff.
So,
like
the
examples
in
this
specific
pr,
typescript,
tslint
eslint,
let's
say
right
are-
are
kind
of
like
top
level
command
line
tools,
and
in
this
case
that
makes
sense
right
that
they're
pretty
much
always
dev
depths
but
like
they
might
be.
C
So,
like
I
kind
of
like
feels
strange
to
me
because,
like
prefer
global,
was
a
problem
for
similar
reasons
right,
which
is
that
that's
not
something
that
the
pa
it
turns
out.
That's
not
something!
The
package
author
actually
has
the
the
expertise
to
know
about
it
about
itself.
Right.
Like
the
package
author
can
know,
I'm
an
executable,
but
that
is
not
the
same
as
I
should
be
installed
globally
and
for
there's
many
other
reasons.
Why
prefer
global
fell
out
of
vogue?
D
Yeah,
I
I
agree
with
you.
I
think
this
is.
I
prefer
dev
as
sort
of
overly
presumptuous
for
a
package
author
to
to
specify
for
exactly
the
reasons
you
you
list,
and
you
know
the
the
other
thing
is
that,
like
there's,
there's
effectively
for
things
that
are
not
published
to
the
npm
registry,
like
there's,
really
no
difference
between
dev
and
prod
depths
right,
it's
just
like.
D
Do
it's
basically,
just
like
a
an
arbitrary
field
for
like
you
know
that
you
can
exclude
those
if
you
want
as
part
of
your
deployment,
but
there's
quite
a
lot
of
apps
out
there
that
just
install
everything
as
regular
depths.
D
You
know
webpack
being
one
of
them
and
one
of
the
you
know
what
they
do
with
their
ci.
Is
they
they
run
a
build
and
then
push
the
push
the
assets
up
to
a
cdn
or
something
like
that's
an
extremely
common
use
case.
So
if
we
said
well,
you
can't
have
webpack
has
to
be
a
dev
depth.
D
I
don't
know
it
just
feels
like
it's
adding
friction
without
much
value
and
if
the
only,
if
the
only
benefit,
if
the
only
benefit
here
is
like
loading,
the
size
of
node
modules
yeah,
I
don't
know
it
seems
kind
of
like
an
easy
enough
thing
for
the
consumer
to
to
manage.
If
they
care
about
that
and
if
they
don't,
then
okay,
they
don't
care
about.
A
A
C
An
rfc,
but
something
was
brought
up
about
like
bin
dependencies
at
one
point
and
the
the
without
getting
into
the
details.
The
rough
concept
is
things
that
are
run
that
my
package
needs
to
run
as
a
command
line
tool.
C
D
Yeah,
even
that
case
I
mean
yes,
you
don't
need
73
copies
of
webpack
and
react,
and
you
know
anything
else
on
your
on
your
machine,
but
I
don't
I
mean
if
they
each
have
slightly
different
versions
or
you
know
other
thing
other
peer
depths
that
get
resolved
like
you're.
You
kind
of
do
need
to
have
73
different
copies
here
and
to
the
extent
that
they
are
the
same
versions
or
the
same
contents
within
those
versions
like
that
seems
to
be
better
addressed
by
really
tackling
that.
D
You
know
the
problem
of
repeated
depths
head
on
like
who's
to
say
you
need
73
copies
of
of
mcderp
on
your
machine
either,
even
though
that
may
be
a
production
dependency,
that's
fair!
So
I
I
think
that
like,
if
we're
going
to,
if
we're
going
to
unify
it
like
what
that
looks
like
is
something
more
like
tinker,
pnp
and
and
not
like
forcing
stuff
to
be
dev
depths
the
the
furthest.
D
I
would
be
willing
to
go
if
there
was
like
really
strong
consensus,
for
it
would
be
that,
if
preferred
dev
is
true,
then
we
might
warn
if
you're
not
explicitly,
saving
saving
prod
but
yeah
doing
more
than
a
warning
feels
way
over
the
line
and.
D
Feels
like
kind
of
a
I
don't
know
just
noise
without
a
lot
of
signal.
C
Well
and
you'd
want
that
warning
to
only
show
up
for
the
top
level
package
like
for
the
person
who's,
adding
that
thing
directly
as
a
dep
and
you'd
never
want
anyone
like
you'd
never
want
any
anyone
using
standard
to
see
the
warning
about
standards
used
to
be
slim.
D
Right
right
and
that's,
that
is
how
this
is
phrased.
It's
just
when
you're
installing
the
library
with
preferred
have
equals
true
and
you're
about
to
save
it
as
a
production
depth.
Then
it
would
throw
unless
you've
explicitly
set
safe.
E
So
just
to
add,
though,
I
understand
that
it
might
feel
like
a
little
bit
of
a
reach,
but
this
is
definitely
something
that
happens
all
the
time
right
like
I,
I
very
regularly
see
something
and
I'm
like
that's
not
supposed
to
be
a
proud
death
and
it
doesn't
hurt
anybody
but
like
it's.
This
is
a
real
problem,
so
maybe
you
know,
maybe
there
is
some
validity
in
in
throwing
in
a
warning.
D
Yeah
a
warning
is
a
warning
is,
like
I
said
like
that's.
I
could
see
the
case
for
that
it
would.
It
would
help
a
lot
of
a
lot
of
devs
from
accidentally
adding
something
that
should
probably
be
the
dev
depth
and
especially,
if
there's
like
a
clear
way
to
ignore
that
warning
by
saying:
no,
no,
I
really
mean
it
like
don't
yell
at
me.
E
D
Right
so
this
would
be
when
you're
yeah.
I
guess
that's,
I
guess
that
is
ambiguous.
I
I
interpreted
it
when
installing
library
with
preferred
developers
true
as
a
production
dev,
I
kind
of
interpreted
that
as
like,
if
you're
doing,
npm
install
foo,
but
not
you
know
like
if
you're
about
to
save
it
to
your
package.json.
Basically.
E
A
Awesome
three
maybe
put
some
feedback
in
there
see
itself.
Then.
D
A
Just
that
as
a
label
for
that
awesome,
just
want
to
be
mindful
of
time.
Since
we
have
25
minutes
left-
and
I
know
we've
got
four
more
yeah
so
just
want
to
move
on.
If
there's
any
other
thoughts,
feelings
feel
free
to
back
there
moving
on,
though
issue
number
264,
so
our
the
rrfc
for
optional
files,
key
and
package
lock
to
specify
the
files
to
include
in
node
modules.
A
This
is
by
raffy
I'll
link.
The
issue
itself
in
case
folks
haven't
seen
it.
This
is
opened
last
week
or
two
weeks
ago.
Sorry.
D
So
this
I
I
really
like
I
mean
just
come
out
of
the
gate
here.
I
really
like
the
the
use
case
here
and
I
like
the
the
command
like
npm
installed
files
equals.
You
know
some
list
of
things.
What
I
don't
like
about
it
is
putting
that
in
package
lock,
json,
because
that
is
ephemeral
and
and
can
like
cause
problems.
I
think
what
might
be
a
better
thing
to
sort
of
spend
some
time
bike
shedding
would
be.
D
D
D
So
I
could
see
this
having
some
unfortunate
side
effects
if
there
are
multiple
dev
depths,
but
we
could
always
sort
of
unify
all
of
the
files
of
all
of
the
things
that
depend
on
it,
and
if
you
have
only
one
thing
depending
on
something
and
it
has
a
restricted
file
list,
then
we
only
unpack
those
ones.
That
would
not
be
too
hard
to
do.
C
Yeah,
so
I
agree
with
your
general
feedback
there
isaac,
but
I
think
that
it's
a
very
bad
idea
to
give
consumers
the
ability
to
add
api
constraints
which
are
which
files
are
included
in
other.
A
C
Like
the
the
rfc
rfc
here
says,
like
advanced
users
of
react,
might
know
what
files
who
know
what
files
they're
using.
I
don't
think
that
any
user
of
any
package
should
be
considered
advanced
enough
to
know
what
files
they
need
without
actually
having
read
all
the
source,
which
is
an
untenable
requirement,
and
I
also
like,
if
somebody
like
it's
if
somebody
installs
this,
but
but
like
in
version
1.1.
C
You
know
this
file
has
no
requires
and
in
version
1.2
it
adds
some
requires,
then,
all
of
a
sudden
if
they
rerun
the
install
with
that
files
command
or
if
this
is
stored
in
the
meta
meta
field
or
whatever
that,
like
all
of
a
sudden
that
would
break
and
then
you
would
be
on
the
user
just
to
solve
it.
But
it
would
also
be
on
the
maintainer
to
field
that
bug
report.
C
I
I'm
wondering,
if
maybe
an
alternative
is,
is
to
allow
package
authors
to
specify
like
file
groups
that
then
the
user
could
opt
into
because
that
way
deciding
which
files
are,
which
is
a
decision
left
to
the
only
person
with
the
context,
to
know
that
the
package
author,
but
the
dis.
But
the
decision
to
like
opt
into
essentially
like
you
know,
preset
prunes
at
install
time
is
it
seems
like
something
that
is
safe
for
a
consumer
to
choose
and
could
totally
go
in,
like
the
peer
dependencies,
meta
field
or
some
similar
field.
D
Yeah,
I
mean,
I
guess
the
the
thing
is
like
we,
we
sort
of
do
have
a
way
to
specify
file
groups
that
you
that
you
include
in
your
package
right
and
you
want
to
have
multiple
file
groups.
Well,
good
news.
You
can
have
as
many
packages
as
you
want
and
each
one
has
its
own
group
of
files.
You
know
lowdash
does
this,
it's
it's
not
uncommon
at
all
right
and
then
we
we
even
like
automatically
include
the
documentation
for
each
one
of
those
file.
C
Groups
without
overrides,
though
the
package
name,
is
something
that's
important
because
it's
used
throughout
the
graph
so
with
overrides.
I
think.
That's
a
completely
reasonable
response
to
say
just
use
different
packages
and
react
should
publish
a
different
package
for
it's
like
production,
minimizer.
D
C
Slash
like
like
I'm
saying
that,
like
I
hear
what
you're
saying
as
as
if
they
had
done
that
in
the
first
place,
then
everything
would
be
fine,
but
since
they
didn't
and
without
overrides
available,
it's
not
really
practical
to
tell
the
ecosystem
to
shift
its
require
import.
Specifier
patterns,
I
mean,
as
you
mentioned,
lowdash
there's
been
a
lot
of
back
and
forth
about
like
in
some
code
bases.
Do
you
import,
curly,
brace
throttle
from
lowdash,
or
do
you
import
throttle
from
lowdash.throttle,
you
know
and
so
on?
C
D
D
D
You
can
quite
easily
list
something
as
a
bundle,
dependency
and
add
it
to
your
git
repo
and
then
just
don't
add
the
files
that
you
don't
need
and
the
the
result
will
be
that
when
you're,
when
your
thing
is
installed,
it'll
have
a
bundled
version
of
react,
which
is
only
these
this
one
file
that
doesn't
work
for
peer
dependencies,
obviously
because
it's
going
to
be
under
your
packages,
node
modules
folder,
so
with
react.
Specifically,
probably
it's.
D
Yeah,
I
might
be,
I
might
just
have
a
callus
over
that
particular
pain
point,
because
the
npm
client
does
this
right.
Yeah,
it's
not
trivial,
but
it's
also.
C
Sort
of
not
the
end
of
the
world.
Well,
I'm
not
familiar
with
that
many
things
outside
of
npm
itself
that
do
this,
so
I
also
suspect
that
it's
a
pain
point
that
is
somewhat
uniquely
experienced
by
the
clyde
team.
D
A
Like
does
over,
like
is
the
burden
not
on
the
end
user,
anyways
like
to
maintain
this
file
list
in
case
the
package
that
they've
installed
has
changed
where
these
files
are
living,
and
in
that
case,
would
it
not
be
like
would
not
overrides?
Essentially
you
like,
creating
an
alias
for
like
a
mafi
version
of
that
depth
like?
Would
that
not
solve
for
what
this
they're
trying
to
do
here?.
D
A
D
Like
yeah,
it
does
turn
the
internal
details
of
a
you
know:
we've
kind
of
treated
like
the
the
specific
files
underneath
a
particular
package
as
implementation
like
internals
right
right
and
technically
it
can.
C
C
Files,
because
you
can
have
you,
can
like
define
the
x
the
required
interface
and
like
it,
can
map
to
literally
any
folder
structure
you
want
so
you
like
on
before
experts
exports.
You
could
look
at
your
use
of
a
package
and
you
could
absolutely
infer
how
the
file
system
was
structured
like
inside
that
node
modules
folder.
You
can
no
longer
do
that.
So
it
feels
like
the
world
where
consumers
have
the
ability
to
decide.
Files
is
far
different
and
like
in.
D
D
A
D
A
You're
gonna
have
to
maintain
like
that
that
override
right.
A
Exactly
exactly
like
you're,
maintaining
a
file
list
here
that
might
change
based
on
the
distribution
like
changing
so
yeah
cool.
So
let's
move
on
then
to
our
rse
250,
provide
the
possibility
to
reference
license
file.
I
know
we've
talked
about
this
before
a
little
bit
and
I'll
paste
the
issue
so
yeah.
We.
D
We
talked
about
adding
a
license
file
field.
I
think
in
last,
in
our
last
call
license.
File
is
better
than
license
url.
Just
because
license
the
the
thing
can
change
without,
like
the
license
of
the
thing
can
change,
and
then
you
have
one
url
that
you
want
to
update
and
it
you
can't
change
what
it
applies
to
if
you
get
into
those
conflicts
really
quickly.
A
D
Yeah,
I
think
the
I
mean
my
my
sense
on
that
is
like
okay,
if
you
have
multiple
license,
files
like
speed
x
has
a
way
to
do
that,
and
you
can
specify
a
license
file
with
either
the
default.
One
of
those
that
you
want
people
to
use
or
a
file
that
says
here
are
the
three
licenses,
or
here
are
the
three
license
files
having
having
multiple
having
that
field,
be
an
array
feels
a
little
excessive.
D
That
said,
we
could
make
it.
You
know
a
string
or
an
array
like
we
do
that
with
some
other
things
anyway,
it's
not
such
a
big
deal.
I
sort
of
feel
like
this
is
this
reminds
me,
though,
of
like
back
when
we
have
the
repositories
field,
because
people
had
multiple
repos
for
a
given
package
and
ultimately
it
was
just
kind
of
more
of
a
headache
than
anything
else,
and
it
was
rather
painful
to
sort
of
walk
that
back.
D
C
I
don't
even
think
we
need
this
like
if,
if
we
specif,
if
we
allow
a
user
to
then
name
their
license
file,
something
different,
then
that
also
means
that
github
will
not
auto
detect
it,
and
presumably
other
repo
providers
also
have
some
form
of
license
heuristics
right.
So
by
adding
this
field
like
we're,
we're
either
creating
confusion
or
additional
cost
on
all
those
other
platforms.
C
C
D
Because
you
may
have
so
it's
it's
not
uncommon
to
have
like
license.
Hyphen
gpl
license
hyphen
mit.
C
C
Talked
about
last
week,
you
can
make
a
license
dot,
md
file
that
says
for
gpl
click
here
for
mit
click
here
and
then
name
them
whatever.
You
want
yeah
yeah
exactly
so
so
like
what
is
the?
What
is
the
case
where
it's
actually
doing
anything
except
saving
a
click,
perhaps
for
having
a
differently
named.
C
File
like
adding
a
new
field
to
package.json,
adding
a
new
requirement
for
all
license,
based
tools
which
includes
hosting
like
platforms
like
for
this,
like
that's
a
lot
of
cost,
because
this,
the
very
tiny
percentage
of
dual
lines
license
packages,
might
want
different
license
files
and
might
want
to
avoid
having
an
extra
click
through
a
like,
centralized
file
like
it.
Doesn't
I
don't,
it
doesn't
feel
worth
it
to
me.
D
Yeah,
I
think,
if
we
end
up
having
to
you
know
we
end
up
requiring
that
the
file
be
named
license.something
anyway,
like
we
already
auto.
C
D
C
D
Wow,
jordan
you're
shutting
them
shutting
them
down.
Today,
I
feel
like
I
feel,
like
everyone
pitching
the
new
features
and
you're
telling
me
to
do
less
work.
This
is
great.
C
Sorry,
I'm
not
trying
to
shut
things
down
right
like
these
are.
These
are
use
cases
worth
solving
and
I
think
clearly,
like
the
license
field
should
have
been
built
in
the
first
place,
to
accept
either
a
spedix
string
or
an
object
that
included
a
file
path
pointer
right
but
like,
given
that
it
wasn't
the
cost
to
transition.
To
that
feature.
Set
seems
not
worth
it
to
me
is
where
I'm
going.
D
No,
no,
that's!
That's
fine!
I'm
busting
your
chest
a
little
bit,
so
I
think
yeah,
like
the
reason
why
we
did
not
go
with
an
object.
There
is
because
speedix
has
this
c
license
in
file
name
field
right,
so
which
is
not
ideal,
but
it's
sort
of
it's
it.
It
makes
the
tooling
have
to
work
a
little
harder.
D
D
D
A
So,
let's
move
on
then
to
second
last
item:
that's
on
the
agenda
today,
rfc
217,
so
this
is
we've
discussed
this
multiple
times
ad
registry
per
package
per
organization
config.
So
I
know
this
has
come
up
quite
a
few
times
I'll
paste,
the
pr
for
folks,
I'm
not
sure
if
anybody's
posted
last
week
or
after
our
call
last
week,
I'm
not
sure
if
anybody
posted
on
the
actual
issue
itself.
D
E
I
think
there
was
some
exploration
that
needed
to
be
done
on
what
it
would
take
to
do
like
a
file
like
a
registry
spec
thing
too
right.
Yes,
wasn't
it
like?
We
were
saying,
there's
like
at
first,
we
were
saying:
there's
two
options
and
then
it
was
like,
but
we're
never
gonna
do
one
of
the
options
so.
D
Well,
it's
it's
not
that
we're
never
going
to
there.
There
are
some
other
use
cases
addressed
by
it,
but
it
is
a
little
bit
more
of
a
hazard.
B
A
Yeah
it
just
yeah,
let
it
sit,
let
it
mellow
okay.
Well,
then,
we
only
have
about
five
minutes
left.
Then
there
was
the.
The
very
last
item
has
also
been
brought
up
before
a
few
times,
which
is
rc
138,
and
this
is
add,
configurable
data
to
http
header.
A
I
will
paste
that
for
folks
and
I
think
we're
still
waiting
on
this
to
be
updated.
As
far
as
I
remember,
the
examples
in
the
rfc
itself
are
outdated,
so
I
don't
think
mark's
been
able
to
join
the
last
few
meetings.
So
I'm
not
sure
if
he's
had
time
to
look
at
this,
I
think
that's
the
update
there
is
that
we're
waiting.
So
the
actual
examples
in
the
rfc
match
the
expectation
of
how
the
any
file
looks
is
that
right.
A
Okay,
this
is
something
we
could
also,
if
we're
okay
with
like
accepting
it,
we
could
potentially
modify
that
on
their
behalf
and
land.
It.
D
Yeah
I
just
haven't
having
gotten
around
to
taking
a
crack
at
a
implementation
of
this.
It
sort
of
just
works
in
npm
six.
It
does
not
work
in
npm
seven
today,
just
because
of
the
the
way
that
we're
a
little
bit
more
restricted
in
which
configs
we
pass
through
which
dependencies
yeah
yeah
yes,
so
we
would
have
to
kind
of
add
it
to
that.
To
that
flat
options
include
list.
A
Okay,
I
mean
we
don't
have
to
have
the
implementation
ready
to
agree
that
we're
going
to
do
it,
but
and
if
it
works
with
ipm6
yeah.
D
A
For
sure
cool
is
there
anything
else.
A
I
think
we
didn't
get
to
this
week
that
we
might
want
to
make
sure
we
get
to
next
week
any
anything
that
wasn't
on
the
agenda.
That
folks
want
to
add.