►
From YouTube: Open RFC Meeting - Wednesday, January 26th 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
just
double
checking
we
should
be
live.
Awesome,
yeah,
we're
live,
welcome
everyone
to
another
npm,
open
rc
call.
Today's
date
is
january.
26
2022,
we'll
be
following
along
in
the
agenda
that
was
posted
in
the
rc's,
repo
and
pmrc's
repo,
which
was
number
517
and
I'll
quickly
share
for
folks
who
don't
have
it
yet
the
me
notes,
link
and
poked
a
couple
folks
in
slack
channels
feel
free
to
jump
in
whenever
you
can
quick
reminder.
A
This
call,
as
well
as
all
interactions
on
the
rc's
repos
are
covered
under
code
of
conduct.
We
ask
that
you
please
be
mindful
and
thoughtful,
as
other
people
are
speaking.
Please
raise
your
hands
on
these
calls
if
you'd
like
to
jump
in
and
we'll
call
upon
you
to
speak
and,
as
usual,
give
some
time
for
announcements.
The
one
that
we've
had
here
for
the
last
couple
weeks
on
our
radar
is
the
openjs
world
conference,
which
is
still
looking
for
proposals.
Talk
proposals.
Please
check
that
out.
A
A
Oh
thanks
owen,
so
yeah
it
closes
on
february
14th,
it's
the
last
day
to
get
your
proposal
in.
Hopefully
folks
from
our
team
will
be
joining
that
conference
either
speaking
or
just
joining
virtually
are
in
person.
Hopefully
great
any
other
announcements
folks
want
to
share.
A
If
not,
then
we
can
just
dive
right
into
the
agenda.
It's
pretty
small
today
and
there's
a
couple
things
that
we
might
want
to
cut
from
this.
The
first
up
is
the
deprecating
packages
and
ux
revamp
roy.
This
is
rfc
number
516..
Did
you
want
to
speak
to
this.
B
Sure
yeah
it's
a
long
time
coming.
This
is
something
that
was
surfaced
last
year,
so
just
finally
got
to
write
the
proper
rfc
to
explain
it,
but
it's
a
nice
thought
exercise.
You
can
look
at
the
render
rfc.
Let
me
paste
the
link
here,
but
basically.
B
It's
about
replacing
the
application
warnings
that
we
got
printed
during
the
install
that
is
kind
of
like
the
last
step
in
kind
of
the
work
we've
been
doing
to
just
clean
up
the
install
experience
all
together.
It's
been
a
long
time
coming,
so
we've
been
favoring,
adding
the
notifications
at
the
end.
So
as
we
do
for
audit
as
we
do,
we
did
for
fun
when
we
introduced
it,
so
it
would
basically
replace
any
deprecation
warning
that
just
gets
printed
directly
the
standard
output
into
a
nice
notification.
B
At
the
end,
just
saying,
okay,
you
have
three
deprecated
packages
in
your
install
and
then
giving
the
option
to
the
user
to
do
a
different
action
to
maybe
check
for
an
overview
of
all
the
of
all
the
deprecation
notices
that
were
basically
bubbled
up
during
the
install
but
yeah.
But
when
I
was
writing
that
rfc,
I
got
to
start
thinking
yeah.
What
should
that
interface?
Look
like
so
for
the
sake
of
a
first
pass
here.
B
I
I
just
left
it
as
just
the
the
same
thing
you
would
get
during
the
npm
install
phase
that
same
list
just
decluttered
a
little
bit
so
that
it
doesn't
have
the
warning
deprecated
like
written
the
prefix
of
every
line.
So
it's
a
little
bit
cleaner
on
that
regard,
but
it's
basically
the
package
name
version
and
then
the
that
message
that
the
package
author
can
can
leave
when
when
they
decide
to
deprecate
a
package
so
yeah,
that's
the
first
pass.
B
I
left
just
as
the
list,
and
then
I
imagine
that,
like
ideally,
we
probably
want
to
augment
or
or
just
improve
the
existing
commands
to
maybe
surface
help
surface
better,
the
deprecation
so
yeah.
I
suggest
it
here
that
maybe
expand
npmls
and
pm
explain
to
also
add
information
about
a
deprecated
package.
So
if
you're
running
in
piano
less
because
you
like
to
check
on
your
on
the
state
of
your
three
install,
then
you
can
notice
right
away.
Oh
this
bracket
is
dedicated.
Why,
then
you
can
go
deep
for
it
like
so
yeah.
B
Instead
of
we
can
also
go
another
different
route.
Maybe
try
to
have
a
different
command
that
can
just
explain
more
about
the
deprecation,
but
I
think
the
explaining
and
ls
do
a
good
job
already
of
showing
you
where
you're
getting
that
dependency
from.
So
maybe
that's,
probably
what
we
want
to
use
and
just
have
some
sort
of
so
so
there's
the
option
of
either
having
it
as
a
top
level
command
like,
I
think,
the
grfc
here
I
named
it
like
npm
deprecations,
but
not
in
love
with
it,
open
to
anything.
B
It
can
be
better,
but
it
can
be
either
a
top
level
command
like
deprecations
in
this
case
that
prints
a
list
or
maybe
just
part
of
a
different
command
under
a
flag
or
something.
But
basically
it's
the
idea.
Okay,
getting
that
overview
list
from
somewhere
and
then
and
there's
the
call
to
action
at
the
end
of
the
install
and
then
you
can
dig
more
into
it.
So
that's
it!
B
It
might
be
a
good
one,
but
I
think
that
there
are
arguments
to
be
made
both
and
both
ways.
So
I'd
like
to
hear
different
opinions,
but
yeah,
because
maybe
now
we
have
overrides
now,
you
actually
can
do
something
about
it.
But
before
that
there
was
nothing
really,
you
could
do
about
duplicated
transitive
dependencies
right.
B
So
yeah,
I'm
also
open
happy
to
hear
some
opinions.
C
So
I
don't
know
if
overrides
would
actually
help
for
deprecated
packages
unless
there's
like
a
direct
fork
that
has
the
same
api
right
as
as
far
as
you
know,
overriding
transient
dependencies,
but
I
think
that's
interesting.
My
immediate
thought
is,
you
know
I
don't
think
we
need
a
dedicated
command.
C
I
also
don't
think
that
we
need
a
global
flag.
I
I
think
you
know
long
term
we're
looking
at
being
able
to
surface
certain
packages
easier
in
general,
so
I
think
we
need
to
think
in
terms
of
that
and
darcy,
and
I
have
been
talking
about
that
for
a
while.
C
So
but
I
I
do
like
the
output,
I
think
it's
less
scary,
and
then
you
know
this
kind
of
also
goes
along
with
with
audit
in
that
in
when,
when
something's
installed
globally,
we
probably
don't
need
to
hear
about
dev
dependencies
for
audit
or
for
deprecations,
but
maybe
within
a
as
a
as
a
dependency
or
a
transient
dependency
depending
so
anyway.
Those
are
my
thoughts.
A
Yeah,
so
I
like
this
a
lot.
I
appreciate
you
codifying
this
roy
because
we,
I
think
I
gave
this
feedback
in
you
know
another
issue
a
while
ago,
and
even
just
like
saying
yeah,
we
can
consultate
these
warnings,
like
fritzy,
said
it's
less
scary.
For
your
end
users,
a
lot
of
people
complain
about
the
deprecation
warnings
to
us
still
they're,
the
last
pieces.
You
say
roy
like
that
are
remaining
here.
A
I
do
think
that,
because
they're
currently
like
set
up
as
warnings,
this
is
kind
of
like
a
log
level
issue
like
maybe
these
could
still
live
even
install
during
install,
but
that
they,
if
they're,
somehow
we're
attached
to
a
different
log
level
like
or
we
somehow
said
that
you
know
warnings
could
be
suppressed
by
default
on
install
then,
maybe
that's
that
doesn't
matter
to
people.
A
I
think
you
have
the
right
idea
that
this
information
is
gonna,
be
there's
gonna,
be
people
that
to
know
about
this,
but
they're
going
to
be
in
search
of
it
right,
so
hiding
it
by
default
makes
sense.
A
What
did
you
call
it?
Npm
deprecations,
I
I
don't
think
that's
necessarily
necessary
at
all,
but
definitely
mpmls,
npm,
explain
and
potentially
npm
outdated
would
be
right
places
for
this
information
to
live.
Npm
outdated,
especially,
is
interesting
because,
like
the
there
might
be
a
reason
why
you
want
to
see
deprecate
like
deprecated
packages
in
the
output
of
npm
updated
because
it's
almost
people
are
running
that
as
a
warning
to
be
like:
okay,
okay,
which
versions
they
have
to
update
right
now
in
the
case
of
a
deprecation,
it's
like
this
potentially
might
be.
A
Deprecations
can
happen
within
release
lines
that
can
happen.
You
know
somebody
could
add
a
new
package
still
a
new
version
of
that
package.
That
is
actually
not
deprecated
right,
so
depositions
can
happen.
They
don't
happen
across
the
entire
package
version
set
right.
So
at
any
time
somebody
could,
you
know,
release
an
undeprecated
version
of
that
package
right.
A
So
it's
it's
interesting
because
maybe
you
want
to
see
like
that
information
or
deprecated
package
in
npm
update,
because
you
have
to
switch
to
a
new
new
package
altogether
right
like
you're
like
oh,
I
want
to
see
that
warning
here,
because
it's
like,
oh
that
you
know
this
is
just
as
bad
as
if
it's
out
of
date,
in
fact,
it's
worse,
it's
like
a
worse
signal
right.
It's
it's
like
I'm
going
to
have
to
go
from.
You
know
node
fetch
to
now
axios
because
they've
dropped.
You
know
they're
deprecating,
the
commonjs.
A
You
know
support
or
something
like
that
right,
like
so
yeah,
I
think
npm
outdated,
npm
ls
might
make
sense
and
in
terms
of
the
transit
of
dependencies
that
that
jordan
was
referencing,
we
can
get
around
that
because
we
already
have
that
capability
with
all
right.
So
by
default,
we'll
show
you
the
scope
for
in
those
existing
commands
by
default.
We'll
show
you
the
just
top
level
dependencies
direct
dependencies
and
then,
if
you
pass
dash
all
then
it's
like
okay.
A
Well
now
I
want
to
see
all
the
deprecated
dependencies,
so
we
we
already
have
that
capability
today.
So
it's
just
about
where
that
information
lives,
so
I
think
mpm,
updated
and
potentially
npm
ls
are
the
right
places.
Npm
explain
that
gets
into
territory
where
I
think,
oh,
my
well.
If
we're
going
to
put
that
kind
of
metadata
into
npm,
explain
why
don't
we
put
audit
information
into
npm?
Explain
why
we
put
all
this
other
kind
of
metadata?
A
A
But
that's
that's
my
two
cents
on
on
this.
I
think
it's
a
great
change
in
the
very
immediate
features,
something
quickly
we
can
do.
We
don't
have
to
completely
refactor
the
entire
ui
ux
right
now.
Let's
just
take
this
incremental
step
and
and
make
people
happy,
like
you
know
very
very
soon,
so
yeah.
C
Yeah,
I
agree
with
sending
the
inline
log
messages
to
a
different
log
level
and
and
having
the
summary
there.
So
we
we
keep
the
functionality,
we're
just
we're
just
changing
the
log
level
and
and
we
still
surface
the
information,
maybe
just
not
obviously
in
as
much
detail.
So
I
like
that.
D
My
one
thought
about
the
log
level
is
what
if
we
could
still
wrap
it
up
all
by
default
and
show
it
at
the
end,
but
what
if
we
kept
top
level
dependencies
as
warnings
in
case
people
are
relying
on
that
behavior
and
made
transitive
deprecations
what's
below
like
silly
or
verbose
somewhere
in
there,
and
that
would
give
my
only
concern
is
people
who
are
maybe
relying
on
this
behavior
unknowingly
of
like
hey
every
time
I
run
npm
install.
D
I
get
these
deprecations
that
I
should
really
get
to
someday
and
we
move
that
information
and
they'll
still
be
able
to
see
it
if
they
read
like
the
new
output,
but
ideally
they
would
want
to
get
to
these,
like
sooner
rather
than
later.
So
I
feel
like
hiding
top
level
ones
since
it's
a
change
in
behavior.
D
I
could
go
either
way
on
that,
but
that
was
just
my
one
thought
and
I
had
one
other
thought
which
is
like
probably
further
down
the
line
breaking
change,
but
I
do
feel
like
security,
audit,
outdated
and
deprecations
all
are
like
similar
like
is
there
a
command
that
you
could
run?
That
says,
show
me
everything
in
my
tree
that
I
should
not
be
depending
on
for
some
reason
or
another,
whether
it's
insecure,
been
marked
by
cve,
been
marked
by
a
deprecation
or
just
it's
outdated
and
there's.
D
You
know
new
versions
since
then
like
to
me.
That's
you
know
if
we
could
rewrite
everything
like
that's
technically
an
audit.
I
want
to
audit
my
package.
Tree
audit
doesn't
necessarily
mean
security,
but
I
don't
see
that
as
a
change,
we're
going
to
make
anytime
soon
to
audit
displaying
more
information,
but
that's
just
a
higher
level
thought
that
I
had
too.
A
Yeah
yeah,
I
totally
agree
with
you
where
I
would
quickly
just
push
back
on
the
showing
some
warnings
and
not
others.
We
don't
do
that
with
like
audit
advisories.
So
exactly
what
you're
saying
so
like,
and
we
don't
do
that
with
like
installed
packages
right.
So
the
type
of
information
we're
showing
right
now
for
deprecated
packages
seems
to
be
very
unique
and
and
not
like
it
doesn't
seem
like.
A
We
don't
show
for
direct
depth
that,
like
an
inline
message
or
warning
that
there's
a
cva
against
one
of
those,
we
just
showed
the
consolidated
view
of
that
data
at
the
very
end,
and
I
would
say
that
that's
actually
takes
a
higher
precedent
than
the
deprecation
warning
would
right.
So
I
would
I
would
say
that,
like
the
consolidated
view
is
probably
the
ideal
and
then
yeah
like
we
can
continue
to
maybe
log
that
information,
but
I
don't
know
if
it
exists
now
in
like
npm
outdated.
A
Okay,
like
I
I
wanted.
Maybe
you
wanted
that
deprecated
version
of
that
thing
right,
you
were
meaningfully
installing
it
are.
We
gonna
warn
you
about
that.
You
know
this
is
an
interesting
like
balance
right,
I
saw
your
hand
was
up.
Did
you
want
to
say
something.
B
I
was
going
to
speak
directly
to
that
comment
you
made
like
if
yeah,
that
might
be
much
more
important
right
if
there's
a
cv
that
affects
the
direct
dependency
like
you
could
claim
that
you
would
wanted
that
printed
in
the.
B
Warning
during
the
install
but
yeah,
I
think
that
the
idea
here,
like
the
ux,
is
really
to
have
this
as
notifications
at
the
end
and
the
user
can
take
actions
later.
D
Yeah,
I
agree
with
all
that
that
those
are
all
all
good
points
I
yeah.
I
do
see
that,
as
you
know,
deprecations
don't
shouldn't
be
treated,
especially
as
a
special
case
when
we
have
numerous
reasons
why
you
wouldn't
want
to
install
something
so
and
showing
it
on.
Every
install
has
always
bothering
me,
especially
for
ones
where
it's
like
you
know
the
the
example
in
the
rfc.
I
feel
like
I've
seen
all
of
those
many
times.
A
Yeah
yeah,
we
we
get
a
lot
of
people
asking
us
to
change
this.
This
is
something
that
would,
I
think,
just
make
a
lot
of
people
happy
so
great,
and
I
to
your
kind
of
longer
term
view
and
approach
luke
about
consolidating
this
in
one
place.
I
I
think
we're
we're
going
to
get
there
with.
A
Ideally,
maybe
that
query
concept
that
we've
been
mulling
around
internally
and
a
more
standardized
view
of
like
package
information
right.
Our
package
note
like
nodes,
okay,
cool
any
other
feedback
on
this
or
are
we
kind
of
good
to?
A
A
Unless
that
information
is
readily
available
and
we
can
easily
do
it,
then
fine,
I
would
leave
it
but
yeah.
I
think
npm
ls
might
be
the
better
place
because
we
do
show
other
kind
of
status,
like
the
reason
why
I'm
saying
that
is
that
mpmls
does
have
a
historical,
some
if
metadata
attached
to
the
defancy,
whether
it's
extraneous
depth.
If
it's,
what's
the
other,
like
statements,
yeah,
there's
like
missing
or.
B
B
A
Right
so
yeah,
so
there
might
be
a
case
where
we
want
to
show
this
state,
but
I'm
also
a
bit
concerned
that
ls
is
going
to
become
the
dumping
ground
for
these
states
without
without
like
properly
thinking
about
how
that
actually,
like
the
ui
of
that.
How
that's
going
to
change
like
is
this
comma
separated?
Now,
if
something's,
deprecated
and
deduped
or
is
it
you
know
deprecated,
deduped
and
bundled?
A
What
do
all
three
of
those
states
look
like
together
yeah,
it's
just
interesting,
because
I
in
your
example
here
right,
you
don't
only
show
deprecated
alongside
those
but
there's
potential
for
like
something
to
be
multi
like
multiple
states
right
so.
B
Yeah,
there's
no
yeah
yeah,
there's
no
extra
color
code
here,
but
we
could
also
do
something
more
visual,
maybe
attach
some
symbol
attach
some
color
to
it,
so
that
it
highlights
better
yeah.
A
Yeah
this
harkens
back
to
a
conversation,
that's
going
to
be
going
on
since
we've
been
running
these
rfcs,
which
wesley
todd
has
poked
on
and-
and
he
hasn't
been
here
for
a
while,
but
he
essentially
said
you
know.
Are
these
not
these
different
views
like
npm
ls
outdated?
Are
they
not
just
different
views
of
the
same
information
right
so
and
audit
as
well
like
fpm
audit
is
a
good
example.
A
Just
like
you
know,
extra,
just
a
different
slice
of
the
same
information
that
we're
bubbling
up
so
like
if
I
just
was
able
to
run
mpmls,
and
then
it
showed
me
all
this
extra
metadata
like
oh,
this
is
also
vulnerable
right,
like
it'd,
be
nice
to
see
that
state
as
well
on
my
on
ls
right
like
so.
I
think
we
get
into
the
territory
of,
like
you,
know,
a
scope
creep.
A
If,
beyond
what
I
the
problem,
I
think
this
rc's
trying
to
fix
right
now,
but
yeah,
if
you
could
at
least
maybe
expand
on
this,
to
show
what
mpm
outdated
would
look
like,
because
I
think
that's
the
one
I
would
expect
them
this
to
be
this
information
to
live
in.
Most
at
least
personally,
that's
the
one
I
command.
I
could
see
this
being
most
closely
aligned
to
and
then
yeah,
let's,
let's,
let's
ship,
this,
let's
make
this
change
like.
I
don't
want
to
see
any
more.
A
The
number
one
thing
that
I
heard
in
this
conversation
from
fritzy
is
is
what
I've
heard
from
other
people,
especially
maintainers,
is
that
it's
scary
for
some
people
right,
it's
scary,
for
new
users
to
see
all
this
output,
these
warnings,
and
they
can't
do
anything
about
it
right,
like
a
lot
of
the
transitive
dependency
warnings
for
that
they
can't
upgrade
right
like
a
maintainer,
has
to
go
upgrade
that
depth
right,
potentially
right,
we'll
do
our
best
and
give
you
a
the
best
like
green
field
for
ever
greenfield.
B
Yeah,
I
think
if
we
were
to
really
try
to
cut
a
little
bit
more
the
scope
here,
then
we
should
really
focus
only
on
the
notification
at
the
end
of
things,
so
removing
the
changing
the
lock
level-
maybe
it's
just
log
level,
verbose
or
encoded,
one
that
doesn't
get
printed
automatically
right
by
default
and
what
is
the
call
to
action
right?
Do
we
introduce
a
new
top
level
command
or
what
is
the
top,
the
the
call
to
action
at
the
end?
A
A
A
There
right
so,
if
we
need
there's
no
like
there's
no
all-encompassing
npm
update,
and
then
you
change
the
state
deprecate.
That
would
be
really
like
you
know,
even
though,
maybe
under
the
hood,
we're
actually
doing
a
push
and
we're.
Actually,
it
is
like
a
that.
Deprecate
action
is
actually
pretty
much
like
a
push
with
like
a
new
state
to
the
package,
which
is
saying
this
is
deprecated
the
we
as
the
cli
have
a
top
level
command
for
deprecating.
So
why
not
have
a
top
level
command
for
listing
the
deprecated
versions?
So
I'm
actually.
A
The
problem
is
that
you
get
into
flight
because
the
top
level
command
supports
positional
arguments
for
values.
A
You
get
into
the
problem
that,
like
we,
don't
have
the
ability
to
create
a
sub-command
within
deprecate,
so
we
have
to
make
it
a
flag
and
flag
says
commands,
I'm
always
very
like
I
don't
know,
I'm
wary
of
that,
because
the
the
it's
not
doesn't
align
with
what
the
intent
of
the
original
command
was
right.
Deprecate
is
specifically
there
to
deprecate
things,
so
I'm
actually
coming
full
circle.
Now,
a
new
deprecations
top
level
commands
removes
the
need
to
add
that
information
to
any
any
other
view.
A
Right
now,
at
least,
we
don't
have
to
like
find
a
way
to
shoehorn
deprecation
warnings
into
that
you
can
piggyback
off
of
like
the
existing
flags,
like
we'll
show
you
top
level
direct
dependency
deprecations
first
and
then,
if
you
pass
dash,
all
we'll
show
you
all
them
with
transitives
and
then.
A
What
is
that,
I
think
so
imagine
it's
just
like
ls,
so
you
run
npm
deprecations
they'll,
give
you
the
same
same
kind
of
like
list
of.
However,
we
want
to
visualize
this.
This
is
kind
of
like
up,
for
you
know
some
interpretation
by
you,
but
it
would
show
you
top
level
dependencies
that
are
deprecated
by
default
and
then
the
description
of
why
they
were
deprecated
so
kind
of
similar
to
what
we
have
today
and
then,
if
you
pass
the
dash
dash
all
flag,
that
would
give
you
transitives
as
well.
B
A
Don't
know
I
don't
I
no,
no,
no!
No.
I
think
that
the
name,
no,
no,
the
name,
unfortunately,
that's
like
getting
into
like
for
like
that's
a
verb.
It's
like
an
action
deprecate,
I
think
that's.
I
have
a
hard
time
telling
people
to
run
npm
deprecate
and
it's
gonna
list
all
the
like.
It
sounds
that
sounds
scary.
A
If
we're
talking
about
easing
people's
minds,
yeah
yeah,
I
know
we've
spent
a
lot
of
time
on
this,
but
yeah.
If
you
could
maybe
update
the
rce
a
little
bit,
let's,
let's
maybe
remove
the
state
status
information
on
ls
and
explain
like
if
people
want
to
know
about
deprecations,
they
can
run
this
top
level
command,
we'll
remove
the
warning
warnings
by
default,
I'm
I'm
50
50
in
terms
of
whether
we
keep
them
just
at
a
different
log
level.
We
don't
do
that.
A
Like
I
said
before,
we
don't
do
that
with
any
other
kind
of
audited
advisory
or
it's
you
know
like
we
don't
do
that
at
all.
So
it'd
be
interesting.
Why
we
would
want
to
like
continue
to
store
those
in
in
the
logs
yeah.
That's
good,
cool,
okay,
move
on
to
this!
Pr
4260.,
this
was
not
created
by
rick
fritzi.
This
is
the
an
arborist
adding
an
arborist
refi
hook.
This
is
sort
of
in
line.
A
This
is,
I
think,
was
created
by
the
team
at
white
source,
who
have
talked
me
internally
about
trying
to
get
something
like
this
implemented
into
npm.
Again,
there's
a
whole
string
of
conversations
that
have
been
had
around
npm
v7s.
A
You
know
breaking
change
of
removing
hook
scripts,
so
we
didn't
really
do
a
great
job
at
explaining
that
this
was
a
breaking
change.
We
might
have
at
some
point
put
it
in
a
line
item
noted
it
to
you
know,
know
tsc
or
other
folks,
but
it
really
wasn't
like
pot,
I
think
really
popularized
or
we
didn't
the
number
one.
Breaking
change
for
a
lot
of
folks
in
v7
was
pure
depth,
so
hook
scripts
unfortunately
fell.
A
We
stopped
supporting
them
because
of
a
major
refactor
to
the
way
that
fpm
resolves
your
trees
and
that
came
with
it.
You
know
an
inability
really
to
distinguish
between
certain.
You
know,
life
cycle
events
that
we
wanted
to
fire
off
and
we've
had
the
conversation
on
and
off
for
about
a
year.
Now
about
introducing
a
new
life
cycle
event
that
might
encapsulate
or
bring
back
some
some
level
of
support
for
tree,
mutated
event
or
or
you
know
something
has
happened.
Please
fire
off.
A
You
know
an
event,
there's
definitely
the
concept
that
we
have
internally
right
now
of
like
sort
of
a
reserved
time
in
which
we
don't
expect
to
be
anything
to
mutate.
You
know
package
json
or
anything
to
happen
and
we're
getting
closer
and
closer.
I
think
to
the
point
in
which
we
can
say
we'll
have
sort
of
immutable
installs.
Once
we
have,
you
know,
once
we
stop
supporting,
install
scripts
and
and
have
other
mechanisms
in
place
for
the
ecosystem
to
distribute,
you
know,
distributions
or
variants
of
packages.
A
So
I'm
very
wary
to
you
know,
plus
one
something
like
this
to
say
that
we
want
to
add
back
any
kind
of
like
hooks
into
arborist
today,
without
having
let
broader
discussion
and
fritz
t.
I
know
you've
already
started
a
work
in
progress
rfc
for
refactoring
kind
of
like
and
trying
to
bring
more
context
to
you
when
scripts
are
being
run
and
the
the
two
contexts
that
come
up
the
most
are.
The
package
being
installed
versus
the
project,
that's
installing
the
package.
A
Those
are
the
two
sort
of
contexts
we
see
the
most,
and
this
is
definitely
one
of
those
cases
where
they
are.
I
think,
a
maintainer
of
a
project
which
used
to
rely
on
these
hooks
to
sort
of
do
some
interesting
things
to
protect
their
users
or
or
to
you
know,
analyze
the
packages
being
installed
and
they've
sort
of
lost
that
ability,
and
so
their
hope
is
to
get
something
like
this
soon,
some
sort
of
hook
into
back
into
npm
as
it's
processing
the
installation
of
packages.
A
So
I
I
apologize
that
the
they
weren't
able
to
join.
But
my
hope
is
that
we
can
have
some
good
async
discussion
and
probably
in
this
pr
itself,
so
yeah.
C
I
think
long
term,
you
know
if
we
were
to
prioritize,
you
know
immutable
installs.
C
We
could
have
something:
an
output
option
for
install
that
generates
a
report
that
gives
them
enough
information
to
go
back
in
and
call
arborists
directly
to
do
the
mutation
that
they
want
to
do
or
to
analyze
the
changes
that
were
made.
C
So
I
think,
if
we
do
everything
as
an
after
effect,
like
hey,
you
know
you
ran
install
this
isn't
a
hook,
but
here
you're,
you're
piping,
the
output,
to
something
that
you
then
use
and
do
something
with
that's
fine
right.
I
I
don't
know,
I
think,
there's
a
lot
of
ways
we
can
solve
this
without
hooks,
but
you
know
in
the
long
term,
in
in
the
in
the
short
term
right
we
need
to
to
to
get
to
the
point
where
arborist
itself
is
internally
immutable
right.
A
Yeah,
this
kind
of
also
ties
into
when
we
shipped
overrides-
or
I
think
we
were
just
leading
up
to
shipping
overrides
a
few
people
in
the
community
had
asked
us
whether
or
not
we
were
going
to
support
patching
dependencies,
which
is
something
that
other
package
managers
do.
Support
like
floating
like
get
get
patchers
like
to
to
change.
Essentially
the
contents
of
a
package
after
it's
been
installed-
and
this,
I
think,
is
a
concept
and
like
a
feature
that
I
don't
know
if
we'll
personally,
I
would
be
very
wary
of
us.
A
You
know
supporting
the
whole
idea,
I
think
behind
installation
and
my
understanding
of
is
if
we
can
just
untar
a
package
for
you
in
place.
That's
that's!
That's
it!
That's
that's
what
the
extent
of
where
I
think
we
should
end
installation
ends
and
after
that,
we're
getting
into
the
territory
of
people
mutating
packages
that
no
longer
it's
that
almost
breaks
the
contract
of
the
the
package
as
it
was
distributed
right
so
post-install
scripts,
obviously
were
and
install
scripts
in
general
are
a
way
to
like.
A
You
know
mutate
a
package
once
it's
on
your
your
system,
and
people
will
probably
still
want
to
do
that
to
some
extent
and
will
still
want
to
do
things
once
they
have
your
your
software
on
there.
But
I
think
we
should
be
really
focused
on
like
just
delivering
by
default.
A
like
reproducible,
build
and
install
sort
of
experience
for
people
first
and
foremost
go
ahead
miles.
E
E
I
haven't
reviewed
all
of
the
language
specific
package
managers
for
this,
but
the
first
one
that
comes
to
mind
would
be
something
like
the
debian
project
or
a
lot
of
open
like
a
lot
of
distributions
that
are
operating
system
distributions,
as
opposed
to
language
distributions
and
in
those
cases
the
patches
make
sense,
because
essentially
we're
saying
like
there's
a
philosophy
in
debian,
for
example,
where
the
packager
is
not
the
same
as
the
author
of
the
source
code.
E
So
the
patches
that
are
being
floated
are
generally
like
compatibility
patches,
a
great
example
of
this
in
a
way,
but
not
exactly
is
like
how
the
node.js
project
works,
because
we
vendor
all
of
our
dependencies
into
node
proper
and
we
actually
float
a
bunch
of
patches
on
them,
whether
it's
v8
or
opens
sellers
stuff
like
that.
We
do
float
a
bunch
of
patches.
E
So
I
think
that
in
the
world
of
npm,
where
the
packages
are
being
published
by
the
author
and
those
who
own
the
source
tree
patching
doesn't
make
a
ton
of
sense
in
the
same
capacity
at
the
same
level,
and
I
think
that
something
like
overrides
and
infrastructure.
I
didn't
see,
if
that's
what
you
were
just
saying
or
anything
but
like
something
like
overrides
very
well,
could
play
that
role,
because
it's
easy
for
you
to
have
like
your
own
version
of
the
package.
E
Git
also
offers
you
know
some
utilities
around
this
and
and
maybe
there's
things
to
be
thought
about,
but
like
a
post-install
script
can
apply
a
patch
against
an
application
and
I
think,
there's
a
huge
difference
between
the
package.
Installer
attempting
to
include
patches
that
are
part
of
their
install
versus
the
package
distributor
trying
to
have
patches
that
are
kind
of
like
part
of
the
distribution
itself.
A
Yeah
it's
just
like
when
you
hook
in
there,
it's
the
dangerous
part
right.
So
when
you
allow
somebody
to
apply
the
patch
or
when
it's
being
like
you
know
changing,
do
I
get
a
chance
to
change
back
to
json.
While
you
know
npm
is
reading
or
you
know,
like
you
know,
when
those
life
cycle
events,
fire
is
the
interesting
part
for
sure
like
it's.
A
So
it's
it's
definitely
one
of
those
places
where
we're
like.
Well,
let's
just
do
this
as
late
as
we
can,
and
only
once.
So
that's
the
idea
of
like
something
as
like
tree
mutation
event
has
happened
and
maybe,
like
communification
event,
has
happened
like
the
entire
tree
has
being
resolved.
The
entire
tree
is,
it
is
placed.
You
know
like
that.
A
That
to
me
seems
like
the
two
type
of
events
that
we
would
like,
make
the
most
sense
and
and
would
be
the
most
sense
to
like
support
as
well,
because
it
otherwise
you
get
into
like
just
crazy
sort
of
use.
Cases
that
folks
are
currently
trying
to
you
know
prevent
like
there's
a
whole
bunch
of
tooling.
I
think
that
exists.
A
That's
trying
to
prevent
and
intercept
packages
as
they're
being
installed
and
there's
now
ways
to
prevent
that
using
overrides,
or
you
know
again
like
just
making
the
npm
advisorydb
that
much
better
or
having
our
team.
You
know
the
registry
team
continue
to
ensure
that
there's
no
malware
actually
on
the
registry
to
get
into
your
projects
is,
is
important,
so
anyways.
This
is
a.
This
is
gonna
stay
open
for
for
a
while,
I
think-
and
hopefully
we
can
have
a
good
conversation
with
those
folks
once
they
get
back
back
on
here.
A
Yeah,
let's
quickly
move
on.
I
know
we
only
have
about
15
minutes
left
the
two
next
items.
I
think
we
talked
about
last
week
and
I
think
we
had
action
items
related
to
them
that
will
we
should
follow
up.
So
this
is
the
511
removing
npm
sure
crap
from
list
of
unignorable
files.
I
think
we
all
agreed
on
next
steps
there.
So
it's
just
a
matter
of
creating
tickets.
I
think
that's
on
me
to
do
and
then
the
pr
420
4227
so
changing
the
default,
save
prefix
from
carrot
to
none.
A
This
is
something
we'll
probably
close
with
some
feedback
from
last
week
as
well.
This
is
not
something
we're
going
to
change.
I
think
the
last
one
is
the
one
that
should
take
most
of
our
time
here.
This
is
the
rce
343.
roy.
This
was
originally
proposed
by
you.
A
We
had
some
good
discussion
last
year
about
this
and
of
course,
a
year
later,
we
are
now
looking
back
and
saying.
Oh,
we
probably
should
have
done
something
more
in
this
space.
So
I'm
not
sure
if
you
want
to
provide
a
quick
synopsis
of
what
this
was
and
sort
of,
what
we're
doing
to
to
fix
this
sure
yeah.
B
This
is
a
I'd
say,
a
major
quality
of
life
great
to
work
spaces,
which
is
basically
the
thing
that
as
a
user,
I
always
wanted-
and
I
see
a
lot
of
people
struggling
assuming
that
this
is
the
case
and
it's
not,
which
is
the
ability
of
just
a
cd
into
a
folder.
B
That
is
a
workspace
currently
in
your
project
and
running
commands
there,
assuming
that
everything
will
just
work
as
you
expect,
as
a
user,
so
that
has
a
yeah
there's
a
big
gap
which
I
think
is
made
primarily
due
to
the
way
that
the
original
implementations
from
learner
from
yarn
work
with
workspaces,
which
they
would
to
the
automatic
switching.
B
So
if
you
inside
workspace
a
which
is
a
workspace
within
your
monorepo,
and
you
run
an
npm
installed
that
you
want
to
add
a
dependency
there,
everything
will
the
package
will
be
add
to
the
package
json
there.
It
will
be
properly
locked
at
the
root
level
and
currently
that's
not
the
case
with
the
npm
cli.
So
currently,
with
the
workspaces
implementation
we
have
today,
you
always
have
to
run
from
the
root
or
specifying
the
root
as
the
prefix
for
your
project,
and
you
need
to
specify.
B
Where
is
the
workspace
that
you
want
to
operate
in
and
then
you
install
a
new
dependency
or
you
can
do?
You
can
run
a
script,
use
other
top
level
and
game
comments,
so
this
is
yeah,
it's
it's
been
a
while,
and
there
was
a
lot
of
back
and
forth.
B
So
originally,
there
was
a
lot
of
push
to
be
more
explicit
to
to
avoid
the
hazards
of
magically
trying
to
figure
out
whether
you're
inside
a
workspace
folder
within
a
pro
a
monoreport
project
that
has
workspaces
configured,
but
now,
I
guess,
with
more
adoption
and
yeah
we're
getting
more
and
more
feedback,
our
own
team,
starting
to
use
more
and
more
workspaces.
B
B
Do
not
do
not
outweigh
the
benefits
of
doing
the
magic
and
just
running
as
the
user
intent
when,
when
they're
running
from
a
workspace,
so
basically
the
the
rfc.
I
just
cleaned
it
up,
but
it's
basically
we're
going
back
to
the
original
proposal.
There.
C
Yeah
just
to
just
to
kind
of
summarize,
where
we're
going,
we
have
a
pr
that's
approved.
It
hasn't
landed
yet
that
when
your
ena
workspace
directory
by
default,
the
command
will
run
as
if
you
had
specified
that
workspace
and
it
auto
detects
the
prefix
if
you
sp.
So
if
you
want
to
disable
that
behavior
and
use
the
old
behavior,
then
you
will
either
use
dash,
no
workspaces
or
you
will
specify
a
prefix
so
either
in
either
case.
You
know
you
could
specify
the
current
directory
as
the
prefix.
C
So
in
either
case
that
would
do
the
old
behavior
we
treated
this
as
undefined
behavior,
meaning
we
don't
need
to
do
like.
We
don't
think
we
need
to
do
a
major
version
bump
in
order
to
clarify
in
order
to
clarify
this
so
yeah,
because
this
is
what
users
expect
when
you're
in
a
working
directory
and
you
run
a
work,
sorry
a
workspace
directory
and
you
and
you
run
a
command.
They
expect
it
to
work
as
if
you
had
specified
that
directory
or
that
workspace
name
as
a
workspace.
So.
B
Yeah,
the
per
yeah-
I
guess
the
only
particularity
there
is
there.
There
was
a
lot
of
just
overall
activity
in
that
in
that
rfc
with
a
bunch
of
comments
suggesting
we
would
go
a
different
direction,
but
it's
it's
been
a
long
while
and
yeah
now
that
now
that
we're
we're
actually
working
on
it
implementing
it
where
we're
going
to
the
direction
of
the
original
proposal,
there.
A
Yeah,
so
I
just
copy
and
pasted
one
liner
there
for
setting
the
workspaces
false
globally
with
npm
config.
I'm
wondering
if
that's
an
option
for
those
power
users
that,
like
truly
don't
want
to
opt
back
into
the
behavior
where,
unless
I
define
the
workspaces
key
or
I
yeah,
I
do
explicit
definition
for
workspaces
and
opting
in
then
I
want
to
opt
out
of
this
behavior.
That's
the
potential.
A
I
think
that
might
be
a
potential
option
for
them.
So
yeah,
like
I
think,
jordan
and
maybe
even
wes
jordan.
I
think
maybe
isaac
at
the
time
last
year
were
were
pushing
against
this
and
and
that's
when
we
started
to
discuss
potential
other
options
like
mpmrc
files.
That
would
have
references
to
like
the
the
path
to
the
route
and
all
this
kind
of,
like
configuration
that
you
know,
seem
prescriptively
hard
for
the
the
average
user.
That,
I
think,
has
this
assumption.
A
So
now,
maybe
maybe
if
we
can
provide
some
sort
of
easy,
opt
out
like
what
I
just
provided,
I'm
not
sure
if
that
will
actually
work
but
be
good
to
just
like
you
know,
document
that
for
for
folks,
if
they
do
want
to
opt
out
of
that
behavior,
I
guess
like
as
we're
I'm
not
sure
that
what
the
documentation
looks
like
fritzi
for
that
pr.
A
That
might
be
good
just
to
provide
like
a
how-to
addition
to
your
workspaces,
because
there
should
be
some
sort
of
documentation
about
how
we're
going
to
start
walking
up
and
when
we,
you
know
almost
like
the
pseudocode
version
of
nodes
require
algorithm
that
lives
there.
We
should
have
something
similar
that
you
know
maps
how
workspaces
are
going
to
determine
whether
or
not
you
know
you're
executing
within
a
workspace
project
right.
C
A
Yeah,
we
do
have
a
section
for
under
using
npm
dedicated
for
workspaces,
but
I
think
that
yeah
like
that,
might
be
a
good
place
to
put
this
section
like
the
workspace,
algorithm
yeah
or
something
like
that:
yeah
cool
cool.
I
think
that
leaves
us
with
some
extra
time
about
five
minutes
left.
If
folks
had
any
other
topics,
they
want
to
bring
up
right.
Well,.
A
Yeah,
I
think
that
we
do
want
to
plus
one
this
and
yeah.
I
I
will
give
you
give
the
the
plus
one.
Actually.
Let
me
quickly
review
this
this
afternoon
first
and
then
just
because
I
know
you
made
a
couple
edits
and
then
let's,
let's
ratify
it,.