►
From YouTube: Open RFC Meeting - Wednesday, Oct 30th 2019
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
A
A
A
A
get
eyes
on
any
work
that
the
community
wants
us
to
be
working
on,
essentially
just
a
place
for
us
to
be
having
some
more
open
conversations
desired.
Outcomes
are
obviously
that
we're
moving
forward
with
RCS
and
we're
working
on
the
right
things
that
are
going
to
service
the
community
as
best
as
we
can
so
I
want
to
quickly
dive
into
the
next
sort
of
agenda.
Item.
Sure
number
two
I
posted
a
issue
after
our
last
call
and
added
a
poll
for
changing
the
time.
A
I
know
that
Jordan
Harvin
has
said
that
you
would
love
to
join.
These
calls.
Wesley
Todd,
who
also
works
on
package
maintenance
working
group
and
works
with
the
Express
team,
has
also
said
that
he's
would
like
to
join.
We've
had
those
folks
at
at
different
points
jump
onto
these
calls.
It
does
seem
that
people
would
potentially
like
to
change
the
time
a
day,
and
what
I'm
proposing
here
is
that
we
shift
at
least
one
of
the
calls
that
we
do
each
month
because
we're
sort
of
on
a
bi-weekly
cadence
to
a
2:00
p.m.
A
A
C
A
So
I'll
take
that
as
a
action
item
essentially
I'll
close
at
that
initial
poll
will
update
the
dates.
Are
they
sure
at
the
time
of
our
next
call
to
be
2
p.m.
Eastern
as
it
was
the
one
that
was
most
voted
on
and
I'm
just
there
another
poll
to
decide
when?
If,
if
we
want
a
run,
this
the
the
second
bi-weekly
each
month
to
be
either
on
a
different
day
and
a
different
time?
Or
what
have
us
so
I'll?
A
Take
that
on
okay
moving
on
so
the
way
that
I
was
able
to
actually
generate
this
RC
agenda,
I
took
some
cues
from
the
India
Foundation
and
the
way
that
they
are
generating
their
meeting
agendas.
They
have
some
tooling
in
place
to
bubble
up
any
issues
or
PRS
that
happen
to
have
a
specific
label
associated
with
them.
So
last
night
I
did
some
work
around
this,
because
this
agenda
unfortunately
has
not
been
getting
put
together
in
enough
time
to
I.
A
So
so
the
idea
here
is
that
going
forward
any
issue
or
PR
that
you
would
like
to
in
the
wild
get
us
to
discuss
at
this
at
this
call,
if
you
add
the
label
agenda
to
it,
you
will
essentially
surface
that
when
we
generate
the
meeting
agenda
going
forward,
and
ideally
this
agenda
will
now
also
get
queued
up
on
a
cron
job.
So
it's
not
going
to
be
manually
created
by
myself
going
forward.
So
that
was
just
another
sort
of
high-level
note.
A
There's
still
some
work
around
extending
having
a
lot
of
our
projects
extend
from
sort
of
our
baseline
settings
that
right
now
live
in
a
project
called
the
open
source
project,
our
open
source
project
right
now
that
has
all
the
labels
that
we
agreed
upon
in
another
call
that
we'd
like
to
be
using
across
our
projects.
It
has
a
setting
CMO
in
there
that
we
can
share
across
our
projects.
So
it's
super
easy
for
you
to
be
keeping
sort
of
a
standard
set
of
labels
across
every
project,
so
yeah
so
another
to
do.
A
For
me
just
the
further
lament
that
going
forward,
these
agendas
will
be
automatically
generated
and
if
you
want
to
remove
something
from
the
agenda,
all
you
have
to
do
is
remove
that
label
from
the
issue
or
PR.
So
this
should
be
make
these.
These
calls
go
a
lot
smoother
and
yeah.
It's
just
that
heads
up
any
comments
on
that.
A
Nope,
okay,
cool,
so
moving
on
to
what
essentially
is
our
first
real
issue
for
the
for
the
call
again,
unfortunately,
I
don't
know
if
a
lot
of
people,
that's
fine
to
review
the
the
various
issues
and
PRS
that
have
been
bubbled
up.
This
RC
is
for
essentially
having
yarn
resolutions,
which
I
believe
is
something
that
we've
discussed
about
supporting
in
m7.
A
C
C
So
one
of
the
one
of
the
design
goals
of
arborist
and
for
NPM
seven
is
better
interoperability
with
yarn
and
NPM,
and
so
one
of
the
one
of
the
key
aspects
of
that
is,
you
know
we
might
not
have
a
package
like
JSON
urn
and
can
shrink
wrap
file.
We
might
have
a
yard
lock
file
or
a
PM
lock
or
some
other
thing
right,
and
so
the
the
plan
is
to
and
also
you
know,
as
we
discussed
in
our
team
meeting
recently
as
I'm
going
through
some
of
the
like
tree
resolution
and
reifying
stuff.
C
C
It
represents
the
package
tree,
but
it
can
only
represent
the
package
tree
where
it's
sort
of
a
consistent,
nested
hierarchy
of
like
node
modules,
package,
node
modules,
package,
right
and
but
it
has
the
concept
of
like
this
thing
is
a
parent
of
this
other
thing,
but
when
it
doesn't
have
is
this
thing
is
in
this
is
assembling
to
this
other
folder
and
I'm
gonna
actually,
and
that
folder
is
within
the
node
modules
tree,
but
not
within
the
kind
of
like
nested
those
models
folders.
So
this
is
what
you
see
with
the
trees
that
PMPM
generates.
C
It's
also
important
if
we're
gonna
snapshot
and
capture
the
state
of
a
workspaces
directory
so
and
there's
there's
additional
information
which
a
yarn
lock
file
presents
and
then
information
it
doesn't
present.
So
we
kind
of
have
this
like
overlapping,
non
identical
set
of
data
that
we
can
get
from
the
various
files.
So
anyway,
the
plan
is
to
have
arborist,
be
clever
about
pulling
one
information.
C
There's
I
suspect
that
we're
going
to
end
up
with
a
somewhat
different
format
for
a
lock
file
that
arborists
will
use
to
just
kind
of
like
capture
the
state
of
that
of
that
resolution
for
performance
reasons
and
I.
Don't
suspect
that
will
add
a
new
thing
that
goes
in
your
project,
but
more
likely
will
will
capture
that
state
in
a
new
file
that
lives
in
node
modules,
somewhat
like
how
PMPM
stores
its
lock
file
so
yeah,
putting
doing
yarn
doing
resolutions,
as
part
of
that
is
absolutely
on
the
table.
A
C
C
I
think
I
think
actually
the
so
it's
kind
of
a
it's
one
of
these
cases,
where
the
feature
itself
is
a
minor.
The
feature
itself
is
a
you
know,
non-breaking
featured
edition,
but
all
the
underlying
work
to
support
it
is
actually
much
harder
and
the
and
is
a
breaking
change.
So
we
may
find
that
yarn
resolutions
is
like
pretty
easy
to
do
and
we
just
hold
it
in
because
we
have
to
do
all
the
same.
C
A
I've
updated
the
ticket
accordingly,
with
the
labels
and
I
think
I'll.
Leave
it
off
the
agenda
for
next
called
on
going
forward.
So
number
14
fix
up
a
new,
true
status
board.
This
essentially
is
just
a
backlog
item
for
myself.
I've
always
spoken
to
a
bit.
How
we're
using
this
I'm
actually
going
to
remove
this
as
agenda
item,
so
the
status
board
essentially
is
popping
up
a
number
of
metrics
and
sort
of
state
of
our
projects.
So
I
was
working
on
that
last
night
and
I
can
just
essentially
give
a
status
update.
A
There
I
still
have
like
five
or
six
major
changes
to
make,
but
right
now
the
agenda
creation
is
script
actually
lives
inside
of
the
status
board
project.
So
once
we
open
source
that
next
week
that
will
be
available
to
to
the
wider
wider
public,
so
any
any
future
improvements
will
folks
should
be
able
to
see
and
have
visibility
on
so
yeah.
What
time
should
we
run?
The
open,
RC
calls
again
I.
Think
we've
already
covered
this
now.
I
have
a
action
item
so
I'll
remove
this
as
an
agenda.
I.
A
A
B
That
internal
repo
already
got
there
I
guess
the
repost,
not
internal,
already
got
renamed,
and
this
was
to
add
the
Settings
animal.
So
originally
the
open
source
for
a
project
boilerplate
was
supposed
to
extend
the
github,
the
docket
hub
repo
for
the
MPI
morgue,
which
means
that
the
the
docket
hub
repo
was
supposed
to
be
the
base
for
everything.
And
currently
we
have
you
can't
so
you
can't
in
essex
tensions
so
or
extending.
So
this
particular
repo
would,
except
from
the
github
repo,
and
then
you
can't
have
like
grandchildren
on
this
one.
B
B
So,
for
instance,
all
of
our
open
source
stuff
could
extend
from
this
rather
than
the
default,
even
though
by
virtue
of
existing
in
the
npm
org,
they
get
the
default.
And
then
you
can
just
create
the
settings
file
to
serve
pull
something
slightly
different.
It's
actually
fairly
good
separation
of
concerns,
I
think
comparatively
for,
like
internal
and
open
source
public
base
and
repose
yeah.
A
Well,
I
think
the
idea
is
to
be
a
bit
more
surgical
there
and
to
slowly
adopt
those
settings
in
the
open
source
projects.
I
know
that
we
did
essentially
inherit
a
whole
bunch
of
settings
when
we
created
that
dock
you
have
a
project
at
the
org
level,
so
yeah
I
think
this
is
the
right
approach.
So
just
as
an
action
or
take
away,
maybe
you
can
update
that
issue
to
reflect
the
actual
scope
of
the
the
work.
I
know
that
that
may
we
may
be
able
to
just
close
this
as
it's
going
to
be
ongoing.
D
A
A
Adoption
of
the
docket
holder
may
not
be
the
right
tool
to
essentially
be
doing.
You
know
to
be
rolling
out
these
sort
of
org-wide
settings
shared
settings
right
so
yeah.
It
was
kind
of
like
we
used
the,
not
sure
what
the
analogy
is,
but
you
know
we
we
were
not
as
surgical
as
we
could
have
been
when
we
rolled
this
out.
So
thanks
no
problem.
A
B
Sure
so
currently-
and
we
don't
have
so-
we
have
a
1%
test
coverage
and
test
Suites
for
the
CLI
and
we'd
also
feel
like
to
include
some
benchmarking
metrics,
so
that
we
can
see
how
quick
our
operations
are.
So
a
few
scenarios
defined
mostly
around
installing
so
installing,
with
no
cash
interlock
file
and
own
own
modules,
folder
and
then
settling
with
one
cash,
with
no
limit
on
modules
and
a
lock
file
and
then
installing
with
the
log
file
and
know
all
the
other
things.
B
So
all
these
particular
permeations
permutations
rather-
and
there
is
a
project
that
PMPM
started-
an
APM
/
package
manager,
benchmarking
project
or
something
like
this,
and
it
basically
runs
each
of
the
CLI
or
each
of
the
package
managers
against
the
set
of
scenarios
and
which
is
pretty
fantastic.
So
we
wanted
to
adopt
this
kind
of
thing
internally,
so
we
are
and
I
basically
rejigged
some
of
the
boilerplate
around
the
scenario
so
that
it's
a
little
easier
to
sort
of
define.
I
want
you
to
run.
B
You
know
in
this
command
with
no
cash,
with
no
modules
before
wasn't
quite
very
clear
what
you
accompanying
each
of
the
scenario.
So
now
it's
very
easy
to
define
like
a
scenario
and
then
Roenick
see
light
or
package
manager
against
that
scenario
and
yeah
so
that'll
land
in
the
CLI
tool.
First,
which
means
that
incoming
pull
requests
will
get
sort
of
a
notification
in
their
pull
requests
or
a
commit
message.
I'm,
not
gonna
message
rather,
but
I
am
a
comment
sort
of
stating
the
results.
B
That's
there,
the
be
one
of
the
SBT
would
be
then
you'd
get
a
comparison
and
you'll
be
able
to
see
all
this
in
a
sort
of
more
bubbled
up
version.
But
in
order
to
sort
of
avoid
group
called
sculpt
creep,
we're
sort
of
keeping
it
a
little
bit
minimalistic.
And
then
we
can
sort
of
expand
on
this
later
and
be
a
little
more
an
iterative
with
it.
B
And
then
hopefully
we
can
create
or
either
fork
the
PMPM
one
that's
going
on
and
adopt
the
same
kind
of
boilerplate
in
it
or
just
sort
of
create
another
repo
and
drop
the
same
kind
of
scenario
plate.
So
we
can
sort
of
run
yarn
and
PMPM
and
yarn
PNP
and
such
against
these
particular
scenarios.
There's
also
I
think
you
mentioned
the
Pico
or
some
other
thing,
I
think
ok,
I.
C
Don't
think
it's
a
pika
pack,
I,
don't
know
if
I
don't
know
if
pika
really
does
installing
or
if
it's
just
kind
of
a
bundler
and
publisher,
it's
just
it's
just
a
bundling
from
what
I
ran.
Ok,
so
I
and
I.
Don't
think
performance
of
publishing
is
really
like,
not
very
high
sensitivity
right,
like
people
can
people
generally
don't
complain
that
publishers
take
too
long.
C
They
tend
to
complain
that
installs.
Take
you
long,
and
rightly
so,
right
because
you're
talking
about
several
orders
of
magnitude
and
for
difference
in
terms
of
how
much
operations
they
have
to
do,
and
also
you
install
much
more
frequently
and
many
more
people
do
it
so
I,
don't
know
if
benchmarking
against
peak
is
really
that
valuable.
C
Yeah
the
main
thing
that
I
want
out
of
this
is
you
know,
and
even
less,
even
about
benchmarking,
SPM,
cannon
and
yarn,
but
also
I
want
to
benchmark
in
chem
seven
against
96.
So
I
want
to
be
ready
to
do
that,
because
we're
moving
a
lot
of
stuff
around.
So
things
could
get
a
lot
faster
or
a
lot
slower.
A
Okay,
moving
on
the
ad
funding
to
package.json
issue
again,
this
is
pointing
at
essentially
the
state's
board
tickets.
Unfortunately,
so
they
aren't
necessarily
exposed
to
the
wider
org
just
yet
they
will
be
next
week,
but
maybe
you
can
speak
a
little
bit
to
the
states
of
adding
funding
to
package.json
and
the
NPM
funds.
Sub-Command
I
know
Isaac
ratified
that
RFC
are
essentially
we
sort
of
had
consensus
there
that
this
was
the
the
right
first
step.
Maybe
we
can
speak
to
the
implementation
a
bit
and
where
it's
at.
D
Anyone
wants
to
have
the
longer
explanation
about
the
implementation
itself,
but
basically
I
try
to
follow
examples
of
whatever
I
can
write,
so
so
to
make
sure
that
I
don't
get
things
to
wrong.
So,
basically,
I
took
the
list
command
as
sort
of
like
reference
for
trying
to
list
all
the
three
of
dependencies
and
their
repo
command
implementation
as
a
baseline
on
how
to
open
the
browser
showing
the
funding
URL
that
is
described
that
is
Jason,
so
anyways
yeah.
D
It's
basically
trying
to
get
from
the
examples
we
have
already
in
the
CLI
and
the
RFC
is
pretty
simple.
We
had
a
funding,
an
objector
to
take
a
package
Jason.
It
has
a
type
in
the
URL,
so
when
p.m.
fund
is
gonna,
be
able
to
list
all
of
the
dependencies
that
has
a
funding
field
on
it
and
when
you
do,
when
chemists
all
it's
going
to
have
a
little
message
showing
you,
okay
and
numbers
of
package
need
needs
funding.
You
can
run
and
can
come
in
from
I'm
more
of
a
poly.
D
D
A
D
A
Sure
awesome:
okay,
moving
on
default,
template
files
for
projects,
I
think
this
speaks
again
to
the
extension
issue.
So
it's
essentially
duplicate
I'm,
just
gonna,
remove
it
from
the
agenda
for
our
next
call.
Unless
Michael
this
is
a
bit
different.
I
think
it's
essentially
the
same
as
the
extension
issue.
B
B
Now
it's
not
quite
the
same,
so
the
we
didn't
so
basically
the
org
sort
of
ratified
some
default
templates,
but
those
don't
necessarily
sit
the
same
way.
They
should
for
open
source
projects,
and
so
this
discussion
around
this
issue
was
creating
defaults
specifically
for
open
source
project
because
it's
against
the
boilerplate.
So
if
we
get
in
a
situation
where
the
org
has
a
default,
github
folder,
that's
sort
of
extending
so
by
default
templates,
specifically
get
extended
by
virtue
of
that
folder.
B
So
every
repo
underneath
a
word
will
buy
deep
one
get
those
templates,
and
so,
if
we
want
to
overwrite
specifically
over
the
open
source
without
having
to
like
write
templates
for
all
those
things,
you
can
put
them
in
here
and
then
those
ones
keeps
have
a
settings
folder
that
extends
this,
and
then
it
will
overwrite
those
templates
which
is
kind
of
a
nice
layered
separation
of
concerns.
So
the
the
default
templates
in
this
particular
or
should
be
the
ones
we
want
for
open
source
projects.
B
It
was
basically
what
this
issue
is,
so
it
did
not
necessarily
so
like
the
two
I
just
posted
in
a
chat
about
the
issue
that
I
just
updated
was
specifically
around
flushing
out
the
settings
file,
which
is
to
say
the
repository
settings,
need
to
be
added.
I
added
some
detail
there.
This
one
is
specifically
around
the
templating
because
those
two
things,
although
they
sound
the
same
arch,
the
same
thing
right
like
that
job
by
virtue
of
it
being
called
the
doc
github
repo
or
by
virtue
of
that
repository
being
called
doc,
get
up.
B
You
extend
templates
across
the
entire
org,
but
the
settings
in
the
settings
yamo
are
only
extended
by
virtue
of
extending
them
by
using
the
settings
and
one
other
file.
So
when
you
get
by
default
across
org
repos,
the
other
one
you
have
to
like
opt
into
and
all
the
open
source
projects
that
we
want
to
make
sure
we
have
our
correct
settings
for,
should
actually
extend
this
and
then
they'll
opt
in
to
this
set
of
not
only
settings
but
also
templates.
A
A
A
Okay,
moving
on
to
PRS
now,
Isaac
I
know
that
this
is
actually
being
on
the
agenda.
The
last
couple
times
we've
met
up,
but
you
essentially
have
the
intimate
knowledge
and
context.
I
know
that
you've
locked
this
issue
now
or
at
the
last
I
know
that
we've
sort
of
run
in
circles
at
the
same
conversation
a
couple
times.
Maybe
you
can
give
a
little
bit
of
context
the
state
of
it
and
sort
of
how
we're
moving
forward
yeah.
C
C
A
C
C
The
other,
the
other
thing
is,
you
know,
we're
we're
this,
we're
that
male
and
like
so
yes,
I
think
that
we
should
document
what
the
what
the
beta
process
for
d7
is
going
to
look
like
I,
don't
you
know
like
with
with
a
six
dot
12.1
right,
we
like
you,
landed
a
bunch
of
PRS
and
then
we
shipped
it
and
it's
fine
cuz.
It's
like
really
low
risk
stuff.
It's
all
patch
changes.
You
know,
bug
fixes
and
stuff.
C
C
This
tag
before
it
gets
shipped
by
default
with
node,
and
so
there's
there's
a
very
good
chance
that
you
know
the
first
v7
thing
that
the
majority
of
people
actually
hit
might
be
7.3
or
you
know
so
whatever,
but
if
we
want
to
have
the
option
of
installing
period
EPS
by
default
or
doing
some
of
the
suggested
fall
backs
in
that
PR
of
saying,
well,
we're
not
going
to
install
them
by
default
unless
you
opt
into
it
or
unless
you
run
this
second
command.
That
will
fill
in
your
your
peer
dives.
C
C
Do
this
package
resolution
step
with
their
with
their
human
brain,
so
we
have
to
do
all
the
work
to
be
able
to
install
them
by
default,
and
let's
just
do
that,
work
and
then,
let's
see
how
it
goes
and
if
we
need
to
roll
that
back
and
make
it
not
a
default
or
whatever.
That's
that's
a
relatively
small
bit
of
additional
work,
so
I
lock
the
issue
because
it's
like
we're
gonna
talk
about
this
again.
C
Once
we
have
an
implementation
and
we'll
unlock
it,
then,
and
also
and
also
I,
said
you
know
if,
if
if
anybody
wants
that
like
what
anybody
has
a
new
issue
that
has
not
been
addressed
in
this,
then
for
sure,
let
me
know
and
I'll
reopen
it,
we'll
discuss
it
more
yeah
if
it's
just
if
it's
stuff.
That's
already
kind
of
been
addressed
and
you
just
disagree
like
sorry,
you
know
you're,
not
the
boss
of
me
yeah
nice.
C
Remember
me
to
flip
about
it,
but,
like
you
know,
we've
got
a
project
to
run.
We
got
other
stuff
to
do
so
when
we
have
a
when
we
have
an
implementation
to
talk
about
and
we'll
reopen
it
and
we'll
try
to
get
people
to
start
banging
on
it
and
see,
like
you
know,
is
this
really
the
the
apocalypse
that
was
predicted
or
is
it
the
you
know
the
savior
that
all
of
our
users
hope
it
to
be
and
in
the
react
land
or
is.
C
A
A
C
A
Now
this
again
as
a
you
had
sort
of
talked
about
a
blessed,
the
concept
of
like
a
blessed
key,
something
like
MPM
for,
like
all
this
config
to
live,
I'm,
not
sure
if
you've
had
time
to
sort
of
like
refresh
your
memory
about
this,
it's
it
was
from
a
couple
months,
back
yeah
I'm,
not
sure
where
we've
land
on
this,
whether
this
needs
further
flushing
out
of
what
that
would
look
like
if
we
want
to
support
it.
Does
it
make
sense
like
like
back
lock
some
work
for
this
so.
C
I
think
I
think
this
is
a
separate
what
I
said,
what
I
sort
of
suggested
here
on
August
19th
in
the
comment
on
this
is
this
is
sort
of
a
separate
RFC
right.
We're
talking
about
the
initial
RFC
is
just
here's
this
one
config
option
that
I
want
to
be
able
to
set
in
package.json,
so
that
I
don't
have
to
put
it
in
a
dot.
Npm
RC
file
like
okay,
but
why
don't
we
just
let
you
put
configs
in
your
package
JSON
instead
of
an
NPM
RC
file
like
that
seems
to
be
a
pattern.
C
A
Should
we
just
give
that
feedback,
and
then
we
can
change
it
at
the
top
or
change
the
label
to
you
need
stocks
as
well,
so
we
can.
We
can
do
that
and
then
I
think
the
action
would
be
just
to
give
that
feedback
that
it
sounds
like
we
should
I
think
you
already
did
kind
of
provide
that
sort
of
direction.
Yeah.
C
C
C
Just
the
rest
of
your
package,
JSON,
it's
not
for
typescript.
We
might
want
to
call
it
something
like
NPM,
config
or
some
other
name,
but
that
that
aside,
it
would
essentially
just
be
taking
the
place
of
a
dead
project
config
right,
so
we
we
could
implement
this
pretty
easily
in
our
config
loading
logic,
to
say,
you
know,
look
for
a
dot,
NPM
RC
file,
if
you
don't
find
it
see.
C
If
the
package
JSON
has
an
NPM
field
which
is
an
object
and
then
just
that's
your
that's
your
project
config,
we
could
also
another
way
to
do.
It
would
be
to
say
that
this
is
essentially
a
second
project
config
that
could
be
used
in
addition
to
an
NPM
RC
file,
and
then
we
need
to
figure
out
okay
well,
which
one
which
one
takes
precedence
right.
If
you
have
a
dot,
NPM
RC
file-
and
you
also
have
an
NPM
field
in
your
package
JSON
in
which
to
use.
B
B
A
B
A
B
C
Of
not
doing
it
well,
so
the
dotted
PMRC
file
won't
show
up
in
the
tarball
anyway,
because
we
don't
we
don't
ship
package
configs
in
a
in
package,
which
is
which
is
actually
important,
because
you
know
we
have
you
may
like
secrets
or
passwords
or
tokens
what
other
than
that
yeah.
That's
pretty
common.
So
even
though,
that's
a
really
bad
idea.
B
C
Doesn't
matter
because
we're
not
going
to
look
at
it
in
a
nested
folder
anyway,
like
if
you're
installing
something
right?
This
is
the
the
initial
push.
The
initial
PR
is
just
saying,
like
I
want
to
be
able
to
specify
the
script
or
the
binary.
That's
used
to
run
in
PM
scripts
in
this
package.
If
you
think
about
it,
like
you,
don't
run
the
test
script
from
a
package,
you
install
right,
you
do
run
now.
This
gets
interesting.
You
do
run
like
post
install
pre-installed.
Those
kind
of
lifestyles
like
so.
B
B
You
cloned
this
repo
and
you
ran
to
like
install
it,
would
you'd
have
a
dot,
M
PMRC
file
right
if
you
like,
npm
install
for
this
repo
and
you
need
it
to
run
post
install
the
scripts
that
you
look.
Dot,
NPM
and
RTC,
wouldn't
be
there
right
and
so
then
I
understand,
and
then
the
scripting,
like
you're,
effectively
trying
to
hoist
config
out
of
the
data
NPM
RC
file
in
to
get
it
to
run
yeah.
B
C
B
Yeah
is
that
is
that
not
what
the
first
objective
of
this
one
right,
that's
what
I
just
assumed?
What
else
would
you
need
to
advance
with
the
show
you
said
something
about
testing
just
then,
but
yeah.
C
A
A
B
Think
impact
is
once
but,
like
I
think
you
just
mentioned
a
closing
song
green
saw
whatever
I
scripts
and
then
all
the
testing
stuff
like
that
impact
would
need
to
be
defined
and
then
I
still
struggle
with
the
impetus
cos.
If
you
want
your
tests
to
run
in
a
certain
script,
you
just
put
in
a
dog
NPM
RC
file,
Ike
I,
don't
know
why
you'd
need
to
have
in
writing.
C
B
C
I
mean
this
is
kind
of
a
solution
of
like
yeah.
If
you
don't,
if
you,
if
you
have
an
NPM
RC
file
and
you
don't
want
an
NPM
RC
file,
you
could
fix
that
by
not
caring
right
like
and
that's
a
perfectly
fine
solution.
Oh
I
love
problems
that
you
can
fix
by
not
caring,
they're,
so
easy
to
fix,
but
know
that
the
the
the
impact
and
where
this
gets
interesting
yeah,
like
I
hadn't,
really
thought
this
through
until
just
now,
but.
C
A
A
C
C
Yeah,
there's,
there's
I
think
doing
doing
something
special
for
script.
Bin
is
not
the
right
approach
right,
that's
not
elegant
or,
and
it's
gonna
set
some
user
expectations
that
you
can
put
other
configs
in
there
that
and
then
they
won't
work
and
that's
kind
of
weird
I'd
rather
have
fewer
one-off
things
for
individual
config
values,
individual
config
keys.
So
the
two
questions
are
like:
do
we
do
we
add
another
config
layer
for
installed
packages
or
not
cuz?
Currently,
configs
are
the
same
for
everything.
C
That's
calling,
and
the
second
question
is:
do
we
allow
do
we
want
to
open
the
door
towards
having
conditional
configs
based
on
different
versions?
And
if
so,
should
we
also
just
put
that
in
the
NPM
RC
file
format?
So
you
can
have
you
know
like
a
Windows
block
that
overrides
everything
on
Windows,
unix
block
or
whatever,
and
then
do
we
want?
How
do
we
want
to
represent
that
in
package.json
if
we
use
package.json
broken
things?
So
since
you
want
to
kick
up
those.
A
Questions
or
discussions
in
an
issue
on
the
RFC
project
I
feel
like
they
essentially
what
you
just
outlined.
There
are
two
good
questions
we
should
surface
and
it
sounds
like
this
RFC
as
it
stands
today
is
something
that
we
don't
want
to
move
forward
with
that's
sort
of
that
right
yeah.
It
would
have
to
be
drastically
changed
for
it
yeah,
so,
okay,
so
action
night.
If
there's
is
just
give
that
feedback
and
then
say
that
we've
moved
the
discussion
to
asking
some
some
questions
about
how
we'd
want
to
move
forward
with
something
that's
more
holistic.
A
Awesome
I
think
we
have
time
for
one
more
given
the
fact
that
there
was
some
many
PR
pr's
pulled
up
from
from
this
automation
that
iran
is
there
any
specific
one
on
here.
The
last
of
the
last
I
think
six
that
we
had
that
somebody
wants
to
speak
to
you.
I
can
essentially
add
a
high-level
go
over.
Some
of
the
interesting
ones
are
singleton
packages.
Is
that
something
we
want
to
look
into.
A
A
C
A
A
So
this
was
interesting
proposal.
This
was
essentially
like
a
hook
lifecycle
hook
for
when
your
dependencies
have
changed,
essentially
allowing
people
to
create
tooling
around
auditing
or
verification,
or
anything
like
that
and
not
sure
where
we've
we've
sort
of
netted
out
and
whether
this
is
something
we
would
want
to
like,
pull
back
in
and
and
move
forward
with.
Yeah.
C
A
C
So
then
we
would
have
like
free
change
as
well,
and
then
the
question
becomes
like:
when
exactly
do
we
run
that
script
and
what
information
does
it
have
available
to
it?
So
there
are
some
things
where
there
are
some
things
where,
like
there
is
no
pre
or
if
there
is
it,
you
can
actually
do
anything,
but
we
have
access
to
stuff
like
free
pack
doesn't
yet
know,
I
believe
what
version
that's
or
what
the
filing
is
gonna
be,
but
yeah.
C
We
would
just
need
to
outline,
like
you
know
exactly
when
in
the
in
the
tree
resolution
and
reification
process
that
actually
happens
and
and
what
it
can
do.
My
my
thinking
is
what
you'd
really
want
or
what
I
would
want
if
I
was
going
to
do
use
in
a
target.
The
use
case
described
in
that
PR
I
would
want
to
know
before
we
install
it
right.
I
would
want
to
know
before
the
change
actually
happens
like
what
was
the
what
was
the
old
version?
C
What
is
the
new
version,
and
what's
the
metadata
I'd
be
able
to
get
at
that
and
then
script
somehow,
so
that
I
could
check
and
see?
Like
has
the
license
changed,
does
it
still
have
a
license
file
or-
and
maybe
even
do
some
asynchronous
work
to
check
and
make
sure
that
like
if
it's
something
that
we
need
a
license
exemption,
if
it's
a
you
know,
paid
license
coming
with
that,
we're
still
in
good
standing,
so
there's
a
little
bit
more
bike
shedding
to
be
done.
C
C
Comment:
real
quick,
PR
20,
the
PowerShell
scripts
were
installed
binaries
we
actually
did
implement
this
I
didn't
realize
there
was
a
PR
when
I
landed,
that
I
didn't
realize.
There
was
an
RFC
when
I
landed
that,
but
it
got
into
CMD
Shen
versions.
He
got
one
and
then
that
shipped
with
NPM
6.11,
so
I
move
that
to
the
implemented
folder
in
RFC,
both
of
y'all
yep.