►
From YouTube: Open RFC Meeting - Wednesday, April 6th 2022
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.
C
Yep,
it
looks
like
we're
live
awesome,
welcome
everyone
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
april
6,
2022.
C
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
number
565
here
in
the
rc's
repo.
Just
quick
reminder
for
folks.
These
calls
and
all
comms
on
the
rc's
repo
and
the
npm
repos
are
covered
under
code
of
conduct.
C
For
these
calls,
specifically,
we
ask
you
just
please
be
kind,
as
other
folks
are
talking.
Please
raise
your
hand
and
we'll
call
on
you.
I
appreciate
folks
jumping
on
after
a
long
delay.
We
haven't
run
one
of
these
calls
in
about
a
month
or
so,
and
I
just
want
to
reiterate
the
desired
outcomes
from
the
conversations
here
is
to
to
push
forward
design
ideas.
Gather
feedback
from
the
community
help
ideally
get
some
rough
consensus
on
different
topics
and
and
utilize.
C
This,
as
a
forum
for
for
you,
know
so,
hopefully
helpful
discourse
beyond
what
we
do
asynchronously
and
get
up
issues
and
and
pull
requests
themselves.
So
hopefully
the
rfc
call
has
has
been
a
mechanism
for
for
innovation
and
pushing
the
npm
cli
forward
over
the
last
couple
years,
and-
and
I
think
it
has
been
so
I'm
happy
folks
are
still
attending
and
hopefully,
hopefully
see
out
more
as
we
continue
to
do
this.
C
So
one
quick
announcement
that
I
had-
and
I
want
to
share
with
you
all-
is
that
we've
publicized
now
an
issue
denoting
a
number
of
the
ideal
changes
we
would
like
to
make
for
npm
v9.
C
Some
of
the
issues
need
detail
and
we'll
get
more
granular
as
as
time
goes
on
here,
but
gives
you
kind
of
a
high
level
idea
of
what
we're
thinking
about
and
trying
to
queue
up
for
the
next
major
version
of
npm,
and
so
I've
linked
that
here
in
the
the
meeting
notes,
but
we'll
also
share
it
here
in
chat
for
folks
to
easily
go
check
out,
feel
free
to
ask
any
questions
over
the
next
few
weeks
as
we
we
get
into
sort
of
the
the
weeds
of
that.
C
Most
of
the
breaking
changes
we
consider
and
hope
are
pretty
non-controversial.
A
number
of
them
are
changing
some
config
defaults.
C
We
again
want
to
see
mpmp9
via
a
gradual
breaking
change
if
you
can,
if
you
will,
as
va,
was
very
minimal
in
terms
of
changes
except
for
I
think
node
engines
was
the
only
one
of
the
few
things
we
changed
as
well.
As
I
think,
programmatic
usage
of
the
cli
and
consumption
and
cli
as
a
package
changed
in
v8,
so
v9,
ideally,
is
a
version
that
folks
can
can
adopt
easily
and
we'll
sort
of
standardize.
C
Some
same
defaults
is
sort
of
the
goals
there
so
expect
that
issue
to
sort
of
evolve
over
time.
It
may
be
d
scoped
as
well,
so
just
be
mindful.
Not
everything
on
that
list
will
stay.
It's
pretty
pretty
large
right
now
and
we
are
trying
to
work
within
a
sort
of
a
time
window
here,
that's
reasonable
over
the
next
roughly,
you
know
three
to
six
months,
so
that's
the
one
big
announcement
that
I
had
but
want
to
open
up
the
floor
for
folks.
C
If
not,
we
can
dive
right
into
the
agenda.
We
do
have
a
jam-packed
agenda,
so
we
try
to
break
this
out
into
two
separate
sections
for
the
folks
that
just
jumped
on,
I
will
again
paste
the
pack
of
the
meeting
notes
feel
free
to
add
yourselves
as
attendees
to
that
list.
Just
so
we
denote
that
you
jumped
on
the
call,
so
some
quick
updates
from
some
previous
rfc
discussions.
We
want
to
talk
a
little
bit
about
number
482,
the
rfc
around
output.
C
D
Yes,
let
me
try
to
get
my
context
back
after
a
month
off.
D
I
haven't
read
this
one
recently,
but
I
believe
we
decided
to
do
our
best
to
print
anything
that
the
user
could
use
to
standard
out,
such
as
recoverable
errors,
things
that
could
do
something
about
e-resolve,
like
a
package
missing
and
then
use
standard
air
for
anything
that
else
that
we
can't
guarantee
is
gonna,
be
formatted
such
as
crashes
and
things
of
that
nature,
so
that
this
has
not
been
implemented
yet,
but
we're
working
towards
it
in
a
combination
with
making
the
output
nicer
and
cleaner
a
number
of
changes
that
I
want
to
make
around
the
progress
bar,
removing
that
and
just
making
the
the
you
know,
kind
of
the
logs
going
by
as
the
indication
that
something
is
happening
and
add
more
of
those
to
steps
such
as
extracting
archives,
where
things
can
take
a
long
time
and
we
don't
necessarily
output
what
is
happening.
D
There's
been
a
few
cases
of
that,
where
extraction
can
take
minutes
depending
on
the
size
of
the
package
and-
and
you
don't
know,
what's
happening
so
improvements
in
that
area
as
well
as
I
just
drew
a
blank
on
on
what
else
we're
doing
the
log
file
as
well.
The
log
file
should
now
be
streaming.
C
Is
this
one
issue,
do
we
feel
like
we
can
close
this
out,
though,
with
essentially,
that
update
is
that
I
can
probably
take
this
off
the
agenda
for
next
week
yeah.
This
can
be
taken
off
the
agenda.
D
I
I
believe
it
was
my
action
item
to
at
least
post
what
our
the
resolution
from
the
last
call
was.
So
I
have
not
done
that
yet,
but
I
can
do
that
and
this
can
be
taken
off
the
agenda.
C
Thank
you
moving
on
quickly
to
the
second
update
we
had.
I
think
this
is
yours.
Fritzy
we've
been
doing
some
work
in
the
space
of
respecting
and
fixing
up
the
our
resolved
field,
support
with
that
from
pacuments
that
are
returning
from
a
registry,
essentially
a
resolved
field.
Maybe
if
it's,
you
can
speak
to
some
of
the
work
that
we've
done
there.
E
Yeah
so
right
now
looking
at
releasing
a
new
feature
that
is
called.
E
Or
to
never,
and
so
you
never
replace,
you
know,
pacument
host
links
and
then
you
know
in
the
future
we
could
add
always
so
you
always
replace
everything,
no
matter
what
the
host
is
with
whatever
is
configured.
I
think
you
know
this.
This
rfc
goes
into
more
than
just
host
replacement.
I
haven't
read
it
recently,
but
yeah.
That's
the
progress
being
made
right
now.
C
Yeah
caleb,
I
know
that
you
were
a
proponent
of
this
and
I
think
the
author
of
one
of
the
the
pr's
or
maybe
the
rfc
originally
does
what
fritz
sort
of
mentioned
there
does
that
align
or
like
would
that
help
resolve
some
of
the
issues
that
you
were
having
with.
F
I
think
so
I'd
like
to
see
more
details.
If
you
look
at
the
pull
request,
I've
implemented
two
different
options
and
one
of
them
sounds
like
what
he
described,
which
is
to
replace
the
registry,
but
is
that
when
you
create
a
lock
file
or
when
you're
reading
a
lock
file.
F
If
you
ever
record
a
lock
file
using
a
custom
registry
that
ends
up
in
the
lock
file
and
the
proposed
behavior
of
replacing
the
default
registry
wouldn't
work
in
that
case,
so
one
of
the
features
that
I've
implemented
in
the
pr
is
an
option
to
override
the
registry
that
you
record.
So
even
if
you're,
using
a
private
registry,
the
lock
file
that's
spit
out
is
using
the
default
registry.
F
C
Yeah,
that
makes
sense
we
we
had
talked
about
recording
that
information,
and
I
think
that
probably
needs
more
further
discussion
like
that
specific
feature,
because
there
might
be
a
lot
of
redundancy
like
in
recording
that
config,
like
the
registry
config
right
now,
it's
a
magic
value,
obviously,
but
yeah.
We
can
keep
this
on
our
radar
and
keep
talking
about
it
and
crack
it
open
up.
Maybe
that
specific
aspect
of
it,
if
hopefully
fritzy's
work,
is
lands
and
helps
resolve
at
least
one
of
the
the
problems
you
were.
E
Yeah
I'll
take
I'll
I'll,
take
a
closer
look
at
those
pr's
again
and
we'll
we'll
come
up
with
a
plan.
C
Yeah,
actually,
if
you
can
reach
out
you're
in
the
no
tooling
working
group
now,
hey
caleb,
is
that
right.
C
Oh
sorry,
that's
what
I
meant
by
slack
channels,
or
maybe
I
said
working
group,
but
that's
one
of
the
the
places
we
can
at
least
chat
about
this,
so
maybe
fritz.
If
you
can
async
us
pass
along
some
of
the
work
that
you've
been
doing,
we
can
look
into
it.
A
Yeah
real
quick,
I
was
taking
notes
here.
I
just
want
to
make
sure
frixie
when
you
mention
the
replace
registry
host.
Is
there
anything
we
can
relate
to
an
issue
something
already
or
is
it
just.
A
E
On
this
there's
an
issue
on
the
status
board
yeah,
we
can
link
just.
C
Cool,
so
is
that
okay
caleb,
if
you
folk
you
and
fritz
sick
up
after
after
this
call
at
some
point
between
now
and
the
next
meeting
for
sure,
because
we're
looking
to
land
something
quickly
here,
which
may
be
a
little
bit
different
than
what
you
had
originally
proposed.
But
at
the
same
time,
then
we
can
figure
out
what
it
is
from
the
original
proposal.
We
want
to
continue.
G
C
Moving
on
to
the
next
item,
which
again
is
is
yours,
and
this
is
actually
something
that
has
come
up
a
couple
times
where
I
said
like:
why
don't
we
just
land
this
but
npm
copy,
the
pr
has
been
open
for
a
little
while
caleb.
I
know
you
were
excited
about
this.
I
don't
see
I
you
know
I
haven't
heard
or
seen
any
kind
of
like
pushback
yet
from
folks,
I'm
not
sure.
C
If
anybody's
looked
into
this,
I
know
it's
in
a
draft
state,
so
I'm
just
wondering
if
you're
you
might
be
able
to
get
time
to
finish
it
out
and
and
we
can
properly
review
it
and
maybe
just
land
it.
F
I
I
realize
this
is
my
fault,
then
I
should
have
moved
it
out
of
a
draft.
I
think
it
was
ready.
I
wrote
tests,
I
don't
know
if
it
needs
more
tests,
they're
failing
right
now
after
I
rebased
yesterday,
but
I
can
get
that
fixed
up
and
I'll
pull
the
draft
tag,
and
we
don't
have
to
talk
about
that
more
here.
C
Cool
I'm
very
excited
by
this
too,
and
I
think
a
couple
folks
are
for
sure,
and
so
yeah
that'd
be
awesome
to
land.
So
thanks
and
if
folks
have
any
objections
or
they
want
to
go,
learn
more
the
rfc
or
sorry
the
pr
is
actually
498..
Is
that
right?
It
says.
Oh,
this
is
the
docs.
The
actual
pr
is
4082
on
the
cli
repo.
So
thanks
for
sharing
that
moving
on
to
item
number
four
for
updates,
I
just
wanted
to
quickly
note
package
distributions.
C
I
know
there's
been
a
bunch
of
feedback
on
that.
I
have
not
had
a
time
any
time
to
schedule
a
call
like
I
said
I
would
before
we
took
a
break
and
I
want
to
just
circle
back
with
the
fact
that
there
hasn't
been
any
updates.
I
know
to
the
actual
rfc
yet,
but
that's
going
to
be
on
my
radar
here.
This
is
definitely
going
to
be
something
that's
like
a
long
term.
C
Rfc
that
I'm
guessing
is
going
to
take.
You
know
a
few
months
here
to
to
figure
out
all
the
nuance
up
to
there's
also
potentially
still
a
separate
rfc
to
be
created
for
optional
depth,
conditionals
or
or
whatever
you
would
call
that
so
just
to
say
the
update
is
there's
no,
no
major
update
there.
Moving
on
to
number
five,
this
shared
version
specifications.
C
Oh,
I
think,
are
they
on
call
yeah
yeah?
Did
you
want
to
speak
to
this?
No,
I
just
want
to
confirm
my
my
presence,
great
yeah.
So
basically,
this
is
this
is
something
that
we've
seen
in
the
ecosystem,
quite
a
bit
where
people
want
to
pin
various
sdks
or
frameworks
to
the
same
version
and
when
they
install
one
they
want
to
essentially
or
update
one
of
those
packages.
They
want
to
lock
the
rest
in
place
when
we
were
implementing
overrides
nilf
who's.
C
On
this
call,
nathan
lafraniere
had
a
great
idea
to
implement
into
overrides
a
reference,
essentially
a
reference,
alias.
I
guess
you
would
call
or
just
a
reference
name,
so
you
can
actually
kind
of
work
around
this
problem
by
utilizing
overrides
to
specify
essentially
a
dependency
version
that
is
reliant
or
are
going
to
map
to
the
the
version
you
want
to
tie
that
to
so.
C
In
the
example,
I
think
that
we
had
there
was,
you
know,
maybe
like
let's
say
react,
and
some
react
plug-in
that
you
want
to
react,
import
or
something
like
that.
C
Then
you
can
tie
it
the
specific
version
to
react
in
the
override
and
reference
that
for
the
version-
and
I
think
that
works
around
the
the
need-
and
I
just
want
to
confirm
that
that's
the
case
and
we
could
potentially
close
out
this
and
and
just
backlog
the
the
fact
that
direct
dependencies
need
to
be
need
to
be
overwritten,
which
is
something
that
we
did
originally
spec.
But
I
know
it
was
a
bit
complicated
when
I
know
nilf
was
looking
into
it.
So.
G
C
That's
awesome:
if
that
works,
then
that's
that's
great
like
I
would
be
a
plus
one
to
that,
and
I
think
it's
like
you
know,
solves
the
issue
yeah
for
me.
It's
it's
fine
cool
yeah!
Thank
you
thanks!
So
yeah
there
is
a
to
do
for
us
to
actually
make
that
possible,
because
I
think
that
we
do
not
support
direct
penalty
overrides
right
now,
and
that
was
that
was
a
choice,
design
choice
that
we
can,
I
think,
ship
in
a
minor,
because
it's
right
now
just
erroring
so
yeah.
C
We
can
circle
back
on
that
in
in
the
future.
Here
so
last
on
the
updates,
improving
workspaces
so
tierney,
I
know
you
had
proposed
this
sim
linking
experience.
I
think
roy
had
a
few
updates.
They
want
to
share
on
what
we've
been
doing
to
improve
workspaces
in
that
that
liking.
A
We
kind
of
just
put
it
in
the
backlog
and
worked
on
it,
so
we
implemented,
but
not
for
the
specific
example
that
tierne
used
there
for
an
which
was
npm
init,
but
we
implemented
it
for
npm
version,
so
there
is
kind
of
like
a
prior
art
now
and
we
just
want
to
basically
get
that
same
functionality
and
put
it
also
in
npn,
and
it
makes
a
lot
of
sense
so
that
once
you
win
it,
you
initialize
a
new
workspace
it.
The
entire
install
tree
is
already
kind
of
wrapped
up
together
right.
A
The
same
link
will
already
be
in
the
node
modules
folder,
so
it
will
behave
as
expected
for
for
the
final
user,
so
yeah
so
so
yeah.
Just
to
recap,
we
implemented
for
npm
version,
so
once
you
cut
a
version
of
a
specific
workspace,
we
do
that
behavior
of
basically
running
a
really
small
refine,
but
then
we're
planning
to
just
pick
that
up
and
do
the
same
kind
of
work
for
npm
in
it
and
maybe
in
the
future.
More.
C
Awesome-
and
I
think
that's
it
for
updates-
does
this
in
terms
of
the
actual
rfc?
Is
this
something
that
we
should
close
out
then,
if
we're
just
essentially
going
ahead
and
implementing
that?
Are
you,
okay
with
that
tierney?
If
we
close
that
issue
yep.
C
Cool,
thank
you
awesome,
so
so
moving
on
to
new
items-
and
we've
got
quite
a
few,
so
I
want
to
quickly
time
box
each
one
of
these
if
we
can
to
roughly
five
minutes
if
we
run
a
little
bit
long
on
a
few
of
the
longer
ones
like,
I
would
say,
cap
out
at
10,
10
minutes
here.
C
So
we
try
to
get
through
as
many
as
we
can
appreciate
how
many
folks
have
jumped
on
and
also
how
many
rfcs
have
essentially
been
added
to
this
backlog,
but
the
the
first
one
we
have
up
here
is
a
breaking
change
to
npm
bin.
We
thought
this
would
be
a
quick,
quick
discussion.
I
know
jordan.
You
had
commented
on
this
just
to
be
mindful
of
existing
tooling.
That
might
be
relying
on
the
current
behavior
and
output
of
npm
bin
when
there
is
a
non-existent
path,
but.
H
Yeah
the
I
mean
the
comment
was
just
to
call
out
that,
like
so
putting
npm
bin
in
your
path
is
incredibly
unsafe
and
insecure
and
people
shouldn't
do
it,
but
lots
of
people
do
because,
especially
because
npx
didn't
used
to
exist
and
with
npx's
existence
the
utility
of
putting
npm
in
your
path
kind
of
eroded.
So
all
I'm
I'm
glad
to
see
this
change
made.
H
It
should
happen,
but
it
should
be
very
clearly
called
out
that
anybody
who
is
doing
this
will,
like
you
know,
may
see
a
behavior
change
and
and
that
they
should
also
regardless
they
should
be
encouraged
to
switch
to
using
npx.
H
You
know,
and
if
and
I
think
that
yeah,
if
there's
a
way
to
also
tell
them
how
to
use
npx
such
that
it
cannot
install
anything
that
would
also
help
people
migrate
to
it.
C
Yeah
so
you'll
notice
actually
that
the
issue
that
was
linked
here-
it
was
formerly
an
issue
or
a
bug
issue
on
the
cli
repo
we've
moved
it
to
this
dashboard
and
actually
added
it
to
the
v9
roadmap,
because
it
is
breaking
change.
We
wanted
to
make
sure
we
captured
it,
but
I
think
we
we
agreed
kind
of
like
with
the
next
steps
and
just
have
added
it
to
that
backlog
for
v9
go
ahead.
I.
H
H
C
Their
expectations
might
be
broken
of
what
was
returning
before.
I
guess,
that's
what.
H
C
A
Used
it
in
the
past,
because
I
I'm
one
of
these-
that
you
know
these
people
that
publish
bash
modules
to
the
npm
registry
so
like
sometimes
you
want
to
hack
things
like
oh
yeah
run
a
quick
way
to
just
without
maybe
it
was
before.
Npx
yeah
using
npx
is
just
always
better
these
days,
but
still
I
kind
of
use
it
in
the
past.
It
was
very
handy,
but
maybe
I
was
also
doing
something
something
really
happy
back
then.
I
C
Yeah,
so
that's
one
thing
to
discuss:
I
guess
for
next
time
or
leave
as
an
open
question
whether
or
not
we
just
want
to
get
rid
of
it.
So
it's
a
v9
feature
either
way.
Moving
on
to
the
second
item
that
new
item
we
had,
which
is
run,
script
with
workspaces,
should
short
circuit
on
script,
error.
C
I
A
I
H
I
H
So
you
don't
just
run
all
the
scripts,
but
you
run
them
in
the
proper
order,
and
I
would
imagine
in
that
kind
of
world
you
actually
want
them
to
short
circuit,
and
so
maybe,
instead
of
building
just
short
circuiting,
we
could
focus
on
how
do
we
build
a
proper
dependency
chain
of
scripts
and
then
just
include
short
circuiting
there,
because
I
can't
imagine
wanting
like
that
without
the
short
circuiting
like
you,
wouldn't
want
to
run
the
tests
for
project
two.
If
the
build
for
project
one
failed,
because
you
can't
do
that,
you
can't
test
it.
H
H
Saying
conceptually,
I
don't
think
it
is
orthogonal.
I'm
saying
that
in
practice
I
think
that
this
issue
is
subsumed
by
pipelines
or
whatever
you
want
to
call
it,
because
pipelines
would
have
to
have
short-circuiting
behavior
and
people
actually
want
the
pipeline
behavior,
not
the
short-circuiting
behavior
by
itself.
That's
my
supposition.
C
Yeah,
so
I
think
exec
and
run
script.
I
think
both
function
the
same
way
here
and
if
any,
like
the
decision,
as
far
as
referring
to
it,
was
made
that
there
we
didn't
have
a
mechanism
for
like
to
essentially
fast
fail
or
to
fail
to
error,
and
we
can.
I
think
tyranny
obviously
proposes
like
a
flag
like
fast
fail
or
something
like
that,
that
we
could
opt
into
that
behavior
right.
C
So
this
is
something
that
we
could
add
and
that
that
can
be
applied
to
any
like
exec
and
run
script,
and
then
again
the
the
idea
of
like
how
scripts
are
being
run
is,
I
think,
a
little
bit
like
in
what
order
they're
being
run
is
a
bit
different
than
failing
once
you're
like
not
running
them
all
and
failing
early
when
anything
in
that
chain,
like
yeah
fails.
C
So
I
don't
know,
I'm
a
plus
one
on
adding
something
like
this
to
opt
into
that
behavior.
C
So
maybe
we
can
give
that
feedback.
Unfortunately,
john
wasn't
able
to
join
us,
but
we
can
give
them
the
reasoning
why
it
is
like
it
is
today
and
then
also
provide
them
with
the
idea
to
yeah.
Add
an
rfc
for
specifically
something
like
a
fast
fail
or
something
to
run
script
and
exec.
C
Cool
any
other
comments
or
feedback
on
that,
if
not
we'll
jump
to
the
next
one,
which
is
rfc
539.
This
is
audit
auditing,
lock
files
for
injection
fritzi.
You
propose
this.
E
Yeah,
so
I
mean
the
basic
idea:
is
that
someone
could
edit
a
lock
file,
or
maybe
this
applies
to
shrink,
wraps
and
a
dependency,
but
if
it
doesn't
match
the
package
json,
you
know
they
could
they
could
do
something
nefarious.
E
C
Yeah,
I
think
you've
been
doing
some
work
in
that
area
enough
to
verify
log
files
with
ci.
I
think
mpmci
specifically,
but
I'm
not
sure
how
that
falls.
C
J
Integrity
yeah
the
integrity
fields.
If
if
we
made
sure
those
existed,
then
that
would
allow
us
to
actually
verify
things.
But
if
they
don't
exist,
then
we
have
to
go
fetch
the
packagements
from
the
registry,
backfill
them
and
then
we
don't
have
we'd,
have
to
nuke
your
node
modules
and
start
over
to
guarantee
that
you
had
those
tar
balls
extracted.
E
Yeah
and
you
know
what
what
happens
if
they
you
know,
put
in
a
new
integrity
value
right
like
so
there's.
C
Yeah,
so
the
what
I've
seen
in
the
ecosystem
is
folks
have
written
like
actions
like
give
actions
or
like
any
kind
of
like
ci
test
to
do
this
log
file,
validation
and
they
basically
do
an
install
and
then
just
compare
like
a
diff.
The
the
two
things
like
that's
what
I've
seen
in
terms
of
tooling
in
this
space
for
for
doing
that
validation.
Because
to
your
point,
you
basically
have
to
do
a
full,
install
and
go
capture
the
the
the
relevant
manifest
files
with
the
integrity
values
to
ensure
that
that's
yeah,
that's
accurate.
C
E
It'll
give
people
feel
good
vibes
about
it
anyway,
a
way
to
explicitly
run
it
and
and
then
you
know
there
could
be
a
note
in
there
or
documentation
that
this
happens
during
installer
ci
or
wherever
else
it
happens
to
so.
C
Okay,
yeah,
I'm
wondering
if
we
can
just
shove
like
a
check
into
like
into
doctor
or
something
like
that.
Instead
of
putting
this
extra
validation
into
like
hot
pass
right
like
that,
might
slow
things
down,
yeah,
it's
a
sandy
checker,
essentially
right.
So
if
you
don't
feel
like
anybody
else
has
been
touching
like
that.
C
Your
very
first
comment
was:
the
arguments
have
been
made
that
if
anybody
can
modify
something
on
your
desk
like,
like
you
know
or
to
your
repo,
that,
like
what
kind
of
value
are
we
adding
with
a
tool
like
this,
so
like
just
making
it
easy
for
npm
to
be
that
ci
check,
like
somebody
could,
literally
in
actions
or
from
an
npm
doctor,
and
then
it
would
fail,
potentially
because
it
ran
that
the
package
lock
check.
Then
that
might
be
enough
to
be
like
hey.
C
You
can
slip
some
refactor
tech
that
in
but
but
it's
pretty
hefty
without
that
yeah
there's
that
isn't
on
the
radar
right
now.
Okay,
we
could
potentially
add
something
like
that,
because
npm
doctor
really
does
need
a
facelift,
and
I
think
that
there
is
reason
to
be
able
to
run
independent
checks
like
npm
doctor
foo,
whatever
whatever
it
is,
if
it's
av,
if
it's
etc,
would
be
nice
to
do
but
yeah
jordan.
I
see
you
on
yeah.
H
Yeah
I
mean,
I
think
that
the
this
is,
I
think,
like
it's
in
general,
npm
doctor
should
be
great
and
better
and
usable
as
a
ci
check.
That's
awesome.
H
I
think
that
this
particular
case
github
shows
or
hides
package
lock
like
log
file
diffs
by
default,
the
entire
ecosystem,
trains
us
to
rubber
stamp
those
diffs
and
ignore
them
only
the
most
paranoid
folks,
even
take
a
look
at
them
and
that's
not
most,
so
I
think
it
that,
like
it's
incredibly
critical,
that
npm
install
by
default
fails
in
this
case
so
that
it's
not
possible
to
land
these
sort
of
malicious
changes.
H
It's
true
that
a
malicious
dependency
could
overwrite
files,
but,
like
you,
can
use
node
nodes
policies,
features
to
like
protect
your
app
during
runtime.
You
can,
you
know,
develop
in
a
docker
container
on
your
machine
and
not
worry
about
it,
but
if,
if
a
malicious
package
is
hidden
in
a
lock
file
like-
and
nobody
knows
it's
there-
then
that's-
you
know.
That
seems
like
a
bad
thing.
I
mean
I
know
how
to
like
I've
seen
that,
but
I
guess
it
it
seems
entirely.
H
It
seems
like,
if
there's
any
risk
of
something
being
hidden
in
the
lock
file.
That's
not
easily
surfaced
and
like
that.
That's
that's
worthy
of
of
very
eager
action,
and
I
think
the
other
thing
is
humans
aren't
supposed
to
be
editing
the
lock
file.
I
would
be
very
happy
if
changing
one
character
in
the
lock
file
failed.
H
Everything
always
only
npm
should
be
touching
it
like
if
it
weren't
for
reviewability,
I
would
say:
npm
should
be
encrypting
it
so
that
nobody
else
can
touch
it,
but
like
you,
need
it
to
be
reviewable
eat
for
the
paranoid
folks.
So
like
I
just.
I
think
that
in
this
particular
case
it's
just
it
should
just
be
the
default
behavior
that,
like
that,
the
lock
file
is
the
lock
file's
own
integrity
is
checked
essentially.
E
So
no
the
changes
that
you
make
do
they
do
they
fail
if
there's
an
integrity
problem,
or
do
they
correct
the
integrity
problem,
they
won't
do
anything.
J
C
Yeah,
I
think
uninstall
it's
trying
to
be
like
a
self-healing,
yeah,
yeah.
Okay,
I
think
there's
some
more
discussion
to
be
had
on
on
this.
We
should
probably
keep
it
open
for
for
another
little
bit,
but
want
to
quickly
move
on
and
time
box
that
to
the
next
rc
that
we
had,
which
is
jordan's,
which
is
add
or
obey
user
specified
specs,
which
I
think
there's
I
don't
know.
If
there's
going
to
be
a
lot
of
controversy
around
this,
but
like
feel
free
to
yeah.
H
I
mean,
I
hope,
not
the
so.
My
use
cases
eslint
in
8.9
broke
a
use
case
of
mine,
and
so
my
eslint
config
has
a
pure
depth
on
equals.
8.8.0
and
I
put
the
equals
in
there
instead
of
just
omitting
a
range
because
it's
nice
and
explicit-
and
it
means
like
somebody
else
who
sees
it,
should
know
that
I
did
it
on
purpose.
H
So
when
I
go
to
do
the
updates,
I
type
this
npm
install
command
with
the
equals
in
it
and
it
puts
the
carrot
in
the
package
json,
which
then
can
break
things
later
and
in
fact
it
fails
the
peer
dep
in
ci,
like
almost
immediately
so.
What
I
want
is
for,
when
I
tell
npm
to
install
it
with
an
equal
sign
for
it
to
install
it
with
an
equal
sign.
H
I
I'm
when
I
when,
when
there's
no
prefix
at
all,
when
it's
there's
no
range
character
there
at
all,
then
I
think
it's
awesome
that
npm
just
uses
the
save,
prefix
and
defaults
it
to
the
most
reasonable
thing.
It
may
be
a
bug
that
it's
ignoring
it,
I
don't
know
it
feels
yeah
equal
is
definitely
a
valid
number
range
always
has
been
so
above
yeah.
Maybe
that's
just
a
simple
bug
I
just
kind
of
wanted
to.
I
it's.
H
A
A
H
And
I
think
that
exception
yeah.
I
think
that
that
in
general,
like
if
I've
typed
like
two
point
x,
it
is
great.
I
think
it's
the
right
thing
to
resolve
that
to
a
version
and
then
put
it
with
the
carrot
in
package.json.
But
if
I've
typed
tild
2.1,
I
don't
think
it
should
ever
use
the
save
prefix.
I
think
it
should
just
use
the
tilt.
H
It
should
resolve
the
version
to
2.1
point
whatever,
and
then
it
should
put
that
in
there
with
a
tilt
and
like
or
same
with,
I
don't
know
greater
equals
is
that
one
is
more
useful
on
pure
depth.
But
if
I
put
in
pure
depths
like
greater
than
or
equal
to
3,
I
actually
want
the
pure
depth
to
be
greater
than
or
equal
to
3.
I
don't
want
it
to
be
17.
C
C
Well,
I
want
to
quickly
move
on
because
that's
pretty
uncontroversial
and
we
may
still
want
to
wait
till
v9
just
to
to
land
it,
but,
like
that's,
definitely
like,
we
want
to
fix
that
so
so
number
five
here,
which
is
rfc
548,
adding
flag
for
npm
commands
to
run
intransitive
dependencies
to
run,
builds
and
trans
dependencies.
I
think
zack
you
jumped
on
this.
Is
your
proposal
or
your
your
thread.
K
Yeah,
I
I'm
actually
okay,
if
npm
doesn't
want
to
do
this,
but
I
want
there
to
be
a
decision
that
npm
is
not
going
to
support
it.
We
currently
use-
and
I'm
guessing
a
lot
of
others
use
lerna
to
do
some
of
that
transitive
dependency
builds
that
I
think
it
was
jordan
was
talking
about
where,
when
we
build
especially
with
typescript,
makes
it
a
lot
more
convoluted.
K
K
So
essentially
we
would
like
to
com,
like
we've
been
using
npmi
instead
of
learning
bootstrap
for
ever
since
seven
came
out
almost,
and
that
is
the
only
thing
we're
still
keeping
learn
around
for
is
to
run,
commands
and
we'd
like
because
it's
mostly
abandoned
we'd
like
to
come
we'd
like
to
move
off
of
it
entirely
so
bonus
points.
K
If
that
could
work
from
the
edge
too,
where
we
have
lots
of
junior
developers
that
come
in
and
expect
to
just
be
able
to
cd
into
the
directory
npm
build
and
pimp
start,
but
that
obviously
there's
a
lot
more
nuance
that
thankfully
npm
I
is
now
context
aware.
But
you
still
gotta
cd
back
to
the
root
run
the
scripts
with
lerna.
Then
you
can
see
back
into
your
edge
folder
and
develop
like
normal.
C
Yeah,
so
I
think
I
I
left
a
reference
here
to,
and
I
just
nested
it
in
my
the
notes
to
to
myself,
because
I
was
looking
at
this
before
the
call
to
turbo
repo's
pipelines
and
just
like
the
idea
of
more
explicitly
creating
those
dependencies
dependencies
for
like
builds
like
like
saying
that
this
depends
on
that
versus
just
utilizing
like
the
dependency,
like
the
understanding
of
like
what
needs
to
run
before
like
what
needs.
C
What
depends
he
needs
to
run
and
be
built
before
I
can
run
my
script
but
yeah,
I'm
I'm
I'm
interested
in
what
other
folks
have
to
say
about
this
tiny.
I'm
not
sure
I.
B
I
think,
if
the
rest
of
the
ecosystem,
like
you've,
literally
just
named
every
other
tool,
doing
this
if
the
rest
of
the
ecosystem
is
doing
this,
not
not
you
but
like
yeah
yeah,
exactly
if,
if
the
rest
of
the
ecosystem
is
doing
this,
we
should
probably
try
to
not
deviate
from
from
that
expectation
and
force
people
to
have
additional
tooling,
like
I,
I
think,
reducing
dependencies.
For
you
know
if
a
single
tool
allows
teams
to
get
rid
of
a
dependency.
I
think
that's
fine.
H
Yeah,
I
raise
my
hand
for
the
same
comment.
Is
I
mean
npm
run
scripts
are
a
necessary
reinvention
of
make
files
and
like
they
lack
the
biggest
nice
feature
of
makefiles,
which
is
declaring
dependencies
and
having
make
just
magically
figure
out
the
ordering
and
what
can
be
parallelized
and
what
can't
and
so
on
and
npm
has
all
that
information.
The
graph
is
right
there,
so,
like
npm
already
used
it
to
do
the
install,
so
it
seems
like
it
should
be.
H
C
Do-
and
I
don't
know
this
because
I
I
haven't
used
this
in
my
own
projects,
but
just
to
clarify
and
and
zac.
You
may
know
this,
but
do
people
deviate
from
that
relationship
from
the
dependency
relationship
in
the
tooling?
That's
why
I
reference
pipelines
because
they
they're
they've,
it
seems
like
they
deviate
from
just
like
dependencies
as
the
the
thing
but
they've
actually
said
like.
Oh,
I
can
specify
specific
demands.
H
Not
that
I
know
of
I
mean
the
like
the
use
case.
As
I
understand
it
is
parent.
Like
a
depends
on
b
I
want
b
built
before
I
try
to
do
anything
with
a
and
that
includes
running
tests
or
linting,
or
you
know
even
building
a
because,
what's
the
point
of
building
a
if
a
is
dependency
like,
fails
to
build
right
and
go
ahead.
K
The
specific
the
specific
thing
is
like
when
we
build.
We
want
to
build
an
order
when
we
test.
We
want
to
test
an
order
when
we
start,
we
want
to
start
an
order.
The
the
only
time
that's
deviated
is
if
it's
not
going
to
get
sim
linked.
K
So
if
you,
for
example,
like
we
publish
all
of
our
shared
packages,
if
you're
on
an
older
version
of
that
package,
you're
going
to
you're
going
to
get
the
already
built
javascript
files,
if
it's
typescript
project
right
from
that
old
version
installed
at
the
edge,
so
you're
not
gonna-
have
to
worry
about
building
that
one
first.
But
if
you
are
on
the
version
of
the
workspace
that
is
going
to
get
sim
linked,
it
needs
to
or
the
the
expected
outcome
is
you
run
npm
build
from
an
edge
in
a
workspaces
repo.
C
I
This
seems
weird
to
me
because
if
I
run
one
test
in
one
workspace,
I
don't
want
to
run
test
another
workspace
just
because
it's
a
like
if
I've
got
two
workspaces
and
one's
dependent
on
the
other,
and
I
just
want
to
run
the
test.
Why
is
it
all
of
a
sudden
say?
Oh
I'm
longer,
on
these
tests?
First,
that
means
that
build
is
now
special
or
tests
are
unspecial.
I
I
H
K
H
H
Yeah,
like
maybe
it
would
fall
out
of
that,
but
I
guess
that's
what
I'm
saying
it's
like,
because
the
common
case
is
going
to
be.
I
want
to
run
npm
test
on
the
entire
workspace
at
once,
and
I
I
don't
necessarily
like
I
like.
I
feel
like
there's
that
when
there
is
that
dependency
relationship,
the
default
behavior
should
be
to
respect
it
and
that,
like
magically
pulling
in
extra
dependence
that
are
happening
in
the
workspace,
that's
a
fine
extra
flag.
H
B
I
agree
that
that's
probably
a
separate
rfc,
but
it's
I
I
think
I
would
also
be
just
as
a
agree
agreeing
with,
but
we
should
probably
because
this
one's
big,
we
should
probably
separate
that
discussion.
C
Fair
enough,
are
you
okay,
with
keeping
this
open
for
a
bit
zach
just
so
we
can
have
some
more
discussion
about
it,
but
I
think
that
yeah,
it
sounds
like
we
kind
of
are
on
the
same
page,
that
if
every
other
tool
is
supporting
this
and
you
really
want
to
get
off
learner-
and
that
was
like
one
of
the
not
not
goals
of,
but
like
definitely
like
the
hopes
that
we
could
really
support
that
that
ecosystem,
that,
if
this
is
one
of
the
missing
features,
potentially
we
can
help
support
this
use
case
roy.
C
A
Wanted
to
maybe
clarify
like
because
we
did
try
to
work
a
while
ago
on
adding
the
the
kind
of
the
topological
dependency
when
running
the
post,
install
scripts
that
come
at
the
end
of
a
refi
right,
because
for
tho
for
these,
like,
I
think
it's
just
about
like
they
should
have
been
running
in
order
since
the
beginning
right
that
kind
of
breaks
a
few
more
ripples
out
there.
A
G
A
Kind
of
thing
like
I
was
thinking
on
right
because
for
all
the
post,
refi
like
the
pre-installed
post,
install
prepare
right.
All
of
these
should
be
kind
of
like
if
you
have
the
cross
dependencies
in
your
workspaces,
like
kind
of
need
that,
like
right,
otherwise,
the
only
way
around
that
is
kind
of
like
either
using
single
workspace
flags
to
order
manually
or
just
have
like
alphabetical
order
kind
of
like
respecting
that
that
order
that
you
need
for
your
builds
like,
but
that's
very
unreliable.
C
I
guess
I'm
kind
of
liking
this
and-
and
I
don't
think
that
we
have
to
have
these
together
but
you're,
saying
that
they
are
like
tangential
to
each
other.
Once
we
do
one,
we
basically
get
the
other
for
free.
I
do
think
that
is
probably
a
bug
if
we're
not
supporting
like
properly
refining
like
workspaces
or
running,
like
let's
say
certain
scripts
like
prepare
post
install
scripts
in
workspaces
today,
then
it
probably
is
a
bug
in
how
we
implemented
workspaces
and
and
those
commands.
C
We,
we
prepare
and
pat
run,
prepare
scripts
and
we
pack
dependencies
in
order
for
them
to
be
consumed
by
by
you
right,
and
so
I
kind
of
like
in
workspaces
in
this
case
like
in
order
for
them
to
be
useful
and
be
a
part
of
that
fancy
chain
we're
gonna
have
to.
We
should
probably
be
running,
prepare,
etc
like
on
that
workspace
right.
C
C
This
is
definitely
something
we'll
keep
on
our
radar.
We
didn't
get
to
a
number
of
rfc's.
I
just
wanted
to
quickly
note
for
folks
that
are
interested.
There
are
some
interests
around
improving
the
before
flag,
which
I
know
miles
has
proposed
here.
Having
sort
of
some
changes
to
that,
there's
also
the
dependency
selector,
syntax
and
npm
queer,
which
I've
proposed.
It's
been
something
I've
considered
for
a
long
time
and
I
think,
can
be
really
helpful.
C
Useful
go
check
it
out,
there's
also
command
specific
configuration,
which
is
an
rfc
we
just
opened
this
morning,
and
I
would
love
for
folks
to
look
at.
I
think
it's
a
missing
piece
that
we
would
really
help
in
terms
of
teams
trying
to
configure
sanely
configure
commands
differently
between
each
other
and
not
have
just
this
global
set
of
config
and
also
we've
got
something
that
we
will
definitely
get
to
next
week.
An
rfc
open
for
improving
the
npm
signature,
verification
and
that's
a
whole
separate
sub
command.
C
We're
going
to
introduce
that
can
either
be
a
part
of
mpm
audit
or
power
doctor,
but
it's
just
definitely
improving
our
security
and-
and
you
know,
signature
stores
that
we
have
today.
So
please
check
those
out
they're
all
linked
in
the
agenda,
we'll
be
back
next
week
and
appreciate
everybody
jumping
on
this
week
and
having
a
good
discussion
today.
So
talk
to
you
soon,
bye.