►
From YouTube: Open RFC Meeting - Wednesday, February 16th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live
on
youtube.
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
february
16th
2022
we'll
be
following
along
in
the
agenda
that
was
posted
at
the
npm
rfc's
repo
issue,
530
I'll
copy
and
paste
that
for
folks
and
feel
free
to.
A
If
you
haven't
already
add
yourself
to
the
attendees
list
in
the
meeting
notes,
doc,
which
I
will
just
make
sure
it's
been
spammed
a
couple
times
in
the
chat,
feel
free
to
add
yourself
there
and
quick
reminder
these
code
calls
are
all
are
all
run
under
a
code
of
conduct.
We
ask
that
you
please
be
kind
to
each
other
and
and
wait
for
others
to
finish
speaking
or
raise
your
hand
if
you'd
like
to
make
point
and
we'll
call
on
you
and
the
code
of
conduct
there
is
linked.
A
Another
sort
of
announcement
here
is
that
the
openjs
world,
which
is
happening
in
conference,
which
is
happening
in
june,
looks
like
potentially
they've
extended
their
cfp
out
a
week
roughly.
So
if
you
were
considering
putting
up
a
presentation,
you
got
a
little
bit
more
time.
There
feel
free
to
you
know,
join
us
most
of
our
team.
A
Hopefully
we'll
will
attend
either
virtually
or
in
person
or,
potentially
speaking,
would
be
really
great
if
we
could
and
we'll
definitely
be
participating
in
the
collab
summit,
which
will
happen
shortly
after
the
conference.
A
One
other
quick
note
which
I
shared
here
in
the
channel
before,
but
the
state
of
js
2021,
just
came
out
as
well
npm.
The
npmcli
was
a
bit
of
focus
there
or
monterrey,
but
repo
support
and
tooling
in
general,
is
a
bit
of
a
focus
this
year,
which
is
awesome
to
see.
So
you
know
that's
great
to
hear
that
you
know
the
investments
we've
been
making
this
past
year
are
paying
off
and
that
folks
are
interested
in
consuming
workspaces.
A
The
workspaces
features
as
well
as
interested
in
seeing
what
we
we
do
next,
so
any
other
announcements
folks
want
to
share.
B
If
not,
you
can
dive
into
oh
go
ahead,
shout
out
to
congrats
to
jordan
on
his
board
point
to
whatever
pointed
to
the
board
silver
director,
something
like
that.
Don't
have
coal.
I
got
silver.
A
Yeah
thanks
for
noting
that
owen,
I
forgot
to
mention
yeah
jordan.
You've
been
adding
to
the
board
of
directors
at
the
openjs
foundation.
I
think
that's
awesome.
I'm
excited
to
see
what
you
do
there.
I
know
you're.
I
don't
know
how
you
have
the
energy
and
time
that
you
do
to
keep
up
with
all
the
different
conversations
that
I
know
you're
a
part
of,
but
I
appreciate
that
you're,
the
you
know,
sense
of
reason,
a
lot
of
times
in
in
a
lot
of
conversations.
A
So
I
really
appreciate
you
know
on
behalf
of
community.
I
appreciate
that
you're,
you
know
still
investing
your
time
and
effort
there.
So
thanks
happy
now
cool
jumping
into
the
relatively
small
agenda
we
had.
I
know
nil
from
our
team
wasn't
able
to
join
here,
but
it's
pr
525.
A
This
is
stop
ignoring
or
start
stop,
start
ignoring
and
stop
storing
integrity,
values
for
get
dependencies
and
I'll
share
that
rc.
Here
I
guess,
there's
a
quick
high
level
synopsis
of
this
we've
been
noticing
that
we
can't
consistently
create
integrity,
values
across
platforms.
A
So
the
with
the
recent
m1
chip
change
in
macbooks
and
just
in
general,
we've
had
this
problem
bite
us
many
times
where
folks
are
generating
lock.
Files
with
the
integrity,
values
that
are
for
githubs
that
are
are
not
consistent
across
the
machines
that
they're
using,
and
this
causes
a
lot
of
churn.
It
causes
a
lot
of
breakage
and
and
just
a
lot
of
confusion
for
folks.
A
So
this
proposal
that
they've
put
together
here
essentially
addresses
that
by
saying
you
know
in
the
next
major
can
we
drop
the
integrity
value
all
together
with
for
forget
dependencies,
especially
since
we
don't
really
manage
get
dependencies?
They're
not
coming
from
the
registry.
A
Can.
Can
this
be
another
sort
of
thing
that
we
sort
of
drop
on
the
floor?
It's
sort
of
an
indication
again
that
you
know
git
dependencies
are
not
the
same
as
as
as
package
packages
hosted
in
the
the
npm
registry
and
you
don't
have
the
same
level
of
security
around
those
and
yeah.
Definitely
like
it's
a
bit
of
a
code
smell
for
sure,
but
I
I
we
feel
like
this
might
be
the
only
path
forward
to
to
fix
sort
of
the
problem
that
we
have
right
now.
A
D
Yeah,
I
think
this
is
related,
but
might
be
unrelated
to
this
rfc.
I'm
definitely
I'm
behind
the
site.
The
original
idea
for
this
rfc
here,
but
that
might
even
go
further
and
just
propose
a
question
here.
What
if
we
just,
maybe
not
a
deprecation,
but
we
kind
of
steered
users
away
from
ever
using
my
dependencies
like
that,
so
I
kind
of
been
yeah.
D
I'd
say
that,
because
I've
been
working
this
week
with
a
little
bit,
that
is
touching
the
parts
of
the
cold
in
pocochi
that
handles
skit
dependencies
and
it
is
not
good.
So
it's
yeah.
So
I
don't
know
I
feel
like
we
could
even
expand
this
rfc
or
maybe
a
second
one
that
could
expand
on
this.
To
maybe
just
put
us,
you
know
as
a
best
practice.
D
Maybe
we
go
ahead
and
even
deprecate
through
warnings
if
in
case
someone
is
using
bit
dependency
in
their
install
tree
because
most
users,
they
won't
even
be
aware
of
so
maybe
that
separate
discussion
like
we
maybe
can
be-
have
separate,
but
I'm
definitely
on
board
with
the
idea
here,
because
it's
yeah.
C
Well
yeah,
so
I
had
the
question
in
chat
about
are:
is
there
any?
I
don't
know:
if
is
there
an
integrity,
hash
stored
for
file
dependencies
like
bundled
depths
thing
and
basically
like
and
the
leading
question
there
is,
it
seems
like
the
only
thing
that
makes
sense
to
store
an
integrity.
Hash
for
is
something
that
comes
from
a
registry,
and
if
this
doesn't
completely
get
us
there
then
could
we
extend
it.
So
it
does
and
then
to
roy's
question.
C
It's
already
been
a
best
practice
for
a
long
time
that
git
is
for
development,
not
consumption,
and
you
should
only
ever
npm
install
from
registries
for
many
many
years.
It's
a
critical
thing
to
be
able
to
do
for
certain
edge
cases
and
workflows
and
stuff.
So
I
would
love
to
see
it
deprecated
as
long
as
no
one
ever
expects
to
remove
it.
F
Yeah,
I
would,
I
think,
maybe
long
term
what
we
should
do.
I
agree
about.
You
know
only
storing
integrity
checks
for
for
packages
that
are
in
that
are
in
a
registry.
I
think,
maybe
long
term.
We
look
at
this
as
as
saying
you
know,
you
know
if
you
have
get
dependencies
locally,
that's
fine,
but
as
soon
as
you
have
get
dependencies
that
are
tertiary
right,
we
should
warn
and
maybe
long
term
the
default
would
be
to
not
resolve
those
dependencies.
C
In
the
short
term,
as
much
as
I
would
love
a
world
where
git
depths
weren't
allowed
in
transitive
like
in
published
packages,
basically
I
don't
think
that's
practical
either
as
like.
I
I
there's
I'm
as
as
everyone
I'm
sure
who
talks
to
me
for
more
than
five
minutes
knows.
I
have
lots
of
strong
opinions,
and
one
of
those
includes
the
one
I
already
voiced,
which
is
that
you
should
never
install
from
git.
C
C
So
I
I
do
feel
that
we
should
commit
to
always
allowing
git
depths
to
be
installed
in
all
the
ways
that
they
are
now
but
because,
like
like
deprecation
means
two
things
in
general
right.
One
and
it
can
be
one
or
both
of
them,
one
of
them
is
discouragement
and
the
other
one
is
eventual.
You
know
warning
that
it
will
be
removed.
I
think
that
discouragement
is
a
always
a
wonderful
use
case
of
deprecation,
but
in
this
case
I
don't
think
it
would
actually
be
a
good
thing
to
ever.
D
Yeah
and
just
want,
once
again,
I'm
gonna
propose
adding
a
config
value
so
that
we
can
opt
in
to
the
behavior
of
just
skipping
dependencies
right
like
making
that
an
error,
then
that
can
be
added
in
a
minor
version
of
npm.
Then
eventually
in
the
future,
we
can
flip
this
that
switch
and
make
that
the
default
behavior.
If
we
ever
decide
to
make
so.
A
Yeah,
that's
one
way
forward
for
sure
and
definitely
something
that
we
could
provide
as
like
a
feature.
E
A
Will
add
some
value,
I
think
the
not
even
so,
we've
been
talking
about
warnings,
we're
talking
about
deprecation
of
git
depths,
which
kind
of
like
goes
off
into
a
new
tangent
that
isn't
really
associated
even
with
like
this
specific
rfc,
but
it's
definitely
something
that
came
up
as
we
were
looking
at
this,
and
especially
as
we're
considering
how
do
we
create
and-
and
I've
said
this
before
in
these
calls-
how
do
we
create
more
stability
in
installations,
and
how
do
we
create?
Reproducible
builds
like
how
can
we
do
that?
A
How
can
we
get
closer
to
that
goal?
Part
of
that
is
removing
the
immune
like
mutable
depths
and
get
a
git
dependency
is
a
mutable
depth,
and
a
third-party
dependency
like
guitar
ball
is
another
example.
Is,
is
potentially
another
artifact
that
you
might
not
trust.
You
know
it's,
it's
not
the
you
know.
A
So,
as
we've
talked
about
this
internally,
you
know
one
thing:
that's
come
to
mind
for
me
personally
is
not
maybe
even
warning
or
deprecating
these
or
are
not
supporting
these
types
of
dependencies,
but
just
surfacing
the
information
that
is
critical
for
end
users
to
make
decisions
about
and
to
be
warned
about
these
types
of
dependencies,
and
I
think
that
that
information
is
the
hosts,
and
so,
if
we
were
to
similar
to
the
deprecation
warnings
ux
that
we've
just
that
whole
you
know
process
we
went
through
to
clean
up
the
ux
of
deprecations,
at
least
in
the
rfc.
A
There
could
be
potentially
a
line
item
post,
install
which
notes
the
number
of
host
names
or
our
domains
in
which
packages
were
fetched
from.
So
if
we
say
100
packages
installed
from
five
hosts,
that's
going
to
be
indication,
I
think,
or
a
code
smell.
I
think
enough
to
end
users
to
go
dig
in
to
like.
Where
did
this?
These
packages
come
from.
That
sounds
kind
of
scary.
A
Query
functionality
is
definitely
on
our
our
radar
right
now,
but
that
that
sort
of
information
over
sort
of
deciding
for
the
end
users
like
what
they
care
about
is,
is
probably
important
to
bubble
up
first
and
foremost,
and
then
we
can
also
provide
features
to
like
then
ignore
those
types
of
depths.
If
you
want
to
or
or
to
dig
into
that,
join
us
your
hands
up.
C
Node
has
a
policies
feature
which
npm
doesn't
look
at
and
it
certainly
it's
fine
that
it
doesn't
look
at
it
yet,
but
one
of
the
things
people
will
use
that
feature
for
is.
I
want
to
prevent
my
node
programs
from
calling
out
to
internet
places
that
I
don't
know
about
so
things
can't
be
exfiltrated.
C
Npm,
post,
install
scripts
and
dependency
fetching
do
not
have
that
benefit,
so
it
might
be
useful
to
explore
not
as
part
of
this
rfc
obviously
but
explore
npm
respecting
node's
policy
features
because
then
dependency
fetching
as
well
as
install
script
network
access
could
perhaps
be
gated
in
similar
ways.
A
Definitely
yeah,
I
know
bradley
had
come
to
drc
calls
last
year
the
year
before
even
talking
about
the
work
that
was
being
done
with
the
I
think
it's
is
it
still
experimental
policies,
and
I
likened
that
concept
to
what
I've
seen
work
in
the
extension
web
extension
ecosystem
with
web
manifest
files
and
permissions,
because
permissions
map
back
to
like
the
access
that
a
an
extension
is,
is
going
to
be
granted
by
the
end
user
and-
and
so
that
includes
you
know,
access
to
to
browser
tabs
to
certain
information
within
the
browser
context-
and
you
know
I
think,
where
we
landed-
was
a
lot
of
folks
who
are
just
going
to
turn
on
everything
or
nothing.
A
C
More
and
more
often
off
topic,
but
the
like
there
is
something
to
be
said
for
moving
us
toward
an
ecosystem
where
package
maintainers
declare
capabilities
of
their
pack,
that
their
package
needs
and
like
where
use
application.
Users
could
then
decide
if
they
want
to
permit
certain
capabilities
or
they
could
sort
of
generate
or
add
to
the
lock
file.
C
You
know
saying
this
package
only
needs
these
capabilities,
so
if
suddenly
a
patch
version
of
this
package,
some
like
starts
needing
file
system
access,
you
know
either
don't
allow
it
or
don't
install
it
or
whatever,
like
there's
a
lot
of
obvious
things
there,
and
you
know,
I
wonder
if
tying
that
into
this
would
help,
because,
similarly,
a
package
could
declare
it
needs
git
dependencies
from
this
url,
and
then
that
could
be
something
that
application
users
decide
to
ex.
You
know
explicitly
allow.
A
Api
right
now
is
very
verb,
like
verbose
like
like
it's
very
like
you
need
to
tooling
to
almost
generate
the
the
policy
file
for
you
or
the
the
the
policy
config,
because
it
deals
with
like
pass
and
and
yeah
it's
it's.
I
think,
really
tough,
because,
especially
like
that
nuance
of
giving
this
one
package
access
to
get
depths
like.
How
do
I
express
that
in
package.json?
A
Let's
say
right
like
how
do
I
easily
express
that,
so
it
may
be
that
npm
does
introduce
like
some
kind
of,
and
I
go,
I
keep
going
back
to
what
the
browser
and
web
extension
ecosystem
has
done,
because
the
permissions
field
for
in
web
manifest
spec
is,
is,
I
think,
the
closest
thing
and
and
most
succinct
thing
that
I
think
that
we
could
potentially
offer
and
but
the
only
enforcement
that
we
can
provide
as
a
package
manager
is.
A
So
there's
that's
like
that's
the
the
concern
I
have
is
that
you
know
we
might
be
able
to
make
enforce
those
those
policies
on
our
end,
but
then
potentially
code
still
and
can
execute
later
on,
when
when
somebody
executes
something
with
like
the
note
runtime
so
yeah,
anybody
else
have
any
thoughts
or
feelings
on
on
this,
like
is
the
going
back
just
to
the
the
actual
context
of
of
this
rfc
like
if
we
drop
the
integrity
field
for
get
depths
just
in
general
in
the
next
major
nobody's,
gonna
really
complain.
C
The
only
question
I
would
have
is
doesn't
tooling
already
have
to
assume
that
there
might
not
be
an
integrity
field,
so
who
would
it?
If
so,
who
would
it
break
to
remove
it?
Now.
A
Okay,
you
you,
let
me
let
me
circle
back
on
that,
but
that's
a
good
like
does
it
need
to
be
a
major.
I
guess
is
the
the
point
you're
making
yeah.
D
A
Yeah,
okay,
yeah.
We
we've
obviously
got
some
like
high
profile
maintainers
like
poking
us
on
this,
which
is
why
it's
come
to
the
our
forefront
again
so
yeah.
It
might
be.
C
A
Yeah,
it's
tough
to
like
with
something
like
this.
It's
tough
to,
I
think,
get
folks
to
use
a
config
like
like
it's.
Do
you
actually
get
a
enough
data
back
from
from
folks
like
this?
Is
the
sample
size
big
enough,
and
since
we
feel
that
right
now,
basically
the
feature
is
broken
right.
That's
that's!
What
we're
saying
like
the
generating
integrity
value
is
not
consistent
across
machines
so
like
that
effort
gets
up
so
that
if
it
features
broken
it,
it's
not
doing
what
we
intended
it
to
do.
A
That's
a
good
point:
jordan,
we'll
take
that
note
and
then
circle
back
on
this.
Unless
anybody
else
had
any
other
thoughts,
feelings
on
the
more
general
broader
get
depths
narrative.
We
were
talking
about
okay,
jump
down
to
the
next
rfc,
or
actually,
this
pr
522,
adding
an
option
for
npm
diff
to
ignore
new
line
or
character
returns.
A
D
Yeah,
so
basically
yeah,
that
was,
I
was
just
mentioning
that
like
for
again
definitely
basically
copying
everything
from
get
diff
their
options.
We
just
prefix
everything
with
this
to
avoid
the
hazard
of
different
commands,
maybe
having
conflict,
conflicting
flag
names,
but
yeah
we
should
just
yeah.
I
believe
we
should
just
do
the
same
here
for
writing
this
option.
A
A
Yeah,
I
might
like
the
name
of
the
the
flight
is
the
only
thing
I'm
not
like
a
huge
fan
of,
but.
D
Yeah
yeah,
we
follow.
I
personally
I'd
like
to
just
follow
the
standard
like
doesn't
want
like
I
don't
want
to
get
into
the
merit
if
it's
a
good
standard
or
not,
but
basically
the
names
of
the
flags
right
now
are
the
same
as
in
git,
but
it's
prefixed
with
the
diff.
So
I'd
say:
let's
just
stick
to
the
same
standard
that
because
that's
what
users
will
expect
right.
D
I
think
it's
ignore
cr.
I
think
it's
mentioned.
There
ignores
your
eol,
the
long
version
of
it.
If
there's
a
short.
A
A
Moving
on
to
the
next
item
we
had,
which
is
pr
4260,
this
is
actually
a
pull
request
that
we
had
opened
by
the
white
source
team
to
add
a
refi
hook
to
arborist.
I
know
that
they
joined
a
few
weeks
back,
aren't
on
this
call
today.
This
continues
to
be
something
we're
investigating,
though-
and
I
guess
the
update
here
is
you
know
this
is
something
we
could
still
land
within.
A
F
Yeah,
I
just
wanted
to
clarify
that
this
this
pr
was
migrated
from
arborist
to
the
main
one.
So
I'm
not
actually
the
author
there.
The
other
thing
I
wanted
to
say
is
that
you
know
I.
I
think
we
need
to
be
careful
about
adding
hooks
as
a
feature,
and
you
know
related
to
some
of
our
script.
Like
event,
life
cycles,
discussions
in
the
past,
where
there's
a
work
in
work
in
progress
rfc.
F
I
almost
think
that,
like
these
kinds
of
eventing
features
should
not
be
surfaced
in
npm
the
cli
itself,
but
maybe
if
you
use
arborist
directly,
you
could
hook
into
these
things,
and
I
think
that
you
know
hooks
or
however
e-scripts
or
however
it's
implemented
within
arborist,
I
think
would
make
sense,
because
we
definitely
do
need
those
events,
but
exposing
that
to
you
know,
npm
opens
us
up
to
exploitation
by
by
packages
during
the
install
process.
F
So
I
think
I
think,
maybe
you
know
short
term,
it's
fine
to
have
hooks
in
arborist,
medium
term,
where
you
know
we're
talking
about.
You
know
some
changes
to
those
workflows
in
arborist
anyway,
and
then
and
then
long
term.
I
think
we
need
to
be
careful
about
what
we
expose
to
the
life
cycle.
Scripts.
A
A
Why,
like
we're
like,
like
it
just
like
needs
documentation,
so
that
the
fact
that,
like
something
like
this,
that
is
very
big
to
us,
I
would
say,
is
getting
floated
in
a
pr
without
actually
having
like
an
rfc
behind.
It
is
kind
of
the
concern.
I
guess
so
like
going
back
to
that
team.
A
I
know
you
know
I've
extended
the
you
know
the
fact
that
we
have
discussions
here
weekly
about
features
that
we
want
to
implement
and
the
fact
that
there's
previous
work
and
then
a
work
in
progress
rfc
for
completely
refactoring.
What
our
lifecycle
events
look
like.
A
My
hope
is
that
that
team
can
maybe
direct
their
focus
to
actually
doing
some
design
work
with
us
here
and
and
take
a
step
back
for
for
now
from
trying
to
implement
this.
The
way
it
is
today
yeah,
that's
just
my
my
own
thoughts
on
it.
Do.
F
You
know
if
their
use
case
requires
it
to
be
implemented
within
the
npm
cli
itself,
or
could
they
use
like
a
custom
tool
that
invokes
arborist.
A
No,
it
has
to
be
in
the
cli
itself.
As
far
as
I
understand
it,
white
source
was
has
a
tool
that
and
folks
can
correct
me
if
they're
wrong,
I'm
wrong
here,
but
it
will
essentially
during
installation,
but
it
taps
into
life
cycle
the
scripts
like
post,
installer,
pre-install
or
install
scripts
to
essentially
blow
up
when
it
sees
that
it's
trying
to
install
that
you're
trying
to
install
a
dependency.
It
knows
that
might
have
a
vulnerability
or
malware
in
it.
A
Pre
preemptively,
given
the
fact
that
sometimes
we
can
be
slow
to
report
on
the
npm
audit
side,
those
same
malware,
so
they're,
obviously
being
very
extremely
vigilant
to
have
a
lot
of
automation
on
their
side
and
their
tooling
to
quickly
capture
what
they
think
to
be
malware
and
they
are
more
proactive,
and
so
they
provide
this
kind
of
tool
that
that
does
this
kind
of
work.
So
jordan,
I
saw
you
on
mute.
Maybe
you
can
add
anything.
No,
no
you're
good.
A
So
there
is
a
use
case
there
right
like
there
is
a
tooling
in
the
uk,
so
this
is
one
example
of
folks
using
install
scripts
for
something
other
than
let's
say,
building
a
package
or
installing
native
binaries.
You
know
this
is
an
example
of
like
this
is
for
for
security
purpose,
which
is
has
a
legitimate.
A
I
guess
place.
How
do
we
provide
that?
That
team,
with
better
tools
and-
and
so
I
suggested
overrides,
potentially
as
an
option
for
them,
they
could
be
maintaining
a
set
of
known
bad
versions
that
generates
an
overrides
file
that
can
be
utilized
if
they
are
controlling
the
environment.
I
feel
like
that's
the
only
way
they
can
truly
like
do
do
some
of
this
work.
It
feels
like
you
know.
Potentially
they
could
be
shelling
out
to
you
npm
or
wrapping
npm.
I've
seen
tools
do
that
as
well.
A
Mpq
is
a
tool,
that's
like
that,
where
it
essentially
wraps
npm
and
provides
its
own
set
of
security,
guidance
and
sort
of
informed
decisions
around.
What
makes
what
what
is
you
know,
this
good
security,
hygiene
and
practice
in
terms
of
installing
packages
and
sort
of
warrants
you
ahead
of
time?
That
might
be
a
path
forward
for
that
team,
but
yeah.
I
don't
necessarily
think
we
want
to
like
walk
back
and
get
closer
to
the
v6
version
we
had
with
the
lifecycle
scripts
that
we
had
there.
A
D
A
Yeah
I
I
I
noted
that
we
could
add
that
that's
kind
of
like
a
stop
gap
for
for
a
lot
of
folks.
So
it's
something
that
we
should
quickly
do
once
our
team
is
off
fighting
some
some
fires
and
trying
to
get
a
pair
back
our
priority
one
bugs,
but
it's
definitely
one
of
those
things
that
should
get
done.
I
think,
probably
like
relatively
quickly
in
the
next
quarter,.
A
A
A
D
I
had
a
question
because
we
also
last
time
we
discussed
this.
We
also
touched
on
the
optional
dependencies
aspect
of
it.
Right.
Expanding
to
have
optional
dependencies,
just
have
different
ways
of
installing
or
not
optimal
dependencies
right,
and
that
would
come
together
with
this
as
a
nice,
better
syntax
to
provide
the.
E
A
I
don't
know
if
I'm
going
to
try
to
put
it
into
a
single
rfc.
Let
me
get
some
time
here
to
try
to
fix
this
up
and
then
see
yeah
what
we
would
want
to
do
with
optional
dependencies,
because
it.
A
Yeah
and-
and
I
just
want
to
see
where
the
overlap
is
especially
in
terms
of
the
conditional
like
syntax
like
how
we're
defining
those
like,
is
that
something
that
can
be
shared
across
what
we're
going
to
do
for
optional
dependencies.
A
So
that's
why,
if
I
get
some
more
time
here
and
what
might
be
good
is
to
because
I
live
and
die
by,
my
calendar
is
to
actually
schedule
some
time,
maybe,
and
if
folks,
on
this
call
tierney,
oh
and
jordan,
if
you're
interested,
we
can
even
invite
you,
if
you'd
like
to
to
a
session
to
to
try
to
draft
what
and
sort
of
spec
out
what
that
api
like.
That
could
look
like.
D
Yeah
another
point:
just
to
recap:
if
we
do
it
separately,
we
can
do
a
quicker
rfc
and
even
implementation
for
expanding
the
optional
dependencies
conditions
and
then
that,
if
you
can
get
get
that
in
the
hands
of
users
into
the
end
of
the
ecosystem,
even
different
different
systems
or
packages
like.
E
D
A
Okay,
moving
on
to
the
very
last
item
which
was
associated
with
this:
it's
essentially
the
ellipse
here,
adding
lipstick
fields
to
optional
dependencies.
So
this
is,
I
think,
I
put
this
here
because
it's
essentially
associated
with
this
whole
conversation.
So
I
don't
think
there's
any
update
to
that
either.
D
A
That
brings
us
to
the
end
of
our
agenda
with
18
minutes
to
spare.
Does
anybody
have
any
other
topics
they
want
to
bring
up?
Well,
we've
got
your
time.
C
I
know
I
I
do
think
it
would
be
really
nice
around
the
distribution
stuff
if
there
was
a
way
to
have
the
test
files
and
non-test
files.
I
think
that
would
that
would
please
a
lar
a
lot
of
my
consumers
and
would
allow
me
to
not
break
a
use
case
that
I'm
very
interested
in.
So
I,
like
I'd,
be
more
I'm
more
than
happy
to
make
everyone's
installs
smaller.
C
Something
we
haven't
talked
about
in
a
while
stage
releases
literally
like
so
I
I
will
never
publish
from
ci,
because
that's
the
only
irrevocable
action.
I
only
always
do
that
as
a
human,
but
that
means
that
a
human
is
doing
that
on
their
local
machine.
And
hopefully
it's
the
right
thing
to
publish
like
like
the
right
stuff
is
on
the
file
system.
I
would
love
the
ability
that
that
rfc
promises,
which
is
to
publish
staged
in
ci
and
then
later
have
a
human
validate
that
and
promote
it.
C
So
I
like,
I
feel,
like
the
last
time
we
were,
we
discussed
it.
It
probably
required
a
lot
of
back
end
work
but
like
it
would,
given
the
new
push
towards
security,
it
would
dramatically
improve
improve
the
security
of
double
digits
percentages
of
npm's
download
traffic.
If
I
alone
could
do
this
so
like
it
seems
really
important
to
prioritize
that
back
end
work
and
I
would
really
love
to
take
advantage
of
it
using
two
factor.
C
A
C
A
C
A
C
Publishes
like
package
publishing-
and
there
will
be
con-
like
a
lack
of
consensus
right
about
right
now
about
that,
whereas
if
you
had
staged,
builds
at
two
factor,
you
can
create
a
like
a
scenario
where
every
single
person
says
yes,
this
is
secure,
and
maybe
you
could
also
use
a
two-factor
token
if
you
want
to
publish
from
ci
like
so
that
that
would
be
a
great
place
to
be.
E
Yeah
all
right
sorry
come
on
nope,
no,
I'm,
okay,
I'm
changing
the
topic.
So
if
anyone
else
has
something
I
want
to
put
on
that,
absolutely
feel
free.
Okay,
one
thing
I
do
kind
of
want
to
follow
up
on
is:
I
know
I
put
out
an
rfc
that
I
think
was
accepted.
I
believe
it's
accepted,
or
it's
ready
to
be
accepted
for
npm
audit
licenses.
E
I
had
initially
begun
working
on
that
six
months
ago.
I
got
it
relatively
working
in
that
it
did
what
I
wanted
it
to.
It
turns
out
shipping
that
in
arborist
is
probably
the
better
way
to
do
it,
because
then
we
get
a
lot
of
other
features
for
free
and
I
I
realized
I
was
initially
working
on
this
with
roy
and
then
I
started
working
on
it
with
isaac.
E
I
paired
with
isaac
for
a
while
and
isaac,
and
I
got
into
the
arborist
stuff
a
bit
we
were
looking
at
it
and
talking
about
it
not
actually
implementing
it,
and
that
seemed
to
be
the
path
of
like
this
is
the
actual.
E
This
is
the
correct
way
to
do
it.
We
don't
get
a
lot
of
features
if
we
don't
do
it
through
arborists.
I
I'll
be
honest.
I
don't
know
if
I'm
skilled
enough
to
do
it
through
arborist.
The
arborist
is
a
beast,
and
this
specific
implementation
that
isaac
and
I
kind
of
figured
out
would
work,
is
a
relatively
fundamental
change
to
arborist.
It
was
basically
adding
in
another.
E
I
I
it's
been
like
six
months
since
I've
looked
at
the
codes,
I
don't
totally
recall
it,
but
basically
adding
another
class
that
allowed
this
information
to
be
a
bit
more
available.
E
Is
that
something
that
I
should
try
to
try
to
figure
out
myself
or
is?
Is
that
something
that
either
someone
in
the
community
wants
to
work
on?
Or
is
that
something
that
the
npm
team
might
be
able
to
pick
up
or
be
interested?
In?
So.
A
C
Well,
and
also
it's
a
little
there's,
it's
blurry
lines,
because
rfcs
are
usually
for
cli
things
only
and
because
this
requires
back-end
work.
It's
like.
E
That's
audit
assertions
different
than
audit.
Oh.
E
Yes,
I'm
also
excited
about
that.
One
yeah
audit
licenses
is
specifically
what
I'm
talking
about
is
that
one
still
open.
A
Yeah,
so
it's
pr
rfc
182
npm
audit
licenses,
yeah,
which
is
100
best,
served
and
best
built
into
our
burst
itself,
since
it
generates
all
the
metadata
associated
with
audits
and
metaboli
vulnerability,
yeah
yeah.
I
think
that
we
need
to
get
somebody
else
to
pair
with
you
or.
E
I
I'm
happy
to
pair
on
it.
Audit
or
arborist
is
just
it
hurts
my
head.
I'll,
be
honest,
it
is
intense
and
especially
adding
an
entirely
new,
like
basically
redefining
how
part
of
the
at
least
you
know,
and
what
isaac
and
I
were
talking
about
redefining
how
the
fundamental
structure
works
slightly
and
expanding.
That
is
like.
I
do
not
have
the
context
already
around
our
bris
to
be
able
to
do
that
myself.
I
don't
think
so.
Yeah.
A
E
A
The
information
rc
incoming,
I
know
get
me
hit
me
over
the
head.
If
it's
not
open
by
next
next
week,
go
ahead
right.
D
E
Yeah,
I
think
I
think
there
there
might
have
been
some
some
slight
details
that
change
if,
given
that
it
goes
into
into
arborists
right
like
here
in
this
pr,
I
specifically
call
out
using,
I
think,
like
you're,
using
the
tool,
but
the
tool
becomes.
I
forget
what
the
tool
is
called,
but
the
tool
becomes
mildly
irrelevant.
If
I
recall
correctly,
like
we're
not
directly
relying
on
it
to
like,
you
know,
not
shelling
out
to
it
yeah
licensee.
Thank
you.
E
We're
not
like
shelling
out
to
it
like
I
was
originally
planning,
and
so
that
changes
some
things
but
yeah.
I
will
I'll
happily
go
and
re
re-review
it.
I
might
not
get
to
it
before
the
next
rfc
meeting.
I
am
out
most
of
next
week
but
yeah
happy
to
have
her
to
re,
revisit
this
and
get
it
done.
A
Yep,
I
think
that
would
be
great
yeah.
My
concern
is
definitely
that
I
know
that
you're
extremely
smart
and
the
fact
that
you
find
it
permissively
hard
to
do
something
that
seems
also
like
on
on
from,
like
a
thousand
foot
view,
seems
pretty
simple
to
do
so.
I'm
I'm
definitely
interested
in
facilitating
this
in
a
more
general
sense
soon.
So
yeah.
E
Cool
yeah-
and
I
I
I'm
happy
to
pair
on
this
with
folks-
you
know
I'm.
I
just
wanted
this
to
move
forward,
because
I
think
it's
something
that
is
positive
for
the
ecosystem.
I
personally
fundamentally
believe
that
licensing
should
not
be
locked
by
paying
money.
I
think
that's
absurd,
so
yeah
I
I
want
to.
I
do
want
to
see
this
progress
for
sure.
A
Cool
any
other
items,
questions
topics
folks
want
to
chat
about.
We
have
about
seven
minutes
left.
A
If
not,
I
will
give
you
all
some
time
back
today
and
it
sounds
like
we
got
a
couple.
Takeaways
expect
me
to
reach
out
to
try
to
schedule
a
call
and
to
talk
about
package
distributions
and
then
also
expect
me
to
to
do
a
bit
of
work
on
the
rc
that
I
keep
saying
but
won't
name.
I'm
happy.
C
In
one
more
quick
thing,
the
explain
stuff
we
talked
about
last
week:
where
would
we
land
on
that?
Is
that,
like
we
just
need
to
make
a
pr?
Someone
needs
to
do
it
or
is
just
need
to
fix
it
yeah?
Okay,
just
sure
it
should
work
like
you
said,
should
work
without
I
have
two
of
them,
but
they're
both
related
one
was
about
only
pride
and
the
other
was
about
without
reifing
on
modules.
E
A
Great
well
with
that,
I
will
see
you
folks
next
week,
hopefully
or
async
in
stock
cheers.
Thank
you.