►
From YouTube: Open RFC Meeting - Wednesday, August 19th 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
All
right
welcome
everyone
to
another
npm,
open
rfc
call,
so
I'm
your
host
today,
our
usual
host
darcy,
is
a
no
well
deserved.
Pto,
so
gonna
be
doing
the
call
today
so
yeah.
Let's
start
with
today's
agenda
and
usually
first
things
we
do
is
housekeeping
just
introductions
and
making
some
announcements.
A
So
to
start
with
I'd
like
to
remind
everyone
that
this
call
and
all
the
interactions
with
the
npm
open
rfc
are
under
our
code
of
content.
So
if
you
haven't
yet,
please
take
some
time
to
go.
A
Check
it
out
in
our
in
our
website.
Oh
yes
and
thanks
isaac.
I
see
isaac
posted
the
markdown
document
for
this
meeting.
So
usually
we
take
notes
who
attended
and
the
agenda
is
there,
so
you
can
follow
along.
A
So,
yes,
let
me
also
start
with
some
announcements
from
this
week,
so
we
have
shipped
two
versions
of
npm
this
week.
Another
patch
release
for
v6,
just
some
small
bug
fixes
and
dependency
updates,
but
also
a
new
version
of
the
npm
7
beta,
so
yay,
if
you
haven't
tried
it
out
yet
please
go
ahead,
give
it
a
try.
A
Let
us
know
if
you
find
any
bugs
it's
just
going
to
our
github
and
you
can
post
an
issue
there
to.
Let
us
know
so
it's
very
appreciated.
If
anyone
wants
to
give
it
a
try.
A
D
D
F
D
The
user
experience
thing
it
seems
more
expected
to
me
if
I
dash
save,
because
normally
that
would
put
it
in
prod
anyway.
Anyway,
I
don't
want
to
just
distract
the
conversation
so
a
couple
days
and
it
did
something
that
I
always
thought
was
unexpected
before
I
did
it
the
way.
I
expect
it
now,
even
if
it's
a
bug,
yeah.
D
Nicely
is
it
doesn't
alphabetize
your
your
package
json,
so
it
used
to
sort
when
you
didn't
install
your
dependency
list,
which,
for
a
diff
was
actually
problematic
because
then
suddenly
like.
If
somebody
else
had
done
some
manual
moving
things
around
for
some
reason
and
then
you
installed,
it
would
actually
mark
the
entire
block
as
a
change
in
the
diff
right
and
now
it
depends
on
the
bottom,
which
also,
I
think,
is
a
great
user
experience,
because
now
the
diff
actually
just
shows.
C
It's
so
rare
that
you
get
a
a
report
of
something
that
is
not
working
but
as
designed
and
it
comes
along
with,
and
it's
so
wonderful
that
you
change
generously.
A
C
A
Yeah,
let
me
just
wrap
up
the
intros,
so
I
was
noticing
we
have
a
lot
of
new
folks
today.
So
if
folks
want
to
introduce
themselves
even
even
the
recurrent
ones,
so
that
the
new
folks
can
also
get
to
know
you
so
I'm
gonna
start,
I'm
riodorno,
I'm
a
member
of
the
mgm
team
at
github
and
yeah
we're
working
on
the
cli.
A
So
if
let
me
just
start
calling
names,
so
if
we're
not
lost
and
if
you
just
want
to
say
your
name
and
anything,
it
can
be
the
reason
why
you're
here
or
just
where
you
work,
it
is
great.
So
christian
wanna.
A
E
Oh
sorry,
that
was
a
very
good
sign
of
the
german
internet
because
it's
always
cutting
out
in
the
very
important
pieces.
Yeah.
Sorry
I
didn't
hear
you
say
my
name,
sorry
about
that
so
yeah,
my
name
is
christian.
I
work
in
as
an
I.t
consultant
in
germany,
which
means
that
I
usually
just
write
and
design
and
consult
on
big
web
application
project
and
I
use
npm
on
a
daily
basis
and
yeah.
E
I
started
I
just
started
contributing
one
rfc
and
yeah,
I'm
still
stuck
with
that
one.
However,
as
I
said
last
time,
I'm
not
offended
by
that.
I
just
know
it
takes
time.
H
Sure
yeah,
so
I'm
mark
dalton,
I'm
a
developer
for
sona
type.
For
those
who
don't
know
sonotype,
we
do
the
products
nexus
repository
manager,
nexus,
livecycle
and
so
on
so
forth.
There's
an
rfc
raised
by
one
of
my
colleagues.
This
is
what
the
discussion
is
about
today.
So
I've
just
raised
a
apr
to
sort
of
demonstrate
that
rfc
and
what
that
might
mean
and
so
on
see
if
we
can
take
it
further.
A
Awesome
yeah,
okay,
isaac.
C
Yep
I'm
isaac.
I
also
work
on
the
cli
here
at
github
been
doing
npm
for
a
long
time
all
right.
So
next
up
jason.
I
Yeah,
I
am
jason.
I
am
a
student,
a
master's
student
in
west
virginia
university.
We
created
an
mr
for
one
of
our
classes
to
add
some
security
into
the
pipeline
of
the
npm
and
was
invited
to
this
meeting
to
talk
about
it.
So
I'm
here
with
the
rest
of
my
school
group
here.
A
J
J
We
briefly
have
used
npm
there
for
various
projects.
We
normally
focus
more
on
a
spring.
You
know
with
spring
mpc
and
stuff,
but
package
management's
an
issue
we've
been
dealing
with
with
some
of
our
software
projects
at
the
plate,
so
npm
something
we've
been
exploring,
but
yeah.
A
Cool
right,
lucas.
K
D
Sure,
hey
everybody,
I'm
les,
I
work
at
netflix.
I
work
on
our
engineering
tools
and
services
team,
which
does
a
lot
with
npm.
So
we're
doing
you
know
a
bunch
of
tooling
and
I've
been
coming
to
these
meetings.
I
think,
since
they
started
so
they're
great
welcome
everyone.
A
Awesome
anthony.
M
A
Cool
jordan.
G
Hey,
let's
see,
I
maintain
a
lot
of
packages,
I
work
with
cc39
and
a
bunch
of
stuff
with
node
and
been
on
these
meetings
a
while
yeah
thanks
for
having
me.
A
Yeah,
georgia
is
definitely
one
of
the
recurrent
ones
here.
Tierney
want
to
go
next.
N
A
Awesome
bradley.
A
A
So
all
right,
let's
go
to
the
agenda,
but
I
mean
at
the
same
time
as
if
isaac
or
and
west
want
to
go
back
to
maybe
discussing
any
npm
seven,
you
exchange
prior
to
the
regular
agenda.
I.
C
I
think
we
can
hold
off
until
we
have
a
you
know,
or
maybe
I
could
invite
wes
to
write
an
rfc
to
formalize.
Some
of
those
unintended
feature
improvements.
D
A
True
could
be
all
right,
so
let's
go
to
the
first
item
in
the
regular
agenda.
It's
gonna
be
the
overrides
rfc
from
isaac.
C
Yeah,
so
not
too
much
motion
on
this
not
too
much
to
report.
The
the
discussion
is
kind
of
you
know,
also
sort
of
just
been
where
we
left
it
quite
some
time
ago.
C
The
last
time
we
discussed
it
at
one
of
these
calls,
so
I
I
think
the
the
only
real
thing
holding
it
back
is
that
we
would
like
to
at
least
take
kind
of
a
first
pass
at
implementation
to
make
sure
we're
not
getting
ourselves
into
something
really
really
awful
before
before
ratifying
the
the
rfc,
but
otherwise
it's
it's
pretty
much
ready
to
go.
If
anybody
has
any
comments
on
it,
then
kind
of,
I
would
say,
speak
now
or
forever
hold
your
piece,
but
there
is
probably
actually
going.
C
D
C
Yeah
we
did,
we
did
touch
on
this
very
briefly,
I
believe.
In
the
last
column,
it
was
just
in
my
head
when
we
were
talking
about
the
parent
package
concept,
so
you
know
having
having
a
specifier
and
saying
I
inherit
my
package
json
from
the
manifest
at
this
particular
you
know
name
at
version
or
range
or
whatever.
If
we
do
that,
we
can
just
add
overrides
as
one
of
the
things
that
can
be
inherited.
D
A
C
I
have
not:
we've
been
pretty
head
down
heads
down
with
v7.
A
Yeah,
so
I
guess
you
could
also
wait.
Maybe
for
the
next
meeting
see,
if
is
back
right,
oh
and
thanks
to
whoever
is
taking
notes.
Yes,
I
do
need
someone
to
keep
up
the
notes
there.
Thank
you.
A
On
with
the
agenda,
there
is
the
rfc:
no,
it's
not
actually
an
rfc,
it's
one
of
the
issues
in
the
cli
repo
that
got
flagged
for
discussion,
which
is
the
npm
audit
app
id.
H
Yeah
that
one,
that
one
is
what
I
wanted
to
talk
about,
that
one's
me
just
in
case
didn't
link
the
my
name
to
the
right.
Yes,.
H
H
Yeah,
okay,
so
yeah,
so
I
mean,
like
I
said
in
the
introduction.
It
was
originally
a
colleague
of
mine
that
introduced
this,
so
I
mean
I
can
demonstrate
it
in
a
in
a
second,
if
you
like
as
well,
but
but
fundamentally
what
we
have
when
we
do
an
npm
audit.
H
So
we
actually
take
it
a
slightly
different
level.
So,
rather
than
just
reporting
vulnerabilities
like
npm
audit
does
we
can
do
policy,
which
is
on
a
per
application
basis.
So
it's
not
an
overriding
overarching
that
this
dependency
is
vulnerable.
It
can
be
tailored
to
each
individual
application.
H
So
the
idea,
basically
being
we
want
to
try
and
put
some
application
id
so
that
identifies
the
application
and
the
application
identifier
against
our
product.
So
when
somebody
does
an
npm
audit,
the
audit
will
be
based
against
the
application
specifically,
which
might
have
some
tailored
policy
evaluation.
H
Basically,
I
can
quickly
demonstrate
what
I've
got
so
far.
If
that
would
help,
maybe
explain
it
a
little
bit
better.
D
Yeah
sure
so
I've
been
I've
been
thinking
a
little
bit
about
this,
and
I
wonder
if
there
isn't
value
in
just
sending
the
original
package
jason
along
with
the
package
lock
in
the
audit,
because
there's
more
to
it
than
just
the
identifier
whatever
you
might
think
of
that,
I
think
that
audit
could
provide
some
extra
value
on
other
things
too.
So
so
I'm
writing
some
tooling.
That's
going
to
do
this
out
of
band
right
so
like
like.
I
want
to
do
like
linting
on
certain
configurations
right.
D
So
if
you
have
this
package,
and
this
and
and
you're
missing
an
npm
script
for
it
like
say,
you
wanted
react
scripts
and
somebody
accidentally
deletes
one
of
the
the
react
scripts
like
it
would
be
reasonable
to
say,
like
hey
you
set
up,
you
know,
create
react
app,
but
then,
like
somebody
must
have
deleted
one
of
the
important
lifecycle
scripts
to
run
it.
You
know.
D
Maybe
do
you
want
to
just
add
that
back
stuff
like
that
when
it's
tangentially
related
but-
and
it
also
might
not
be
something
that
npm
and
the
public
rarity
wants
to
provide
for
your
case
providing
a
as
a
you
know,
another
registry
proxy
there's
a
lot
of
added
value.
You
could
have
there.
We
also
run
a
registry
proxy
and
I'm
I'm
going
to
be
doing
stuff
in
the
client
side,
where
we're
already
doing
the
quick
audit.
A
D
H
Yeah,
I
did
actually
take
it.
I
mean
I
actually
listened
to
the
recording
from
from
last
time,
and
it
was
mentioned,
you
know,
it'd
be
useful
to
to
make
it
generic,
so
I
didn't
go
with
the
whole,
send
the
whole
package
json
across,
but
what
I
did.
I
added
a
a
metadata
object
to
the
package,
dot
json
and
it's
the
content
of
the
metadata
object
that
gets
sent.
H
A
Right
and.
H
C
C
So
npm
v6
sends
effectively
the
entire
packagelock
json
file.
It
does
some
redacting
of
a
bunch
of
things
and
actually
that
can
sometimes
cause
problems.
For
example,
if
you,
if
you
depend
on
a
git
fork,
it
will
redact
the
the
name
and
version
of
the
thing
that's
in
the
package
lock
json
tree,
which
makes
it
appear
to
be
an
invalid
tree,
because
now
one
of
your
depths
is
is
no
longer
met
right,
instead
of
depending
on
you
know,
tap
at
my
tap
fork.
It's
depending
on
this.
C
You
know
opaque,
you
would
string,
so
we
got
rid
of
that
and
as
well
the
the
audit
response
that
the
cly
sends
up.
What
it
expects
from
the
registry
is
the
the
the
full
list
of
like
remediation
actions
where
we
ran
into
with
npm
seven.
C
One
of
the
problems
we
ran
into
is
that
a
lot
of
those
remediation
actions
are
very
sort
of
npm
six
tree
specific,
and
so
they
they
didn't
actually
make
much
sense,
because
we
have
different
different
algorithms
that
we're
using
improved
algorithms
that
we're
using
for
tree
reification
and
for
depth
updates.
C
So
we
ended
up
having
to
do
all
of
these
remediations
client-side
anyway,
and
so
all
we
ever
send
is
the
quick
audit.
Even
when
you
run
npm
audit
or
npm
audit
fix,
we
took
that
a
step
further
and
realized.
Well,
the
the
data
that
we're
returning
from
the
audit
endpoint
we
throw
away
most
of
it
right
it.
C
Actually,
if
you
look
at
the
response
data,
it
actually
includes
the
full
markdown
text
of
the
of
every
advisory
and
the
the
impact
of
that
made
it
really
challenging
to
it
makes
it
really
challenging,
as
well
as
having
to
do
all
of
the
remediation
server
side,
makes
it
very
challenging
to
make
that
web
service
very
performant.
It's
it's
hard
to
cache.
C
It
requires
a
a
lot
of
computation,
there's
some
cases
where
you
can
totally
send
it
into
a
tailspin
and-
and
just
you
know,
basically,
that's
why
the
audit
service
every
once
in
a
while
just
starts
returning
503s.
So
the
where
we're
moving
to
is
a
much
much
more
streamlined
approach
where
effectively.
C
The
the
thing
that
we
send
up
is
a
just
a
an
object
that
has
the
the
key
is
a
package
name,
and
the
value
is
an
array
of
all
the
versions
that
show
up
in
your
tree
rather
than
the
full
tree
structure,
and
the
response
that
we
get
from
the
server
side
is
just
an
object
where
the
key
is
a
package
name,
and
the
value
is
an
array
of
some
sort
of
minified
advisory
bits.
C
So
they
each
advisory
object
just
contains
the
the
id
the
affected
range,
the
url
and
and
the
severity
level,
and
then
on
the
client.
We
actually
calculate
all
of
the
remediations
and
all
of
the
you
know.
Kind
of
meta
vulnerabilities
like
foo
is
effectively
vulnerable
because
it
depends
on
strictly
vulnerable
versions
of
bar
and
so
on,
and
that's
how
we
can
actually
do
a
more
kind
of
tightened
up
output
and
also
can
now
remediate
and
fix
entire
classes
of
problems
that
previously
npm
audit
would
just
kind
of
throw
its
hands
up
and
say.
C
What
this
means
for
the
context
of
this
conversation
is
yes,
we
can
absolutely
throw
a
you
know
a
metadata
object
in
there,
but
it
is
going
to
have
some
performance
impacts
and
get
us
back
into
that
direction
of,
like
you
know,
sending
a
lot
more
data
than
we
strictly
need
for
the
operation
that
we're
that
we're
doing
so
wes
for
some
of
your
applications
of
like
you
know,
oh
you,
you
depend
on
react
scripts,
but
your
your
prepare
script
is
gone.
C
Have
it
like
look
at
the
the
source
code
and
the
in
git
or
whatever,
and
and
run
its
calculations
there
sending
an
app
id
we
can
do
in
a
header,
and
it's
a
it's
a
very
small
identifier,
and
so,
if,
if
you
can
just
kind
of
link
that
and
save
that
somewhere
in
the
repo,
it
doesn't
kind
of
blow
up
the
data
that
we
need
to
send
back
and
forth.
C
But
now
all
that
being
said,
the
other
thing
is
if
we
wanted
to
start
using
these
advisories
for,
like
general
purpose,
you
know
app
specific
type
stuff,
not
just
ignore
this
advisory.
Don't
ignore
this
one,
or
this
should
actually
be
considered
critical
rather
than
low,
because
we
happen
to
be
hitting
that
case
or
whatever
using
it
for
things
like.
Oh,
you
know
this.
This
requires
that
you
have
a
script
or
you
know,
use
it
in
a
particular
way.
It's
not
really
set
up
for
that.
D
D
I
I
am
all
for
that.
If
we
go
that
route
today,
we
don't
even
offer
that
either
so
like
I
have
to
do
it
fully
out
of
band,
which
is
ask
my
users
to
install
my
package
and
run
my
package
in
all
of
these
scripts,
which
adds
overhead.
It's
not
bad
overhead.
It's
just
like
react
scripts,
for
example,
right
where,
like
what
I'm
doing
is
I'm
basically
saying
you
go
and
run
npm
install.
D
D
C
D
C
I
think
I
think
to
your
to
your
core
point
like
that
absolutely
makes
sense.
I
don't
think
this
is
the
particular
vector
to
to
add
that
kind
of
functionality,
but
I
I
think
it's
valuable
and
I
think
it's
something
we
should
absolutely
explore,
and
you
know
we
we
hit
that
ourselves
right.
We
and
the
npm
client
itself
has
a
pretty
long
script
lock,
and
some
of
our
internal
apps
are
just
kind
of
absurd.
C
The
for
the
purposes
of
like
audit
app
id,
I
think
just
sending
it
as
a
header
and
letting
the
server
sort
of
use
that
or
ignore
it
as
it
wishes,
is
kind
of
the
best
thing
for
our
users.
There's
really
no
obstacle
that
I
can
see
to
ratifying
and
implementing
this
this
particular
rfc.
It's
just
sort
of
typing.
C
Either
one
really
I
yeah
I
haven't,
haven't
fully
explored
it
and
when
we
kind
of
get
to
that
in
the
development
agenda,
I'm
sure
we'll.
When
we
get
down
to
that
kind
of
point
in
the
backlog,
we
may
have
more
more
feedback,
but
I
think
either
one
is
probably
fine.
It's
sort
of
it's
sort
of
a
bike
shed
about.
C
You
know
whether
it's
like
what
the
actual
spelling
of
the
header
and
the
the
position
of
it
is
putting
it
in
the
in
the
body
of
the
request
is
not
ideal
because
it
increases
the.
It
makes
it
a
little
bit
more
challenging
for
us
to
just
cache
the
the
responses
that
we
give.
H
A
A
Yeah
and
continue,
I
mean
as
a
commenting
that
rfc
and
the
following
up,
because
it's
from
a
different
author
right,
it's
not
from
you
mark
correct.
It's.
A
So
you
can
definitely
sync
and
yeah,
but
yeah,
maybe
maybe
just
follow
up
with
up
here
a
comment
there
and
and
then
maybe
you
can
rewrite.
I
don't
know.
Yeah
okay
sounds
good.
C
Yeah,
we
don't
usually
hang
too
much
on
ceremony
when
it
comes
to
actually
like
implementing
and
ratifying
rfc.
So
the
purpose
is
to
get
a
good
final
product.
So
you
know,
if
that's
on
us
to
edit
it
before
we
kind
of
move
it
into
the
accepted,
folder
or
implemented
folder,
then
I
don't
don't
feel
like
you
need
to.
H
File
all
the
proper
forms
sure
yeah.
I
can
go
on
to
that
this
week
and
yeah
I'll
get
a
pr
submitted
against
the
rfc.
A
Cool
cool
awesome
yeah.
So,
let's
move
on
to
the
next
item
over
here
it
is
from.
I
think
it
is
a
pull
request.
I'm
not
sure
it's
a
ready
or
it's
just
a
draft,
but
it's
a
poor
request
in
the
cly,
I
think,
proposing
a
new
security
pipeline.
A
I
It
a
little
bit
basically
this
this
is
coming
from
a
school
project.
Basically,
we
were
looking
at
the
evolution
of
devops
into
including
security,
so
dev
secure
ops,
and
in
doing
that,
we
decided
to
look
at
the
the
npm
project
itself,
because
we
all
typically
use
it
if
not
daily,
almost
daily
each.
So
we
looked
at
that
looked
at
what
the
existing
pipeline
was
and
what
tools
were
available
that
could
help
us
add
some
security
into
it.
I
So
we
added
the
npm
audit
into
the
actual
pipeline
using
npm
itself
to
do
an
audit
in
the
pipeline
just
to
make
sure
that
there
wasn't
any
known
issues
within
within
the
stuff
that
or
the
packages
that
you
guys
were
using.
I
So
we've
actually
spoken
up
into
separate
ones,
we're
doing
a
production
run
at
the
lower
end
of
the.
I
think
they
did
it
on
moderate
or
low
to
fail.
Then,
when
on
the
dev
ones,
I
moved
it
up
to
high.
I
Now
that
we
can
talk
about
you
know
if
we
still
want
to
do
it
on
what's
the
right
level
there.
I
did
it
at
those
levels
because
that
to
get
the
pipeline
to
pass,
when
I
was
writing
it,
it
had
to
be
at
those
levels.
I
I
So
we
added
that
in
there
and
surprisingly
or
surprisingly
or
not,
there
was
no
issues
found
in
the
tauli
thing,
which
was,
I
think
great,
looks
like
a
pretty
dry
code.
I
Then
we
also
added
a
dependabot
in
there
which
dependable,
I
don't
know
if
you
guys
have
looked
at
or
used
it
it'll
actually
create
mrs
on
individual
packages
within
the
json
to
keep
those
updated
that
one
was
in
there
again
up
for
discussion
on.
If
you
even
would
want
to
use
the
the
panda
bot,
but
that's
basically
where
that
came
from.
C
Awesome
yeah,
I'm
good.
I
mean
these
are
all
kind
of
changes
to
the
just
to
sort
of
the
npm
project,
not
not
really
like
the
npm
product
that
we're
shipping
that
right.
I
It's
in
the
pipeline
itself,
so
whenever
you
create
an
mr,
it
would
run
these
npm
audit
on
it
and
fail
or
pass
the
pipeline
depending
on
what
the
audit
says
or
whatever
what
how
they
would
come
back
with.
C
Right
right,
but
this
is
when
you,
when
you,
create
a
pull
request
on
like
npm
cli,
correct,
yes,
okay
yeah,
I
think
we
had
talked
about
moving
to
dependable.
We
do.
We
do
use
it
on
a
handful
of
other
repos
within
within
the
npm
project,
and
obviously
it's
used
very
widely
at
github.
C
I
think
the
the
pushback
that
we
had
for
doing
it
right
now
is
that
we
actually
do
have
like
a
bunch
of
known
things
that
we
need
to
go
through
and
and
either
yank
out
or
or
update,
and
but
I
think,
once
we
get
to
a
more
sort
of
stable
state.
It'll
it'll
make
sense
like
right
now
we
have
a
bunch
of
known
known
advisories
that
we
just
can't
fix
without
sort
of
replacing
a
module
or
updating
something
deep
in
the
vowels
of
nodejib.
I
Yeah,
I
did
notice
that
one
because
I
have
been
running
on
a
cli
fork
of
mine
and
it
was
creating
a
major
update
packages
from
like
three
to
version.
Eight
yeah.
It's
not
it's
kind
of
scary.
C
Yeah,
so
in
the
in
in
the
release,
slash
beta
7,
I
don't
know
if
this
is,
if
that's
where
you
had
based
this
this
pr
originally,
but
oh,
no
okay,
so
this
is
based
on
latest
yeah
latest
is
about
to
be
moved
to
a
kind
of
deprecated
legacy,
not
deprecated,
but
a
legacy
kind
of
state
and
once
v7
goes
to
ga.
So
I
would
actually
recommend
doing
this
against
the
npm
v7.
C
It's
release,
slash
v7.0.0-beta
branch
and
it
it
will
probably
still
find
some
problems
and
there's
some
some
that
we
know
about.
So
we
may
put
off
merging
it
until
we,
you
know,
are
not
going
to
get
spammed
by
it
unusefully,
but
then
it
it
won't
be
trying
to
update
from
you
know,
version
three
to
eight
yeah.
I
Okay,
yeah:
I
can
go
ahead
and
update
that
cool.
A
That's
great
yeah,
thank
you,
jason
for
putting
that
together,
so
yeah.
I
think
we're
definitely
gonna
be
able
to
follow
up
with
that
after
the
b7
is
more
stable.
So
thank
you
so
much
yeah.
Let's
move
on
to
the
next
item
over
here,
which
is
the
rrfc
from
miles
on
npm,
run
series
from
parallel
yeah
miles.
If
you
did,
you
want
to
follow
up
from
last
week.
L
Yeah,
I
don't
honestly,
we
can
probably
move
on
to
the
next
item.
We
didn't
really
like.
We
talked
about
this
in
the
last
meeting.
I
think
some
good
points
were
brought
up.
As
far
as
I
know,
there
wasn't
any
more
discussion
that
happened
in
the
issue
around
it,
so
I
guess
I
guess
maybe
for
now-
and
you
all
could
tell
me
the
best
process
here.
Maybe
we
could
just
remove
it
from
the
agenda
until
we
have
something
a
little
bit
more
practical
or
specific
to
discuss.
L
I
know
that
there
were
concerns
about
like
the
scope
of
this
and
that,
like
series
seemed
to
be
a
little
bit
cleaner
than
parallel,
but
there
was
actually
like
also
a
bit
of
a
version
to
like
hey.
Do
we
want
to
complicate
the
script
running
process
of
npm
at
all?
So
I
guess
like
one
thing
that
could
be
good
to
know
before
removing
the
agenda
item
agenda
label,
which
I
think
we
should
do
today
anyways
is
like.
L
I
could
see
a
world
where
we
just
drop
parallel
for
right
now
and
just
look
at
series
and
it's
like
an
easy
way
of
running
multiple
things
in
series
in
a
platform
agnostic
way,
but
if
folks
are
kind
of
feeling
like.
Maybe
this
is
out
of
scope,
then
or
like
just
not
worth
prioritizing
right
now.
Maybe
it
should
just
be
close.
I'm
kind
of
flexible
on
both
but
a
fairly
full
dance
card,
as
it
is.
C
Yeah,
I'm
okay
with
removing
it
from
the
agenda,
but
we
should
keep
it
open.
I
think
it's
a
it's
a
worthwhile
use
case,
which
has
certainly
come
up
a
few
times
over
the
years.
It's
not
like
a
super
super
pressing
thing.
Most
people
end
up
just
sort
of
writing
a
shell
script
and
going
on
with
their
lives,
but
it
would
be
nice
to
have
a
better
kind
of
a
better
answer
to
that.
E
Yeah,
I
just
wanted
to
support
that.
I
mean
you
basically
said
you
wanted
to
well.
How
do
I
put
this
focus
on
exit
codes,
especially
in
parallel?
However,
if
I
think
parallel
would
even
be
useful
if
it
would
not
allow
that,
for
example,
if
you
ran,
I
don't
know
sas
and
webpack
at
the
same
time
or
the
type
compiler.
At
the
same
time,
if
you
had
like
some
kind
of
watch
command,
I
could
definitely
see
that
it
would
be
useful.
E
So
even
in
like
it's
its
simplest
form.
A
L
A
Yep
great
all
right,
so,
let's
move
on
to
the
next
item.
I
see
we
have
here
the
rfc
from
lucas
the
ability
to
skip
script.
C
Hooks
yeah,
we
we
discussed
this
last
time.
I
think
where
we
landed,
was
let's
just
go
ahead
and
do
it
the
using
a
different
name
rather
than
ignore
scripts,
but
to
be
something
like
ignore
hooks
or
ignore
pre
or
whatever
just
seemed
a
little
more
complicated
than
it
was
worth,
certainly
ignoring
your
ignoring
the
entire
command
that
you
just
executed
like
doing
nothing
when
you
run
npm
test
dash
dash
ignore
scripts,
that's
not
good
and
running
pre
and
post
test
scripts
in
that
case
is
also
confusing.
C
It
kind
of
swung
all
the
way
to
the
other
side
of
the
spectrum,
and
the
suggestion
in
this
rc
is
is
perfectly
reasonable,
so
and
very
little
code
and
easy
to
do
so.
I'm
going
to
move
this
to
accepted
today.
K
Right,
I
think
I
think
lucas
had
something
to
say.
Oh
sorry,
sorry,
I'm
I'm
just
happy
that
the
cli
is
going
to
work
as
I
expect
it
to
do
soon.
So
just
just
yeah,
avoiding
my
agreement
and
happiness,
cool.
A
All
right
isaac,
I
see
there's
another
one
here.
I
think
it
might
be
ratified
already,
I'm
not
sure,
but
the
rfc
21
bring
back
subset
of
npm
package
environment
variables.
C
Yeah,
so
this
is
actually,
I
believe
it's
I
believe
we
ratified
it,
and
it's
also.
If
we
didn't
know,
I
guess
we
didn't
ratify
it,
we
didn't
merge
the
pr.
No,
we
did.
No,
we
merged
the
implementation.
Okay,
so
the
pr
still
needs
to
get
merged.
I
will
get
on
that
this
afternoon,
but
in
the
latest
npm
v7
beta.
It's
it's
actually
implemented,
as
suggested
in
this
change.
Essentially,
what
this
is
is
there
was
a
you
know.
We
kind
of.
C
Went
too
far
in
reducing
package
install
scripts?
Previously
it
was,
I
mean
it
was
absurd.
It
was
sending
putting
everything
that
was
anywhere
in
your
package.json
or
any
configs,
and
now
it
just
does
the
non-default
configs
and
a
handful
of
like
commonly
used
package
environment
variables.
C
So
you
know
you
can
still
get
the
name
version,
config
engines
main
and
bin.
C
A
Great
right
so
next
item
on
the
agenda
is
the
npm
audit
licenses
rfc
from
tierney
yeah.
N
You
wanna
so
similar
to
similar
to
miles.
I
think
the
biggest
thing
I'm
looking
for
right
now
is
just
more
feedback.
I
realized
that,
like
we
weren't,
really
capturing
the
context
that
was
being
shared
on
the
last
or
the
meeting
we
talked
about
it.
So
if
folks
could
share
some
of
that
context,
like
their
written
context
of
what
they'd
like
to
see
in
it
that'd
be
great.
I've
had
a
couple
pieces
of
feedback
of
like
well.
N
No,
we
should
do
this
or
this
with
no
like
consensus
or
agreement
really
on
those.
So
I'm
happy
to
do
whatever
like
take
whatever
path.
We
want
to
take
just
getting
that
feedback,
so
I
can
like
in
writing,
because
I'm
not
going
to
be
able
to
do
it
well
with
with
like
vocal
feedback
getting
that
feedback
in
writing.
That
would
be
super
helpful.
C
C
The
only
thing
tony,
I
wonder,
if
have
you
have
you
interacted
with
at
all
the
the
licensee
project.
N
I
I
have
not
I
it
has
been
pointed
out
to
me
both
when
I
initially
said
I
was
gonna.
Do
this
a
former
npm
employee
said
it
might
be
easy
to
just
use
licensee,
because
that's
what
npm
already
uses,
and
also
that
was
one
of
the
recommendations
in
the
actual
thing-
was
to
use
the
licensee
format
so
yeah.
I
think.
C
I
mean
the
the
reason
why
I
suggested
is
like
getting
into
the
getting
into
the
business
of
you
know:
parsing
speedic
result
speedix
results
and
keeping
up
with
all
of
those
updates
and
everything
else.
It's
it
can
be
pretty
challenging,
and
I
know
you
know.
Kyle
mitchell
has
been
doing
that
that
particular
type
of
work
for
his
most
of
his
legal
career.
So.
A
N
C
Yeah,
oh,
I
was
just
saying
it
would
be
good
to
align
with
that
data
format
and
you
know
maybe
take
a
similar
kind
of
approach,
but
then
just
use
that,
as
part
of
the
part
of
the
thing
that
we
audit.
N
A
N
A
Awesome,
okay,
so
last
item
in
the
agenda:
it's
the
rfc
for
parent
package
jason.
I
know
we
discussed
a
lot
about
it
next
time
at
the
christian
yeah.
I
don't
remember
well
where
we
landed
on
it
last
time.
E
Actually,
I
just
tried
to
yeah
munch
all
the
feedback
into
the
rfc,
so
if
anyone
feels
like
giving
it
a
read,
feel
free
and
leave
a
comment,
I
would
not
have
anything
more
to
add
to
that
at
the
moment.
I
would
think.
L
I
guess
a
quick
question
is
more
of
a
clarifying
question
just
because
I'm
not
really
familiar
with
this
rfc
when
you're
talking
about
like
parent
package,
so
we're
talking
about
like
essentially
like
symbolic
references
across
the
package.
Json
so
like
one
could
consume
information
from
its
parent.
E
Yeah,
so
the
idea
basically
was
to
start
to
inherent
actually
dependencies
and
scripts
and
then
what
I
also
learned
today,
probably
overrides
and
yeah
kinda-
put
them
all
together
during
npm
pack,
so
that
the
client
basically
doesn't
even
know
that
the
the
package
at
one
point
at
one
point,
was
inherited
for
performance
reasons.
L
Okay,
I
mean
this
is
not
exactly
identical,
but
I
was
talking
to
michael
rogers
yesterday
about
some
work
that
he's
doing
on
like
transpilation
tools
and
one
of
the
things
that
he's
working
on
is
like
a
tool.
So
you
can
write
your
whole
project
in
esm
and
then
it
creates
a
disk
folder.
It
copies
all
the
esm
and
everything
in
there.
It
transpiles
all
of
that
esm
to
common
js,
and
then
it
generates
the
package
json.
L
That
has
the
references
to
everything,
and
then
you
publish
out
of
that
disk
folder
other
than
rather
than
the
root.
The
reason
I
mentioned
this
is
because
it
seems
like
what
you're
talking
about
is
possibly
somewhat
similar.
Where,
like
you,
would
have
some
kind
of
like
post-processing
that
would
like.
Maybe
there
would
be
like
some
way
of
referencing
this
stuff
in
the
package
json,
but
the
package
json
that
was
in
your
root,
wouldn't
necessarily
be
like
what
goes
out
with
the
published
assets
and
at
a
high
level.
L
I
guess
like
one
of
the
things
that
I
that
I
think
about
here
is
like
from
a
platform
perspective,
how
much
of
it
needs
like
direct
platform
support
versus
how
much
of
this
is
something
that
can
be
like
a
framework
or
tool
sitting
on
top
of
the
platform.
And
again
I
say
that
as
someone
who
doesn't
really
totally
understand
it.
So
I
guess
like
to
turn
all
those
statements
into
a
question.
L
Are
there
things
about
the
proposal
that
like
explicitly
require
like
first
class
support
by
npm
and
then
in
turn
like
how
would
that
affect
the
integration
into
like
the
node
runtime
and
other
tools,
that
kind
of
bootstrap
off
of
the
package.json
artifact?
Because
that's
one
of
the
places
where
I've
seen
things
get
a
little
airy.
C
It
really
should
not
require
any
changes
to
node
or
any
kind
of
support
from
node.
The
the
only
thing
that
it
would
be
affecting
is
the
sort
of
the
effective
dependencies
at,
and
you
know,
overrides
and
like
the
things
that
npm
will
use
to
or
to
like
resolve
and
manage
the
package
tree.
C
So
when
we
read
the
root
package,
json
we'll
have
to
do
this
extra
processing
step
if
it
has
a
parent
and
when
we
pack
or
publish
the
current
project,
then
we'll
sort
of
flatten
that
that
dependency
and
and
put
the
resulting
manifest
in
the
package.
Artifact.
A
A
L
A
I
do
wonder
if
that
gets
like,
if
you
wanted
to
inherit
these
keys
from
a
parent
project
like
how
that
would
work.
C
C
And
especially
since
one
of
the
things
that
we've
talked
about
wanting
to
inherit
is
your
your
set
of
scripts
right,
that's
sort
of
the
main
thing
I
have
a
project,
I
have
a
folder
full
of
projects
and
I
don't
want
to
have
to
put
the
same
exact.
You
know
lint
and
test
and
pre-publish
and
everything
else
script
in
each
one,
so
we
are
and
same
with
dependencies,
dev
dependencies
and
so
on.
So
like
it's,
not
as
simple
as
just
saying.
Oh,
this
you
know
manifest.proto
equals
parent
manifest.
H
E
E
Through
further
rfcs,
or
even
while
ratifying
it,
I
just
like
to
narrow
down
the
scope
a
little
bit.
Otherwise,
it
just
becomes
a
big
balloon
that
nobody
can
control.
H
Cool
thanks,
yeah.
I
was
just
just
curious
on
the
the
the
dependencies
approach
and
you
know.
Typically,
we
use
scripts
that
will
just
pass
the
package.json
to
find
dependencies
and
then
do
things
on
it.
It
sounds
like
you
might
need
to
start
reconsidering
or
have
ways
of
getting
all
dependencies
if
they're
coming
from
parents
as
well.
C
Yeah,
so
there's
there's
certainly
going
to
be
some
impact
for
other
tooling.
I
think
this
is
sort
of
like
node
might
not
be
one
of
those
things
that
has
this
impact,
but
you
know
other
things
that
look
at
package.json
to
see.
C
What
you
depend
on
will
have
to
do
this,
this
inheritance
and
implement
it
as
well
or
they'll
have
to
just
ask
npm
for
it
somehow,
so
you
know
it's
an
another
way
that
we
could
potentially
get
there
is
we
have
a
is
to
actually
which
I
just
was
thinking
about
the
other
day.
We
can
actually
have
a
second
like
a
a
separate
file
alongside
package.json,
which
specifies
the
parentage
and
anything
that
I'm
overriding
from
the
parent
and
then
npm
will
generate
that
package.json
file.
C
You
know
whenever
it
whenever
it
needs
to
a
flattened
version
of
the
whole
thing
you
mean
yeah,
so
the
thing
that's
actually
called
spelled
you
know,
package.json
will
be.
The
flat
will
always
be
the
flattened
version,
the
last
time
that
npm
resolved
it.
But
we'll
you
know
anytime.
We
see
this
sort
of
package
source.json,
we'll
process
it
and
munch
it
and
write
out
to
package.json.
A
I
see
you
have
your
hammer.
D
A
Yeah
yeah,
I
think
wes.
If
you
want
to
drop
a
message
in
the
chat,
it's
going
to
be
better
because
we
can
hear
you
at
all,
but
jordan
is,
do
you
also
have
raise
your
hand.
G
Yeah
I
just
I
wanted
to
like
echo
the
I
mean
so
one
of
the
packages
I
maintain
is
resolve
and
any
changes
like
this,
this
package,
json
parent
thing,
will
would
be
a
massive
impact
to
it,
and
even
if
npm
provided
like
a
nice
api,
that
gave
me
like
a
promise
for
the
full
package
data
or
something
like
that,
would
still
be
a
lot
of
work
to
implement,
especially
because
resolve
also
has
a
synchronous
api.
G
So
it
would
need
to
synchronously
determine
this
since
the
parent.
If
the
parent
was
over
the
network,
that
would
be
a
big
problem.
So
I
think
I
really
like
the
suggestion
of
saying.
Package.Json
is
always
static,
but
npm
may
have
a
new
way
to
generate
it
from
a
different
file.
That
seems
like
it
kind
of
sidesteps
a
lot
of
issues
and
avoids
dumping
a
massive
amount
of
burden
onto
the
ecosystem.
L
And
for
what
it's
worth,
that
was
more
the
correlation
that
I
was
thinking
about
in
regards
to
michael's
work.
It
was
more
about
the
idea
that,
like
the
package
json,
that's
like
afterward
of
your
file
is
no
longer
necessarily
the
package.
Json
that's
getting
published
and
there
might
be
some
dynamicism,
but
all
of
that
ends
up
being
like
resolved
prior
to
publish.
C
Great,
can
you
jordan,
can
you
make
that
suggestion
in
in
the
rfc
I'll
take
the
discussion
there?
A
Awesome:
okay:
we
have
just
two
minutes
left
if
anyone
have
any
announcement
any
last
licks
yeah.
A
Well,
if
not,
thank
you
all
so
much
for
showing
up
and
see
you
all
again
next
week
see
you
next
week,
bye.