►
From YouTube: Open RFC Meeting - Wednesday, August 12th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Yeah,
that's
possible.
Are
you
recording
locally
right
now.
B
A
Yes,
yes,
okay,
I
just
want
to
double
check
to
make
sure
that
we
aren't
actually
streaming
live
or
that
isn't
broken
in
some
way
right.
Okay,.
C
Yeah
yeah,
let
me
start
so
yeah
welcome
everyone.
This
is
the
open,
rfc
weekly
call
we're
running
here
at
npm.
C
So
basically,
I
think
everyone
who's
in
today
has
been
here
already,
so
maybe
no
need
to
run
the
introductions
one
by
one,
but
I'd
like
to
mention
that
this
call
is
on
the
record
of
conduct,
so
an
interactions
here
is
covered
by
that.
So
we
ask
you
to
please
respect
it
and
yes
and
the
intentions
in
desired
outcomes
of
this
call
is
definitely
to
interact
with
the
community.
C
Have
this
place
to
better
feedback
and
follow
up
in
any
rfc
that
we
have
open
make
sure
we
follow
along
with
what's
going
on
there
yeah.
So
before
we
start,
I
guess
we
have
the
announcements
here,
and
I
know
the
team
has
a
big
one
for
this
week.
D
Before
that
sure
I
can
say
something
to
that,
so.
D
So
yeah
first
beta
of
npm
v7
is
out
and
live
you
should
you
should
install
it.
You
should
be
aware
that
some
stuff
might
still
be
a
little
bit
unstable.
This
is
our
first
kind
of
beta,
not
actually
the
first
beta
release,
but
it's
first
beta
release
that
we're
making
any
kind
of
noise
about
you
can
kind
of
gather
that
from
the
beta.4
pre-release
tag
on
it
to
get
it
run,
npm
install
g
npm
at
next
hyphen
7.
D
and
that
that
tag
will
keep
getting
updated
as
we
release
new
betas.
So
if
stuff
is
broken,
it
might
get
fixed
pretty
soon.
One
thing:
that's
kind
of
nice
here,
the
oh
there's
a
lot
in
the
blog
post,
but
one
thing
worth
noting
is
that
the
update
notifier
will
now
check
daily
if
you're
on
a
pre-release
version
of
npm
and
then
fall
back
to
weekly.
D
If
you're,
you
know
once
it
once
the
beta
tag
drops,
so
any
of
our
beta
testers
will
be
we'll,
be
able
to
kind
of
keep
you
up
to
date,
a
little
bit
more
quickly
and
hopefully
that'll
reduce
the
number
of
duplicate
bug
reports
we
get
for
stuff
that
we
just
fixed
new
versions
are
going
out.
I
mean
this
is
the
first
one
went
out,
I
think
last
week
and
we're
on
number
four
now
so
it'll
be
it'll,
be
pretty
fast
and
furious.
C
Thanks,
okay,
anything
else
in
terms
of
announcement.
Otherwise
I
should
probably
ask
someone
for
notes.
Take.
C
Great
yeah
so
yeah
we
can
move
on
with
the
agenda
we
have
here
today
and
I
see
that
the
first
item
here
is
from
miles.
The
npm
run
series
run
parallel
rfc.
I
think
it's
for
now.
It's
just
an
issue
right
rrc,
but
maybe
if
you
want
to
speak
up
to
that
mod.
E
Yeah
I
mean
like
this
is
just
more
like
an
idea
that
came
up
when
I
was
messing
around
with
I
actually
used
cat
and
x
arcs
to
like
stream
together
a
whole
bunch
of
different
commands
into
like
series
and
for
testing
pipelines
or
build
pipelines.
You
know
it's
very
reasonable,
like
that.
You
may
be
having
a
separate
script
for
building
css
versus
building
js
versus
html
and
like
a
different
series
of
ones
for
production
versus
development.
E
We've
seen
tools
such
as
webpack
or
gulp
or
grunt
be
used
for
this,
but
you
know
kind
of,
depending
on
the
complexity
of
what
you're
doing
and
how
you're
tying
together
different
tools,
and
sometimes
you
really
don't
need
a
meta
tool,
if,
like
all
you
want
to
do
for
testing,
for
example,
is
like
run
eslint
and
then
run
tap.
You
end
up
having
to
write
like
npm,
run,
tap,
tap,
npm,
run,
lint
and
end
npm
run
tap
and
then
have
two
separate
scripts.
E
For
that
you
know
for
two
things:
it's
not
a
big
deal,
but
when
it
just
it
can
start
to
kind
of
get
out
of
control,
as
you
have
more
than
one.
I
I
saw
some
feedback
on
it
that
you
know,
like
series,
might
be
easy
to
do,
but
parallel
gets
a
little
bit
more
complicated,
especially
if
you
have
like
interleaving
logs.
So
I
could
see
potentially
even
splitting
this
into
two
separate
proposals.
E
I
think
there
was
also
some
feedback
about
like
whether
you
know
this
should
be
an
argument
to
run
or
a
new
command
and
just
kind
of
like
what
would
be
the
best
syntax
for
this
and
to
be
you
know
blunt.
I
don't
really
have
too
much
opinion
about
like
the
implementation
of
this,
I'm
more
just
kind
of
pointing
out
a
pattern
that
is
useful.
E
Another
thing
that
that
becomes
like
a
little
more
complicated
and
I
can
I
can
bring
up
some
examples-
is
like,
depending
on
on
how
you
want
to
run
things
like
if,
in
the
case
of
like
testing
well,
I
may
want
to
run
both
my
linter
and
my
test
suite
independent
on
whether
or
not
one
passes
and
one
fails,
and
they
just
want
to
have
the
output
of
both
at
the
end.
Right
now,
the
and
and
approach
causes
it's
a
hard
bale.
E
There
are
ways
that
you
can
do
this,
but
it
ends
up
becoming
extremely
platform
and
posix
specific
I've
done
some
weird
stuff
where,
like
you,
save
the
state
of
them,
you
like
pipe
it
into
an
environment
variable
and
then
check
that
it's
gross.
It
works,
but
it's
not
like
fun.
So
I
think
that
there's
a
lot
of
design
space
here
as
far
as
like
figuring
out
like
the
scope
of
what
we
want
to
solve,
but
I
at
least
to
myself.
E
D
Well,
you
can
just
set
your
test
script
to
tap
and
your
post
test
script
to
eslint
and
that's
effectively
that
but
like
yeah,
when
you
have,
if
you
have
five
things
that
you
want
to
chain
together,
then
it
starts
to
get
more
convoluted.
D
The
the
thing
that
I
have
the
kind
of
like
just
to
play
devil's
advocate
a
little
bit
and
press
on
this.
What
I
sort
of
don't
want
to
do
is
get
to
a
point
where
we
have
where
we've
like
re-implemented
make
right.
Make
is
great,
I
love
make
and
I
think
more
people
should
use
it
like,
especially
if
you
want
to
have
like.
Oh
you
know
my
build.
D
My
build
web
only
has
to
redo,
like
I
only
want
to
build
the
css
files
that
have
changed
and
build
web
only
has
to
be
run.
If
one
of
these
five
things
has
been
done,
and
so
I
have
like
these
four
that
can
run
in
parallel
and
this
one
that
has
to
kind
of
wait
for
them
all
like
there's
tools
for
that
and
they're
great
and
they're
hard
to
get
right.
You
know,
I
don't
know
how
many
decades
have
gone
into
making
make
good
question
about
make.
Does
it
run
on
windows.
D
No,
I
don't
believe
so.
I
mean
there,
there
may
be
a
wsl,
I'm
pretty
sure
wsl
has
make,
but
I
mean
if
you're
just
running
in
like
sort
of
a
stock
windows,
then
there's
no
there's
no
make
implementation
for
that.
C
D
B
D
C
Had
his
hand
raised
before.
B
Yeah
so
like
in
general,
I
I
think
cross-platform
ways
to
do
things
is
important.
I
think
I
have
a
number
of
projects
where
windows
users
have
said
that
they
have
trouble
and
I've
had
to
make
fixes,
because
I
just
didn't
realize
it
didn't
work
on
windows
or
no
windows.
User
had
ever
tried
it
and
for
the
series
approach
when
there
are
explicit
script
names.
B
I
think
that
that
seems
straightforward
to
me
and
would
solve
a
lot
of
those
issues
that
miles
mentioned,
and
you
know,
as
like
isaac
mentioned
make
but
like
if
make
was
sufficient
for
node,
then
then
it
kind
of
feels
like
npm
run,
shouldn't
have
been
added
ever
and
like,
but
because
make
doesn't
work
on
windows.
It's
not
sufficient
for
note
so
like
on
non-wsl
windows,
obviously,
but
then
the
the
concerns
I
have
which
miles
referenced
were
so
for
the
parallel
one.
B
It's
interleaving
output
and
making
sure
that
exit
codes
propagate
correctly
there
as
I've
tried
all
of
the
tools
that
I'm
aware
of
for
running
tasks
in
parallel
and
arbitrary
tasks
in
parallel,
and
as
far
as
I
can
tell,
they
all
are
brittle
in
various
ways
and
do
not
do
that
correctly.
So,
if
that's
something
npm
could
solve,
that
would
be
glorious
because
then
there
would
be
one
working
tool
for
that
purpose.
B
The
other
kind
of
question
it
raises
with
both
of
those
is
globs
and
patterns,
so
there's
like
npm,
run
all
or
something
people
want
to
be
able
to
do
like
run
all
my
tests
star
or
they
have
some
convention
around
colon
usage
or
whatever,
and
it
would
be,
I
think,
very
tricky
to
allow
to
bring
in
some
some
sort
of
conventions
to
an
existing
run
script
ecosystem,
but
it
would
also
make
a
bunch
of
people
upset.
B
I
think
if
we
didn't
do
anything
like
that,
so
that's
kind
of
a
minefield
around
either
of
these
features
as
well,
but
I
like
it
so
I
think
splitting
them
makes
sense.
I
would
like
to
see
them
both
eventually
land
and
as
much
as
and
and
I
just
unfortunately,
just
don't
think
make
is
really
like.
I
think
make
needs
to
be
somewhat
reinvented
since
make
doesn't
work
on
all
the
nodes
operating
systems.
C
A
B
I
do
that
partially
because
for
like
usability,
because
then,
when
I'm
typing
the
command,
I
don't
run
the
risk
of
forgetting
the
precondition
or
the
post
condition,
but
also
because
then
it
works
easier
for
windows,
users
and
kind
of
it
avoids
needing
to
have
a
bunch
of
ampersand
chains
in
my
scripts.
B
D
Yeah
I
mean
especially
if
you,
if
you
get
into
things
where
it's
like
you
know,
when
I,
when
I
run
version,
I
want
to
run
tests
before
my
as
my
pre
version
script,
and
then
I
have
a
post
test
script
and
then
I
post
version
script
that
runs
npm,
publish
and
a
pre-published
script.
D
That
does
that
pushes
it
to
get
like
you
end
up
with
this
kind
of
weird,
like
tree
of
of
scripts,
that
are
going
to
get
run
in
like
a
depth
first
reversal
order,
when
what
you
really
want
is
a
just
a
series
of
like
do
when
I
do
this
command.
Do
these
five
things
right
exactly.
F
Yeah,
I
think
this
is
a
minefield,
so
I
will
just
say
that
I
think
we
already
have
a
lot
of
problems
with
the
like
nested
doll
approach
to
npm
scripts,
where
we
have
like
npm
run,
foo
runs,
npm,
run
bar
and
an
npn
run.
You
know,
and
it
just
goes
on
and
on
and
I've
seen
much
worse
cases
of
this
in
applications
than
I've
seen
in
libraries.
F
So
I
think
you
know
if
we
make
it
more
powerful,
we
run
the
risk
of
folks
doing
even
wilder
things
with
it
and
I'm
not
sure
that's
a
good
thing.
That
said,
we
have
an
internal
tool
that
uses
a
re-implementation
of
team
mux
in
javascript
to
do
a
user
experience
around
running
things
in
parallel.
That's
actually
really
nice,
I'm
not
saying
the
implementation
is
great,
but
the
user
experience
is
pretty
nice.
F
You
you
end
up
running
this
one
command,
it
pops
open
a
tmux
session,
but
it
is
fully
re-implemented
in
javascript,
so
it
is
cross-platform
and
then
you
just
get
the
log
output
next
to
each
other
or,
however,
you
know
your
thing
wants
to
run
it
and
I'm
pretty
sure
that
is
building
on
top
of
some
npm
run
scripts.
F
So
if
we
wanted
to
go
somewhere
out
like
that
doing
some
sort
of
session,
like
like
a
tmux
session
for
the
non-interleaving
log
problem,
actually
is
a
pretty
good
user
experience.
That's
all
I
want
to
say
that
said.
I
really
think
folks
go
way
too
far
and
they
should
have
just
probably
moved
it
into
a
scripps
directory
and
not
been
doing
all
this
sort
of
weird
chaining
of
npm
scripts.
F
So
I
would
rather
see
a
support
for
a
cross-platform
script
directory
that
npm
respects
where
you
could
say:
npm
run
foo
and
it
would
actually
see
if
there's
a
script
and
package
json
and
if
not
then
check
a
known
file
location
for
it.
And
then
let
people
go
wild
in
there
then,
and
that
could
then
you
know,
have
all
the
parallel
stuff.
F
Just
implemented
as
some
sort
of
cross-platform
bash
type,
you
know
syntax
instead,
because
I
think
that
putting
it
all
in
jason
is
just
super
painful
and
I've
seen
a
lot
of
bugs
because
of
it.
So.
B
B
F
But
that's
not
true,
you
just
said
you
want
logic
right,
you
want.
If
this
one
fails.
Sometimes
I
might
run
these
other
and
let
them
complete,
but
sometimes
I
want
to
bail
out.
Like
I
mean
that
is
logic,
whether
it's
simple
logic
represents
well
in
bash
or
sorry
in
jason
or
not,
is
what
you're
saying,
but
you.
D
What,
if
you
know
what,
if
we
just
just
kind
of
throwing
out
a
weird
idea,
what
if
we
looked
for
like
a
something
like
travis
or
github
actions,
like
you,
know,
workflow
yaml
file
and
had
a
a
way
to
like
run
all
the
things
in
there,
because
that
has
like
there
are
patterns
already,
for
you
know,
should
this
fail
fast,
what
you
know,
what
commands
need
to
be
run
like
which
ones
need
to
depend
on
which
other
ones
I
mean
you
want
to
talk
about
like
re-implementing
make
I
mean
effectively,
that's
what
ci
has
done.
D
It's
reimplemented
make
complete
with
dependencies
and
configurable
parallelization
and
everything
else.
I
would.
D
Right
I
mean
the
challenge
is,
like
you
know,
one
of
the
big
things
that's
in
every
ci
system
is
a
matrix
of
operating
systems
and
versions
and
like
npm,
is
not
going
to
do
that.
I'm
not
going
to
ship
an
implementation
of
windows
with
for
you
to
run
your
nvm
test
on
and
probably
even
different.
D
Node
versions
would
be
to
to
like
a
bridge
too
far,
but
a
way
to
say,
like
here's,
a
here's,
a
bunch
of
like
commands,
I
don't
know
like
yaml
and
and
some
kind
of
like
existing
dsl
for
for
describing
the
dependencies
would
start
to
make
a
lot
more
sense,
because
json
is
very
limited
like
and
that's
kind
of
the
point
of
json
right
like
you,
you
don't,
it
should
be
nudging
you
towards
writing
your
script
somewhere
else.
C
Sure,
okay,
so
for
the
sake
of
moving
forward
in
the
agenda
here,
let's
unbox
the
discussion
but
yeah.
I
think
we
should
definitely
follow
up
in
the
rfc
or
the
com.
It's
just
an
issue
now
or
maybe
getting
someone
making
it
into
a
real
rfc.
If
there
is
interest,
but
I
saw
a
couple
of
comments
in
different
directions:
it'd
be
nice.
C
If
isaac
was
you
can
document
that
in
the
in
that
issue,
there.
C
Yep,
okay,
so
yeah
moving
forward
next
item
here
in
the
agenda
is
going
to
be
the
head
ability
to
skip
scripts
books.
Oh
okay,
this
is
from
lucas.
I
don't
think
he
joined
today.
D
Yeah
I
mean
I
I
think
I
I
think
this
is
great
though,
and
personally,
and
it's
like
the
implementation
is-
is
almost
no
amount
of
work.
The
the
thing
that
is
kind
of
interesting
in
this
somebody
did
bring
up
in
the
issue
that
it's
a
little
bit
weird
to
have
npm
test
dash
dash,
ignore
scripts
still
run
the
test
script,
but
not
run
the
pre,
and
postscript
I
mean
to
me
that
kind
of
makes
the
most
sense.
But
who
was
that
that
was
asking
us.
D
Right
so
so,
right
now
you
know
in
v6,
if
you
run
npm
test
dash
ignore
scripts,
it
just
doesn't
run
your
test,
which
I
think
is
a
terrible
experience
and
in
npm
seven
well,
we
went
all
the
way
to
the
other
side
of
the
spectrum.
If
you
run
npm
test
ignore
scripts,
it
just
runs
everything
anyway,
along
with
pre
and
post.
So
those
are.
Those
are
like
the
two
worst
options
I
feel
like
the
middle.
The
middle
way
suggested
by
this
rfc
is,
is
actually
pretty
good.
C
Cool
yeah,
if
no
one
else
has
any
comments,
maybe
follow
up
in
the
rfc.
But
it's
looking
good
right.
C
D
C
B
B
Really
big
problem:
I
have
300
packages
with
a
test.
The
test
stash
only
script
specifically
so
that
in
ci
I
don't
have
to
run
my
linter
on
every
matrix,
build
because
npm
test
ignore
scripts
does
nothing
which
I
learned
the
hard
way
when
my
tests
were
passing
mysteriously
for
a
month.
B
Be
a
great
programmer,
even
though
npm
6
is,
is
kind
of
it.
So
the
only
option
or
another
alternative,
though,
might
be
a
new
option.
That's
not
called
ignore,
not
spelled
ignore
scripts,
because
it
would
be
really
nice
to
ship
that
in
npm
six,
even
though
you
probably
aren't
going
to
want
to
do
anything
in
npm
6.
D
Just
throwing
it
out
there,
I
think
I
mean,
I
think,
calling
it
ignore.
Scripts
makes
the
most
sense,
because
what
ignore
scripts
means
like
in
like
semantically
like
what
is
the
spirit
of
that
config
flag?
What
it
means
is,
do
the
thing
I'm
telling
you
to
do,
but
don't
do
all
the
all
the
other
extra
junk
right
and
if
you
run
npm
tests
like
the
thing
I'm
telling
you
to
do
is
to
run
the
test
script
and
don't
do
the
extra
junk
means.
Don't
do
the
pre
and
post.
B
D
Yeah
we,
we
will
have
a
few
a
few
little
very,
very
small,
fixes
that
are
going
out
here
pretty
soon
but
yeah.
I
think
something
like
we
should
really
just
sort
of
treat
that
as
like
it
npm
6
is
what
it
is
and
adding
new
features
is
probably
not
gonna
happen.
C
I'm
good
I'm
good
just
a
little
interesting
here,
but
all
good,
but
yeah
it's
looking
good
to
ratify
right.
So,
let's,
let's
call
it
ratified
we
can.
Where
is
that
pr
and
ship
it
in
the
next
beta
release?
C
Yep
cool
all
right!
So,
let's
move
on
to
the
next
one.
We
have
the
the
one
from
you:
isaac,
bringing
back
a
subset
of
npm
package,
very
new
variables.
D
Yeah
yeah,
this
came
out
of
a
conversation
in
on
twitter
with
a
couple
of
folks
and
really
like
this
is
in
the
current
beta
that
we
just
shipped,
but
really
the
the
only
question
is
like.
Are
there
others
that
that
should
be
added,
or
is
this
enough
so
effectively?
What
this
adds.
D
D
Name
version
config
with
the
whole
nested
underscore
object
thing
engines
bin
with
the
whole
nested
underscore
object
thing,
and
I
think
that's
it,
because
those
are
the
ones
that
I
was
able
to
find
some
some
reference
of
people
using
them,
and
you
know
you
probably
don't
need
the
whole
array
of
contributors
or
you
know
other,
like
random
stuff
like
scripts
and
whatnot.
D
D
C
Yeah
and
for
anything
that
is
package
json,
you
do
have
a
fallback
like
track
of
without
the
npm
package
chasing
the
very
variable
right
that
people
can
use
to
read
the
actual
package.
Jason.
D
Yeah,
I
mean
obviously
that's
not
gonna
work,
that
that
adds
a
little
bit
of
complexity,
because
you
have
to
like
write
a
program
in
javascript
that
reads
the
file
and
json
reverses
it
or
whatever.
If
you,
if
you're
doing
something
like
you
know,
just
using
the
version
to
like
update
all
your
docs
or
something
like
that,
and
you
just
want
to
kind
of
get
the
environment
variable
and
spit
it
out
somewhere
else,
parsing,
the
the
the
json
is
a
little
bit
tedious.
F
Can
I
can,
I
ask,
like
I
understand
that
people
use
this
but
where's
the
line
because,
like
it
seems
to
me
like
adding
a
node
c
standard
in
jason,
parse
or
whatever,
is
like
not
a
very
large
ask
for
the
simplicity
that
it
brings
to
just
remove.
Basically,
all
of
them,
which
was,
I
thought,
a
good
original
decision.
D
B
Go
ahead,
yeah
just
the
I
mean.
I
think
these
are
already
covered
because
we've
talked
about
it
on
github,
but
the
issue,
the
things
that
I
think
are
important
to
not
have
to
read.
Package.Json
for
or
if
I'm
running,
npm
version
it
should
be
apparent
in
the
environment.
What
version
I'm
going
from
into.
D
So
that
actually
already
is
covered
in
the
right
npm
version
command
like
there.
There
are
some
additional
environment
variables
that
are
not.
You
don't
have
to
pull
out
a
package.
B
Right
but
I'm
I'm
that's
an
example
that
I'm
providing
of
like
where
information
that
is
contextually
directly
relevant
to
the
command
being
run
should
be
provided,
but
everything
else
like
the
you
know,
you
could
argue
the
package
name,
maybe,
but
like
really,
you
could
read
package.json
for
that
stuff.
It's
just
that,
like
the
in.
In
the
version
case,
the
one
of
those
two
versions
is
ephemeral,
and
so
at
some,
whether
in
pre-version
version
or
post
version,
one
of
them
isn't
packaged
json
and
the
other
one
isn't
so
they
both
like
for
clarity.
B
They
kind
of
both
need
to
be
in
the
environment
and
then
there's
probably
similar
things
around.
I
don't
know
like
if
you're
in
publish,
maybe
you
want
to
know
if
it's
a
dry
run
or
not
and
in
general
terms
right,
there's
the
in
publish
package
so
like
tools
need
to
be
able
to
know
if
they're
running
and
publish
or
an
installer
like
which
life
cycle
hook
they're
running
in
but
like
again,
that's
all
contextual
stuff.
It's
not
anything
else.
D
Yeah,
the
the
all
of
those
and
all
those
things
are
covered
actually
better
in
npm,
seven
and
more
reliably
than
than
an
npm
six
but
yeah.
I
think
jess
telford
had
brought
up
a
few
in
that
in
that
thread,.
D
Like
what
did
he
ask
for
name
main
config,
a
couple
of
others?
Nobody
ever,
but
my
you
know
my
pushback
was
like
nobody
needs
npm
underscore
package,
underscores
contributors
underscore
43,
underscore
email
right
like
that's,
it's
ludicrous
and
it
actually
for
large
packages
and
large
apps,
like
we've.
D
We've
seen
this
in
some
of
our
internal
apps
at
npm
like
running
the
scripts
on
some
systems,
will
actually
blow
up
the
the
environment
caused
the
script
to
fail
because
it's
like
trying
to
dump
too
much
stuff-
and
you
know
it
had
a
that
machine-
had
a
really
low.
U
limit
for
environment
size
and
a
ton
of
configs
and
stuff,
so
it
just
gets
pretty
pretty
onerous.
F
D
Yeah,
so
the
the
exports
is
probably
not
going
to
work
and
probably
wouldn't
even
in
npm6,
because
it
it
starts
with
a
dot
right
like
and
that's
gonna.
That's
gonna
cause
the
keys
to
start
with
an
underscore
which
then
npm,
the
old
npm
lifecycle
will
say.
Oh
this
is
a
private
value.
I
shouldn't
there's
a
private
config
value.
I
should
not
be
putting
it
in
the
environment
so
that
already
like,
we
don't
really
have
to
worry
about
the
future.
So
much
in
terms
of
the
like,
you
know
slippery
slope
angle.
D
D
D
All
right:
well,
I'm
gonna
like
we
should
probably
call
this
ratified
because
we
already
shipped
it.
C
A
A
A
That's
right,
yeah
probably
just
have
to
follow
up,
and
I
can
ping
tierney
again
to
see
what
the
next
steps
are.
H
So
yeah
I
after
we
spoke
about
this
at
the
last
meet
three
weeks
ago.
Actually
I
was
very
much
convinced
that
we
actually
resolved
this
during
npm
pack
and
the
rfc
accordingly
and
to
me
what
only
kinda
remains
is
like
open
questions
a
bit
like
what
you
would
inherit
because,
like
it's
like,
I
think
it's
more
of
a
problem,
that's
kind
of
being
amplified
in
workspaces
environments.
H
So
I
think
it's
to
personas,
like
you,
have
a
a
developer
who's
installing
a
package
and
the
developer
doesn't
even
know
that
the
packet
apparent.
H
However,
if
you
develop
the
package
locally,
of
course
you
want
to
know,
as
the
package
offer,
that
there
is
a
parent
and
you
need.
I
think
you
do
need
a
mean
to
see
like
that.
H
For
example,
if
you
run
npm
list
like
where
the
script
is
coming
from
or
where
the
pack
dependencies
are
coming
from,
if
they
are
coming
from
the
parent
or
if
they
are
defined
in
the
child,
so
to
me
basically
the
so
it's
I
don't
know
it's
kind
of
it
kind
of
more
evolved
into
yeah
support
for
like
development
environment.
I
would
say,
if
that's
appropriate.
H
And
I
think
one
of
the
things
I
kinda
came
up
with,
which
would
be
problematic,
would
be
if
you
have,
if
you
inherit
from
a
parent-
and
you
also
have
that
parent
as
a
death
dependency,
for
example
like
how
would
you?
How
would
you
update
this?
This
would
probably
get
messy
very
very
fast,
so
I
think
those
are
kind
of
the
things
that
should
just
be
prohibited
all
together.
D
I'm
not
sure
why
it
would
be
why
it
would
be
tricky
to
have
the
parent
package
be
a
dependency
or
dev
dependency.
H
For
example,
if
you
run
npm
update,
you
would
do
it
with
like
npm
update
and
then
like
the
package
name
or
like
even
npm,
outdated
as
well
and
then
like.
How
would
you
say
I
want
to?
I
want
to
update
my
death
dependency
and
not
my
parent,
for
example,.
D
Let's
say
that
when
we
publish
we,
we
flatten
flatten
that
so
at
publish
time
we
we
fetch
that
spec
we
get
the
manifest.
We
do
the
merge
and
we
say
okay,
this
is
the
package
that's
actually
getting
published,
but
we
leave
your
dev
environment
alone.
D
If
you
have
it
as
a
dev
dependency,
like
that's
fine,
you
just
you're
just
updating
a
file.
That's
in
you're
updating
files
in
your
node
modules,
folder,
your
your
effective
package.json
is
still
going
to
be
based
on
resolving
that
spec
and
and
getting
that
manifest
and
kind
of
merging
it
into
the
current
one.
H
But
wouldn't
you
have?
Wouldn't
you
have
the
death
dependency
and
the
parent
identifier
in
your
local
dev
environment?
And
if
you
ran
npm
update,
you
would
need
to
specify.
H
You
would
need
a
mean
to
specify
whether
you
would
want
to
update
the
parent
or
the
death
dependency.
D
D
It's
saying
my
parent
is
this
package
specifier
it
could
be
a
dependency
or
dev
dependency
or
nothing,
and
it
would
be
basically
no
different
than
having,
like
you
know,
a
package
that
doesn't
depend
have
a
parent
that
depends
on
that
package
right.
D
So
the
way
the
way
I
would
approach
it
is
like
we'll
we'll
talk
about
a
way
to
you
know,
update
the
parent
that
you
depend
on,
but
for
the
time
being,
we'll
just
say:
if
you
want
to
change
the
parent
spec
that
you
depend
on
you,
you
open
up
your
editor
and
you
open
package.json
and
you
go
edit
it
and
at
publish
time
we'll
or
at
pac
time.
More
specifically,
we
will
sort
of
flatten
that
that
package,
json
and
otherwise,
every
time
you
run
an
npm
command.
We
have
to
load
that
parent
specifier.
D
So
you
know
that
does
impose
some.
Some
developer
experience
challenges
if
the
specifier
is
a
remote
spec
right.
So
if
I,
if
my
parent
package
is
like
foo
at
one
two
three
well,
I
have
to
touch
the
registry
every
time
I
do
anything
like
just
to
run
npm
ls.
Now
I
have
to
have
to
hit
the
registry
there's
some
ways
we
can
make
that
a
little
better
like
obviously
it's
going
to
be
cached
and
so
on.
We
could
even
like
prefer
offline
when
we
make
that
particular
request.
D
But
I
think
the
expectation,
if
I
do
that
if
my
parent
package
is
a
remote
package,
the
expectation
would
be.
I
update
the
remote
in
my
local
package.
Changes
like
right
away.
H
So
kind
of
what
you're
saying
is-
and
maybe
I
got
this
completely
wrong
last
time
or
I
just
missed
it-
that
I
would
specify
my
parent
basically
just
like
this
any
version
or
anything
and
then
like
npm,
would
just
like
go
look
inside
the
note
modules,
folder.
D
No,
no
I'm
saying
the
opposite
of
that.
I'm
saying
you
would
say
parent
typescript
at
one.x.
Okay,
if
you
did
just
parent
typescript.
Well,
that's
gonna
get
typescript
at
latest
because
that's
how
it
works.
If
you
run
npm
install
typescript,
that
might
be
the
version
in
package.
That
might
be
the
version.
That's
in
your
dependencies
list
or
it
might
be
a
completely
different
version
and
that's
it's
completely.
Orthogonal.
H
All
right,
I'm
I'm
not
sure
how
so
okay,
so
I
have
it
at
a
specific.
I
just
basically
give
it
a
sem
version
range
like
I
could,
with
any
other
dependency
as
well
right,
and
it
would
result
him.
A
H
D
D
H
D
Sorry,
we
use
the
term
specifier
a
lot
as
kind
of
a
technical
term
internal
in
the
cli.
I
realize
it's
not.
I
was
not
defining
that.
H
So
if
you
have
a
def
dependency
now
for
typescript-
and
you
run
npm
update,
you
or
npm
outdated
is
even
is
even
better.
You
would
get
output.
That
said
that
maybe
typescript
is
outdated
as
a
parent,
no
and
as
a
death
dependency,
or
you
would
just
leave
like
the
the
parent
out
of
there
completely,
because
otherwise
it
would
just
bloat.
D
D
H
Yeah
but
like
if
I
developed
it
locally,
I
would
I
wouldn't
have
I
wouldn't
run
an
npm
pack
right
or
am
I
just
missing
something
completely
here
I
mean
it
would
only
be
run
like
npm
pack
would
only
be
run
if
I
publish
it,
but
if
I
locally
develop
my
package
and
I
wanted
to
run-
I
don't
know
npm
test
and
npm
test
is
maybe
defined
in
my
parent.
I
couldn't
do
that
right.
You
could.
D
We
would
then
see
that
there's
a
parent
field,
we
would
load
the
parent
manifest.
We
would
apply
those
inheritances
and
we'd
return,
the
resulting
manifest
from
the
rejson
call.
Okay.
So
your
test.
So
when,
when
npm
says,
give
me
the
local
package,
json
it'll
get
the
one
that's
fully
resolved,
there
might
be
some
indicator
or
some
hidden
field.
That
says
we
got
this
from
a
parent.
You
know
just
for
our
tracking
purposes,
but
for
most
of
the
code
base
it
would
just
kind
of
be
oblivious.
H
D
H
D
I
do
feel
like
there's
a
bunch
of
quite
a
bit
of
like
ux
and
and
technical
challenges
that
that
need
to
be
combed
through
for
this,
and
so
I'm
not
quite
ready
to
ratify
it.
But
you
know,
and
also
the
just
the
performance
impacts
of
of
doing
what
would
be
kind
of
the
most
expected
thing.
So
that's
why
it's
sort
of
been
on
the
back
burner.
H
Finish
up,
I'm
not
I'm
not
taking
offense!
So,
okay,
I,
I
definitely
do
see
it's
a
it's
a
big
thing
and
I
mean
like
I,
I
kind
of
rewrote
the
entire
thing
once
already,
which
kind
of
goes
to
show
that
it's
not
that
easy.
So
I
I
wouldn't
be
offended
if
it.
D
Yeah,
so
the
the
the
important
thing
is
when
we
we
don't
currently
right.
Currently,
we
just
put
the
package
json.
We
just
pass
it
to
tar
and
let
it
do
its
thing
in
order
to
implement
this
safely,
we
would
have
to
read
the
package
json
and
then
kind
of
re-encode
it
for
the
file
that
goes
in
the
in
the
package.
Tarball.
If
there's
a
if
there's
a
parent
field.
D
Right
so
what
goes
in
yeah?
I
would
say
what
goes
in
the
lock
file
gets
really
pretty
interesting.
That
is,
that
is
a
nut
that
has
to
kind
of
be
cracked
there,
because
you
you,
we
want
to
be
able
to
just
read
the
lock
file
and
have
that
be
like
a
correct
package
tree.
D
D
So
it's
it's
not
that
that's
a
blocker
per
se
and
I
I
I
would
hesitate
to
say
exactly
how
we
should
do
it
before
kind
of
getting
a
little
bit
more
in
the
weeds
with
the
implementation.
But.
D
Well,
I
mean
that
would
break
when
you
run
yeah.
That
would
break
without
a
log
file
like
the
the
goal
of
the
log
file.
Is
it
it
should
always
be
just
you
know,
whatever
whatever
works
with
the
log
file
will
mostly
work
without
one,
and
you
know
just
by
looking
at
what's
actually
there,
and
it
should
also
not
cause
you
to
get
different
data
if
there's
a
log
file
versus
if
there's
a
fully
resolved
node
modules.
D
D
What
it
should
do
is
again
it
should
resolve
the
the
root
package
json
against
the
parent.
It
should
see-
oh
well,
I
have
this
tree
here,
but
there's
a
bunch
of
invalid
things.
You
know
some
missing
depths
or
extraneous
steps
and
fix
them
and
otherwise
follow
what
the
lock
file
says.
So
that
would
always
fail.
Then,
if
I
didn't
have
the
if
the
paragraph.
D
D
Well,
the
log
file
is
specifying
the
the
resolved
and
the
and
the
tree
shape
of
what
we
expect
to
to
put
in
node
modules.
It's
not
going
to
save
you
from
a
package
json
that
can't
be
loaded
properly,
like
all
of
the
all
of
the
logic
here
like
what
I'm
suggesting
is
all
of
the
logic.
Around
parentage
of
packages
happens
at
the
phase
where
we
load
the
package.json
file,
okay
and
that's
where
we
resolve
it
and
and
flatten
that
manifest,
say.
D
The
the
two
tricky
things
the
two
trickiest
things
are
when
I
npm
install-
and
I
update
something
in
that-
you
know
I'm
going
to
save
my
depth
back.
D
I
have
to
be
smart
enough
to
like
to
say
I
want
to
say
this
to
the
original
json
object
and
save
it
back
with
the
parent
reference
yeah
and
not
accidentally,
not
accidentally,
save
the
whole
flattened
one
without
the
parent
reference,
and
when
I
create
the
package
tarball
for
publishing
or
packing,
it
needs
to
save
the
flattened
one
and
not
the
the
one
that
has
the
parent
reference.
B
So
well,
there's
a
few
more
wrinkles
than
that
right,
like
one
of
them
is
when
I
do
npm
install
dash
dash,
save
which
one
do
I
want
to
save
it
to
well,
you
can't
save
it
to
the
parent.
It's
not
here
when
I'm
when
I'm
in
in
the
like.
If
I'm
inside,
that
the
child
one
and
I'm
developing
yeah
the
parent,
is
there
right
like
that's
where
it
would
be
read
from
in
order
to
smush
it
together?
So,
like
I
mean.
D
B
D
B
If
the
parent
is
a
relative
file
path,
that
traverses
up
out
of
the
directory-
and
I
have
the
current
one
sim
linked-
is
that
also
like?
How
do
you
do
all
the
right,
the
correct
real
pathy
things
to
make
that
work
as
expected,
and
what,
if
someone
expects
it
to
go
up
from
the
sim
links
directory
and
not
from
the
originals
directory.
D
So
if
the
parent
is
so,
what
I
would
do
is
I
mean
it's
actually
pretty
simple,
like
we
fetch
the
parent
by
calling
picoche.manifest
and
passing
in
that
specifier
and
that
will
go
find
it
wherever
that
specifier
points,
whether
that's
a
name
at
version,
whether
it's
a
url
tarball,
you
know
right,
but
if
it's
file,
colon,
slash,
slash
dot,
dot.
D
Colon
slash,
dot,
dot,
slash
blah
blah
blah
coach
a.manifest
will
see
that
file
call
and
it'll
go
in
that
folder
it'll
read
that
package
json
and
it
will
return
me
a
manifest
object,
but
for
the
purposes
of
npm
like
from
no
from
a
relative
path
from
the
package,
that's
doing
the
the
file
offset
so
whether
it's
a
sim
link
or
real
path
or
anything
doesn't
actually
matter.
What's
gonna
matter
is
because
it's
it's
not
loading.
D
So,
for
the
purposes
of
of
this,
like
whatever
that
specifier
is
it's
somewhere
else,
whether
it's
a
whether
it
happens
to
be
a
folder
on
my
machine
like
maybe
it's
a
folder,
I
don't
have
permission
to
read,
or
maybe
it's
a
folder,
I
just
shouldn't
be
reading
or
writing
in
or
sorry
maybe
it's
a
folder,
I
don't
have
permission
to
write
to
or
at
the
very
least
from
the
purposes
of
running
this
particular
install
it's
sort
of
outside
of
my
domain
and
so
modifying
you
know,
modifying
repo,
a
when
you're
working
in
repo
b
is
extremely
bad
behavior.
G
Oh,
I
agree
one
thing
I
if
I,
if
I
may
add
so,
the
whole
thing
seems
clear
to
me
now
with
one
assumption
that
the
parents
exact
specification,
which
version
of
the
package
it
is,
is
also
going
to
have
to
be
saved
in
package
lock.
Otherwise,
the
duplication
might
do
weird
things
or
the
package
log
might
get
outdated
or
confused.
I
don't
see
how
it
would
work
otherwise,
and
at
the
same
time
I
would
personally
be
surprised
if
package
log
didn't
lock
the
parent
as
well.
D
Yeah,
so
that's
I
mean
maybe
the
maybe
the
thing
we
do
is
the
the
package
lock
actually
includes
a
parent
field
which
has
the
specifier,
which
has
the
manifest
that
we
fetched
to
resolve
against
package
json
and
we
checked
there
first
right
and
then,
if
it's
missing,
then
we
do
the
picoche
lookup.
That's
I
I
think
that's
completely
reasonable
yeah.
I
see
yes
and.
C
F
F
Yeah
we're
almost
at
time,
so
I
don't
even
know
if
we
want
to
go
into
it,
but
I
was
going
to
say:
have
we
tackled
the
circular
parent
problem
yet
too,
because
that
would
be
if
you,
if
you're
referencing
something
and
it
goes
through
a
chain
and
somehow,
in
the
end
that
circula,
you
know,
circulate
back
to
your.
You
know
the
package
you're
working
on.
We
need
to
prevent
that
in
some
way.
I
would
assume.
D
Yes,
we
we
will
have
to
prevent
that
you're
right,
it's
pretty
easy
to
prevent
that
we'll
just
keep
a
list
of
all
the
all
the
resolve
values
and
if
we
get
back
to
one
we've
already
seen,
we
just
go.
Okay,
we're
done.
C
Yeah
cool
so
yeah
we're
at
time
here,
so
I
think
we're
gonna
have
to
end
the
discussion
for
now
but
yeah.
Maybe
it's
a
good
idea
to
also
go
back
to
the
rfc
and
document.
C
I
think
there's
a
lot
of
progress
here
today,
yeah
so
for
today
I
know:
there's
there
was
still
three
items
left.
I
promised
last
time
I'll
try
to
switch
the
order
so
that
we
can
go
through
these
first,
so
zb
like
I
think
next
week
we
might
go
npm
audit
first
and
try
to
reverse.
G
I
can
try
to
join
some
meeting,
but
next
week
it's
gonna
be
even
worse
than
now.
I'm
I'm
trying
to
work
and
get
the
life
afloat
after
we've
lost
a
babysitter.
So
it's
it's
not
easy
on
time.