►
From YouTube: Open RFC Meeting - Wednesday, April 1st 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
on
YouTube.
Welcome
everybody
again
to
another
open
RFC
meeting,
hosted
here
at
M
p.m.
my
name
is
Darcy
Clarke
I'm
your
host
and
we'll
quickly
dive
into
the
agenda,
which
I
will
link
here
with
the
meeting
notes
for
folks,
if
you
want
to
make
sure
that
you've
added
yourself
to
attendees
at
Claudia's,
again
agreed
to
kindly
take
notes
appreciate
that
Claudia,
a
few
housekeeping
notes.
A
This
colleague
again
is
a
way
for
us
at
NPM
to
essentially
interface
with
the
community
and
hopefully
be
moving
conversations
forward
having
another
outlet
for
community
to
interface
with
us
and
hopefully
be
moving.
You
know
our
seas
and
future
work
forward
based
on
community
feedback.
All
these
calls,
as
well
as
any
interactions
on
the
actual
NPM
slash,
RFC's
github
repo
are
under
the
code
of
conduct,
which
you
can
find
a
reference
to
on
the
actual
RFC's
repo,
and
with
that
in
mind,
is
there
any
announcements
or
anything
that
folks
wanted
to
put
on
the
agenda?
B
No
I
think
we
should
just
probably
well,
unless
you
want
to
discuss
as
a
part
of
this
something
we
somebody
could
go
and
open
as
an
RFC
I
know,
we
haven't
really
done
that
before
we
only
discussed
existing
RFC's,
but
I
think
this
is
there's.
Definitely
an
RFC
worthy
of
writing
up
on
the
audit
stuff
sure.
B
A
A
We've
now
run
two
deep
dives
and
we're
gonna
go
into
the
notes
a
bit
and
just
do
essentially
a
Coles
Notes
TLDR
later
in
this
call,
but
just
to
let
folks
know
that
that's
another
meeting
that
we're
running
so
you
now
get
twice
as
much
NPM
in
your
life
each
month.
So
that's
pretty
nice
and
hopefully
folks
can
be
joining
in
on
those
calls.
So
same
time
same
place
now,
weekly
deep
dives
are
again
focused
around
a
specific
RFC
or
topic
that
we
wanted
to
into
more
thoroughly
where's.
A
The
open
RFC
meetings
are
tailored
to
the
broader
conversations
and
try
and
move
at
different
issues
and
PRS
forward
at
a
higher
level.
So,
given
the
agenda,
let's
dive
into
the
first
essentially
are
RFC,
which
was
really
eight
usage
of
update.
No
fire
ROI
way.
I.
Think
you
open
this.
It's
number
118
I'm,
not
sure
if
you
want
to
speak
to
the
intent
and
where
we're
at
with
with
putting
some
together
and
or
Isaac.
If
you
were
the
last
person,
I
think
that's
on
the
call
that
actually
actually
commented
on
this.
C
Yeah
I
can
start
I,
guess
yeah,
so
basically
yeah
we
got
some.
We
run
into
some
issues
in
the
past
with
for
the
update,
not
fire,
and
it's
been
brought
up
to
us
more
more
than
once
that
it
could
be
kind
of
like
nice
to
get
rid
of
it
or
replace
it
with
something
else.
So
I
kind
of
just
wanted
to
like
start
a
discussion.
So
it's
basically
a
on
our
RFC
just
to
her
just
to
get
that
conversation
started,
but.
D
C
Yeah
but
one
thing
that
changed
though,
since
I
opened,
that
is,
that
the
folks
from
yeoman
they
actually
gave
me
right
access
on
the
package
itself.
So
now
we
can
have
more
hands-on
in
the
maintenance
of
the
eff
up.
They
do
not
fire
itself.
So
there's
that
there's
that
change
to
also
take
into
account.
A
Right
so
I
mean
it's,
it's
good
that
you
now
have
access
to.
That
I
was
actually
a
good
surprised
that
you
were
part
of
that
org,
but
I
think
at
least
I'm
in
the
cut
like
the
camp
of
it
would
be
great
less
depth.
Dependencies
is,
is
probably
better
for
us
and
it
is
gonna
bite
us
less
often,
especially
if
it's
pretty
simple
logic
that
we
could
be
baking
into
the
CLI
itself,
I'm,
not
sure
Isaac.
If
you
hadn't
didn't,
have
a
chance
to
see
what
you
were
commenting
on.
D
D
D
Yeah,
so
the
thing
I
was
thinking
we
could
do
is
actually
just
put
a
header
in
the
registry
that
says
like
you're.
Using
this.
You
know
your
your
user
agent
says
that
you're
using
this
version
of
a
client
and
there's
a
new
version
of
that
client.
So
you
should
download
it
and
we
could.
We
could
even
do
that
conditionally,
like
if
people
are
using
yarn,
then
yarn
will
send
a
user
raisin
agent
header
and
we
can
tell
them
that
there's
a
new
version
of
yarn
and
same
for
4
p.m.
D
B
D
Right,
so
if
you
don't
send
that
header,
then
you
don't
get
the
notifier
telling
you
to
update,
which
you
know
is
probably
fine.
A
lot
of
a
lot
of
proxies.
Do
you
just
pass
along
whatever
headers
the
the
registry
sends
so
I?
Don't
think
it
will
be
relevant
for
a
lot
of
people,
but
if
a
proxy
then
wants
to
filter
out
that
header
it
totally
can
and
or
if
it
wants
to
push
a
different
header
that
says
you
should
be
on
in
version.
B
So
that's
kind
of
where
I
was
going
with
that
is
I
could
picture
something
we
would
use
would
be
probably
do
having
a
more
controlled
approach
there.
So
one
of
the
things
we
often
consider
is,
you
know,
there's
a
difference
for
your
average
user
and
your
company
user.
We
want
centrally
managed
experiences
in
a
lot
of
these
cases,
whereas
you
know,
as
a
you
know,
open
source
engineer,
you
probably
don't
want.
Well,
not
that
you
don't
want
you
just
won't
ever
get
centrally
managed
right.
B
D
B
What
I
don't
think
we
want
to
do
that?
I
mean
we
want
people
to
be
able
to
install
whatever
they
want.
We
just
want.
You
know
if
it's
a
matter
of
if
we
do
start
to
take
more
control
over
centrally
managing
what
we
recommend,
because
the
update
notifier
is
really
just
a
recommendation.
Not
any
sort
of
you
know
forced
things,
so
that
would
just
be
a
nice
another
tool
in
our
toolbox
for
helping
recommend
folks
on
to
other
versions.
C
D
A
D
D
You're
not
making
it,
we
would
not
make
another
okay,
and
essentially
it
would
just
be
the
the
sort
of
simple
stupid
way
to
do
it
is
the
registry
looks
at
the
user
agent
header
if
the
user
agent
Heather
is,
you
know
unknown
client,
and
it's
not
the
current
latest
version
of
that
known
client.
Then
it
returned-
and
it
just
includes
the
header
and
the
response,
and
so
it
doesn't
have
to
be
too
particular
about
what
kinds
of
requests
get
which
kinds
of
headers
it's
just.
It
just
puts
it
in
all
of
them.
D
We
can,
we
can
also
say
things
like
you
know.
This
is
hey.
This
is
a
breaking
change
or
you
know
there's
a
new
version
on
next.
If
you
want
to
try
it
or
we
can
limit
it
to
only
things
that
are,
you
know
within
your
same
major
version
or
whatever,
so
that
does
give
us
a
little
bit
more
control
than
then
we're
likely
to
get
in
a
reasonable
way
from
update
notifier
yeah.
A
C
A
C
C
B
I
followed
that
with
I
agree,
it
is
very
wild,
so
he
also
was
chatting
with
me
on
Twitter
a
little
bit
about
this,
so
I
also
read
through
it
and
I
I
see.
This
is
a
big
change
which
doesn't
have
a
lot
of
upside
for
most
folks.
I'm,
not
saying
it
is
a
bad
idea,
but
because
it
is
so
drastically
different
than
and
because
because
it
is
drastically
different
and
the
overlap
with
just
having
them
be
dev
dependencies,
which
is
what
they
are
today
is
sort
of
unclear
like
there's.
C
B
Other
dev
dependencies
and
it's
like
well,
okay,
slightly
different
but
like
what
is
the
win
here
and
the
win
is
where
I'd
say
I
feel
like
the
amount
of
effort
it'll
take
to
change
is
something
like
this
is
really
high
for
the
win,
which
is
not
looking
in
your
node
modules
and
seeing
thousands
of
things
because
Babel
right
and
it's
like
totally
I,
get
it
I
hate
that,
but
like
also,
what
difference
does
that
make
to
any
average
user
like
I?
Think
almost
none
well.
B
B
So
one
example
is
the
ability
to
import
something
which
was
not
directly
it
dependency,
but
happened
to
be
installed
by
something
like
a
dev
dependency
on
Babel,
where
somebody
then
had
a
Babel
transform
I've
seen
this
happen,
where
they
didn't
actually
install
it,
but
they
were
able
to
use
it
because
it
was
installed
by
some
other
underlying
dev
dependency,
which
was
just
like
I,
think
and
that's
a
totally
different
issue
than
what
this
is
trying
to
propose.
I
think
that's.
D
Also
I
mean
that's
also
the
general
problem
of
unlisted
devs,
I
I,
think
this
I
mean
this
particular
change
is,
is
very
big.
I
haven't
had
a
chance
to
go
through
and
really
evaluate
it.
It's
it's
very
subtle
and
it
will
have
you
know.
Adding
a
new
dependency
type
is
is
a
change
that
ripples
all
throughout
the
system,
and
it's
something
that
also
affects
other
package
managers,
who
then
kind
of
have
some
pressure
to
support
it
and
have
to
do
the
same
kind
of
thing.
So
it's
it's
not
it's
not
a
small
change
at
all.
D
We
also
to
worry
about
the
backwards
compatibility
if,
if
you
have
something
listed
as
a
been
dependency,
but
you
know
older
versions,
the
client
know
how
to
handle
it
and
so
on.
So
just
it's
something
that
it
has
to
be
dealt
with
very
carefully.
I
think
the
last
new
dependency
type
we
added
was
peer
dependencies
and
like
we're
still
like
solving
all
the
problems
with
that
and
all
those
kind
of
subtle
edge
cases
that
that
introduce
so
I
think
that
the
wind
here
is
is
really
not
clear
to
me.
D
You
know
if
it's
just
that
you
don't
want
to
see
them
in
mp,
MLS
like
we
could
make
n
P
MLS
not
show
you
as
much
stuff.
I
mean
it.
It
is
dumb
that,
like
I,
run
npm
LS
and
a
package
that
has
one
dependency
and
a
dependency
on
tap
and
I
see
a
thousand
bowel
thing,
because
you
know
NYC
and
reactant
T
report
everything
else.
D
So
anything
that
is
not
a
direct
dependency
would
go
in
dot,
slash,
node
module,
slash,
node
modules,
and
the
tree
resolution
would
also
work
because
it
would
sort
of
find
it
in
a
parent's
node
modules
folder.
But
when
you
run
NPM
LS,
you
would
only
see
the
depths
that
you're
actually
directly
depending
on
good.
B
I
could
I,
maybe
I
think
we
could
solution
on
unlisted
depths.
I
I
have
a
very
personal
investment
right
now
in
a
different
approach,
but
I
I
think
this
is
subtly
a
different
issue
and
maybe
it'll
be
better
for
us
to
have
a
separate
discussion
on
unlisted
deps
elite
there,
okay,
but
my
point
is
just.
D
D
D
You
know
a
bit
of
code,
that's
using
the
Lib
that
it
provides.
So
you
know
this
is
definitely
the
case
in
a
lot
of
a
lot
of
babble
like
babble,
CLI
stuff,
it's
the
case
or
NYC
or
tap
like
or
not.
So
much,
for
my
seems
is
a
standalone
binary,
but
it
it
has
very
particular
ways
that
it
expects
to
be
used.
D
Test
frameworks
are
great
example
like
if
you're
using
the
just
CLI
it
expects
that
when
you
do
require
just
you're
getting
the
same
thing
right
you're
using
that
version
of
its
of
its
code,
so
I,
don't
know.
This
seems
like
it
introduces
a
weird
opportunity
for
an
impedance
mismatch
and,
like
version
mismatches
between
projects,
in
a
way
that,
like
it's,
it's
just
going
back
to
global
dependencies
like
this
is
why
you
should
install
things
locally
and
use
NPM
scripts
instead
of
installing
them
globally.
D
A
A
C
B
A
C
B
C
I,
don't
know
yeah,
okay
yeah
we
could.
We
could
do
it
like
add
it
behind
a
flag,
but
again,
like
I,
think
this
is
the
kind
of
thing.
What
we're,
what
we're
getting
it's
kind
of
not
much
compared
to
to
the
the
risk
of
to
the
echo
system
right
so
because
what
we're
getting
is
basically
ignoring
a
couple
more
files
from
every
package
right,
but
the
risk
is
like
breaking
other
people
workflow.
So
so.
D
A
I'll
go
and
then
I'll
give
you
the
floor.
I
was
gonna,
say
the
exact
same
thing
as
Wes
in
terms
of
moving.
If
we
did
agree
on
a
new
set
of
files
to
ignore
expanding
that
list,
the
way
in
which
we
would
implement
it,
wouldn't
just
be
to
like
do.
A
breaking
change
would
be
to
first
warn
and
then
and
then
to
implement
that
right.
So
you
would
give
plenty
of
time,
for
you
know
the
ecosystem,
to
realize
that
this
that
there
would
be
that
kind
of
change
happening.
A
Potentially,
when
you
were
doing
a
publish,
we
would
be
warning
that
you
know
you're,
including
files
that
eventually
will
be
ignored
in
the
future.
That
is
like
a
possible
solution.
That's
like
I,
think
the
implementation
of
how
to
roll
this
or
how
to
roll
something
like
this.
Like
a
change
like
this
and.
D
So
I
was
gonna
say
that
we
we
have
this
this
plan
to
have
a
warning
or
a
confirmation
before
you
publish
and
right
in
that
confirmation,
we're
gonna
have
that
list
of
files
that
we
display.
So
what
we
could
do
is
you
know
if
there
are
any
files
of
matching
a
particular
base
name
pattern,
then
you
know
the
default.
Confirmation
is
no
and
we
print
a
warning.
This
is
like
hey.
You've
got
like
a
you
know,
dot
swp
file
here.
Are
you
sure
you
want
publishing
the
the
list?
D
That's
in
NPM
Pacus,
the
default
ignored
files
are,
should
really
be
things
that
are
like
actively
harmful
to
include,
or
or
so
so
widely
despised,
that
there's
no
chance
that
anybody
would
or
very
little
chance
and
anybody
would
want
them
in
a
package
and
then
the
workaround
is
you
explicitly
include
them?
If
you
do
want
them,
there,
so
I
think
leaving
that
list
sort
of
as
it
is
or
being
very
conservative
about
how
we
add
to.
D
It
would
probably
be
a
good
idea,
but
things
like
editor
config,
and
you
know
like
your
github
project,
folder
or
whatever
else
we
could
just
handle
that
in
the
in
the
publish
confirmation
step
and
it
doesn't
even
have
to
be
like
this-
is
going
to
stop
working
type
of
warning.
It
could
just
literally
be
like
hey:
are
you
sure
you're?
You
know
you're,
including
your
get
up
folder
here
right.
C
B
B
It
is
possible
that
you
could
have
secrets
in
there
and
I
think
that's
a
fairly
easy
one
right
if
you
had
like
a
secret
for
one
of
your,
even
if
it's
an
encrypted
secret
right
for
one
of
your
things,
I
assume
you'd
prefer
not
to
send
that
out
to
everybody
and
the
github
directory
can
also
get
very
large
much
larger
than
some
of
the
other
ones.
So
I
think
that's
like
a
pretty
clear
one.
That
would
be
a
good
addition.
Obviously
editor
config,
not
as
important
here
but
when
I
think
I'd.
Just
close
the
tab.
B
I
was
looking
at
the
list,
but
I
think
that,
having
a
way
to
add
things
like
this,
so
I'm
thinking
also
like
dot
env
files,
which
is
another
fairly
common
file
that
is
not
currently
ignored.
As
far
as
I
know
is
that
does
that
get
ignored
by
Peck
list,
I'm
I
was
trying
to
look
at
the
pack
list,
documentation,
dot,
env,
no.
B
A
There's
another
one
that
I
noticed
also,
it
doesn't
look
like
we're
checking
for
AWS
like
files
folders,
which
is
a
common
like
tutorial
like
to
be
storing
creds
in
so
that's
a
potential
like
gotcha
for
checking
in
or
distributing
that
as
far
as
I
can
see
in
the
existing
list.
We're
not
looking
for
that
stuff.
So
yeah
iid
have
warning
yeah.
C
Really
like
that,
so
I
gonna
put
out
an
action
item
here
of
basically
closing
this
one.
Opening
anyone
for
a
warning
kind
of
thing
during
publish
I,
think
that
idea
and
that
list
can
be
like
more
I,
think
we
can
find
them
that
way.
It's
gonna
be
way
easier
right.
This
is
just
a
warning,
not
a
an
error
kind
of
thing.
B
B
There
and
why
I
like
the
idea
of
default
is
because
that
it's
Veni
gonna
become
noise
for
many
folks
right.
So
if
you
see
a
warning
every
single
time
about
your
editor
config,
doesn't
that
and
then
suddenly
you
see
your
you
get
blindness
to
this
warning
because
that's
just
what
happens
and
then
suddenly
your
dot
secrets
file
is
in
that
list
and
you've,
just
like
gotten
used
to
ignoring
it.
I.
C
D
C
D
Other
things,
they're
just
sort
of
noisy
and
then
have
a
set
of
warnings
that
we
put
in
the
or
some
kind
of
messaging
that
we
put
in
the
publish
confirmation,
which
could
just
be
an
update
to
the
published
confirmation,
RFC
to
say,
hey
like.
If
there
are
any
files
matching
these
patterns,
then
the
default.
The
default
cook
from
the
command
prompt
is
no,
and
we
print
a
message
saying
that
say
so.
A
Okay,
if
there's
nothing
else
on
that,
specifically,
we
should
probably
move
on
to
issue
number
95
RC,
safe,
pure
flag,
so
I'm
not
sure
again,
the
this
was
championed
by
you
Roy
pretty
much.
This
is
the
Roy
open,
RFC
meeting.
So
it's
good,
you
have
a
stable
connection.
Yeah
did
you
wanna
again
give
a
highlighter?
Yes,.
C
D
We
we
covered
this
four
weeks
ago.
It
looks
like
right.
The
the
different
behavior
with
how
that
save
flag
works
is
significantly
more
tricky
to
get
right.
So
the
way
it's
working
right
now
is
it's
exactly
the
same
as
installed
like
save
prod
or
save
dev
or
save
optional,
so
yeah
I,
don't
know.
I
kind
of
I
kind
of
would
want
to
see
some
clearer
explanation
of
what
exactly
the
the
difference
in
behavior
would
be,
and
and
the
argument
for
it,
and
so
this
is
still
kind
of
in
the
our
RFC
category.
D
C
A
A
C
I
put
it
in
the
agenda,
because
I
would
like
to
hear
Isaac's
thoughts
on
it
because
I
know
Isaac
implemented,
accept
dependencies
to
do
arborist.
So
I'd
like
to
know
if
this
like,
if
it
fulfills
the
expectations,
things
that
they're
asking
about
in
this
perf
C
or
not
or
what
is
the
difference,
if
not
yeah
you.
D
You
know
if
we
just
if
we
just
looked
at
it
as
like,
let's
implement
the
exact
same
type
of
resolutions
that
that
yarn
does
it
gives
you
very
fine-grained
control,
but
it
unfortunately
I
think
exposes
a
lot
of
the
inner
workings
of
like
how
the
tree
is
built
in
a
way.
That's
not
great
and
sort
of
imposes
a
lot
of
adds.
A
lot
of
foot
guns
to
the
experience.
B
C
D
D
You
know
one
of
the
simplest
ways
as
we
do
something
very
much
like
yard
resolutions,
which
would
be
sort
of
the
ultimate
like.
Yes,
you
can
put
any
package,
you
want
anywhere,
you
want
it,
but
getting
that
to
be
getting
that
to
work
properly
within
within
NPM
is
I.
Don't
know
it's
like
doing
that
in
a
user-friendly
way
is
kind
of
tricky
right
like
it
is
very
much
a
power
user
feature
and.
D
B
Yeah
I
will
do
my
best
to
figure
out
what
things
I
feel
comfortable
sharing,
and
you
know
this
is
all
internal
analysis,
so
I'm
I'm
comfortable,
saying
there
are
weird
ways:
people
are
using
things
I'm
a
little
less
comfortable
right
now
until
I
reach
out
to
the
teams
who
are
doing
these
things
to
make
sure
I
understand
why
using
them
as
public
case
studies,
yeah
I'm
not
we'll
see
if
I
can
share
some
of
that
in
the
future.
I'm.
D
Not
sure
I'm
not
suggesting
that
you
share,
like
you,
know
the
details
of
their
project
or
specifically
which
models
are
using
or
even
that
it's
something
happening
at
Netflix.
It
could
just
be
like
you
know,
a
module.
X
has
a
dependency
on
a
Y
and
blah
blah.
Blah
like
you
can
have
the
context
can
make
it
really
generic.
Just
like
you
know,
as
a
user
dealing
with
this
type
of
situation,
resolutions
can
be
used
in
this
way.
Sure.
D
The
other
problem
that
I
have
with
or
the
other
I
don't
know
the
problem,
but
it's
it's
sort
of
an
unfortunate
feature
of
resolutions,
in
my
opinion,
is
just
the
the
naming
convention
with
sort
of
how
you
define
which
module
you
want
to
upload,
upgrade
or
change
to
a
given
resolution,
and
it
the
the
challenge
from
a
sort
of
elegance
of
tree
management.
Point
of
view
is,
we
have
to
you
know
like
let's
say
you
have
D
to
slash
left
pad
that
you
want
to.
D
You
know
just
looking
at
like
the
yarn
resolutions,
health,
ox
d
to
slash
left
pad,
you
want
to
set
at
version,
1.1,
dot,
one
and
then
C,
slash,
star,
star,
slash,
left
pad.
You
want
to
set
it
caret
1.1.2
and
at
the
root
level
you
have
left
pad
100.
So
the
thing
that's
tricky
about
this
is
now,
instead
of
having
the
edge
definition,
be
sort
of
solely
dependent
on
that
node,
it's
dependent
on
both
the
node.
C
D
And
the
the
root
code
that
it's
in
and
it
has
to
check
to
see
if
it's
in
that
in
that
list
and
this
gets
into
tricky
situations
where
like
see,
depends
on
something
else
which
depends
on
left
pad.
And
now
we
have
to
make
sure
that
we,
you
know,
we
said
essentially
have
to
create
that
conflicting
dependency
invested
in
the
appropriate
place
so
have.
B
B
Off
the
deep
end
right
and
the
reason
they're
that
I,
so
so,
if
you
take
this
to
its
ultimate
conclusion,
I
think
their
decision-making
stands
as
valid.
I
think
the
problem
is,
we
should
never
take
it
to
that
ultimate
end.
Conclusion:
where
you're,
like
yeah,
we
can
solve
for
every
single
use
case
under
the
Sun
with
a
robust.
You
know
DSL
here,
because
that's
not
what
people
really
want.
What
people
really
want
is
I.
B
Have
this
one
damn
thing:
minimus
tits
complaining
fix
it
right
and
it's
like
all
I,
want
is
to
say
blanket
fix
the
minimis
thing,
so
it
stops
telling
me
I'm,
audit,
failing
right
and
so
I
think
we
just
need
to
make
sure.
We
don't
go
too
far
down
the
road
of.
Let's
make
this
like
that
level
of
robust,
because
then
we'll
end
up,
saying
yeah,
we
should
follow
them
on
using
Prolog.
B
A
I
think
what
you're
saying
wes
is
accurate,
where
exactly
the
use
case
is
I
want
to
quickly
patch
this
thing,
so
I
stop
getting
bugged
about
it
and
which
may
highlight
the
actual
root
cause
of
why
people
need
resolutions
which
is
like
they're
getting
bugged
by
some
sort
of
CVE
or
security
or
audit.
Like
warning,
we.
B
B
There's
another
use
case
in
its
bug
fixes-
and
this
is
a
very
common
one-
is
you
have
a
fork
of
something
because
you're
working
on
trying
to
get
it
merged
by
the
open
source
project
and
everything
in
between,
because
it's
a
deep
transitive
and
you
don't
have
time
to
hold
your
product
up.
So
you
want
to
resolve
it
to
your
internal
fork,
publisher,.
B
And
this
is
it
so
say
it's
not
in
that
case
it
might
be
also
replacing
the
DEP,
but
sometimes
like
what
we'll
do
is
we'll
shadow,
a
public
dependency
with
an
internal
one
and
then
do
a
resolution
so
that
we
get
the
like
beta
shadowed
version.
So
we'll
have
like
you
know
in
the
registered
proxy,
will
publish
lodash
at
you
know,
4.0
internal
fork,
bug
fix
one
right
or
something,
and
you
want
the
resolution
to
point
to
that
internal
shadow
temporarily
right,
which
is
a
different
thing.
D
B
B
Especially
like
once
yeah
I
mean
may
or
may
not,
especially
maybe
once
there
are
some
stronger
guarantees
between
your
get
state
and
the
registry
state.
That
would
be
fine,
but
there's
a
bunch
of
reasons
why
that
probably
will
never
be
the
case.
You
know
in
in
the
open
source
world
once
some
github
and
you
all
collaborate
a
bit.
You
be
able
to
have
more
guarantees
there,
but
like
between
again
I'm
thinking
internally.
Here
the
guarantee
between
what
we
have
in
stash
and
our
artifactory
is
like
mill
less
than
right.
B
B
So
aliases
help
in
some
cases
here
so
also
aliases
are
fairly
new
as
well
I,
say
fairly.
You
know
so,
like
I,
haven't,
I,
haven't
seen
cases
and
then
been
like.
Oh
yeah
alias
do
this
for
this
particular
case.
Yet
so
I'm
not
sure
I
know
enough
about
the
ins
and
outs
of
them
to
say
if
they
fully
solve
it,
but
right.
B
D
Problem
is
that
nay,
liasing
will
will
will
not
handle
deep
dependencies.
So
if
I,
if
I
have
I
mean
Elias
thing,
would
work
really
nicely
with
resolutions,
but
if
I
had
you
know
if
I
depend
on
lodash
and
I
change
it
to
it,
if
I,
if
I
depend
on
something
that
depends
on
lo
and
there's
a
bug
fix,
I,
don't
float
my
bug,
fix
and
so
I
publish
it
and
then
I
at
the
top
level.
I
say:
I
depend
on
low
at
NPM
:
my
internal
low
at
1.2
degree
when
the
tree
gets
built.
D
My
thing
that
depends
on
low
we'll
look
at
that
and
say:
oh
look,
there's
a
version
of
low,
but
it's
not
one.
That's
gonna
meet
my
dependency
because
it's
actually
this
other
thing.
So
let
me
install
a
new
copy
of
low
and
you're
back
in
the
same
situation
before
so,
for
example,
with
the
minimus
things
would
still
have
the
program
in
it.
Is
there
Britany
the
thing
I
would
still
like
to
do,
though
I
mean
before
we
get
like
we've
we've
identified
that
there's
some
issues
with
the
solution.
D
D
You
know
like
our
RFC
kind
of
kind
of
mode
for
now,
so,
let's,
let's
sort
of
identify
and
go
through
what
those
use
cases
are
and
then
try
to
design
a
solution
that
that
meets
them
with
a
with
a
minimum
amount
of
foot
guns
and
kind
of
overpowered
features,
because
I
do
feel
like
resolutions
is,
is
a
sort
of
overpowered
feature
and
that's
a
that's.
A
hazard.
B
Yeah
and
it's
a
hazard,
we
have
precedents
for
leading
to
a
path
of
you
know
bad
case
right,
which
is
looking
at
what
yarn
and
that's
why
I
say
it's
worth
really
deep,
digging
deep
on
what
the
yarn
v2
solution
is
and
even
reading
some
of
the
threads
on
their
github
about
it,
because
I
think
it
is
a
great
case
study
in
deeply
going
into
an
engineering
task
without
thinking
about
the
the
real
user
cases
and
impact
and
the
product
side.
Yeah
bottom
line
like
NPM,
is
not
a
tool
that
you
use.
D
B
For
you,
so
we
should
also
probably
look
at
what
Gradle
is
doing
and
I'm
sorry
I'm,
bringing
up
a
Java
thing,
I'm
on
a
team
with
a
bunch
of
folks.
So
I'm
learning
a
lot
and
they
have
some
really
interesting
solutions
in
this
space
in
their
tool,
which
might
be
worth
using
as
a
sort
of
a
guide
or
at
least
learning
from
as
well
yeah.
D
B
C
A
C
A
C
I
think
it
is
in
great
position
now
to
be
ratified.
We
discussed
extensively
even
if
that
call,
but
basically
maybe
just
pick
up
quickly
to
a
couple
of
things
that
me
and
Isaac
we
set
up
outside
of
the
calls,
but
basically
we
got
rid
of
the
after
limitation
to
not
publish
the
kind
of
artificial
check
on
publish.
If
there
was
a
workspaces
like
we
would
pretend
we
got
rid
of
that
like
we
might
end
up
to
just
having
to
deal
with
the
package
that
are
published
that
are
already
in
the
registry
workspaces
anyway.
C
D
B
Am
Not
sure
I
will
have
time,
I
trust
you
all
I,
think
we've
had
great
conversations,
and
you
have
heard
my
opinions
enough
to
take
them
into
account
and
well.
I'm
I
will
be
working
with
this
one
way
or
the
other,
and
so
we
can
always
iterate
in
the
future.
So
I
don't
want
to
stand
in
the
way
because
of
my
bandwidth
constraints
sounds.
D
A
So,
with
a
couple
of
minutes
left
here,
we
added
the
notes
from
the
deep
dive,
so
RFC
number
92
staged
workflows
for
CI
a--
and
human
interoperability,
essentially
staged
publishes,
which
we
did
deep
dive
meeting
last
week
on
the
mean
earth
Scott
posted
by
Claudia.
Thank
you
again
for
for
doing
that
and
they're
linked
here
in
the
agenda,
I'm,
not
sure.
If
they're
we
want
to
quickly
Issac.
You
said
you
wanted
to
do
a
Coles
notes
about
that
discussion.
A
D
D
So
the
other
thing
is
the
include
staged.
Instead
of
being
a
boolean,
it
will
be
a
array
of
names,
so
you
can
specify
include
staged
multiple
times
to
have
multiple
packages
on
that
list.
Otherwise
it's
each
one
is
the
name
of
a
package
and
so
forth
at
depth
and
all
transitive
dependencies
of
that
dependency.
It
will
include
include
the
staged
versions
of
those
packages,
and
so
it
seems
like
we're.
We
were
relatively
settled
on
the
content.
D
But
essentially,
if
we
wanted
to
talk
about
it
here,
I
think
whether
I
believe
you
brought
up
some
concerns
about
it
or
something,
but
the
security
detection
case.
We
actually
have
an
issue
with
this
now
on
the
registry
and
it's
not
a
you,
know
public
or
widespread
issue,
but
it
is
a
thing
that
happens
in
NPM
and
get
repos
and
github
as
well,
where
people
publish
something
that
has
a
secrets
file
in
it,
and
it
takes
us
some.
D
You
know
some
like
we
can
tell
if
it
has
a
secrets
file
in
it
when
you
publish
the
thing,
but
at
that
point,
there's
very
little
that
we
can
do
right.
The
options
are
either
if
we
detect
a
secrets
file,
we
we
fail
to
publish
and
it
doesn't
get
published,
and
then
it's
on
you
to
sort
of
like
refactor
your
code
to
make
sure
it's
not
actually
secrets
and
like
sometimes
it's
like
it's
a.
There
was
a
case
of
a
crypto
thing
that
actually
had
a
private
key
that
was
like
should
have
been
there.
D
D
But
what
that
means
is,
if
there's
something
that
is
potentially
malware,
but
we're
not
sure,
then
it
can
be
very
disruptive
to
not
allow
it
to
be
published
because
it
could
be
perfectly
valid,
but
a
human
has
to
look
at
it
and
if
it
is
now
we're
then
we've
just
let
something
go
out
to
the
registry
for
some
period
of
time.
Righty,
even
though
it
tripped
an
alarm,
it's
gonna
take
some.
You
know
some
minutes
or
hours
for
a
human
to
actually
look
at
it.
D
Saying
like
hey
your
your
package,
we
got
it
it's
fine,
but
if
you
want
to
be
staged
for
some
period
of
time,
because
of
reasons
if
you
want
to
install
it
in
the
meantime,
here's
the
command
to
run
to
install
this
package
so
I
think
that
would
kind
of
unblock
folks
who
would
otherwise
be
affected.
If
we
were
too
strict
and
also
give
us
a
little
bit
more
ability
to
make
the
registry
a
little
safer,
yeah.
B
A
I
feel
like
that's
a
status
or
some
sort
of
like
metadata
label
for
that
published
stage,
publish
which
I
think
we
had
spoken
about
internally
before
Isaac
about
the
future
state
that
we
could
get
to
with
with
this
feature
and
functionality
right
like
we
could
eventually
have
some
sort
of
yeah
state
like
security
scan,
is
run
and
then
given
or
it's
pending
being
run.
It
sounds
like
potential
secrets
in
package
could
be
true
or
false.
A
C
D
C
D
D
D
B
D
C
A
Awesome
cool
so
we're
about
five
minutes
over
or
more
just
want
to
be
mindful
of
folks
time.
I
think
that
we
haven't
cued
up
exactly
what
the
next
deep
dive
conversation
is.
So
I
might
actually
put
out
a
poll
right
after
this
with
a
couple
of
topics
or
RC
topics,
so
I
I
think
be
on
the
lookout
there
can.
B
D
Yeah
I
think
resolutions
is
a
good
one.
I
would
like
to
spend.
I
would
like
to
make
sure
that
we
don't
just
say
like
let's
talk
about
yarn
resolutions
and
instead,
let's
say
like,
let's
really
dig
into
use
cases
for
it
without
solutions,
because
that
would
be.
That
would
be
much
more
useful
in
if
some
kind
of,
like
better
understanding
came
out
of
that
for
the.
D
A
A
So
if
it's
bubbling
up
use
cases
as
Isaac
noid
and
that's
you
know,
ideally
what
we're
gonna
focus
on,
but
other
than
that
I
just
wanted
to
say
again,
thanks
for
everybody
jumping
on
today,
and
hopefully
we
can
move
forward
on
a
couple
of
these
threads
feel
free
to
poke
me
if
we've
missed
anything
or
we
didn't
get
anything
today
or
just
feel
free
to
add
comments
to
the
existing
conversations
that
are
happening
in
the
gabrielle,
so
yeah.
Thank
you
again
for
everybody.
Jumping
on
and
I'll
see
you
next
week.