►
From YouTube: Open RFC Meeting - Wednesday, March 17th 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,
welcome
everyone
to
another
mpm,
open
rc
call.
Today's
date
is
wednesday
march
17th,
2021
we'll
be
following
along
the
agenda
that
was
posted
in
issue
342
and
I'll
share.
The
meeting
notes
talk
for
folks,
as
they
join
feel
free
to
add
yourselves
to
the
attendees
list,
quick
acknowledgement,
code
of
conduct
indulgent,
please
be
kind,
and
mindful
on
these
calls
and
in
all
rc
columns
in
the
rfcs
repo,
as
well
as
all
the
other
repos
inside
the
fpmwark.
A
We
ask
that
you
please
survive
by
our
code
of
conduct,
which
is
outlined
there
under
our
policies.
That's
found
on
npmjs.com
again.
These
calls
are
are
intended
to
hopefully
move
future
ideas
as
well.
As
you
know,
open
up
comms
with
the
community
and
push
features
forward.
A
A
If
not,
we
can
just
jump
into
the
agenda,
it's
a
bit
smaller
than
normal.
So
the
first
item
on
here
is
pr
or
rfc
332
supporting
yard
style
commands.
This
was
created
by
orta
and
we
had
a
pretty
good
long
discussion.
A
B
Yes,
there
is
a
pull
request
that
I
think
is
going
to
land
tomorrow.
That
updates
a
little
bit
of
the
language
around
the
suggestions
you
get
when
you
type
npm,
run
or
or
exec
or
something
and
it
tries
to
spit
out
the
usage.
The
did
you
mean.
Output
now
shows
top
level
run
and
exec
and
differentiates
between
them.
So
we
are
working
towards
removing
that
ambiguity,
because
I
know
last
week
we
talked
about
how
there
really
are
three
things
going
on
here.
A
I
think
that's
a
great
synopsis.
We
can
leave
this
or
go
ahead.
C
I
I
think
that
we
should
we
keep
coming
to
the
same
decision.
I
would
like
to
document
take
an
action
item
to
document
this
decision
and
close
this
rrc.
We
are
not
going
to
collapse
them
into
one
way
of
handling
top
level
commands
if
we
want
a
new
top
level
command.
C
That
does
collapse
them
in
some
way,
like
you
know
somewhat
how
npm
exec
sort
of
collapses,
local
scripts,
global
scripts
and
then
new
things
that
just
got
installed
like
that's,
that's
another
conversation
which
might
actually
satisfy
orta's
request
here,
but
we're
not
gonna.
Do
the
thing
he's
actually
requesting
like
that's.
I
don't
see
us
changing
on
that,
so
we
should.
We
should
just
say:
hey
we're,
we're
reducing
this
ambiguity
and
we
are
not
going
to
do
this.
Other
thing
that
you're
wanting
sorry
we've
we've,
given
it
a
fair
hearing
like.
D
Yeah,
I
think
I'm
not
sure
if
he,
if
or
to
speak
up
to
that
last
time,
but
one
question
I'd
like
to
see
and
answer
is:
is
there
anything
else
we
can
do
to
at
least
associate
a
little
bit
of
the
user
experience
that
they're
looking
for
with
the
rfc
right?
I
don't
know
if
we
explored
that
type
of
question
last
time.
E
Part
of
orta's
motivation
seems
to
be
that
people
think
of
npx
as
installing
things,
even
though
that's
not
its
only
purpose,
and
I'm
not
sure
if
there's
something
that
we
could
do,
that
npm
could
do
to
fix
that
by
like
adding
a
changing,
cli
behavior
isn't
going
to
affect
user
expectations.
C
Yeah,
so
I
don't
think
that
the
plan
is
to
change,
npx
or
or
to
change
the
suggestion
that
you
do
npm
install
tsc
and
pxt.
C
I
think
the
what
I'm,
what
I'm
suggesting
here
is
you
tell
the
person
to
run
a
command
that
will
run
the
thing
that
you
want
them
to
run
and
currently
there's
a
there's,
a
shortcoming
in
our
in
our
functionality,
because
we
don't
have
a
a
way
to
say
exact,
local
right,
also,
the
the
what
we
write
to
the
terminal
when
you
run
npm
tsc
and
that's
not
a
command,
we
know
is
not
particularly
helpful
right
now
right.
C
C
C
D
And
I
can
help
you
out
with
taking
notes,
darcy
and
you're
muted.
A
Thank
you
so
much
yeah.
That's
great
sorry.
I
was
trying
to
pull
double
duty
here
thanks
thanks
roy
okay,
so
action
item
there
isaac
is
to
let's
document
the
decision
and
and
and
we
can
move
on,
and
I
think
that
what
spawned
out
of
this
is
actually
you
know
a
couple
more
of
these
rfcs
that
actually
are
are
have
more
likelihood
of
us
actually
landing.
So
I
still
think
it
was
great
and
and
do
appreciate
or
to
bring
this
up
again
so
cool
great.
A
So
moving
on
to
pr
number
325.
or
sorry,
this
was
an
issue
325,
which
was
essentially
a
request
for
rfc.
So
essentially
a
discussion
on
running
pre-post
install
scripts
on
single
package
installation.
We
talked
about
this,
I
think
pretty
extensively
or
last.
I
think
two
calls
that
we've
had
about
the
idea
of
like
mutation
events-
and
I
don't
know
where
we
landed
in
terms
of
next
steps.
If
that's
something
that
we
were
gonna
create
a
separate
like
rfc
for
isaac,
maybe
you
remember
or
jordan,
you
remember.
C
Yeah,
I
think
this
is.
I
don't
think
that
the
state
of
this
has
changed.
We
need
an
rfc
for
the
node
modules
tree
has
changed
in
some
way
type
of
lifecycle
script.
I
believe
that
that
was
I.
If
I'm,
if
I
remember
correctly,
we
had
decided
that,
like
let's
finish,
gar
was
was
working
on
a
an
exercise
of
kind
of
documenting
and
auditing.
All
of
our
life
cycles.
Scripts.
C
Am
I
remembering
that
correctly
yeah
and
that's
the
reading
is
now
actually
accurate,
okay,
great
great,
so
yeah.
I
think
the
way
is
cleared
now
for
us
to
have
an
rfc
that
identifies
that
that
missing
type
of
interesting
event
and
assigns
a
new
lifecycle
event
name
for
that
it
should
not
be
pre-install
post
install.
It
should
be
something
different,
because
those
are
kind
of
already
have
like
semantics
attached
to
them
and
expanding
those
semantics
beyond
the
already
fuzzy
problematically
fuzzy
state
they're
in
now
is
is
not
a
great
idea.
C
A
A
Yes,
I
think
that
will
help
with
the
confusion
and
they'll
be
more
clear
what
it
you're
actually
like,
attaching
to
go
head
car.
B
Another
thing
that
came
out
of
this
is
is,
and
there's
no
rfc's
coming
out
of
this
yet,
but
a
plan
on
the
cli
team
to
move
life
cycle
scripts
out
of
scripts
because
there's
some
confusion
there
about
npm
run,
does
it,
but
if
it
runs
the
life
cycle,
it's
another
thing.
B
Obviously,
if
we
implement
it
in
seven
and
have
to
fall
back,
but
the
idea
is
we
push
people
toward
defining
their
life
cycle
scripts
in
one
place
and
then
the
things
that
work
on
npm
run
and
another,
and
if
you
need
one
to
run
the
other,
then
npm,
the
lifecycle
strips
can
just
call
npm
run
right.
So
that's
just
another
thing:
that's
falling
out
in
our
in
our
internal
discussions.
A
Awesome,
thank
you.
Okay.
So,
in
terms
of
this,
do
you
want
to
keep
it
open,
but
maybe
take
it
off
the
agenda.
B
A
Keep
it
open
until
we
essentially
have
another
rfc
that
supersedes
it
or
just
to
essentially
keep
this
as
like
a
running
debt
that
we
have
to
pay
down,
because
otherwise,
I
don't
think
we
have
any
sort
of
like
backlog
to
do's,
specifically
for
for
creating
rfcs.
A
Issue
for
it
yeah
in
this
in
this
repo,
so
one
of
the
two
works
for
me
action
item
for
me,
though,
is
going
to
be
taking
off
the
agenda
label,
so
any
other
feedback
on
that
any
other
commentary.
A
C
No,
no,
I
I
think
the
like
we
just.
We
need
to
open
an
rfc
for
a
new
mutation
event
describing
when
it
happens,
and
what
data
is
shared
with
it
and
and
in
what
way
the
the
space
to
bike
shed.
Is
that
there's,
somewhere
between
a
full
and
comprehensive
description
of
like
the
diff
object
that
arborist
generates
and
on
the
other
side
of
the
spectrum,
you
get
nothing,
we
fire
it
and
you
look
at
it
and
you
do
whatever
you
want
and
that's
an
implementation.
C
It's
not
an
implementation
detail,
because
it's
part
of
the
api
surface
for
using
the
script
hook
so
yeah
for
using
this
life
cycle
event.
So
we
just
need
to.
We
just
need
to
document
what
that
is.
I
mean
I
would.
C
I
would
push
for
the
I
would
push
as
hard
as
possible
and
you
get
nothing
because
it's
very
future
proof
it's
you
know,
prevents
us
from
having
to
shim
or
or
back
port,
any
kind
of
breaking
changes
we
make
in
what
that
diff
object
looks
like
it
frees
our
hands
much
more,
but
obviously
it's
less
useful
and
it
puts
a
little
bit
more
work
on
the
side
of
the
user.
E
C
E
A
pre
and
a
post
right
so
assuming
that
there's
a
pre
and
a
post,
it's
it
is
less
useful
but
is
somewhat
reasonable.
Because
then
I
can
always
look
at
what
I
care
about
and
then
look
at
the
next
thing.
Yeah,
especially
if
arborist
provides
some
sort
of
diff
where
I
could
like
back
up
the
package
lock
and
then
you
know
like
if
there's
some
trivial
tools
that
I
could
opt
into,
then
that
preserves
the
future
proofing
without
completely
avoiding
the
convenience
yeah,
that's
something
we
can
discuss
later
so.
C
Yeah
pre
pre
would
be
you
read
the
package
tree
and
then
you
stash
that
somewhere
and
then
post.
You
read
the
package
tree
again
and
look
at
the
thing
you
stash
and
you
do
a
diff.
I
mean
that
that's
kind
of
like
the
the
baseline.
We
could
do
that
right.
We
could
do
that
today
and
it'd
be
very
easy
and
very
unlikely
that
we
ever
break
it
somewhere
in
there.
C
A
E
C
Mean
you
could
just
create
an
rrfc
issue
and
assign
it
to
yourself
if
you'd
like
yeah,
I
have
the
time
to
write
a
bullet
point.
A
Okay,
thank
you.
Thank
you
so
much
for
for
the
feedback
there,
but,
and
we
that
may
be
something
that
we
do
but
yeah
it
might
make
more
sense
to
just
keep
creating
rfc
or
rc
tickets
cool
moving
on
then
313.
A
The
issue
are,
or
the
yeah
sorry
the
rfc
for
adding
method
for
help
to
have
a
config
option.
This
is
by
yesh
singh.
Who
actually
was
the
person
who
helped
get
the
set
scripts
landed
in.
I
think
7.1.
A
C
Yeah,
that's
I
I'm
sorry.
I
should
have
probably
removed
the
agenda
label
there.
That's
that's
something
we
should
just
do
we're
in
the
middle
of
a
pretty
massive
refactor
of
configs
right
now,
so
that
our
config
help
is
all
procedurally
generated
from
the
config
definitions
and
everything
is
in
one
place
with
the
default.
The
description,
the
type
everything
once
that's
done.
It
will
be
extremely
easy
to
just
dump
the
help
output
for
one
particular
config
option
so
yeah.
C
We
could
probably
just
close
this
rrc
the
only
thing
that
I
think
might
be
kind
of
worth
bike
shedding.
There
are
some
config
options
that
are
that
match
a
top
level
command.
So
if
you
ran
npm
help
user
agent
right
like
I
know
that
that's
a
config
option
and
it's
not
a
command
name.
If
you
ran
npm
help,
audit
or
npm
help
diff,
okay.
Well,
that's
a
config
option
that
is
also
a
command
name.
So
how
do
you
explicitly
get
help
on
that?
C
C
E
B
Yeah,
I
think,
isaac
in
your
suggestion
there,
where
it's
showing
the
unhelpfulness
of
being
too
helpful.
The
problem
is
that
it
shouldn't
say:
oh
there's
this
other
thing
I
know
about
I'll,
show
that
instead,
it
should
say
that's
not
a
thing
help
config
that
works
go
type.
That
right,
we
don't
being
too
helpful,
would
be
an
anti-helpful
here.
Because
of
the
thing
you
mentioned,
where
one's
going
to
work
and
the
other
is
going
to
work
for
something
else
and
not
give
you
the
config
yeah.
E
C
Sure
yeah
I
mean
a
npm
config
help
top
level
command
or
if,
if
you
set
usage
and
config
has
another
argument,
then
show
the
help
for
that
argument,
I
I
have.
I
have
no
opinions
as
to
the
shape
of
this
bike.
Shed
we're
just
kind
of
the
functional
pieces
will
be
there
very
shortly
to
do
it
so.
F
I
guess
the
other
thing
I'd
say
in
that
is
that
generally
in
javascript
tooling,
I
I
have
seen
dash
health
or
dash
helper
dash
h,
that's
that's
the
kind
of
standard.
A
Yep
cool
my
car,
I
see
your
hands
up.
B
Yeah
just
to
say
that
the
refactoring
in
our
commands,
the
usage
output
and
this
config
we're
moving
towards
a
place
where
supporting
this
should
be
something
that
just
falls
out
of
it
right
and
as
far
as
what
flags
make
it
happen
whatever.
But
yeah
we're
we're
not
that
far
away
from
being
able
to
actually
give
useful
usage
output
versus
something
we
just
hand
type
and
hope
that
covers
all
the
bases.
A
Awesome:
okay,
so
unless
there's
some
more
commentary
there
and
feel
free
to
add
again
comments
back
to
the
issue
itself,
I'm
going
to
move
on
to
the
next
agenda
we
had,
which
was
essentially
just
an
update
for
workspaces
roy.
This
is
rfc.
A
D
D
So
that
is
a
separate
rfc
that
I
need
to
go
ride
it
probably
right
now
it's
gonna
be
a
good
time
to
to
get
it
done,
but
would
be
nice
to
start
gathering
some
feedback
ideas,
any
possible
unintended
consequences
of
that.
But
I
think
from
the
user
experience
point
of
view,
it's
the
users
already
have
an
expectation
like
if
I
sit
into
a
workspace
and
I
run
npm
tests,
they
already
have
the
expectation
of
that
working.
So
I
I
feel
this
is
more
of
a
bug
fix
than
major
kind
of
change,
but
yeah.
A
So,
just
to
summarize
what
you're
saying
here,
maybe
in
just
a
little
bit
different
fashion,
what
we're
noticing
or
what
we're
hearing
is
that
when
somebody
is
inside
of
a
workspace
directory,
that's
obviously
like
not
the
you're
not
on
the
route
anymore.
A
The
expectation
is
that
when
they
run
npm
command,
that
we'll
become
workspace,
aware
with
the
work
that
we're
doing
here,
that
it
should
run
similar
to
or
if
not
the
same
as
if
it
was
run
in
the
root
of
that
project,
with
the
workspace
flag
set
to
that
directory.
It's
that
precisely
yeah
yeah
yeah.
A
This
would
be
a
bit
of
a
change
from.
I
know
how
we've
discussed
this
over
the
last
last
year
or
so
from.
If
you
cd
into
a
workspace
directory-
and
you
run
npm
install,
you
know
the
expectation
there
is
that
that's
going
to
create
the
log
file
there
that's
going
to
install
the
dependencies
there.
That's
like
not
going
to
know
about
the
fact
that
it's
actually
a
part
of
this
larger
project,
whereas
now
you
know
the
expectation
is
that,
if
you're
inside
of
a
workspace
directory,
it's
going
to
do
this.
A
D
A
So
I
guess
my
only
like
thought
there
is
just
like
how
far
do
we
go?
We
go
all
the
way
up.
Do
we
continue
to
resolve
and
walk
the
you
know
like
how
far
do
you
look
for,
because,
if
you're
nested
the
workspace
you
know
then,
where?
Where
do
we
look,
for,
I
guess
the
the
def
workspace
definition
and
the
package
json
to
that
workspace
right.
D
Yeah,
I
do
believe
arborist
already
has
some
helpers
that
look
up
that
just
recursively
look
up
trying
to
find,
but
isaac
can
probably
speak
a
little
bit
more
to
that
specific
functionality,
but
I
think
we
go
up
as
much
as
we
can
and
we
try
to
find
a
package.json
with
a
workspace
definition
on
it
and
as
soon
as
we
find
it-
and
it
just
corresponds
to
the
path
that
we're
currently
running
on
right.
We
can
say
that
that's
a
match
like
this.
A
A
Like
some
some
edge
cases
or
issues
where
you
know
somebody's
created
directory
manually,
they
jump
into
that
or
they've
done
npm.
You
know,
let's
say
they've
yeah
yeah
they've
created
a
directory
manually.
They
jump
into
that
and
then
they
run
a
npm
command
to
like
install
or
or
add
a
depth
to
that
workspace
and
there's
no
reference.
A
Yet
to
that
workspace
and
the
package
json
in
the
root,
then
you
know
you
obviously
have
a
mismatch
there
right
so
and
that's
just
one
edge
case
that
I
can
imagine
like
you
know,
people
will
will
find
people
getting
into
some,
maybe
unexpected
behavior
then
still
but
yeah.
I
don't
think
that's
any
different
than
what
people
are
experiencing
today
with
workspaces.
So
I
don't
know
if
it's
any
better,
better
or
worse
so
cool
anybody
else
have
thoughts,
feelings
about
that.
D
Yeah
I'll
go
ahead
and
put
a
put
up
the
the
actual
rfc,
and
we
can
talk
a
little
bit
more
over
next
week.
Cool.
A
Thank
you
cool,
so
moving
on
pr
and
rfc
336,
adding
a
wear
config
to
commands,
so
nilf
wasn't
able
to
join.
Unfortunately,
today,
although
we've
talked
about
this
a
little
bit
internally,
and
if
I
open
up
this,
I
also
see
that
roy
you've
also
chimed
in
a
little
bit.
A
So
you
know,
maybe
I
can
give
a
high-level
synopsis
of
what
this
is.
It's
essentially
a
config,
as
we
were
looking
at
npm
config,
specifically,
we
noticed
that
there
was
only
two
locations
where
you're,
essentially
able
to
edit
your
mpmrc
file,
or
essentially
edit
config
and
and
one
of
them
and
and
neither
one
of
them
was
project
level
specific.
A
I
think
we
expose
the
fact
that
you
know
it'd
be
great
to
have
the
ability
to
define
where
we're
essentially
looking
where,
like
what
location,
we're
essentially
like
looking
and
running,
commands
against,
and
so
in
this
case
the
proposal
is
to
sort
of
expose
the
sort
of
four
areas
we
we
typically
look,
look
up
or
or
interact
with
the
system,
so
it's
usually
at
the
project
level,
user
level,
global
level
and
sort
of
the
built-in
config,
obviously
is
not
something
that
we're
gonna.
A
Let
you
like
modify,
but
those
three
global
user
and
project
level
paths
are
or
something
we
want
to
kind
of
like
bubble
up
to
the
surface
and
yeah.
C
Nobody
has
thoughts
or
yeah,
so
my
my
only
I
I
mean
I
I'll
I
can.
I
had
meant
to
kind
of
chat
with
this
chat
over
this
with
milf
directly,
but
my
only
concern
which
maybe
would
maybe
it's
just
not
relevant
or
we
just
deal
with
it
some
other
way.
But
my
only
concern
is
that
the
word,
where
is
very
vague
and
we've
gotten
ourselves
into
trouble
in
the
past
kind
of
having
config
options
and
flags
that
that
do
double
duty.
C
C
You
know
what
I
mean,
but
it
does
make
sense
for
where
to
set
a
config
value,
so
it
I,
I
would
almost
prefer
to
have
two
flags
right
like
one
one
for
exact
and
another
one
for
config
and
and
have
the
names
be
unambiguous.
So
you
know
npm
config
set
foo
equals
bar
dash
dash,
which
config
equals
user
right,
like
might
be
it's
a
little
more
verbose.
C
But
and
generally
I
do
like
things
to
be
shorter
and
easier
to
type,
but
that
would
avoid
a
situation
where,
like
you
know,
we
kind
of
have
this
sort
of
fuzzy
fuzzy
boundaries
between
some
of
these
config
files,
and
I
might
just
be
hypersensitive
to
that,
because
I'm
in
the
middle
of
you
know
refactoring
how
our
configs
work.
But
I
think
it's
a
worthwhile
thing
to
consider.
A
Yeah
scope,
config
is
a
real
thing
that
I
think
we're
trying
to
address
right
so
yeah
our
command
specific
config
is
a
thing
we're
trying
to
address.
I
always
go
back
to
at
least
personally.
I
always
go
back
to
the
way
that
you
can
configure
init
as
kind
of
an
example
of
almost
like.
We
almost
got
there
at
one
point
or
like
we
have
init
dash
author
or
init
dash
something
else,
and
obviously
that
config
means
nothing
to
almost
every
other
command,
even
though
it
gets
passed
around.
So
I'm
not
sure.
A
A
B
B
This
is
just
for
npm
config,
right
to
tell
it
either
when
it's
getting
or
sending,
because
I
mean
we
could
reuse
this
for
get
too
to
see
at
what
level
yeah.
I
think
this
is
just
by
shed
the
name
and
make
sure
that
it's
not
going
to
collide
with
anything
else.
You're
using
having
the
word
config
in
it
might
seem
overly
verbose,
but,
like
the
use
case
of
this,
isn't
going
to
be
something
that's
so
onerous
that
a
little
extra
typing
is
going
to
hurt
us.
B
A
Yeah,
I'm
super
easy
on
what
the
actual
names
are
like
it's.
It's
has
nothing.
I
really
don't
care
about
that,
it's
more
so
that
I
I
really
want
us
to
be
able
to
introduce
this
in
a
flag
that
you
can
specifically
for
config
that
you
can,
which
is
really
interesting,
because
you
could
define
this
at
the
user
level.
A
You
can
define
that
config
that
you
want
actually
npm
config
to
respect
the
project
level
and
then,
but
today
you
could
get
your
npm
config
to
default,
to
essentially
being
like
project
like
look,
get
and
set
at
the
project
level,
because
I
feel
like
that
at
least
personally,
I
feel
like
that's
the
way
it
should
be
in
mpm8
and
going
forward,
but
introducing
the
option
to
like
configure
it
by
default
or
in
like
a
minor,
because
we
put
it
behind
a
flag
is
like
a
great
first
step
to
that.
B
A
Good
thing:
okay,
so
I'll
leave
that
on
the
docket
for
now-
and
hopefully
maybe
even
next
week
enough-
can
joining
the
call
moving
on
to
the
other
rc
that
he
had
proposed,
which
was
and
sort
of
in
line
with
some
of
the
discussion.
We've
already
had
rc
number
339,
improving
the
command
suggestions,
or
I
believe
this
is
the
fallback
output
that
we
we
provide
to
the
users.
A
I
know
jordan,
you
had
looked
at
this
and
isaac
had
also
commented
on
this.
I
think
there's
been
some
updates
here,
like
in
terms
of
the
work
that
gar
you've
been
doing
like
the
did.
You
mean
work
that
you've
done.
B
A
Anybody
have
any
questions
about
what's
being
proposed
here,
just
improvements.
This
is
just
like
cleaning
up
and
making
improvements
to
like
the
suggestions
that
you
get
when
we
don't
know
what
what
you
meant,
because
we
don't
actually
know
whether
it
was
command
whether
it
was
a
script,
whether
it
was
binary
you're
trying
to
execute
like
jordan,.
E
Yeah,
just
I
mean
the,
I
think,
the
the
spirit
behind
the
comment.
The
one
comment
I
made
on
the
pr
was:
the
output
should
be
as
concise
as
possible,
while
also
pointing
me
as
quickly
as
possible
to
the
thing
I
really
wanted
to
do.
So.
If
I
see
like
two
paragraphs
of
explanation,
that's
too
much
if,
but
similarly,
if
I
see
a
list
of
commands,
but
I
don't
know
what
they
do
like,
what
the
difference
is
between
them-
that's
not
helpful
either.
B
Yeah,
okay,
did
you
want
to
demo
this?
Yes,
we
would
a
demo
not
memo.
Let's
do
it.
So
here's
my
pull
request
right
now
and
based
on
that
comment,
I'm
going
to
make
the
change
I
wanted
to
make,
which
is
to
remove
the
usage
dump
from
the
suggestion,
because
if
we
know
what,
if
we
know
how
to
suggest
things,
we
shouldn't
be
dumping
all
that
we
should
either
say
I
don't
know
what
you're
talking
about
or
you
could
have
been
talking
about
these
things
right
and
this
is
in
the
pool.
B
C
Also
worth
commenting
here,
this
usage
banner,
when
you
just
run
npm
with
no
args,
is
absurdly
long.
I
mean
when
there
was
when
there
was
five
commands.
It
was
perfect
and
now
that
there's
like
a
bazillion,
it's
a
little,
it's
a
little
61.
absurd.
So
yeah
and
yeah.
B
A
Are
great
so
thank
you,
yeah
very
useful
demo.
Thank
you,
and
that
brings
us
to
essentially
the
end
of
the
agenda.
We
had
was
there
because
we
actually
have
some
extra
time.
Did
anybody
have
an
rc
or
any
items
that
they
want
to
bring
up.
G
A
Sure
so
I
think
we're
we
want
to.
Essentially
you
know,
sort
of
lament
a
or
the
action
item
here
is
to
lament.
A
You
know
the
fact
that
I
don't
think
we're
going
to
move
forward
with
the
fallback
style
that,
like
copying,
sort
of
the
implementation
that
yarn
has
and
sort
of
the
rfc
as
you
have
it
today,
but
in
this
call
I
think
we've
explicitly
talked
about
a
couple
rfcs
that
have
been
open
since
the
last
conversation
since
the
last
two
weeks
that
we're
trying
to
improve
the
help,
help
search
and
sort
of
the
suggestions
that
we're
giving
when
we
don't
know
what
you
meant
to
run.
A
So
we
want
to
essentially
give
clear
you
know.
The
action
home
is
we'll
give
a
clear
reason
why
we're
probably
not
going
to
move
forward
with,
like
the
yarn
style
fall
back
and
but
with
the
hopes
and
not
hopes
but
like,
but
with
the
understanding
that
we're
also
going
to
try
to
improve
the
experience
of
like
npm
exec
mpm,
run
and.
G
Yeah
yeah
yeah,
I
think,
there's
the
tension
with
the
idea
that,
like
a
local
exec
like
running
tsc,
still
required
adding
a
script
and
doing
a
bunch
of
hoops
to
get
to
a
point
where
you
could
have
local
without
using
mpx.
Sorry,
I
know
that's
the
whole
thing:
okay,
yeah
I'll
read
up
on
all
the
stuff.
C
Bottom
line
when,
when
somebody
runs
npm
install
tsc
and
npm
tsc,
it's
not
going
to
run
tsc,
but
it
will
tell
them
what
to
do
in
a
way.
That's
a
lot
more
useful
than
what
we
have
today.
C
C
Yeah
yeah,
so
the
specifics
of
like
what
goes
in.
We
did
a
little
bit
of
discussion
and
there's
some
open
rocs
on,
like
the
specifics
of
what
those.
What
that
help
output
is,
but
essentially
we're
gonna
get
rid
of
the
the
massive
npm
usage
banner
in
cases
where
we
made
some
kind
of
reasonable
guess
and
say:
instead,
did
you
mean
npm
run
tsc,
or
did
you
mean
npm,
exec,
tsc,
local
or
you
know,
exact
local
tsc
or
something.
G
C
G
A
Yeah
and
if
you
check
out
the
other
two
rfcs
that
nilf
put
together,
I
think
that
those
also
kind
of
help,
like
obviously
we
have
a
dental,
prop
identified
a
problem
here
in
terms
of
consistency
and
also
the
developer
experience
we
want
to
improve
so
like.
I
think
that
what
what
I'll
say
is
like
we
really
appreciate
that
you
are
poking
on
this
right
like
because
it's
it's
forcing
mtm
to
be
better
right,
like
in
a
bunch
of
different
ways,
so
yeah.
A
So
thank
you.
Thank
you
all
cool
yeah,
so
roy
you
said
you
had
a
couple
items
you
wanted
to
also
bring
up
here
with
the
extra
time
that
we
had.
D
Yeah,
I
think
there
was
a
couple
of
discussions
from
the
last
meeting
we
didn't
got
to,
but
basically
there
was
this
feedback
around
the
resolver
message.
Just
just
basically,
I
think
it's
surface
on
twitter
or
something
like
that,
but
basically
people
keep
hitting
resolve
errors
like
and
the
solution
is
right
there
for
them.
The
alternatives
right
like
run
with
force
or
legacy
pure
period,
slides
to
to
try
to
unblock
you.
D
If
you
can't
do
anything
about
your
install
tree,
but
yeah
people
keep
still
like
being
confused
and
like
what
do
I
do
with
this,
so
the
idea
was
basically
the
the
topic
of
the
discussion
is
like
how
we
better
highlight
this.
Actually,
these
actual
action
items
to
make
sure
we
help
out
the
users
still
hitting
those.
C
Maybe
I
mean
you
do
have
to
kind
of
read
and
interpret
some
english
prose
with
that
existing
message
right
we
could.
We
could
tell
them
what.
A
C
We,
we
could
just
say
you
know,
fix
the
upstream
dependency
conflict
or
try
one
of
the
following
commands
and
then
print
out
what
command
they
ran.
And
then
we
tack
on
dash
dash
force
or
we
tack
on
dash
legacy
pure
depth,
cause
we're
kind
of
like
that.
Would
that
would
give
them
something
that
can
copy.
A
C
Level
differences
that
we
could
be
relying
on,
then
I
think
printing
out
printing
out
the
the
explanation
in
the
e-resolve
report
is
probably
worthwhile
like.
If
it's
your
dap,
that's
conflicting,
I
mean
I've
talked
to.
I've
talked
to
a
few
people
who
are
like.
This
is
great.
I
had
no
idea
that
this
bug
was
lurking
here
and
that
would
have
broken
a
bunch
of
stuff
and
we
fixed
it
all,
and
I've
seen
some
depths
that
that
were
some
of
our
early
e-resolve
reports.
Once
we
added
those
explanations
they
just
fixed
it.
C
I
know
gatsby
has
been
kind
of
it's
been
a
big
project.
They've
been
up
to
like
that's
a
net
win
for
the
community
right,
that's
improving
things.
I
don't
want
to
take
that
away,
but
also,
if
it's
not
your
depth
and
something
crashed
and
or
it's
not
a
depth
you
care
about,
then
the
the
reported
fix
should
not
require
you
to
read
as
many
words.
C
A
Yeah,
I'm
just
also
thinking
about
npm,
like
audit
warnings
right
like
so,
we
don't
display
all
the
depths
that
essentially
like
that
audited
with
that
essentially
have
errors
in
them
right
or
vulnerabilities,
like
we
don't
print
that
out
by
default.
We
just
give
you
a
nice
like
one-liner
about
like
that
information
and
tell
you
like.
If
you
want
to
learn
more,
you
can
do
this.
C
Right
so
if
you
install
and
there
were-
and
there
were
audit
vulnerabilities-
that's
not
something
that
prevents
a
correct
resolution
of
the
package
tree.
So
the
contract
of
npm
install
is
when
you
run
npm
install
you
get
a
a
package
tree
in
node
modules
that
satisfies
this
contract.
To
this
level
that
we
have
established
right.
A
C
And
we
already
downgrade
the
log
level
when
it's
just
a
warning
right,
so
it's
log
level
worn
rather
than
error.
I
mean,
I
think
it's
fine.
I
think
that,
like
the
lightweight
solution
here
of
like
let's,
let's
make
a
more
useful
suggestion
block
would
probably
prevent
a
lot
of
the
twitter
issues
that
are
popping
up
without
without
taking
away
the
bit
of
it.
That's
actually.
D
C
Like
it'd
be
nice,
you
know
what
one
one
wild
idea
for
user
experience
enhancements,
that
sort
of
sort
of
dovetails
with
the
the
did
you
mean
stuff
like
it
would
be
nice
if,
in
that,
in
that,
like
final
error
handler
right,
if
we
have
a
set
of
suggestions
for
things
that
we're
suggesting,
maybe
you
should
run
instead,
we
if
we
could
make
that
interactive,
that
might
be
really
cool
and
I
think
if
users
were
presented
with
a
prompt
that
said
like
do
you
want
to
run
this
with
force
or
do
you
want
to
run
it
with
legacy
pure
dapps
and
they
typed
one
or
two
or
used
up
and
down
arrows
or
whatever
like?
C
I
have
to
pick
and
pick
one
and
similarly,
for
you
know
if
I
ran
npm
tsc
and
it
said
well,
did
you
mean
one
of
these
things
and,
like
you
know,
I
could
press
escape
to
just
exit
and
do
something
else
like
that
kind
of
is
nice
and
that.
C
So
I
don't
know-
maybe
that's
that's
kind
of
a
that's
in
my
list
of
things
that
I've
been
meaning
to
write
in
rfc
for
but
I'm
waiting
until
after
we
have
this.
Did
you
mean
stuff
kind
of
a
little
more
sparkling.
A
B
D
D
C
C
I
I
think
it's
I
think
it's
just
a
backlog
feature
request
really,
but
the
feature
request
was
basically
to
make
lock
file
version
a
configurable
option,
so
I
could
set.
I
could
run
npm
install
dash
dash,
lock,
file
version
equals
one
and
it
would
save
a
you
know:
log
file
version,
one
style
package.json
file
or,
alternatively,
if
I
want
to.
If
I
want
to
jump
ahead
into
the
future,
I
can
do
lock
style
version.
Lock,
file
version
equals
three
and
then
not
include
all
the
backwards
compatibility
junk.
C
So
if
I
know
that
my
whole
team
is
working
on
npm
seven
and
we're
not
using
npm
six
at
all,
I
can
cut
the
size
of
my
lock
file
down
by
about
what
like
40
percent
or
so
35
to
40
by
just
not
including
all
the
backwards
compatibility
stuff.
So
yeah,
I
I
think,
that's
a
that's
a
good
suggestion
and
it's
entirely
almost
entirely
an
arborist
except
for
the
definition
of
the
top
level
command.
But
what
we
could
also
do
is
only
upgrade
never
downgrade
a
lock
file
that
we
see.
C
So,
if
you're
in
a
project
that
has
a
lock
file
version
of
three
and
your
current
configured
lock,
file
version
is
two
we'll
be
like
okay,
but
this
lock
file
version
is
three,
so
I'm
just
gonna
stay
on
three,
but
it
would
still
upgrade
from
version
two
so
that
subsequent
installs
could
be
more.
You
know
fancy.
C
C
Well,
I
don't
know
whatever
version
of
npm
has
implemented
lock
style
version
five.
At
that
point,
we've
probably
decided
that
we
no
longer
care
about
npm,
seven
support;
okay,
presumably
like
it's.
It's
the
same
thing
of
like
what,
if
you're,
using
npm
eight,
which
doesn't
which
defaults
to
let's
say
a
lock
style
version,
lock
file
version
of
three,
so
there's
no
backwards
compatibility
for
npm,
five
and
six,
it
is
what
it
is
like.
C
A
We
have
a
couple
minutes
left.
Anybody
else
have
any
thoughts
anything
else.
They
won't
share
any
announcements
for
folks
that
might
have
just
joined.
F
No,
only
the
only
thing
is
just
a
request
on
on
getting
getting
refreshed
eyes
on
the
audit
license.
Rfc
I
just
like
to
whatever
whatever
the
next
steps
are,
even
if
it's
closing
it
just
any
kind
of
next
steps
there
or
rewriting
it
completely.
I'm
fine
with
that.
F
I'm
happy
to
do
it
this
week
or
whenever
it
works
for
y'all,
whenever
you're
all
able
to
get
that
feedback.
But
that's
that's
the
only
one.
F
That's
182..
I
commented
on
it
at
the
end.
C
Yeah,
I
think
auditing
auditing
licenses,
when,
if
I
remember
correctly
when
this
was
created,
npm
7
had
not
yet
been
released.
But
I
think
now
we
we
kind
of
have
all
that
info
in
the
in
the
package
lock
and
in
the
in
the
tree
as
we
as
we
read
it.
So
it
would
be
a
lot
easier
to
implement
now.
G
A
We're
essentially
that
time
I
appreciate
everybody
jumping
on
today
and
had
some
good
discussion
for
sure
feel
free
to
keep
adding
comments
and
and
keep
proposing
our
seats.
This
is
great.
This
is
helping
us
a
lot,
and
I
think
that
you
know
npm
is
is
improving
because
of
it.
So
thank
you.
So
much
hopefully
see
you
all
next
week
same
time
same
place,
cheers
later.