►
From YouTube: Open RFC Meeting - Wednesday, March 24th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live.
Thank
you.
Everyone
for
joining
us
again
on
another
npm,
open
rc
call.
Today's
date
is
wednesday
march
24th,
24th
2021
we'll
be
following
along
in
the
agenda
that
was
posted
in
the
rfc's
repo
issue,
number
346
and
just
in
case
you
haven't
already
got
access
to
it.
I
will
be
copying
and
pasting
spamming.
The
hack
and
be
meeting
note
stock
feel
free
to
add
yourselves
as
attendees
there.
A
quick
reminder.
A
These
calls
and
all
communication
on
the
open,
rfc
or
on
the
rc
repos
is
covered
under
our
code
of
conduct.
But
we
just
ask
that
you
please
be
kind
and
mindful
on
these
calls,
as
other
folks
are
speaking
if
you'd
like
to
add
or
comment.
While
someone
is
talking,
please
raise
your
hand
and
we'll
call
on
you
and
I
guess
quickly,
some
announcements
from
our
side.
A
We
cut
npm
version
7.7
yesterday
and
are
have
actually
floated
a
few
patches
since
then,
and
in
v77
we
actually
shipped
some
net
new
capabilities
for
npm
run
and
the
run
script,
suite
of
commands,
as
well
as
npm
exec,
to
be
workspace
aware.
So
two
new
configs
were
introduced,
workspaces
and
workspace,
which
essentially
help
you
filter
and
run
utilizing
those
configs
you
can
help.
A
You
essentially
run
those
commands
against
your
workspaces,
so
pretty
awesome
that
shipped
yesterday
and
we're
still
doing
our
best
to
stay
on
top
of
feedback
and
so
feel
free
to
try
it
out.
Let
us
know
how
that's
going
and
we'll
be
rolling
out
more
commands.
That
essentially,
should
be
workspace
aware,
as
as
sort
of
the
week's
roll
on
here,
with
hope
that
we
will
be
done
that
second
phase
of
sort
of
workspace
work
sort
of
the
second
week
of
april.
A
Ideally,
so
that's
the
announce
big
announcement
from
us.
Did
anybody
on
the
call
have
any
news
or
announcements
they
want
to
share.
A
If
not,
I
know
we
have
a
light
group
today.
Most
of
the
folks,
as
I
mentioned
earlier,
offline
are
either
on
pto,
sdo
or
just
out
of
the
office.
So
it's
just
myself
from
the
core
team
here,
but
yeah.
I
wanted
to
still
dive
into
some
of
the
the
items
that
we
had
queued
up.
I
had
initially
jumping
into
the
agenda
initially
outlined
three
rc's
that
have
been
waiting
to
sort
of
be
ratified
and
accepted.
A
I
think,
given
you
know
the
the
folks
we
have
today,
we
might
want
to
sit
on
this
for
another
week
and
just
agree
to
to
keep
it
open
and
actually
accept
them.
For
now
these
are
the
overrides
rfc
the
registry
protocol
and
then
also
the
essentially
the
phase
two,
our
rfc
for
the
workspaces
work
that
we're
worth
shipping
today
and
are
throughout
these
next
few
weeks
and
so
yeah
I'll
just
keep
them
essentially
on
the
agenda.
Unless
folks
had
any
comments
they
wanted
to
make
on
any
of
those
three
rfcs.
A
If
not,
then
we
can
move
on
to
the
pr
rc
2912.
so
find
mkm5dupes
pretty
print.
So
I
don't
necessarily
know
this
is
actually
a
appear
that
somebody's
opened
to
change
the
the
output
of
find
dupes.
I
think
roy
had
originally
queued
this
up,
just
to
give
some
visibility
on
on
what
this
change
was
looking
like,
essentially
because
we
would
also
ship
this
as
a
sort
of
a
minor
release
or
in
a
minor
release,
because
it
does
change
the
output
here.
A
A
We're
going
to
keep
this
open
for
a
little
bit
and
just
figure
out
if
this
is
actually
something
we
want
to
like
pull
in.
Anybody
have
comments
on
this.
This
change
of
the
output.
B
What
I
go
ahead,
oh
I
was
gonna
say
it
seems
helpful.
It
just
reminds
me
of
how
annoying
it
is
that
I
can't
tell
npm
to
stop
removing
packages
when
I
install,
but
it's
still
more
useful
to
tell
me
what
it's
doing
that
I
don't
like.
A
Right
yeah,
this,
I
think,
is
another
good
example.
We've
actually
been
seeing
an
uptick
as-
and
I
I
say
this
anecdotally
without
the
actual
metrics
to
back
it
up,
but
the
metrics
probably
do
exist,
we're
seeing
an
uptick
in
in
at
least
contributions.
A
So
I
feel,
like
we've,
been
making
a
lot
of
good
headway
with
just
cleaning
up
the
code
base
to
to
a
point
where
people
feel
like
they
can
jump
in
and
add
things,
and
this
is
a
great.
I
think,
example
of
you
know
somebody
identifying
a
pain,
point,
developer,
experience,
sort
of
pain,
point
and
and
making
the
change
easily
and
and
yeah
the
quality
of
life.
Sort
of
experience
should
should
get
better
here
and
improved
over
time.
So
hopefully
we're
going
to
see
a
lot
more
of
this
kind
of
stuff.
A
I
know
we've
been
talking
a
lot
about
like
what
output
looks
like
in
the
design
of
of
and
and
language
we're
using
in
the
output
from
npm.
I
think
this
is
a
good
example
of
that,
as
well
like
like.
Let's,
let's
improve
the
experience,
make
it
more
clear
about
what's
actually
happening
to
the
end
user
and
actually
give
them
actionable.
A
Something
actual
as
well
is
a
top
of
mind
for
us,
like,
especially
with
we
were
hearing
a
lot
of
feedback
with,
like
the
pewdiepiency
installation
by
default,
the
logging,
the
air
we
give
with
e-resolve
conflicts.
You
know
and
errors
you
know
was
not
as
actionable
as
it
could
have
been.
I
think
this
is,
you
know,
yeah
something
we
want
to
keep
in
mind
as
we
go
along
here,
so
feel
free
to
give
feedback
in
pierre
itself.
A
C
I
think
the
only
thing
for
me
is
that,
like
typically,
I
expect
relatively
s
structured
columns
in
npm,
but
I
think
that's
unrelated
unrelated
to
yeah.
A
That's
one
thing
that
I
was
also
going
to
give
feedback
in
the
pr
itself
was
yeah.
Just
the
we
could
clean
up
the
how
it,
how
it
looks
visually
yeah,
yeah.
A
B
Yeah,
like
I
think
in
general,
we
should
make
sure
that
any
output
that
npm
spits
to
the
console
is
also
somehow
consumable
in
json
form.
It's
very
like
disappointing
when
I'm
happily
working
through
some
of
those
commands,
and
then
one
of
them
suddenly
doesn't
have
it
so
it'd
be
really
nice.
If
this
one
did,
I
would
love
to.
B
B
A
Okay,
cool
yeah:
if
you
come
across
them,
let's,
let's
start
our
list
and
like
we
can
put
them
down
as
paper
cuts
to
like
clean
that
up,
because
I
I
totally
agree
that
we
should
have
that
that
that
should
be
sort
of
a
standard
of
all
output.
A
So
moving
on
to
the
second
item
that
we
had
rfc
339,
so
improving
the
suggestions-
nilf,
unfortunately
isn't
here
again
and
isaac
had
sort
of
followed
up
and
made
a
comment
on
this
rfc
we've
made
some
headway
here
already
so
again,
if
you
go
and
you
get
the
latest
npm
you're
going
to
actually
see
some
better
output
today,
some
more
actual
output
for
when
we
essentially
are
doing
some
like
did
you
mean
code,
so
the
the
default
behavior
of
all
for
run
script
is
going
to
actually
fall
back
and
check
against
any
scripts
that
we
might
think
are
similar
to
what
you've.
A
Given
us
as
input,
we
use
the
same
type
of
logic.
I
think
that
we
had
in
help
search
before
and
so
this
this
rfc.
Actually
you
know
we've
semi
implemented
at
least
the
run
script.
Examples-
and
we
could-
I
don't
know
if
we've
implemented
anything
in
exec,
yet
that
is
similar
to
this,
but
it's
definitely
something
we're
trying
to
improve.
So
so
that's
essentially
just
an
update
there
is
that
we
have
shipped
some
quality
of
life
improvements
there
with
the
logging.
So
any
comments,
thoughts
on
those.
A
No
comment
is
good,
good
comments,
so
moving
on
to
the
other
rfc
that
neil
has
had
or
created
for
us
after
some
internal
discussion
about
npm
config.
A
So
this
is
rfc
336,
so
adding
a
where
flag
to
npm
config
I'll
just
copy
and
paste
this
in
there,
and
so
the
thought
behind
this
is
today.
It
seems
very
weird
that
we're
not
able
to
modify
a
set
and
get
config
or
sorry
set
config
locally
to
npm
rc
files
that
are
in
your
at
the
project
level
and
so
introducing
within
the
b7
major
band
here.
Some
way
for
you
to
configure
mpm
npm
config
to
you
know,
interact
with
the
the
project
level.
A
Npm
rc
file
is
sort
of
what
we're
trying
to
accomplish
here,
as
well
as
sort
of
delineate
between
these
four
four
areas
that
we
are
context
that
we
have
today
in
our
docs
and
actually
in
npm
cli,
the
client
itself.
So
you
know
the
built-in
configs
that
we
have
versus
global
user
and
project
level
configs
and
just
really
explicitly
defining
those
in
a
new
new
option.
I
don't
know
if
the
name
of
it
is
is
I
think.
A
Last
week
we
talked
about
maybe
the
name
not
being
the
best
or
it's
a
little
bit
too
verbote
or
not
it's.
It
would
be
better
to
be
more
verbose.
I
I
think,
is
some
of
the
feedback
we
had
before.
So,
where
might
not
be
the
right
term
we
use
in
the
end,
but
yeah
jordan.
I
see
your
hands
up
to
do.
B
Yeah,
just
I
mean
so
stepping
back
from
the
roc
when
I
use
npm
config,
set
in
particular
less
so
with
get,
but
with
set
about
99.9
of
the
time
I
want
to
set
it
in
the
project,
level,
rfc
and
0.1
percent
of
the
time
I
want
to
set
it
at
the
user
level,
one
and
zero
of
the
time
anywhere
else.
B
So,
while
the
where
thing
under
whatever
name
is,
seems
like
a
good
step
to
that
it,
and
it
might
be
better
to
go
with
that
sort
of
match
the
data
model
of
npm
approach,
it
almost
seems
like
just
a
flag
that
says
like
in
the
current
project.
B
Right
would
actually
satisfy
the
majority
use
case
because,
like
generally
speaking,
the
only
thing
that
should
ever
really
go
outside
your
project.
Npmrc
is
your
off
and
virtually
everything
there's
a
few
tiny
things
like
whether
you
see
a
loading
indicator
or
something,
but
virtually
everything
else
like
it,
is
actively
harmful
to
have
it
outside
your
project
directory.
Because
then
your
other
co-workers
on
the
project
can't
you
know,
have
a
different
setting
than
you
so
yeah
I
mean
like.
So
this
seems
fine.
A
A
Yes,
yes,
yes,
that's
great,
so
yeah
set
today
is
being
under
utilized,
probably
because
we
don't
have
any
way
to
look
configure
it
to
to
look
in
one
place
or
another
right
like
so
well
dash
g.
Sorry,
I
think
it
lets
you
do
globally.
So
yeah.
I.
A
I
think
we're
trying
to
thread
the
needle
here
a
little
bit
and
allow
for
we
want
the
default
to
be
project
level,
but
we
can't
make
that
change,
because
there
will
be
a
breaking
change
until
npm
8..
So
I
think
that
allowing
for
let's
say
these
other,
because
we
also
already
have
a
understanding
of
a
system
level
mpmrc
file,
as
well
as
a
user
level
in
pmrc
file.
B
Yeah,
I
mean,
I
think,
that's
a
reasonable
argument.
I
think
that
in
either
case
it's
a
sember
minor
way
to
move
towards
december
major
of
changing
the
default,
which
I
completely
agree
with.
That
is
the
ultimate
goal
and
I'm
I'm
not
super
concerned
with
which
stepping
stone
gets
us
there,
the,
but
like
the
system,
level
npmrc.
B
My
understanding
is
that,
like
six
devops
people
like
use
that
and
rely
on
it
and
maybe
npm
itself
and
like
nobody
else
and
like
because
there's
like
four
locations
right,
there's
user,
there's
project,
there's
global
and
then
there's
like
the
npm
binary
itself
right
and
that
that
last
one
nobody
knows
about
and
nobody
uses,
but
it's
there
and
the
system
one.
I
would
also
expect
that
anyone
who's
using
it
doesn't
want
the
user
to
be
able
to
do
it
to
change
it
easily
and
probably
is
using
permissions
to
prevent
that
anyway.
B
So
it's
just
not
a
use
case
and
then
similar
and
then
the
the
so
it's
just
user
and
project
and
like
again,
I
think
the
use
case
for
user
is
auth,
which
is
already
put
there
and
like
minor,
display
level
things
like
the
spinner
or
whatever,
and
that's
it
and
so
like
and-
and
I
think
that
I
I
would
very
surprised
if
anyone
else.
Actually,
you
know-
I
guess-
maybe
registry,
if
you
work
it
in
a
company.
Your
like
internal
registry
would
go
there.
B
So
there's
like
a
few
options,
and
so
that
supports
the
aware
approach.
But
it's
it
seems
like
it's
kind
of
burying
the
lead
about
the
real
purpose
here,
which
is
that
almost
every
time
people
want
to
change
the
project
and
pmrc
and
virtually
nobody
cares
about
the
rest
of
them.
It's
like
ideologically
consistent
to
have
them
all
and
so
cool,
but
I
don't
know
anyway,
that's
just
my
thoughts.
All
that.
E
B
E
A
So
maybe
you
can,
maybe
you
can
write
out
the
the
feedback
wes
and
we
can.
We
can
speak
speed
up
the
internet
yeah
if
you
want
to
write
in
chat
wes
if
you
can
and
like
the
feedback
yet-
and
we
can
just
repeat
it
here
for
you,
it's
it's
pretty
choppy
and
delayed
for
sure
so
yeah.
The
other
thing
I
just
wanted
to
say
there
is
like
the
only
time
I
have
ever
had.
C
To
use
campium
config
set
earth
set,
can
fix
that
was
like
when
I
am
setting
up
my
own
local
machine
and
like
I'm,
going
to
be
publishing
personal
modules,
and
I
do
want
to
set
the
global
of
like
you
know
when
I
in
it
I
want
to
be
mit,
and
when
I
like,
I
prefer
I
prefer
starting
at
version
one
rather
than
at,
like
I
think
it
starts
at
0.1,
which
is
a
weird
place
to
start
anyway.
C
B
C
C
C
C
Don't
know
why
sorry
yeah-
that's
just
the
use
case
that
I
I
have
for
that
is
like
every
time
I
run
a
new
new
machine.
I
run
those
commands
to
get
that
set
up
and
I'm
at
and
there
is
a
lot
of
codified
content
around
run.
Npm
config
set.
You
know,
author
or
init.author,
I
think
and
stuff
like
that.
So
do
you
want
to
go
ahead
and
read
russ's
point
out
darcy.
A
Yeah
yeah,
I
can
do
that
and
then
I'm
gonna
take
a
few
notes
here
as
well.
So
wes
is
just
following
up
here
in
chat.
Saying
his
point
is
that
even
if
someone
sets
a
registry
at
the
user
global
level,
it
is
likely
that
there's
going
to
be
misuse
and
it
needs
to
be
set
in
all
projects
as
well.
A
So
to
be
quite
honest,
he
thinks
that
we
should
probably
print
out
the
registry
when
it's
not
in
the
public
or
on
all
installs,
but
that
is,
but
that
is
another
topic,
so
this
I
think,
speaks
to.
Actually
you
know
what
we
the
other
rc,
that
we
just
had
that
neil
brought
up
in
terms
of
just
making
clearer
and
better
output
from
from
our
commands.
A
A
You
know
what
registry
you're
configured
to
but
yeah
the
other
parts
there
about
the
user
versus
global
level
registry
config.
Like
you
know,
this
is
something
that
I
run
into
myself.
I
have
I,
I
use
all
three
different
mpmrc
files
for
different
things
like
whether
it
be
my
yeah
just
for
different
config,
similar
to
also
what
you
were
saying
tierney.
I
have
like
custom
init
config
for
the
user
level,
but
that
might
change
the
mpmrc
file
and
my
project
level.
Config
can
override
that.
B
Yeah,
so
from
hearing
more
about
those
extra
use,
cases
which
make
perfect
sense,
I
just
hadn't
thought
about
like
for
me.
I
I
disable
package
lock
in
every
project
and
I
set
version
and
message
in
every
project
so
that
I
can
do
auto
npm
version
stuff.
The
way
I
like
I'm
wondering
if,
given
an
arbitrary
config
value,
there's
really
only
one
canonical
place
it
ever
should
go
like
in
its
stuff
makes
no
sense
in
an
existing
project.
B
Right,
for
example,
kind
of
only
makes
sense
at
the
user
level
registry
based
on
wes
comment,
kind
of
only
makes
sense
per
project,
although
you
maybe
could
set
it
at
the
user
or
system
level
right.
And
so
maybe,
if
we
did
a
quick
scan
of
all
those
config
values,
we
could
decide
an
optimal
location
or
locations
for
each
value
and
then
warn
the
user
when
they're
setting
a
value
in
a
non-optimal
location
and
then
tell
them
how
to
use
the
where
or
whatever
command
to
set
it
in
the
correct
location.
B
Because
if
we
do
that,
then
we've
kept
the
data
model
and
gone
basically
exactly
with
nels
approach,
regardless
of
the
spelling
of
where,
but
we've
also
gently
pushed
everyone
towards
whatever
the
correct
location
is
conceptually
for
the
config
value
they're
trying
to
set,
which
makes
it
much
more,
probably
much
less
disruptive
at
in
npm,
8
or
whatever.
When
the
default
changes.
B
C
You
could
even
have
a
config
option
for
what,
where
default,
sales.
B
A
Okay
yeah,
it
seems
like
a
little
non-deterministic
like
like
with
the
little
bit
of
magic
there
in
terms
of
what
control
like,
I
actually
like
it
when
that
we're,
like
the
mpm,
highly
configurable,
but
we're
very,
very
dumb
in
a
lot
of
places
like
we
just
take
what
you've
given
us
and
put
it
in
places.
But
I
do
like
what
you're
saying
there
jordan
in
terms
of
mapping
what
we
think
the
default
place
should
be.
B
Right,
we'd
still
put
it
wherever
the
user
asked,
we
just
give
them
a
little
notice.
That
says:
hey
just
in
case
like
go.
Read
this
link
and
it'll.
Tell
you
why
we
think
the
correct
location
is
x
right
and
it's
so
it's
non-deterministic
in
the
sense
that
you
have
to
refer
to
a
lookup,
but
the
lookup
is
hard-coded
and
deterministic.
A
Right,
I
think
this
would
also
help
in
terms
of
like
providing
this
kind
of
metadata
into
our
docs
for
the
configs
themselves.
I
think
we
could
encrypt
like
make
our
docs
better
about
like
to
tie
these
things
things
together
right
now,
because
these
four
locations,
right
now
of
where
you
can
can
have
mpmrc
files
and
how
we
respect
them.
A
Like
not
a
lot
of
people,
know
this
information
and
not
a
lot
of
people
know
like
why
they
would
you
know
why
they
would
set
this
value
at
the
project
level
versus
the
like,
like
the
user
level
versus
like
you
know,
across
your
system,
right.
B
B
A
Yeah
yeah,
okay,
so
I'll
take
some
take
some
notes
here
as
well.
I'm
gonna,
probably
because
I'm
doing
doing
things
so
low.
I
might
actually
update
the
notes
after
the
call
as
well.
Just
so
folks,
if
you
don't
see
me
typing
now,
it
doesn't
mean
I'm
not
going
to
backfill
the
meeting
notes
so
but
yeah
I
really
like
that
feedback.
A
Jordan,
that's
that's
a
great
idea,
so
we'll
capture
that
and
and
see
if
we
can
actually
maybe
modify
the
rfc
to
include
some
of
those
ideas
like
the
auto
is
an
interesting
concept.
B
Like
auto
could
be
added
later,
the
important
part
is
the
suggestion
and
the
optimal
locations.
Auto
is
just
kind
of
an
easy
thing
to
add.
Once
you
have
those
okay,
the
other,
the
other
feedback
I
want
to
give
about
the
name
itself.
B
The
only
reason
I
would
push
back
on,
where
is
because
is
because,
for
the
reason
that
all
npm
config
values
are
global,
it's
super
weird
and
confusing
when
you
want
to
use
a
config
name
for
a
different
command,
because
it
makes
sense
there,
but
it's
already
kind
of
claimed
by
another
one,
and
where
is
so
broad
that,
like
I,
can
see
any
number
of
commands
wanting
to
use
that
and
it
wouldn't
and
then
not
taking
those
exact
same
values
and
like
that
that
to
me
suggests
that
we
should
make
the
name
much
more
granular,
so
that
it's
like
scoped
to
config,
set
or
concord
configure
whatever.
A
Be
perfectly
granular
enough
right
and
and
we've
done
the
same
with
init
config
as
as
even
tierney
said
here
like
the
init
dash
author
init
dash
configs
are
all
scoped
that
way
so
not
scope,
but
they're
they're
they're
named
that
way
and
prefix
that
way
to
try
to
be
overtly
verbose,
so
awesome.
So,
let's
move
on.
I
want
to
keep
so
this
rc
by
tierney
the
npm
auto
license.
A
C
A
Us
I
don't
know
what
the
if
there's
been
any
comments.
C
Is
fine
yeah,
I
just
I'm
not
in
any
rush
for
it.
I
would
love
to
see
it
progress
and
I'm
happy
to
do
the
work.
I
just
need
to
know
what
those
steps
are
to
like
you
know
what
the
actual.
B
C
From
the
pm
team
are,
that
would
be
desired
since
there
is.
There
is
some
feedback
about
like
licensee
and
stuff
and,
like
I
don't
know
if
we
want
to
go
down
the
path
of
just
straight
up,
depending
on
licensee
or
using
their
format
and
writing
our
own,
like
parsing
event
or
what?
Whatever
that
is,
I'm
happy
to
write
it
or
we
could
go
down
the
path
of
what
I've
written,
which
is
like
relatively
different
and
more
complex.
I
think
it's
more
complex.
I
could
be
wrong,
though,
but
yeah.
C
B
B
Is
that,
like
the
way
it
already
is
set
up
to
allow
explicit
overrides,
which
is
great,
so
I
can
say
legal,
doesn't
care
about
this
thing
or
it
doesn't
apply
or
they
forgot
a
license,
but
really
it
you
know
they
meant
it
to
be
at
mit,
and
so
we're
going
to
count
that
right
and
then
but
then
it
also
lets
you
point
to
shared
corrections
so
that
you
can
crowdsource
that
and
that
already
exists
so
there's
basically
everything
that
was
in
airbnb's
dependency
graphs.
That,
like
has,
that
kind
of
that
was
intended
to
be
licensed.
B
That
way
and
just
was
missing,
the
exact
correct
you
know
metadata
to
to
market
as
such,
like
that's
already
in
that
public
package,.
C
Well,
there's
there's
also
cases
where
people
and
I've
been
told
this
by
someone
who
formerly
worked
at
google,
who
worked
at
google
at
the
time
if
you
include
mit
in
your
package.json,
but
don't
actually
include
the
mit
license,
that
can
be
a
bit
skeevy
for,
like
you
know,
a
mega
corp,
because
it's
like
you're
saying
it's
mit,
but
you're
not
actually
licensing
it
appropriately.
B
B
The
the
reason
that
that
it's
so
ambiguous,
as
we
know,
is
because
this
stuff
basically
hasn't
been
tested
in
court.
So
nobody
actually
knows.
If
the
author
says
it's
mit
is
sufficient,
even
if
it
wasn't
like
properly
licensed.
But,
like
you
know,
some
lawyers
are
saying.
Well,
that's
sufficient
signal
to
me,
you
know
and
that
a
court
would
accept
that,
and
some
say
no,
I'm
not
comfortable
with
that.
C
Yeah
and
so
for
what
it's
worth
like,
I
built
my
own
tool
that
was
separate
from
the
and
then
that
led
to
me
proposing
this.
As
a
like,
there
is
a
structure
that
I
proposed
that
npm
should
implement.
That
is
separate
from
my
own
tool,
yeah,
and
so
I
I
very
intentionally
kind
of
structured
it
in
a
way.
I
don't
care,
I
don't
care
what
the
solution
is.
I'm
entirely.
B
C
For
us
to
vendor,
or
not
I
keep
saying
I
don't
know
where
that
came
from,
I
like
for
us
to
depend
on
licensee,
that's
fine
with
me,
assuming
it's
also
fine
with
that
former
the
the
maintainer
of
it
but
yeah.
Like
you
know,
I
I
would
love
to
see
that
just
any
ability
to
do
licensing
tooling
at
all
would
be
nice.
I
guess
the
one
thing
I
would
say
is
like:
is
there
anything
that
licensee
doesn't
do
that
we
would
like
it
to
do
and
like
does
it?
C
Does
it
meet
like
what
consumers
of
such
a
function
a
feature
would
want,
and
if
it
does
awesome
cool,
that's
fine
just
depend
on
licensee.
The
other
thing
I'd
say
is:
if
we
did
do
it
with
licensee
I'd
like
to
see
rather
than
a
dot
licensee.json
just
have
that
object
in
a
package
json.
C
A
B
And
I
could
easily
see
us
making
an
npm
config
value
that
where
the
default
is
package.json
and
it
finds
the
config
in
there
and
you
can
override
it
to
point
to
a
file
which
can
be
named
whatever
you
want,
which
would
mean
that
anyone
currently
using
licensee
could
just
set
the
config
value
in
their
project,
npmrc
and
point
it
to
licensee.json.
But
then
new
users
by
default
would
put
it
in
package.json.
B
C
Things
like
think
about
workspaces
right
so
like
if
correct
each
prod
package
has
its
own
thing
like.
Do
you
want
that,
and
do
you
want
to
propagate
that
down
from
the
top
package
jason?
Or
do
you
want
to
there
yeah
there's
three
things,
but.
B
C
Yeah
yeah
at
the
the
end,
like
I
don't
know,
I
I
if
there's
justification
needed
so
far,
I've
not
heard
anything,
and
I
I
doubt
anyone
thinks
this
isn't
a
necessary
thing,
but,
like
literally
every
single
package,
that's
in
that
has
multiple
thousands
of
downloads
and
some
of
them
have
hundreds
of
thousands
of
downloads,
so
like
license,
checker
seems
to
be
the
most
used,
which
is
maintained
by
dev,
glass
or
david
glass.
Who
is
wonderful
but
yeah?
You
know
there's.
C
I
I
think
that
there
is
like
a
very
demonstrated
need
for
this.
There's
also
companies
that
have
started
around
this
concept.
So
yeah,
I
don't
know
I.
I
would
very
much
like
to
see
this.
I
don't
again
don't
care
how
it's
implemented.
We
don't
care
how
we
get
there
just
that
it
gets.
A
Implemented
so
we'll
keep
it
on
we'll
keep
it
on
the
agenda
for
now
see.
B
C
B
So
I
think
that
requires
us
enumerating
the
things
we
wanted
to
do
and
then
we
can
answer
that
question
yeah
yeah,
maybe
like,
if
you
feel
like,
if
someone
feels
like
doing
the
extra
work
you're
making
like
a
nice
comparison
table
of
like
here
are
the
you
know.
Tierne's
thing
I
forget
the
name
of
it.
Licensee
and,
like
you
know,
you've
mentioned
license
tracker
and
a
few
others,
and
then
just
compare
and
contrast
and
show
what
features
they
have
and
don't
and
then
like
that,
can
help
us
inform
us
yeah.
A
So
moving
on
then
to
our
rfc
the
optional
install
issue.
156..
I
think
we
left
this.
I
left
this
open
and
I'll
copy
paste.
The
issue
for
folks
specifically
because
the
ask
here
what
was
this
open
last
week,
I
think
the
ask
here
was
for
different
types
of
dependencies
to
to
be
installed,
installable
so
like
creating
almost
like
groups
or
aliases
that
then
you
could
do
a
filtered
install.
A
I
believe
pmpm
has
filtered
installs.
So
one
interesting
sort
of
I
guess,
update
on
this
discussion
and
that
I
sort
of
added
was
that
this
kind
of
capability
can
be
unlocked
with
workspaces.
Once
we
add
ins
filtering
to
npm
install
which
we're
actually
working
on
today.
So
what
that
means
is
that
when
you
provide
the
one
of
the
two
configs
that
I
I
listed
before,
that
we've
implemented
in
npm
77
is
a
specific
workspace
that
you
want
to
actually
install.
A
Then,
when
you
define
that
you
do
npm,
let's
say:
npm
install
w
static
and
that's
a
workspace.
We
will
install
just
those
dependencies,
we'll
still
resolve
the
tree
the
same
way,
but
we'll
essentially
only
reify
the
dependencies,
which
I
believe
sort
of
walks
is
a
solution
that
essentially
meets
the
need
of
of
what
this
person
has
been
asking
for
without
introducing
net
new
grouping
or
filtering
capabilities
at
least
today.
A
So
the
currently
they
mentioned.
You
know
the
production
flag
that
we
have
and
and
sort
of
open
up
discussion
about
increasing
the
types
of
filters
that
could
be
created.
A
So
I'm
not
sure
if
any
other
folks
had
thoughts
around
this,
but
it
was
definitely
an
interesting
discussion
that
I
thought
you
know
we're
trying
to
address,
at
least
with
the
workspace
work,
we're
doing
right
now.
So.
A
I'm
sure,
like
lots
of
folks,
have
installed
depths
that
they
don't
need
or
didn't
want
to,
or
they
even
need
to
to
install
during
npm
install.
So
that's
you
know,
z
case
that
we
know
is
only
going
to
get
worse
as
people
adopt
workspaces
more
and
more
and
as
we
allow
for
you
to
essentially
install
all
of
those
workspaces.
A
Very
very
large
projects
are
going
to
have
this
problem
and
we're
trying
to
address
it
at
least
with
filtered
installs,
so
cool
so
moving
on.
Then,
if
there's
no
other
comments
there
and
again
that
that
capability
should
be
coming
in
a
few
weeks,
so
just
just
be
mindful
and
sort
of
reiterate
the
timeline
there.
This
is,
ideally,
you
know
landing
very
soon.
The
rc
343,
which
is
one
of
roy's
rfcs.
A
Unfortunately,
you
can
make
it
today
is
this
concept
of
switching
automatically
switching
the
context
based
on
your
current
working
directory
for
workspaces.
He
created
this.
I
think
just
this
past
week,
so
there
hasn't
been
any
discussion
so
feel
free
to
to
add
notes
there.
Unless
folks,
on
the
call.
B
Have
any
comments
they
want
to
make?
I
mean
I
guess
from
reading
that
pr
it
seems
like
that's
how
it
like.
Why
doesn't
already
do
that
by
default,
like
there's
a
package
json
in
the
workspace?
So
if
you
write,
if
you
type
npm
install
in
npm
install
package
in
there,
it
should
just
go
to
that
package.
Json
like
I
may
not
do
that
now,
but
I'm
wondering
like
why.
Why
doesn't
it?
That
seems
like
the
only
thing
it
should
do.
A
A
B
Okay,
so
dd.
B
Yeah,
for
me,
the
workspace
is
the
root
anyway,
so
I'm
gonna
say:
stick
with
child
and
parent
for
this
discussion.
So
when
you
cd
into
the
child,
there's
a
package.json
in
there,
npm
should
have
no
concept
whatsoever
that
it's
inside
a
parent
workspace.
It
should.
B
Because,
like
there's
a
package.json
there,
it's
a
package
right.
Similarly,
if
I
put
a
package.json
at
under
slash
and
add
workspaces
to
it,
that
shouldn't
break
every
package
on
my
machine.
So
if
it's,
if
it
does
already
work
this
way-
and
this
is
just
documenting
it-
I
don't
know
why
we
need
an
rfc
to
do
that.
But
it
sounds
good
like
I'm
on
board.
A
So
I
think,
sorry
when
I
say
documenting
the
way
it
is
now
and-
and
this
is
ring
now,
I'm
remembering
the
internal
discussion
we
had
when
running
commands
inside
of
a
workspace
you.
We
are
currently
not
aware
of
the
fact
that
you're
running
them
inside
of
a
workspace
project.
We
only
see
what,
as
you
said,
there's
packages
on
there
running.
We
shouldn't
be
yeah
and
so
like
this
is.
A
The
proposal
is
to
be
like
our
should
we
walk
the
tree
up
and
and
and
see,
if
you're
inside
of,
if
there's
a
workspace
definition
that
maps
to
the
current
working
directory
and
run
that
command
that
you
just
ran
as
if
it
was
run
in
the
roots
of
the
your
workspace.
And
then
we
because.
A
All
these
commands,
because
the
the
concern
is
that,
for
the
majority
cases
of
cases
when
folks
are
let's
say,
cding
into
a
workspace
folder
inside
inside
their
project,
they
go
in
there
and
they
run
install
and
now
they've
generated
a
lock
file
within
that
folder,
whereas,
like
we
actually
only
want
to
be
generating
that
you
know.
That
might
be
the
intention.
True
right,
like
we
don't
know
what
the
intention
was,
but
you
know
for
the
majority
use
case.
A
I
think
what
people
expect
is
that
that
they
would
have
run
as
if
they
were
scoping.
Let's
say
to
that
specific
workspace,
so
npm
install
dash
w
my
current
workspace
directory
name
would
be
the
expectation
of
how
that
ran
how
that
command
was
from.
A
In
that,
like
once
you're
in
that
tree,
like
yeah
and
and
sorry,
wes
is
giving
some
comments
here.
B
Yeah
his
point
in
the
chat
is
like
you
would
want
it
to
be
opt-in
so,
like
you
specify
workspace,
root
or
something,
and
that
also
could
work.
I
could
also
see
that
when
you
type
npm
install
at
the
root
in
the
root
that
it
puts
an
npm
rc
in
each
workspace
child
workspace
that
sets
the
workspace
space
route
for
you
and
that
way
you
can
always
override
it,
but
by
d
you
know,
and
it
wouldn't
it
wouldn't
like.
B
If
it
already
existed,
it
wouldn't
change
it,
but
like
that,
that
feels
less
magic
to
me,
because
then
it's
magically
creating
explicit
config
that
you
can
override
and
change
later
versus
magically
doing
a
different
thing.
Because
then,
if
I
wanted
to
do
to
like
wipe
out
my
sim
links
and
like
just
reinstall
everything
at
the
local
level,
I
could
do
npm
install
workspace
root
dot.
A
So
we
are
currently
working
on
this
week,
npm
init,
to
be
workspace
aware,
so
you
can
imagine
what
that
might
mean
is
that
we
make
it
so
that
we
will
actually
create
a
workspace
definition
in
package.json
for
you,
when
you
run
mpmna
w
what
you're
suggesting
with
a
generating,
also
an
mpmrc
file,
then
inside
that
workspace
that
maps
some
config
back
to
you
know
the
app
root
that
parent
right
might
be
an
interesting
proposal
or
an
interesting
addition.
B
C
B
With
the
feature
it
seems
reasonable
to
me
to
just
do
it
on
install
because
anything
that
they've
indicated
as
a
workspace
like
that
you
know,
and
if
they
don't
like
that
behavior,
then
they
can.
You
know
yeah,
I
guess
we
could
do
it.
That's
true.
We
could
do
an
npm
workspace
in
it.
That's
specifically
designed
to
convert
an
existing
project
to
use
npm
workspaces.
B
B
I,
like
that
npm
workspace
in
it
and
npm
in
it
workspace
aware,
would
both
set
this
workspace
root
npmrc
in
each
work,
child
workspace
and
that
workspace
route
would
be
used
to
on
to
decide
if
a
command
should
look
up
the
tree
for
or
you
know,
look
to
that
route
right
and
obviously,
if
you
went
to
that
route
and
the
thing
the
place
you
came
from,
wasn't
a
child
workspace
defined
in
that
route.
It
should
error
right
right,
but
as
long
as
that,
matched
then
like
it
won't
do
anything
bizarre
and
it'll
yeah.
A
So
yeah,
I
feel
like
I
don't
know
where
to
capture
that,
because
it
sounds
like
it's
net
like
the
idea
of
a
workspace
definition
or
config
is,
is
definitely
not
new,
but
I
feel
like
we
could
give
that
feedback
in
this
rfc,
specifically
that
it's
like
tangent
tangentially.
This
is
exposing
you
know
like
how
do
we?
How
do
we
map
this
relationship
right
like?
How
would
the
logic
work
in
this
current
rfc?
That's
proposed.
You
know
how
right
now
it
seems
pretty
pretty
we're
assuming
a
lot
here
and
so
like
making
it
explicit.
A
Is
it
sounds
like
your
your
feedback?
Jordan
would
be
to
introduce
a
net
new
config
that
can
be
set
in
an
api's
npmrc
file
and
then
how
that
gets
generated
like
that's
another
tangent,
for
like
we
can
do
mgm
in
it
or
npm
workspace
in
it.
That
would
allow
for
that
to
be
generated
for
you,
but
also
you
can
manually
create
those
that
relationship
yeah.
I
like
it.
It's
interesting.
I
think
we
we're
going
to
want
to
increase
workspace
adoption
over
the
next
quarter.
A
So
like
something
like
this,
that
makes
it
easier,
including
like
that,
what
you
just
hit
on
there,
like
in
terms
of
adoption
like
getting
folks
to
adopt
this
again,
that
that
whole
story
would
be
very
attractive
for
us
to
work
on
and
clean
up
as
we
go
forward
here,
so
so
yeah
any
features
and
functionality
like
that,
like
I
think,
would
be
beneficial
so
yeah.
We
want
to
just
reduce
the
confusion.
A
So
the
thing
is:
I'm
just
concerned
that,
like
still,
if
somebody
runs,
let's
say,
npm
install
inside
of
a
workspace
directory
and
they
don't
have
this
configuration
set
up
at
you
know,
what's
the
expectation,
what
is
their
like,
you
know
what
is
what
are
we?
You
know.
B
Well,
yeah,
I
think
I
can
see
having
both
expectations.
One
expectation
is,
it
behaves
as
if
it
was
a
project
by
itself,
because
I
see
these
into
it.
The
other
expectation
is
the
context
aware
thing
and
it
it
seems
like
a
nice
bridge
to
make
it
really
easy
for
the
default
to
be
the
context
aware,
but
also
make
it
really
easy
to
override
that
default
by
making
it
really
explicit.
A
Thank
you,
yeah.
Thank
you
for
giving
that
feedback
cool
wes.
I
see
you
made
a
couple
of
notes
here
that
the
workspace
na
is
great
and
helping
get
folks
set
up
would
be
great.
We
also
make
need
just
want
to
make
sure
that
I
I
know
this.
We
want
to
make
sure
that
the
root
is
only
allowed
to
be
a
parent
directory.
A
The
workspace
root
is
only
allowed
to
be
a
parent
directory,
so
that's
that
makes
a
lot
of
sense
so
that,
like
essentially
the
directory
has
to
be
nested,
has
to
be
a
child
of
of
that
root
and
not
set
outside
of
the
direct
appearance.
Yes,
so
we've
heard
like
linked
linked
workspaces
or
essentially
a
workspace,
that's
outside
of
the
route
right
now
won't
install.
So
that's
like
just.
I
consider
that
to
be
a
feature
right
now.
A
A
This
also
makes
me
want
to
have
npm
init
package
in
workspace
packages-
foo
interesting,
okay,
yeah,
so
that
I
think
this
is
kind
of
what
we
were
considering
with
the
work
that
we're
doing
right
now
to
make
npm
init
workspace
aware
was
that
by
providing
a
dash
w,
then
it
would
initialize
that
workspace
and
then
create
that
relationship
in
you
know
as
a
workspace
definition
in
your
package.json.
A
A
So
it's
almost
like
the
context,
the
the
working
directory
context
that
you'd
like
to
change
so
yeah,
if
you
can
feel
free
to
add
some
more
feedback
to
actual
rfc
itself.
So
this
is,
you
know
this
came
out
of
the
work
that
roy's
been
doing
with
making
our
commands
workspace
aware.
So
it's
you
know.
This
was
something
that
we
weren't
thinking
about
like
last
year
and
couldn't
have
been
thinking
about
until
we
started
to
really
get
get
into
the
doing
the
work
so
cool.
A
So
just
be
mindful
of
time.
We've
got
four
minutes
left
and
we
have
a
discussion
here
that
I
want
to
bring
up
because
we've
been
asked
about
this
multiple
times.
I
know
we
don't
have
a
ton
of
time
here,
but
we've
been
getting
feedback
since
npm
7
launched
about
the
changes
to
npm
update
and
the
fact
that
you
cannot
update
package
json
via
npm
update.
A
We
only
update
package
locks
and
that
the
recommendation
right
now
for
folks
is
that
if
you
want
to
update
your
package.json,
is
that
you
use
npm
install
to
update
your
depths,
and
this
is
a
bit
tedious
for
folks,
since
they
used
to
be
able
to
update
all
their
dependencies
at
one
time
in
v6
using
npm
update,
and
so
I
want
to
bring
this
up
because
right
now
we
don't
have
a
mechanism
in
v7
before
you
could
essentially
explicitly
opt
out
of
saving
with
no
save,
since
the
behavior,
with
with
v6
was
that
npm
update
would
automatically
update
the
package
json.
A
So
now
people
have
asked
us-
and
not
just
this
person
here
in
this
discussion
270.
But
people
have
asked
us
explicitly.
You
know
what
is
the
flag
or
what
is
the
way
to
do
this,
and
it
seems
like
a
common
common
pattern
that
people
are
asking
for,
so
I'm
essentially
bringing
this
up
as
a
discussion
topic.
I'm
not
sure
if
we
already
have
the
flag
that
we
can
reuse
or
we
have
a
way
to
like
thread
this
needle.
I
doubt
that
we're
gonna
just.
A
Roll
back
the
behavior
it's
going
to
have
to
be
opt-in
again,
whether
it's
npm
update
or
it's
npm,
install
that
like
essentially
allows
you
to
update
package
json
again,
my
head
is,
is
leaning
towards
the
fact
that
we'll
have
to
have
some
config.
That
essentially
does
this
for
for
update
or
or
install
so
does
anybody
have
any
thoughts
or
feelings
around
this?
Have
you
run
into
this
yourselves?
Are
you?
B
Reading
about
it
feels
like
it
should
be
surprising,
but
npm
update,
probably
since,
like
npm,
you
know
in
npm3
or
something
like
didn't
was
like
a
dangerous
command
to
run.
So
I've
been
operating
for
years
on
the
very
strict
muscle
memory
of
no
one
ever
use
npm
update
only
npm
install
explicit
things,
so
I
I
just
haven't
used
it
in
many
years,
but,
like
the
explanations,
seem
reasonable.
A
Right
so
you
know
for
the
developer
experience
and
the
ergonomics,
like,
I
feel
like
we
do
want
to
like
support
this
workflow,
like
that.
If
somebody
wants
to
update
all
of
their
dependencies
at
the
same
time
to
the
latest
versions
in
their
package
json,
we
should
allow
that
some
mechanism
for
them
to
do
that.
So.
C
I
actually
find
this
funny
because
I
was
struggling.
I
thought
npm
update
did
this
and
I
was
trying
to
do
this
the
other
day
because,
just
like
on
my
personal
projects,
I
don't
care
I'll,
run
it
and
if
it
breaks
cool,
I
can
fix
the
thing
that
broke
like
they're,
not
massively
complex,
and
I
was
very
confused
why
I
just
couldn't
get
away
to
like
update
my
dependencies.
I
was
extremely
confused,
so
this
I'm
glad
I
was
here
for
this
because
this
makes
sense.
C
I
would
hugely
support
some
way
to
do
this.
Potentially
reverting
or
you
know
doing
back,
you
know
resetting
npm,
installer
or
sorry
npm
update
or
whatever,
whatever
you
want
to
do
in
this
potentially
having
like
an
up,
update,
interactive
or
something
where
you
know
update,
you
can
step
through
to
avoid
jordan's
concern
of
this
blasts
away.
C
Everything-
and
I
have
to
do
a
lot
of
work
to
figure
it
out
and
like
if
I
update
one
module
and
then
like
run
npm
test
and
it's
fine
cool
I
can
go
on
like
I
can
move
on
to
the
next
one.
I
think
that
would
be
good.
I
think
that
that
also
potentially
has
benefits
for
tools
like
depend-a-bot
and
rest
in
peace,
green
keeper
and
stuff,
like
that
so
yeah.
I
would
love
to
see
that
that's
something
that
I
was
actually
thinking
about
coming
into
this
meeting.
C
So
I
would
yeah
very
much
love
to
see
that,
and
especially
some
kind
of
incremental
one
which
theoretically
couldn't
be
too
it
wouldn't
be
too
hard.
So
yeah
right.
A
A
F
Yeah,
I'm
here,
I'm
here
yeah.
Actually,
we
use
this
a
lot,
especially
in
our
our
team.
We
use
the
update
npm
update
to
we
do
a
lot
of
rnds
in
our
platform,
so
we
we
usually
do
mpn
updates
and
we
push
the
updates
to
to
our
devs.
F
So
it's
right
now
we're
having
what
you
call
this
we're
having
hard
time
monitoring
the
changes
in
terms
of
which
version
is
running
on
which
servers
because
of
the
changes
of
fpm7
before
we
we
automatically
can
detect
which
packages
are
being
run
on
the
servers
or
on
each
on
each
devs.
Computers
based
on
the
package
that
json
so.
F
Or
no
yeah,
we
use
the
log
files,
but
since
we
use
different
types
of
servers
like
windows
or
linux
base,
so
usually
we
just
inform
the
team
if
there's
a
update
or
we're
trying
a
new
version,
a
package
version
right
now.
What
we
do
is
we,
we
send
a
group
message
or
an
email
to
the
team
to
specify
which
versions
are
being
updated
at
the
package:
json.
A
And
do
you
say
explicitly
like
in
the
package.json?
Is
it
explicit
version
or
do
you
allow
for
the
ranges
like
in
package.json
like.
A
A
Okay,
interesting
okay,
so
maybe
we
can
have
some
more
discussion
in
in
the
actual
thread
that
that
you
created
about.
You
know
your
scenario
specifically.
I
know
we're
a
few
minutes
over
time,
so
I
apologize,
we
didn't
didn't
get
you
more
involved
there
earlier,
but
yeah.
This
is
definitely
we'll
keep
this
on
the
agenda.
If
that's
okay,
we'll
keep
it
on
for
next
week
as
well.
So
we'll
bring
this
back
up
and
and
talk
about
this
next
week.
A
If
you
want
to
join
us,
then
as
well,
but
we
can
talk
async
in
the
discussion
thread
about
maybe
some
of
your
use
cases
like
I
said
this
might
actually
be
something
that
we
can
reintroduce
like
this
ability
for
for
your
people
to
do
because
you're,
not
the
only
person,
that's
said
that
they
used
to
use
this
like
npm
update
in
v6
like
and
expect
that
you
know
it's
gonna
update
all
their
versions
and
impact
json,
as
well
as
the
log
file,
so
yeah,
okay,
apologize,
though
we
are
five
minutes
over
now,
so
I'm
gonna
do
my
best
to
summarize
and
add
notes
back
to
the
meeting
no
stock
and
feel
free
to
continue
to
add
comments
and
feedback
in
the
rfcs
themselves
and
I'll
see
you
all
next
week.