►
From YouTube: Open RFC Meeting - Wednesday, July 22nd 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting 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
Awesome
and
we're
live
with
another
npm
open
rc
call.
Today's
date
is
july,
the
22nd
wednesday
july
22nd,
and
I'm
just
going
to
again
copy
and
paste
for
anybody
that
might
have
shown
up
late.
The
hackmd
dock
feel
free
to
add
yourself
to
the
attendees
list
and
we'll
be
following
all
along
the
agenda
that
was
posted
in.
I
think
it
was
issue
160,
but
that's
copied
here
in
the
hackmd
dock
as
well.
A
A
Please
raise
your
hand
if
you
have
any
comments
and
I'll
call
on
you
and
just
yeah
just
be
thoughtful
with
people
as
as
we
discuss
the
contents
of
the
rc's
and
again
just
to
outline
sort
of
the
desired
outcomes
of
this
call
is,
is
to
work
closely
with
community
and
provide
another
channel
for
us
to
essentially
discuss
the
work
in
progress
and
the
rfc
is
being
proposed
to
to
change
and
update
and
improve
the
functionality
of
npm.
A
Is
there
any
announcements
that
we
have
anybody
on?
The
call
that
want
to
bring
up.
A
If
not,
we
can
dive
right
into
the
first
pr,
so
pr
165,
so
this
is-
was
brought
up.
I
think
last
week,
christian
you're
able
to
join
this
is
the
rfc
for
parent
package
apparent
in
package.json,
which
I
think
we
sort
of
discussed
a
little
bit
and
isaac.
I
think
left
a
few
comments
on,
but
would
love.
If
you
could
maybe
go
into
a
bit
of
detail
about
this.
I
think
he
actually
just
dropped.
A
B
Hey
yeah,
sorry
about
that
that
I
don't
know,
I
just
wanted
to
get
rid
of
a
pop-up,
and
then
that
happened.
A
Apologies,
I
was
just
saying
like:
maybe
you
could
give
us
a
little
bit
of
detail
into
what
what
this
is
and
then
we
can
discuss
it.
A
bit.
B
So
what
this
is
is
basically
trying
to
solve
a
problem
that
we
were
having
at
work,
which
is
basically
that
we
have
lots
of
single
page
applications
which
are
all
their
own
npm
packages,
and
they
all
share
the
same
architecture
though
so
they
share
a
lot
of
dependencies.
They
all
share
the
same
office.
They
shared
the
same
scripts.
They
even.
B
Share
the
same
license
and
we
at
the
moment
we
use
learner
to
to
have
a
workspace
feature,
because
npm
7
is
not
yet
live,
and
when
we
built
them
in
a
continuous
integration
environment,
we
want
to
have
them
separate
because
they
are
like
separate
dependencies
and,
and
they
actually
also
separate
git
repositories.
B
So
hoisting
packages,
like
you
would
generally
do
in
like
in
a
workspace
environment,
is
not
really
an
option
for
us,
because
we
felt
that
would
break
the
separation
that
we
wanted
to
achieve,
and
also
we
had
the
java
back
and
guys
kind
of
pushing
us
to
follow
their
route.
B
Their
route,
which
is
kinda
using
like
a
maven
parent
pom,
and
to
just
like,
define
all
the
dependencies
once
and
then
just
use
them
in
like
any
subsequent
packages,
because,
like
you,
try
to
achieve
uniformity
wherever
possible,
and
so
I
kind
of
just
took
a
an
afternoon
when
I
was
home
early
from
work,
and
I
just
kind
of
ripped
it
together
how
I
could
feel
that
might
work
in
npm.
B
So
I
am
by
no
means
saying
that
any
of
what
I've
written
is
any
good.
It's
just
meant
to
be
really
a
conversation
starter
and,
if
any
of
you
just
says
like
this
is
going
into
the
completely
wrong
direction,
I
have
a
absolutely
better
idea,
I'm
absolutely
going
to
take
it.
A
For
sure
I
think
zbu
ever
add
up,
did
you
want
to
weigh
in.
C
If
you
run
npm
install
it's
gonna,
do
all
the
sim
links
and
everything
to
make
it
work
or
it
might
get
you
in
trouble
with
some
cases
of
node
usage
where
node
wouldn't
go
to
a
parent
folder.
I
remember
I
tried
multiple
variants
of
that
a
while
back
and
while
a
bit
little
bit
annoying,
it
can
be
done
for
a
front-end
project.
Definitely
that's
that's
all
I
wanted
to
add
so
maybe
a
temporary
solution
that
we
can
start
with.
A
So
christian,
if
you'd
like
to
respond
to
that
and
then
I
think
west
and
then
order
yeah.
B
B
I'm
I'm
definitely
not
certain,
but
I'm
not
ruling
that
out
either.
I
would
have
to
look
into
that
for
sure.
A
Yeah,
I
think
it
only
solves
for
for
part
of
what
you're
speaking
to
because
you
also
had
it
seemed
like
you
had
licensing
and
you
had
a
whole
bunch
of
other,
like
props,
that
you're
trying
to
to
mimic
across
all
these
all
these
projects.
What's
it
if
you
want
to.
D
Yeah
that
was
part
of
what
I
was
gonna
say
is
the
dependencies
is
one
small
facet
of
this
problem,
but
I
think
there's
a
lot
of
other
good
prior
art
out.
There
look
at
create
the
react
scripts
package,
trying
to
do
a
hybrid
that
you
can
extend
from
that
has
a
bunch
of
script,
definitions
that
you
want
in
every
create
react
app
package
right.
So
I
think,
there's
a
lot
of
really
good
reason
to
have
a
feature
to
solve
this
type
of
problem.
D
Where
do
you
find
the
package
to
extend?
Do
we
need
to
support?
Do
we
need
to
unpack
the
tar
balls
and
do
the
thing
before
we
like,
like
there's
just
a
bunch
of
technical
details
that
make
this
approach
hard,
not
to
say
that
it's
not
good
and
again
we
have
a
lot
of
clear
precedence
where
I
think
we
need
to
come
up
with
a
solution.
D
I
think
this
one
might
be
prohibitively
difficult
and
I
do
not
have
a
good
answer.
I
just
look
at
the
complexity
here
and
think
wow.
Imagine
if
you
download
a
package
and
it
says,
extends
and
then
that
one
extends
something
and
then
the
other
one
extends
something
and
now
you're
like
nested
and
what
you
know
what
precedence
do
the
license
field
take
like
obviously
there's
you
know
just
the
hierarchy,
but
then
you
look
at.
D
Do
you
deeply
nest
things
right,
because
it's
just
a
json
object
so
like
scripts
and
then
we've
got
repositories
and
like
you
know,
then
we
say
we
add,
like
the
supports.
It
really
is
exactly
yes,
it
is.
It
is
exactly
that
so
anyway,
that
was.
That
was
all.
It
is
a
deeper
problem,
but
it
is
a
real
problem
and
I
think
we
should
consider
you
know.
D
E
Yeah,
so
the
extends
has
like
typescript
actually
has
this
exact
feature.
That
is
how
typescript
can
handle
you
know
you,
you
reusing
someone
else's
config,
so
you
can
use
that
as
a
reference
for
someone
else,
that's
doing
the
same
thing
but
of
course,
typescript
everything's
already
available
for
you
locally
on
the
file
system,
so
it's
cheap
to
do
lookups
and,
on
the
other,
like
the
actual
root
of
your
problem,
around
the
ideas
of
like
isolated
dependencies
as
a
part
of
workspaces
in
yarn.
E
That's
actually
a
feature
of
it
where
you
can
just
say,
like
you
can
just
script
where
each
one
is
isolated
as
you
go
through
the
packages
and
it
would
do
a
dependency
result
for
each
one
in
there.
So
that
could
be
a
feature
that
could
get
added
to
npm's
workspaces
too.
A
Yeah,
that's
a
good
point
for
order
isaac.
I
know
you
had
your
hand
up
apologize.
You
can't
do
that
in
a
more
official
capacity
feel
free
to
wait.
F
I'm,
I
am
totally
fine,
with
my
unofficial
hand,
raising
yeah,
so
I
think
you
know
if
we,
if
we
carve
back,
you,
know
kind
of
kind
of
carve
down
the
the
scope
a
little
bit
of
this
rfc.
I
think
that
we
could
actually
get
to
something
that
that
solves
the
use
cases
that
that
christian
and
westbrook
both
brought
up.
F
So
imagine
this,
like,
let's
say
your
your
extends
field
in
package.json-
has
to
refer
to
a
specific
package.json
file,
so
that
can
be
either
file
colon
some
path
or
that
can
be
https
colon,
some
some
url,
that
that
gets
us
out
of
the
situation
where
we
have
to
like
unpack
a
tarball
and
then
you
know,
look
at
its
package
json
and
it
might
have
extends
and
whatever
else
the
other.
F
The
other
piece
that
I
would
add
to
this
is
to
is
to
stipulate
that
the
package
json
that
goes
into
a
packed
tarball
is
always
fully
extended
and
resolved.
So
there's,
no!
So
there's
no
package
json
extension
at
install
time,
and
if
we
do
that,
then
that
also
covers
the
case
where
you're
going
to
have
a
bunch
of
these
in
node
modules.
F
F
So
if
we
add,
if
we
add
kind
of
those
three
guard
rails
around
it,
then
the
implementation
becomes
a
lot
simpler.
We
we
already
have
two
two
different
libraries
for
readingpackage.json.
One
is
called
read:
package
json.
The
other
is
called
read
package
json
fast.
F
F
So
if
we
have,
if
we
just
kind
of
add
the
extension
into
read
package
json,
but
not
into
read
package
json
fast,
then
we
don't
even
have
to
worry
about
it
for
installs
or
or
reading
the
the
actual
tree
right,
because
it's
it
can
never
be.
There
can
never
be
an
extension
in
there
and
that
keeps
us
out
of
kind
of
some
of
the
more
abusively
slow
performance
issues.
The
the
other
piece
of
this.
F
In
order
to
make
that
the
case
we
we
do
have
to
munge
the
package.json
as
it's
being
put
in
the
tarball,
and
so
this
does
add
the
the
caveat
that
if
you're
using
extends
and
you
pack
a
tarball
and
then
you
change
nothing
about
your
current
working
directory.
But
the
extended
package
json
changed
and
you
pack
a
tarball
again,
then
you
will
get
different
bits
in
the
tarball
like
because
it
refetched
it
and
you
know,
got
new
extension
values.
F
A
I
agree
with
that
implementation,
so
the
one
thing
I'd
be
mindful
of
is,
if
there's
any
prior
art
for
extends,
if
anybody
else
is
already
using
it,
if
we're
going
to
essentially
make
this
a
like
a
not
allowed.
F
Yeah
we'd
have
to
do
a
little
bit
of
research
just
to
make
sure
it's
safe.
To
spell
it
that
way,
but
you
know
conceptually,
I
think
I
think
those
are
the
things
that
would
have
to
kind
of
be
added
to
make
this
feasible.
Okay,.
A
So
that's
good
to
note
order
says
it's
also
used
in
ts,
config
json.
So
is
there
a
lot
of
overlap
in
ts,
config
json
with
package.json,
though
okay,
so
yeah.
F
A
So
so
the
two
things
that
you
bring
up-
isaac,
one
it
has
to
be
fully
resolved
before
packing
and
then
the
extends
value
would
have
to
be
like
a
file
path.
Is
that
right,
file
path
or.
F
B
B
However,
I
think
you
could
just
could
you
just
put
like
one
dependency
which
which
kinda
has
the
json
that
you
extend
and
then
because
otherwise,
you
couldn't
version
it
right.
F
Right
use
an
unpackage
url
or
a
raw.github.com
raw.githubusercontent.com
or
whatever
url
like
there's,
there's
plenty
of
ways
to
put
some
json
text
on
the
internet
right.
We
can
certainly
certainly
do
that
a
lot,
but
I
think
extend
package
at
1.0.0
is
a
little
bit
more
hairy
right
because.
F
If
we,
if
we
allow
you
to
pass
in
a
package
specifier
like
a
dependency
specifier,
then
I
would
imagine,
as
a
user,
that
I
can
do
package
at
one.x
as
the
extend
value.
I
would
also
imagine
that
I
could
do
package
at
github,
colon
foo,
slash
bar.
D
So
I
I
was
agreeing
with
you
until
that.
I
I
think
that's
a
reasonable
limit
to
saying
you
can
only
do
registry
specs,
because
that's
the
easy
one
to
know
right.
That's
the
immutable
one!
That's
the
right
that
has
a
bunch
of
controls
around
it
which
give
us
predictability
and
safety
that
something
like
a
git
url.
D
Doesn't
I
I
you
know.
I
guess
I
understand
where
you're
coming
from,
but
I
I'm
just
like
I'm
working
on
getting
rid
of
all
get
based
dependency
declarations
anyway
in
everything
that
I
touch
so
like
to
me.
That's
just
like
delete
it
from
npm
and
I'm
happy.
So
if
we
add
new
features
that
don't
support
it,
I'm
also
happy,
but
you
know
maybe
I'm
alone
in
that.
F
I
I
now
I
now
work
for
a
company
with
a
pretty
big
vested
interest
in
people
using
git
for
a
lot
of
things
so
moving
it
entirely
is
probably
not
a
great
idea,
but
no
we
I'm
it's
a
little
tongue-in-cheek.
I
I
think
I
think
I'm
kind
of
with
you
like
it
just
feels
like
a
like
an
inelegant
restriction
to
say
it
can
be
a
package
specifier,
but
only
this
kind
of
package
specifier
and
I
want
to
avoid
having
picoche
as
a
dependency
of
read
package.
F
Json
right
like
fetching
a
url
is
something
I
can
do
inline
really
easily
and
it's
much
more.
The
question
is
like:
should
it
be
a
reference
to
a
package
or
should
it
be
a
reference
to
a
file,
and
I
think
that's
kind
of
the.
D
D
Here
so
if
you
have
it
so
say
you
say
you
just
started
from
a
place
where
you
say
I
have
a
package
already,
so
the
feature
doesn't
exist
right
and
people
are
hacking.
It
together
on
their
own
and
they've,
got
a
package
that
is
like
already
published
and
it's
like
their
root
thing,
and
they
then
want
to
now
make
a
new
package
that
utilizes
this
extending
feature.
D
You
know
I'm
thinking
of
the
react,
create
scripts
example
right
like
if
create
scripts,
wanted
to
convert
users
to
this
feature.
They
already
have
the
create
scripts
package.
Now
they
would
have
to
have
their
users
find
the
git
repo
find
the
again
pro.
I
don't
know
if
it
would
be
a
tag
like
they'd
have
they'd
have
they'd
be
introducing
a
bunch
of
complexity
onto
their
users
to
say.
D
Well,
I
know
you
normally
just
say
in
npm
install
react
scripts,
but
now
you're
going
to
say,
find
the
git
repo
grab,
whatever
you
feel
comfortable
with
as
a
specifier
that
won't
break
your
build
right
because,
like
master,
isn't
safe,
maybe
create
react,
scripts
produces
tagged
builds,
but
then
they
probably
only
do
the
standard
v.
1.0.1,
they
don't
necessarily
have
the
1.0
right,
which
is
probably
what
people
are
v1.x.
I
guess
right,
which
is
saying
I
actually
do
want.
D
The
newest
version
of
create
react
scripts
at
any
given
time
and
it
pushes
all
of
that
complexity
into
the
git
repo
or
the
some
other
file
hosting
set
up
the
consumer
yeah
exactly,
whereas
if
we
just
support
package
specifiers
that
is
really
easy
for
the
consumer
to
understand,
because,
instead
of
saying
npm
install,
you
know
we
could
give
them
a
command.
Npm
extend
at
you,
know
or
create
react
scripts,
and
then
it
would
just
do
you
know
a
standard
carrot.
You
know
1.0
dot,
whatever
the
current
you
know
latest
is
which.
F
F
Yeah,
so
I
mean
you're
kind
of
the
the
other
thing.
That
and
again
I
this.
I
don't
know
if
this
is
a
feature
or
a
bug
of
which
approach.
But
I
I
think
that
the
the
other
thing
that
that
approach
would
cut
off
is
saying
like
if
I
had
a,
I
wouldn't
be
able
to
do,
extends
dot,
dot,
slash
parent
dot,
json
right,
which
I
could
imagine
being
pretty
useful
in
a
lot
of
mono
repo
setups.
F
Where
I
I
have
one
kind
of
parentpackage.json
and
that's
the
thing
that
I
want
all
my
child
packages
to
extend,
and
it
says
it
has
to
be
a
published
package
right,
published,
meaning
either
or
it
has
to
be
a
package.
It
can
be
either
published
or
from
a
file
url.
F
A
Yeah
but
yeah,
I
appreciate
you
bringing
this
christian
to
us
like
we.
I
think
we
can
work
out
some
details
in
async
in
the
comments
and
feel
free
to
top
up.
Here
I
see
your
hands
up.
B
I
said:
could
you
just
give
me
the
links
to
the
two
reapers
that
you
mentioned
the
two
packages?
One
was,
I
think,
read
packages
right
read.
B
I
would
then
take
a
look
at
it
and
try
to
incorporate
that
into
or
my
thoughts
on
that
in
the
rfc,
if
possible,
because
that
would
help
me
to
gain
a
deeper
understanding
of
what
you're
talking
about,
but
I'm
definitely
on
board
that
you're
right.
It
shouldn't
only
be
published
packages
because
otherwise
we
are
ruling
everyone
else
out
who's,
just
using
monorail
posts
on
disk,
which
is
also
not
good.
A
For
sure,
thanks
for
for
having
us
so
yeah,
so
if
we
can
feel
free
to
again
top
up
and
add
comments
to
the
rfc
itself,
it
sounds
like
we'll
be
discussing
again.
Probably
next
week,
roy
number
one
issue
160
the
poll
that
you've
had
in
place
for
workspaces.
Did
you
want
to
give
a
quick
update
on
the
results
of
that
poll
and
or
any
discussion
that
has
been
had
sure
yeah?
Maybe
it's
if
it's
time
to
close
it.
H
F
Yeah,
that's
I
I
I
fully
come
around
to
that
as
well.
I
like
that
approach
better
it.
It
also
has
the
nice
effect
of
leaving
the
the
command
name
open
for
doing
things
more
like
conceptually,
in
line
with
how
we
use
most
top-level
commands.
H
Yeah
yeah
sure,
so
I
think
well,
it's
it's
fine
to
to
close
the
issue
and
let's
just
bring
that
extra
piece
of
information
to
the
rfc
itself
sounds
good.
G
A
There
that'd
be
great
cool
moving
on
so
pr
150
rc,
I'm
going
to
add
file
pack
dependency
protocol,
I'm
not
sure
if
we
have
david
on
the
call
and
I'm
not
sure
if
there's
been
isaac,
you
were
the
last
to
discuss
sort
of
like.
F
Yeah,
I
don't,
I
don't
know
of
any
updates,
since
we
discussed
it
last
time
and
I
put
the
notes
in
the
rfc,
so
we
can
we
can
let
that
let
that
one
stay
on
the
back
burner
for
a
bit.
Okay,.
A
F
Yeah,
so
I
think
I
think
the
rfc
as
it
currently
stands
is,
is
probably
just
what
we're
gonna
stick
with.
But
the
only
last
sticking
point
was
what
we
used
to
as
kind
of
the
key
to
represent
the
current
package
version
within
the
the
override
tree
and
we're
we're
sticking
with
dots.
So
yep.
A
Sounds
good
what
it
is?
Okay,
so
can
we
expect?
Can
you
merge
that
update
the
the
I
guess
the
file
number's
gonna
have
to
be
updated,
awesome
so
moving
on
again
so
rc
126
added
types
information
order.
I
think
you've
updated
the
rfc
itself.
E
Yep
rfc
has
been
updated
from
atlas
feedback,
so
I'll
fresh
text.
I've
got
a
corresponding
pr
to
read
json
package
that
takes
into
account
every
single
type
of
way
in
which
you
could
define
your
index
in
a
in
a
package
including
the
new
node.js
xbox,
so
the
dot
that
we
just
talked
about.
That's
already
that's
supported
in
there
too.
Realistically,
I
think
it
just
needs
isaac
to
take
some
time
to
give
it
a
look
over
and
see
what
he
thinks.
A
Yeah
cool
yeah
and
I
think,
if
we
can
we'll
keep
this
up
to,
I
guess
get
ratified
then
next
week
is
give
everybody
a
chance
to
look
at
them
but
yeah.
I
appreciate
you
doing
the
work
to
also
get
pr
against
the
repackaged.
Json!
That's
great
awesome,
okay!
So
moving
on
rc
117
roy
did
you
want
to
give
a
quick
update
to
the
workspaces
pr
sure.
H
Yeah
yeah,
the
the
update,
is
quite
quick
there.
There
are
no
updates
for
my
site,
but
maybe
someone
wants
to
add
something,
but
I
think
from
what
we
discussed
last
time.
We
probably
want
to
leave
this
one
open
for
a
bit
more
time,
maybe
take
it
out
of
the
agenda
for
next
meeting
but
yeah.
If
anyone
has
anything
to
comment
on
it,
that
might
be
a
good
time.
H
A
I'll
take
out
for
now
and
I'll
have
to
do
that
to
the
issue
as
well
I'll
just
remove
the
labels
for
those
two.
A
Okay,
moving
on,
then
pr
114
expand
the
list
of
ignored
files,
so
I
think,
based
on
the
time
sorry
discussion
we
had
last
week
roy,
I
think
it
sounded
like
there
was
a
couple
takeaways
for
almost
like
a
separate
rfc
for
similar,
prompts
similar
to
like
what
you
did
with
the
publish
prompt.
H
Yeah,
maybe
not
necessarily
yeah
yeah,
maybe
like
building
on
top
of
that
one
right
having
this
interface
to
display
warnings,
rather
than
than
just
like
blocking
the
the
files
like
this.
This.
This
list
of
ignore
files.
A
H
Yeah
yeah,
I
know
I
know
from
the
last
time
we
we
had
tyranny
that
shared
that
list
right.
We
had
some
feedback
from
people
saying
oh
yeah,
a
bunch
of
these
items
like
are
very
disruptive,
which
is
kind
of
expected
right,
so
yeah.
We
definitely
need
to
be
very
careful
if
we're
going
to
expand.
That
list
should
be
ready
for,
like
we
listed
last
time.
I
think
we
brought
this
up
already,
but
if
things
that
can
be
harmful
but
otherwise,
probably
better
to
not
not
extend
it
too
much
and
now
have
that
warning
list.
A
A
So,
okay,
that
so
like
for
me
personally,
I
think
that
we
could
take
the
list
that
you're
trying
to
expand
and
instead
bring
that
over
to
a
new
rfc
about
having
like
a
net
new,
like
warning,
prompt
before
publish
that
we've
detected
these
files.
Do
you
really
want
to
like
you
know,
I
think,
then
we
could
expand
it
even
larger
to
it
than
what
we
have
today
right
like
we
could
be
more
aggressive
about
that
list
that
we're
going
to
warn
for
so
might
be
best
to
maybe
close
this
out.
H
A
I
agree
with
that:
okay
moving
on
then
to
pr
96
ad,
publish
confirmation
prompt.
I
think
this
is
or
being
ratified.
No.
H
G
H
Yeah,
I
think
it's
just
the
technology
of
merging
it,
but
yeah
should
definitely
not
be
in
the
agenda.
I
can
remove
it.
A
Okay,
I
just
removed
it
as
well,
so
there
you
go
cool.
Thank
you
yep,
so
pr
moving
on
then
fast
and
furious
here,
pr
18,
npm
audit
resolve,
I
think,
zb
you've
joined
specifically
you've
updated
this
actually
just
recently
too.
If
you
want
to
quickly
speak
to
that.
C
Yeah
so
as
we
discussed
on
one
of
the
previous
meetings
a
few
meetings
ago,
I
now
rewrote
the
whole
thing
to
only
be
limited
to
an
rfc
for
introducing
support
for
the
audit
resolve
file
which
stores
decisions
about
what
the
audit
should
ignore
and
for
how
long
or
until
what
date
and
some
minor
other
functionality.
So
this
now
lists
some
context
on
what
this
is
for.
How
this
would
work
and
explain,
support
for
for
the
audit
resolve
file,
the
library
that
provides
support
for
reading
it,
upgrading
it
detecting
versions,
etc,
already
exists.
C
I
need
to
work
a
bit
on
the
api,
so
I
would
appreciate
some
collaboration
there,
like
maybe
I'm
gonna
come
up
with
so
so
I
have
an
idea
for
a
new
api
that
would
be
much
easier
to
embed
and
I'm
gonna
show
this
to
someone,
and
the
question
is
who
that
someone
or
those
people
would
be.
So
that's
one
thing
I
would
like
to
know
who's
interested
in
being
involved
in
potentially
embedding
that
code
in
10
pm
and
then
somewhere
near
the
bottom.
C
Yeah?
There's
a
link
to
json
schema,
that's
in
a
js
file
for
the
version,
one
because
there's
also
a
version
zero,
because,
as
I
mentioned
before,
I
already
made
breaking
changes,
because
the
initial
spec
for
the
audit
resolve
file
was
not
good
enough
and
after
talking
to
a
few
people
on
this
rfc
when
it
was
first
posted,
I
got
that
changed.
C
A
I
think
wes
had
a
quick
question
in
chat.
Do
you
have
an
updated
link?
It
seems
like
the
one
that
he
was
references
broken
to
the.
I
think
the
schema.
C
But
that
seems
to
be
broken.
No,
that's.
The
schema
is
in
the
rfc
itself.
Now
in
the
markdown
file
line,
one
three,
nine,
I'm
gonna.
D
A
Thanks
for
thanks
for
linking
that,
I
think
there's
an
opportunity
to
also
bring
like
this
to
the
package
maintenance
working
group.
I'm
sure
wes
would
probably
also
agree
with
that.
I
know
because
you've
already
done
previous
work
with
on
this
in
terms
of
anybody
on
npm
side
to
sit
down
and
work
on,
bring
this
in.
We
they're,
probably
realistically.
There
probably
won't
be
any
time
in
the
next
month-ish
to
do
that,
but
yeah
like
in
terms
of
getting
some
more
movement
on
this.
A
If
there
was
an
interest
for
of
from
you
to
maybe
even
grant
that
that
that
tool
that
you've
been
working
on
back
to
the
pkg
js
org,
that
might
be
a
way
to
get
more
collaborators
on
it.
Based
on
the
fact,
there's
some
folks
that
actually
have
time
in
that
working
group
right
now
associated
with
some
of
the
tooling
that
that's
being
created
there,
and
maybe
wes
can
speak
to
that
a
bit
in.
D
D
You're
looking
for
collaborators,
we've
had
pretty
good
success.
So
far
with
the
tools
we've
been
putting
in
that
group,
we've
sort
of
got
a
umbrella
maintenance,
sorry
umbrella
charter,
which
is
covered
under
the
node
orb.
So
you
get
like
a
bunch
of
nice
things
which
so
far
has
been
proven,
pretty
effective
at
getting
folks
onboarded
to
contributing
at
least
some
from
other
companies
have
a
lot
not
to
say
the
name.
D
So
I'm
not
going
to
do
it
but
have
been
working
on
getting
their
folks
internally,
who
are
interested
in
contributing
to
meaningful,
open
source
work
to
onboard
onto
that
group.
So
that
would
be
definitely
a
good
opportunity
if
you're
looking
for
feedback
from
you
know,
people
with
experience,
maintaining
packages
and
and
working
in
the
in
the
ecosystem
and
then
also
just
to
get
some
other
folks
like
contributing.
D
A
A
No,
I
think
that
the
updated
schema
is
probably
the
thing
that
we'd
love
to
dig
in
a
bit
more.
So
if
you're,
okay
with
us,
leaving
this
on
the
agenda
for
for
next
week,
but
it
will
give
us
everybody
some
time
to
look
it
over
sure.
C
Yeah
there's
there's
no
rush.
This
is
older
than
my
daughter.
A
C
So
I'm
definitely
up
for
donating
the
the
core
package.
That's
that
I
planned
to
finish
off
for
embedding
into
an
org.
So
if
anyone
could
share
some
sort
of
guidance,
how
to
do
that,
I
I
should
be
able
to
follow
through
this
summer
and
finish
off
the
api
as
a
like
the
first
draft
of
what
I
would
see
this
do
and
then
get
people
to
give
it
a
try.
A
Awesome
appreciate
the
work
and
also
updating
this,
so
we'll
keep
you
on
the
agenda
for
next
week
for
sure.
C
C
Maybe
not
the
tools,
the
size
of
like
snake,
if,
if
I'm
allowed
to
say
that,
but
some
more
local
tools,
more
specialized
tools
or
just
alternatives
to
this
npm
audit
resolver
package
that
I
built
so
that
we
could
experiment
with
different
ways
of
populating
the
file.
F
Eventually,
we're
probably
going
to
want
to
have
a
you
know:
npm
audit
fix
interactive,
which
would
then
I
imagine
just
create
the
file
and
npm
audit
would
automatically
do
the
right
thing
with
it.
A
G
A
Tools
could
generate
it
right
like
automatically
for
you
so
cool
so
quickly.
Moving
on,
we
have
a
few
last
two
last
rc's
here,
rfc
185,
adding
the
ability
to
skip
script
hooks,
which
was
a
fun
bug
and
or
feature
that
lucas
has
found.
Would
you
like
to
tell
us
what
that's
all
about.
I
Yeah
sure
yeah,
this
is
a
small
user
experience
oddity
I
ran
into
last
week,
so
I
was
looking
for
a
way
to
skip
a
pre-test
script
because
it
does
some
linting
and
was
just
getting
in
my
way,
and
I
vaguely
remembered
oh
there
is
this:
ignore
scripts
option
and
just
tried
it
and
like
run
npm
tests
ignore
scripts
and,
to
my
surprise
it
did
nothing.
I
So
there's
two
weird
things
here
right
like
so
when
you
run
anything,
I
guess
it's
not
npm
install
with
the
ignore
scripts
flag.
It
just
does
nothing
at
all
and
there
is
no
way
to
skip
pre
or
post
scripts
for
any
given
script.
Today,.
F
So
yeah
I
commented
on
this
pr.
I
think
this
is
great
when
I,
when
I
poked
at
it
in
npm
seven
I
found.
Actually
there
is
a
change
that
we
hadn't
noticed
in
npm,
seven,
where,
if
you
have
dash
dash
ignore
scripts-
and
you
run
npm
test,
it
will
just
do
it
anyway,
along
with
the
pre
and
post
and
because
of
the
the
rewrite
of
mkm
lifecycle
to
npm
client
run
script,
it's
a
little
bit
less
opinionated
about
configs
and
ignore
script
and
that
stuff.
F
So
it's
a
really
easy
patch
to
implement
pretty
much
exactly
the
way
that
lucas
is
suggesting.
I
am
very
thumbs
up
about
it.
I
think
you
know
I
can
fill
in
the
rest
of
the
art,
the
kind
of
missing
sections
in
the
rfc
and
just
land
it
asap.
Unless
somebody
has
objections
to
it.
It's.
I
D
Yeah,
I
think
well,
this
is
an
awesome
thing
and
I
don't
want
to
blow
the
scope
out,
but
I
think
that
there's
some
space
for
getting
even
more
fine-grained,
I
think
not.
There
are
often
times
where
so
just
recently,
where
a
pre
or
sorry
post
install
script.
Well.
Actually
this
is
a
common
thing.
Let's
just
talk
about
core
js
there
we
go
exactly.
I
want
to
say,
never
ever
ever
run
core
js's
post
install
script
again
on
my
machine
and
I
don't
want
to
say,
don't
run
all
post
installs.
D
I
only
want
to
say,
run
post,
don't
run
core
js
is
supposed
to
install.
I
think
if
we
had
some
more
fine
grained
ability
there
to
set
some
config
values
that
really
you
know
nailed
in
on
exactly
which
posts
which
scripts
you
do
want
to
ignore
would
be
highly
valuable
again.
Don't
allow
that
maybe
that's
a
separate
rfc,
but
it
seems
like
if
we're
gonna
make
changes
to
that
behavior.
D
We,
we
should
probably
go
the
extra
mile
because
that's
a
big
security
hole
for
a
lot
of
folks
and
if
you
find
a
you
know
something
that
you
want
to
ignore.
Today,
you
have
no
option
other
than
ripping
the
entire
dependency
out,
so
this
would
be
a
little.
A
Eventually
overrides
but
yeah,
I
know
what
you're
saying.
I
think
it
is
probably
a
separate
rfc
just
to
be
mindful
of
that,
but.
C
A
C
A
D
That's
one
of
the
problems
I
mean,
I
I
think,
there's
a
greater
problem,
but
I
don't
wanna.
I
don't
wanna
necessarily
talk
about
some
of
the
security
implications
that
I
know
of
right
now
on
the
public
call
if
you
wanna,
they
can
do
anything.
So
I'm
just
saying.
A
D
Currently,
a
post-install
which
is
causing
unfortunate
things
to
happen
that
I
am
working
on
resolving
if
I
would
have
been
able
to
just
tell
everybody.
Hey
just
add
this
line
to
your
npm
config
and
we're
good
to
go,
and
it
would
just
stop
doing
that.
I
would
have
been
able
to
roll
that
out
to
my
entire
company
in
30
minutes
and
what
I
have
now
is
a
very,
very
different
problem.
F
So
that
is,
that
is
a
different
rfc.
The
the
implementation
is
significantly
more.
It's
still
pretty
easy,
but
it's
significantly
more
than
the
one
that
we're
currently
contemplating,
which
is
like
just
wrapping
two
lines
in
a
nif
block,
the
the
ux
around
that
too.
We
should
chat
about
like
how
to
best
do
that,
so
that
you
basically
have
either
like
a
ignore
script,
allow
list
or
an
or
ignore
script
block
list,
or
something
like
that.
So
yeah.
A
Yeah
so
christian
your
last
up
and
then
hopefully
we
can
get
to
the
latter
last
irc
here.
B
A
For
sure,
in
terms
of
this
specifically,
I
think,
though,
we
can
probably
ratify
this
rfc,
so
basically
fix
and
standardize.
The
way
that
ignore
scripts
works
is
is
what
that
this
is
essentially.
F
Right
so
still
yeah
npm
test
ignore
dash
dash,
ignore
script
should
still
run
your
tests.
It
is
essentially
it
and
it's
just
those
four
commands.
The
test
start
stop
and
restart
that
that
has
something
to
do
with
that.
So
if
you
pass
ignore
scripts
to
that,
it
should
just
ignore
the
pre
and
post,
not
the
main
script
yeah.
I
think
it's
technically.
A
A
bug
that
has
now
become
a
feature
which
is
now
will
we'll
now
have
an
rc
for
so
I
appreciate
you
digging
in
there
lucas
that's
great,
so
I
think
we
can
ratify
this.
Then
I'm
not
sure
who
wants
to
take
that
through.
F
I
will
I
will
finish
it
up
and
and
land
it
today.
Okay,
I
appreciate
that.
A
Okay,
moving
on
to
the
last
rc,
with
a
bit
of
time
here
I
apologize
toony.
This
didn't
get
picked
up
about
182
npm,
adding
added
pm
audits
licenses.
Would
you
like
to
explain
this
a
bit.
G
Yeah,
so
this
is
just
basically
a
proposal
to
add
checking
for
licenses
and
license
tooling
into
npm
itself.
So
this
is
more
like
less
of
a
day-to-day
developer
use
case
and
more
of
a
team
use
case
where
company
company
wants
to
you
know
automatically
allow
certain
licenses
no
problem
and
block
other
licenses
from
being
used
in
their
projects.
G
G
I
I've
seen
people
be
like,
so
this
is
just
kind
of
trying
to
push
this
into
the
project
and
kind
of
have
have
a
path
to
visibility,
because,
like
yeah,
you
can
kind
of
get
this
information
for
your
top
level
dependencies
pretty
easily,
but
it's
less
it's
less
ideal
than
being
able
to
get
like
kind
of
a
full
report,
so
this
proposes
one
a
command
npm
audit
licenses.
G
This
was
based
on
feedback
that
I
got
I
collected
from
twitter
like
I
just
asked
folks
what
they
would
want
to
see,
and
this
was
the
command
that
made
the
most
sense
I'm
open
to
changes,
I'm
not
really
opinionated
there.
It
proposes
properties
in
package.json
and
or
audit.json.
G
If
that's
what
that
ends
up
being
called
from
the
the
other
rfc
and
then
it
kind
of
proposes
the
structure
of
that,
so
that
currently
you
know,
I
propose
a
structure
jordan
harband
has
been
discussing
while
we've
been
in
this
meeting
about
that
around
like
licensee,
I
think
is,
is
the
name
how
you
would
say
that
name
the
module,
but
that
being
a
more
ideal
structure
which
I'm
fine
with.
I
don't
care,
I'm
unopinionated
on
that.
G
G
So
that's
kind
of
the
structure
that
I
proposed
and
then
there's
something
else
in
here:
there's
another
top-level
thing:
oh
basically
being
able
to
triage
them
so
triage
this,
whether
it's
on
disk
or,
if
you're,
doing
it
online
and
then
kind
of
having
the
possibility
to
ignore
or
like
block
licenses
or
block
modules
from
being
installed
if
they
have
a
certain
license,
which
would
obviously
create
issues
and
that's
kind
of
kind
of
intentional
but
yeah.
G
It's
like
you
need
to
go
fix
this
before
you
can
actually
use
this,
which
could
mean
changing
a
dependency
or
something
like
that.
But
that's,
I
don't
think
that's
really
in
the
domain
of
what
npm
should
manage
or
that
that's
not
kind
of
npm's
fault.
If
you
need
to
change
it
module
to
to
something
different
and
that's
a
whole
thing
that
you
can't
really
triage
as
a
cli.
So
that's
basically
what
the
proposal
is.
F
If
my
only
I
have
some
like
very
minor
things
that
I
can,
I
can,
you
know
nitpick
with
the
in
the
pr
just
fine,
but
I
think
my
only
complaint
or
suggestion
or
thought
about
this
is
like
why
why
not
just
make
npm
audit
do
that,
like
I
guess,
or
I
guess,
the
difference
between
npm
audit
licenses
should
print
out
the
list
which
is
pretty
trivial
to
do
in
in
arborist
once
we
have
the
the
tree
and
the
the
next
step
then,
is
like
if
you,
if
you
have
this
like
licensee
style
list
of
allowed
and
blocked
licenses,
then
audit
should
just
say
yeah.
H
G
I
think-
and
this
might
be
just
how
I
I
approach
thinking
about
how
npm
commands
should
work,
and
this
I
could
be
totally
wrong
in
this,
but,
like
you
know,
having
that
as
a
distinct
set
of
functionality,
kind
of
like
npm,
install
versus
npm,
something
else
like
config
like
having
that
mp
having
that
be
a
sub
command
of
audit,
in
addition
to
running
like
at
the
root
of
audit
itself
like
if
I
just
want
to
run
this
distinct
set
of
functionality
versus
running
everything,
audit
does
so
like,
including
different
vulnerability,
checks
and
stuff,
like
that,
I
am
completely
unopposed
to
being
a
part
of
audit.
G
In
addition,
but
I
I
think
it
would
be
nice
to
have
that
additional
functionality.
How
like
as
a
command
itself.
You
know
a
isolated
command.
F
The
advantage
of
having
it
as
part
of
audit
itself
implementation,
wise
is,
then
we
get
this.
We
sort
of
for
free
get
the
benefit
of
you
know.
I
run
npm
install
somebody
added
a
license
added
a
dependency
that
has
a
license.
I
don't
like
and
it
will
print
out
and
say
hey
this.
This
thing
is
a
problem
like
you
need
to
run
npm
audit
to
see
it.
G
Yeah,
I'm
I
am
unopinionated
on
that
and
potentially
you
know,
christians
just
said
it's
a
flag
or
something
I
I
guess
the
thing
I'm
thinking
of
there's
just.
I
would
like
to
be
able
to
run
this
functionality
independent
of
audit,
but
I
am
totally
fine
with
it
just
being
part
of
audit
itself
happy
to
change.
This,
however,
would
appease
that
kind
of
proposal.
A
D
I'll
be
really
quick,
I
think
this
and
audit
are
great
together.
I
think
that
one
missing
thing
right
now
is
a
better
control
of
level.
So
when
you
have
a
if
you
and
it's
the
same
thing
with
a
security
vulnerability,
if
there
is
nothing
you
can
do
to
fix
the
problem,
you
shouldn't
be
getting
an
error
on
it
right.
You
should
be
getting
like
a
warning
or
something
like
that,
and
I
think
audit
and
the
way
this
is
written
right
now,
don't
really
have
that
taking
care
of
it.
D
Go
ahead
right,
see,
ignoring
is
pretty,
is
heavy-handed
right.
Ignoring
is
saying,
I
don't
think
this
is
a
problem,
but
what
I
might
be
saying
is
I
recognize
this
as
a
problem.
D
Yeah
change
the
license
and
then
depend
on
the
new
version
right
like
pushing
that
through
is
gonna,
take
a
really
long
time,
but
you
don't
you're,
not
saying
it's
all
right.
I
want
to
ignore
it
permanently
right.
So
anyway,
I
just
want
to
make
you
know
point
out:
an
audit
head
current
audit,
not
with
the
audit
resolver
stuff,
has
the
same
problems.
D
F
So
two
yeah,
two
things
that
that
are
different.
I
think
about
this-
is
like
a
it
is
opt
in
right.
Nobody
opts
in
to
being
warned
about
minimists,
like
critical
failure
of
you
know
letting
me
own
my
own
machine
by
polluting
the
proto.
It's
like
there
are
some
cases
where
it's
like.
Something
is
a
really
big
problem.
If
you
use
it
in
this
particular
way,
but
the
way
most
people
use
it,
it's
not
a
problem,
and
that
becomes
you
know.
F
I
pick
on
on
minimist
and
yargs
and
mcderp
because,
like
this
is
so
close
to
home
for
me,
but
that's
challenging
because
you,
if
it's
a
security
vulnerability,
you
kind
of
do
need
to
tell
everybody
if
it's
a
license
issue
like
that,
really
should
be
just
a
thing
where
you
opt
in
right,
and
so
I
think
the
the
hazard
there
is
much
lower
than
it
is
with
with
security
vulnerabilities.
That
being
said,
because
you
have
to
opt
into
caring
about
this
particular
type
of
license,
there's
a
good
chance.
F
F
So,
ultimately,
I
think
I
think
the
hazard
is
a
is
a
little
bit
lower
because
of
the
opt-in,
and
the
second
thing
I
wanted
to
mention
was
that
the
you
know
audit
printing,
a
million
warnings,
because
you
have
one
or
two
things
in
your
tree
that
are
dependent
upon
heavily,
has
pretty
much
been
like.
F
A
So,
just
to
be
mindful
we're
over
time
now
I
know
that
this
was
created
last
week,
so
hopefully
folks
will
get
some
time
with
between
now
and
our
next
call
we'll
keep
you
on
the
agenda
and
circle
back
on
this
for
sure
sounds
like
there's.
You
know
a
few
things
we'd
like
to
change
about
the
details
of
how
this
would
get
implemented,
but
it
sounds
like
there's
generally
some
some
level
of
consensus
that
we
want
something
like
this.
So
I
appreciate
you
creating
the
rc
tierney.
It's
great.
A
I
know
you've
put
a
lot
of
work
into
some
tooling
around
this
already
in
the
past,
so
yeah.
Hopefully
we
can
work
on
something
together.
A
So
with
that
appreciate
everybody
coming
to
another
open,
rc
call
we'll
be
doing
this
again
same
time
same
place
next
a
week
so
feel
free
to
keep
up
comms
between
now
and
then
on.
The
discussions
themselves
and
I'll
see
you
next
week,
ciao
bye.