►
From YouTube: Open RFC Meeting - Wednesday, August 3rd 2022
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
A
A
We
ask
you
to
please
be
kind
while
you're
on
these
calls
raise
your
hand
if
someone
else
is
speaking
and
just
overall,
please
be
mindful
of
others
and
respectfuls
others
of
others.
A
This
stream
is
streamed,
live
on
youtube
and
recorded,
so
just
be
mindful
of
that
as
well
quick
announcements,
so
our
team
just
launched
npm
v816.
A
So
some
folks
on
this
call
helped
a
lot
with
this
roy
aderno,
our
former
team
member,
who
did
a
bunch
of
the
work
michael
garvin,
did
a
ton
of
work
as
well
to
pick
up
after
roy
as
well,
and
we
got
over
the
finish
line
here
today.
We're
going
to
make
some
noise
about
it
this
afternoon
and
have
a
blog
post
or
a
changelog
post
out
on
github
for
folks
to
learn
a
bit
more
about
npm,
query,
dependency,
selective
syntax
that
we've
implemented
and
also
future
iterations.
A
We
want
to
make
and
improvements
we
want
to
make
to
it
and
the
selector
syntax.
So
quite
quite
a
great
day.
We're
really
excited
about
what
this
means
and
what
we
do
with
npm
queries.
So
just
want
to
share
that
with
folks
who
are
very
interested
about
what
we
can
do
in
terms
of
expanding
the
the
syntax
as
well.
A
So
there's
lots
of
work
ahead
of
us
and
yeah
very,
very
excited.
Did
anybody
else
have
any
other
announcements
they
wanted
to
share.
B
A
In
let
me
quickly
change
that
if
you
refresh
or
try
now,
you
should
be
able
to
edit
and
add
yourselves.
A
If
not
roy,
you
said
you
want
to
add
an
item
to
the
agenda.
Just
want
to
make
sure
we
capture
that
we
can't
even
start
with
that
since
you're.
Here.
C
Yeah
yeah,
I
actually
went
ahead
and
put
it
in
the
agenda
there.
The
first
item
there
but
yeah.
Let
me
go
quick,
feel
free
to
unbox
the
conversation
here,
because
I
just
kind
of
want
to
get
some
spoilers.
So
basically,
lauren
is
from
the
google
open
source
security
team.
I
invited
him
over
to
come
and
chat
with
you
folks,
too
and
yeah,
and
I
think,
like
basically
they're
building
a
whole,
an
entire
suite
of
signing
and
I'll.
Let
him
talk
about
more
of
that
part.
C
That
aspect,
but
I
was
thinking
like
how
I
believe
there
is
an
opportunity
here
to
continue
on
expanding
on
audit,
and
I
know
we
recently
added
odd
signatures
to
to
check
for
signatures
and
they're
building
an
entire
security
framework
that
can
be
also
validated,
so
I
believe,
there's
an
opportunity
to
maybe
continue
to
expand
audit,
to
also
check
for
all
that
extra
validation,
and
I
know
that
yeah
laura.
Why
don't
you
talk
a
little
bit
more
about
the
salsa
initiative.
D
Yeah
so
yeah
hi
everyone,
I'm
laurent,
I'm
in
the
I'm
in
google.
I've
heard
about
jordan
via
the
npm
best
practices
and
scorecard
as
well
good
to
see
you
in
person.
So
I
don't
know
how
many
of
you
have
heard
of
the
initiative
called
the
salsa
slsa
and
six
store.
A
So
maybe
I
should
speak
to
this
a
little
bit
before
you
get
too
head
too
ahead
of
it.
We
actually
might
be
discussing
this
quite
a
lot.
Next
week
we
actually
have
been
doing
a
lot
of
internal
investigation
into
salsa
six
door
and
and
a
number
of
other
computing
as
well
notary
services,
no
v2
azure
just
came
out
with
a
acl,
so
yeah
we've
been
talking
about
this
quite
a
lot
internally.
A
We
have
a
bunch
of
documents
that
we
would
love
to
share
and
can
speak
to
a
little
bit
more
in
the
next
week
or
so
so
and
and
by
the
way
we
will
be
speaking
to
them
in
this
forum.
So
this
is
the
right
place
to
be.
If
you
want
to
continue
to
collaborate
with
us,
I
think
what
we're
speaking
to
in
terms
of
improvements
to
audit,
that
is
also
something
on
our
roadmap,
something
that
we're
considering
in
terms
of
like
what
we
can
do
to
continue
to
improve
that
experience
for
us.
A
I
think
there
is,
and
just
personally
and
I'll
say
my
piece
and
then
let
you
can
continue
specifically
with
salsa,
I'm
a
big
concern
about
the
state
in
which
the
steps
are
at
right
now,
there's
it's
not
also
v1
yet
right,
and
they
also
don't
have
any
sort
of
guidance
or
recommendations
or
accreditation
for
getting
to.
Let's
say
it's
also
level
three
in
in
place
yet-
and
I
know
that
there's
a
lot
of
work
happening,
working
groups
happening
in
the
open
ssf
to
deal
with.
A
You
know
six
door
and
talking
about
package
signing
package,
integrity
ecosystem.
You
know
supply
chain
integrity
and
our
team
is
very
much
aware
and
very
much
wanting
to
work
with
those
teams
to
improve
the
state
of
you
know:
supply
chain
integrity.
Signing
is
just
one
piece
of
that.
We
have
in
the
last
year,
talked
about
trying
to
work
towards
immutable,
installs
immutable
installation.
A
I
think
that
will,
if
we
get
to
that
place,
that's
actually
much
more
of
a
win
for
us
in
terms
of
eventual
s-bomb
creation
and
and
actually
trust
within
the
between.
You
know,
different
installations.
The
idea
of
like
trusted
builders
and
trying
to
tie
a
package
artifact
back
to
a
source
repo
is
a
little
bit
like
I'd,
be
pushing
back
on
this
a
little
bit
because
of
those
attestations
and-
and
we
can
talk
about
that
more
next
week-
I
think
more.
A
I
like
there
will
be
clearly
something
I
can
speak
to
more
next
week,
but
just
wanted
to
get
ahead
of.
I
think
some
of
this
conversation
but
feel
free
to
to
maybe
explain
more
about
maybe
the
work
that
you're
doing
what
else
you
would
like
to
present
like
yeah.
D
Right,
yeah,
no,
that's
really
good
context,
so
I
I
so
you're
right
about
6-0.
It's
not
yet
ga!
I
think
they're
going
to
announce
it
in
october.
D
So
they're
still,
I
guess,
cleaning
up
and
and
productionizing
the
so
that's
correct
accreditation.
Also
yeah
you're
correct,
like
the
levels,
I
guess
the
the
the
current
view
that
we
have
is
that
we
kind
of
trust
github.
So
if
you
build
on
github,
we
kind
of
trust
it.
If
you
build
on
something
like
gcb,
we
like
we,
we
also
cannot
trust
it.
D
So
I
guess
that's
what
I
can
say
about
six
store,
so
where
I'm
more
involved
in
is
is
actually
builders.
So
I
guess
you
touched
upon
builders,
so
we
have
builders
that
run
on
native
natively
on
hub.
D
We
did
a
blog
post
with
jose
palafox
three
months
ago,
and
we
have
so
basically
we
just
use
it's
native
on
github.
We
use
reusable
workflows
to
get
isolation,
and
then
we
can
basically
make
this
a
trusted
builder,
so
yeah
what
I
was
coming
to
talk
about-
and
it's
probably
for
next
week
is
you
know
we'd
like
to
have
a
builder
for
npm.
We
don't
think
it's
very
difficult,
but
you
would
get
automatic.
D
You
know
provenance
generation
and
and
the
binding
to
the
original
repository,
which
might
be
something
that
github
gets
for
free,
but
I
guess
the
rest
of
the
community
doesn't
and
yeah
it's
it's
basically
just
an
extension
of
the
of
the
signature
I
mean
instead
of
just
signing
the
binary
or
like
the
the
table,
you
just
sign
the
table
and
a
little
bit
more
metadata
and
yeah.
That's
all
that's
that's
kind
of
what
we
were
trying
to
do,
because
I
saw
that
you
announced
support
for
six
store
and
so
the
only
I
guess.
D
The
only
thing
that
we
wanted
to
do
is
create
the
builder
and
then
let
npm
decide
where
you
know
everything
leaves
and
let
the
client
decide
what
you
know
they
can
download
it
like
like
a
signature
or
yeah.
So
that's
kind
of
the
context
that
then.
A
I'll,
let
jordan
go
and
then
I
will
correct
one
thing
in
terms
of
the
support
that
you
speak
to
at
least
before
I
let
go
here,
the
sport
with
github.
I
think
we're
supporting
exploration.
I
I
would
not
say
that
at
least
within
npm
we
are
we're
exploring
this
area
for
sure
we're
supporting
the
open,
ssf
for
sure
we've
made
investments
there.
We
have
time
and
and
definitely
dedicated
resources
to
open
ssf
and
all
the
different
working
groups
there
in
terms
of
one
particular
technology.
A
I
would
say
that
we
are
exploring
that
and
we're
exploring
sort
of
the
proposals
around
what
these
build,
attestations
and-
and
things
look
like.
So
that's
what
I
can
speak
to
there
without
explaining
more.
I
just
want
to
correct
the
fact
that,
like
as
far
as
I
know,
like
our
our
team,
hasn't
said
anything
if
there's
a
separate
something
else
coming
from
the
company,
that's
that's
different
than
what
our
team
is
can
can
speak
to
right
now,
but
jordan
go
ahead.
E
Yeah,
so
just
I
think,
there's
been
a
lot
of
unsaid
explanation
for
anyone
who
might
be
watching
the
stream.
My
understanding
is
that
there
is
a
hope
to
be
able
to
look
at
an
npm
package
and
provide
some
sort
of
confidence
about
whether
the
stuff
shipped
in
the
npm
package
came
from
the
github
repo
it
links
to
with
an
npm
package
that
doesn't
have
a
build
process.
E
That's
usually
pretty
easy
because
you
just
compare
the
contents
and
they
they
match
or
they
don't
with
a
package
that
has
a
build
process,
which
is,
I
don't
actually
think,
is
the
majority.
But
it
is
certainly
some
of
the
like
a
significant
percentage
of
the
largest
used
direct
dependencies
that
people
choose
and
you
know
so
it's
not
a
small
small
contingent.
E
It's
difficult
and
part
of
the
reason
it's
difficult
is
because
there
isn't
a
build
process
of
record
for
the
javascript
community
there
and
all
of
the
build
processes
have
lots
of
configuration
options
and
unless
you
have
the
exact
dependency
graph
and
configuration
options
that
a
package
has
used,
you
have
zero
hope
of
being
able
to
replicate
its
build
process,
and
so
that
means
every
individual
version
of
babel
and
its
dependencies
or
typescript
or
whatever,
plus
every
individual
patent
like
permutation
of
the
typescript
or
babel
configs.
Some
people
like
yeah,
I
mean
just
in
packages.
E
I
think
that
that
alone
is
a
pretty
large
problem,
and
I
think
that
while
certainly
github
is
in
a
position,
as
you
know,
to
provide
to
let
a
package
author
choose
to
do,
do
its
publishes
and
builds
on
a
controlled
system
that
would
sort
of
solve
the
problem.
E
How
close
you
think
it
is,
and
you
know
you
could
pull
in
human
review,
but
you
would
you
would
desperately
not
want
false
positives,
because
even
more
so
than
cves,
a
false
positive
is
worse
than
a
false
negative,
because
it,
you
know,
erodes
trust
in
the
ecosystem.
So
I
just
I
think,
the
the
the
underlying
goal
is
great,
but
I
I'm
very
skeptical
that
there
is
a
path
to
it
that
isn't
long
and
wildly
expensive
and
that
isn't
fraught
with
the
risk
of
accidental
false
positives,
torpedoing
the
entire
effort.
E
A
Here
that
we're
speaking
to
like
we
should
and
and
always
noted
this
at
the
beginning,
like
we
should
probably
time
box
this,
just
the
fact
that
we're
putting
this
on
our
radar,
though
I
think,
is
important,
and
I
I
I
share
what
you
just
said,
jordan.
I
share
much
of
your
skepticism
and
I've
shared
that
internally,
as
well
as
we'll
be
sharing.
A
You
know,
obviously
externally,
but
at
the
same
time
I
also
am
hopeful
right,
like
a
lot
of
this
work
is,
is
pointed
the
right
direction
that
we're
trying
to
prevent
supply
chain
attacks,
we're
trying
to
give
more
trust
to
consumers
and
and
trying
to
create.
A
You
know,
links
that
I
think,
are
important
and
do
make
sense
in
a
lot
of
cases
back
to
source
repositories
and
packages
and
and
their
artifacts
and
there's
a
bunch
of
different
ways
that
we
can
try
to
get
there
and-
and
I
do
appreciate
the
work
that
has
been
coming
out
of
google
chain
guard.
A
You
know
open
ssf,
like
they've,
been
pushing
some
new,
innovative
ideas,
based
also
if
anybody
has
looked
up
historically,
like
the
tough
framework,
etc,
and
also,
if
you
look
at
how
npm
has
an
updated
model,
we
you
know,
I
think
we're
definitely
positioned
to
try
to
help
solve
some
of
these
problems
and
yeah.
We
can
speak
more
to
this.
I
think
once
we
have
a
proposal,
and
I
can
promise
you
that
there
will
be
some
more
to
talk
about
likely
next
week.
D
Yeah
yeah
the
google
open
source
security
team
yeah.
It's
just
called
ghost
g-o-s-s-t.
A
D
A
Yeah
we
we
meet
every
week,
yeah
weekly,
it
will
depend
upon
announcements
and
things
being
opened
up,
but
I
I
can
just
tell
you,
based
on
how
things
have
been
going,
that
you
know
it's
likely,
we'll
we'll
be
speaking
about
this
topic
next
week.
Cool
want
to
quickly
move
on.
I
know
arch,
fs
or
fz.
Sorry,
you
joined,
I
believe
we
have
one
of
your
items.
I
want
to
bump
it
to
the
top
here
of
the
agenda.
A
This
is
the
adding
support
for
a
cpu
or
os
flag
to
install
basically
for
specific
platforms.
I
saw
this
issue
open
up
almost
a
month
ago
and
I
just
wanted
to
make
sure
that
we
we
got
some
visibility.
I
know
jordan
that
you've
given
some
feedback
on
this
as
well,
but
maybe
you
can
speak
to
it
yourself,
voter.
F
A
Jordan,
I
I
think
you
were
the
one
primarily
giving
feedback.
I
haven't
had
I'll
be
honest.
I
apologize.
I
haven't
had
time
to
review
this
fully
like
the
feedback
that
I
know
jordan
was
given,
but
maybe
you
can
speak
to
me.
E
The
the
thankfully,
the
number
of
packages
that
require
compilation
are
minimal.
That
is,
it's
definitely
a
best
practice
to
avoid
needing
that,
but
some
do
for
real
justification.
Justified
reasons.
E
E
If
I
like,
if
I
tried
to
fake
it,
and
so
I
was
curiou,
I
was
just
trying
to
understand
like
what's
the
point
like
why
you
know-
and
there
was
a
little
you
I
wasn't
sure
I
understood
your
explanation,
and
so
I
didn't
reply
after
that,
because
I
wanted
to
try
to
understand
it
before
before
that.
But
yes,.
F
Have
you
heard
the
of
wine
on
linux
sure
so
using
wine,
you
can
actually
build
cross
platform
from
linux
and
we
actually
are
using
this.
So
electron.
Probably
you
heard
about
it
and
there's
a
package
for
electron
to
build
it's.
It's
called
electron
builder
that
can
do
building
for
windows
from
linux,
using
wine
and
basically.
F
No,
no
wine
is
actually
made
for
linux,
so
you
can
actually
okay
on
programs
that
were
made
for
windows,
but
it
also
helps
to
actually
build
applications
for
windows
from
linux.
Okay
and
since
the
main
reason
here
is
that
a
lot
of
new
packages
on
on
npm,
who
basically
build
native
modules,
have
started
using
the
this
way
that
they
publish
multiple
packages
and
each
package
is
for
for
that
specific
os
and
cpu,
and
only
the
ones
ones
are
installed
that
are
correct
for
the
current
platform.
F
But
this
doesn't
work
with
with
multi-platform
builds
or
cross-platform
builds.
A
Right,
so
you
want
to
wait
some
money
into
and
not
and
bypass
the
checks
that
we're
doing
essentially,
is
that
that's
kind
of
what
you're
speaking
to
right,
like
so
in
terms
of
the
optional
depth
strategy,
because
this
speaks
actually
what
you're
asking
for
speaks
to
like
package
distributions
that
we're
trying
to
to
solve
for
a
bit
more
holistically.
But
the
current
strategy
that
you're
speaking
to
is
that
some
packages
define
or
ask
you
to
define
a
whole
bunch
of
optional
dependencies
and
and
then
utilize.
A
F
C
F
I
I
would
only
need
it
for
the
optional
dependencies
when
optional
dependencies
are
decided
to
be
installed
or
not.
I
would
like
to
also
say
that
if
this
is
not
a
high
priority
thing,
if
more
people
are
coming
from
the
community
and
asking
for
this,
it
should
go
ahead.
Currently,
I
resolved
my
issue
by
basically
not
using
this
optional
dependency
way
of
installing
the
packages.
B
F
F
Well,
you
know
that
package.json
for
for
the
packages
can
define
for
what
operating
system
and
cpu
they
are.
They
are
compatible
with
basically,
and
this
would
basically
change
which
optional
dependencies
are
installed.
A
I
think
yeah,
I
think,
the
that
right
now
we
gate
essentially
based
on
the
process
information.
So
if,
like
we
see
the
os
or
the
cpu
information,
there
is
mismatch
with
the
support
that's
defined
in
the
package.json
and
the
optional
depth.
Then
we
throw,
I
think,
there's
a
missing
config
that
exists
for
us
to
meet
disable
or
like
overwrite
those
checks.
I
think
that's
what
we're
missing
right
now
or
we
could
potentially
introduce
that,
would
help
support
this,
but
go
ahead.
Roy.
I
see
your
hands
up
this
way.
C
Yeah,
I
think
this
is.
You
can
also
tie
with
the
distribution
in
rfc
like
if
we
because
kind
of
the
base,
for
that
is
the
optional
dependencies
and
it
might
be
useful
yeah.
It
might
be
useful
if
you
want
to
be
able
to
test
different
different
binaries
in
in
yeah
just
different
systems.
A
Yeah,
so
it's
like
user
defined
versus
like
respecting.
What's
in
the
package
right,
like
a
consumer
defined,
I
guess
you
can
say,
like
consumer
defined
cpu
config,
to
allow
you
to
get
an
optional
depth
package,
that's
different
than
what
we're
using
to
like
yeah.
A
B
A
Yeah,
like
we'll,
throw
and
essentially
fail
to
install
eventsy.
If
we
see
like
that
mismatch
and
yeah,
so
this
is
trying
to
work
around
the
go
ahead.
A
B
Well,
that's
outside
the
scope
of
you
can
do
that
with
environment
variables,
but
right
like
and
then
there's
no
way
foreign
to
know
if
that
needs
to
happen.
This
is
like
a
user
beware
at
this
point.
It
seems
dangerous
because
there's
assumptions
that
those
dependency
builders
are
going
to
have
that
aren't
true
when
it
comes
time
to
run
no.
A
Go
ahead,
jordan,
if
you
had
a
comment.
E
I
can
if
I
published
a
package
that
needed
to
come
that
had
optional
dependencies
that
were
os
or
cpu
dependent.
I
would
probably
expect
a
bunch
of
bug
reports
from
people
that
thought
that
using
those
flags
was
a
way
to
fix
their
problem.
That's
not
a
reason
not
to
support
it.
It
still
seems
worth
supporting,
but
it
seems
like
documentation.
Warnings
at
least
would
be
nice.
F
Arch
since
I'm
the
first
one
requesting
this
feature,
I
would
recommend
to
wait
to
see
if
more
people
need
this,
because,
basically
we
we
resolve
this
for
ourselves
and
it's
it's
functioning
in
another
way
and
we
should
see,
probably
the
community
will
grow
with
native
module
packages
using
these
optional
dependencies
and
probably
then
people
will
also
come
and
requesting
this.
If
not,
then
it's
not
worth
focusing
on
this.
At
this
point,.
A
A
Looked
at
the
package
distributions
rc,
we
have
some
work
to
do.
A
I
think
around
optional
dependencies
in
general,
that
has
been
on
hold
for
a
while,
just
because
of
my
limited
capacity
to
go,
write
a
separate
rc
for
expanding
our
our
support
and
and
sort
of
modifying
what
we
we
do
with
optional
dependencies,
but
I
think
that's
a
good
thread
if
you're
interested
in
this
sort
of
area
and
kind
of
interested
in
what
we
might
do
down
down
the
line
in
the
future,
with
essentially
package
distribution
variants
and
how
you
might
be
able
to
specify
them
in
the
future
or
manage
them
in
the
future.
A
So
yeah,
that's
my!
I
guess
my
only
feedback
there.
F
Yeah,
so
from
my
side
I
don't
really
have
a
feedback,
I'm
I'm
quite
quite
new
to
actually
using
these
optional
dependencies,
and
I
have
actually
learned
it
from
the
rost
community
recommending
this.
So
I
don't
have
anything
there.
A
Great
well,
thank
you
for
for
jumping
on
the
call
today
and
talking
us
through
the
issue.
I
just
want
to
quickly
move
on
to
the
next
item
we
had,
which
was
6
20
20,
the
rfc
for
npm
init,
adding
a
new
question.
We've
had
this
come
up
before
this
is
for
the
type
common
jsr
module.
A
E
Yeah
I
mean
I,
so
I
think
one
of
the
biggest
problems
with
type
module
is
that
most
people
misunderstand
it
to
be
necessary
to
use
esm.
It
is
not
necessary
at
all,
and
no
one
ever
needs
to
use
it
and
everything
works.
Fine.
The
only
thing
that
it
does
is
makes
jis
files
treated
as
esm
instead
of
common
js,
but
you
can
always
do
cjs
or
mjs
and
you'll
get
the
expected
format.
E
I
think
having
that
as
a
question
is
going
to
be
cause
way
more
confusion
than
it
solves
always.
I
think
that
the
type
field
should
just
not
be
used,
and
if
people
want
to
use
dsn,
they
should
use
mjs
files,
and
I
I
don't
think,
there's
any
point
in
npm
in
it
like
there's
any.
I
don't
think.
E
In
npm
in
it
asking
that
question,
I
don't
care
if
somebody
wants
to
override
it
by
a
command
line.
Arg
like
that's
fine
right,
like
I
think,
but
it
just
people
should
never
see
that
information.
I
think,
because
it
just
confuses
everyone
and
it
it's
not
required
so.
C
Yeah,
I'm
not
just
not
sure
if
I
agree
with
the
sentiment,
but
I
definitely
agree
with
the
part
where
it's
hard
today
right
it's
in
the
difficult
place
today,
yes
support
but
moving
forward.
I
believe
it's
probably
going
to
be
the
future
right.
E
And
it
may
be,
but
type
module
is
not
required
for
any
use
of
dsm
right,
the
all
they
have
to
learn
which
they
do
have
to
learn.
Something
is
that
dot
mjs
is
esm
files,
that's
it
and
then
there's
no
need
for
the
type
existing
tooling
fine
right.
So
I'm
not
even
even
though
I
have
lots
of
skepticism
about
esm
itself
being
the
default.
That
is
a
totally
unrelated
philosophical
debate
here,
yeah,
even
if
literally
everyone
shifts
to
esm
within
the
next
year,
which
of
course
won't
happen.
E
E
E
It
that
is
the
only
reason
people
wanted
that
flag.
That's
the
only
purpose
it
serves
and
that
doesn't
help
newcomers.
They
don't
need
to
be
attached
to
legacy
legacy,
aesthetic
preferences
from
previous
decades
and
yes,
dot.
Njs
absolutely
has
its
own
mind
type.
It's
like
an
official
thing.
That
is
the
thing
so
like
it's,
it's
unrelated
to
the
migration
to
esm
and
when
or
if
that
will
ever
happen,
it
is
just
it's.
It's
an
added
complication
that
newcomers
shouldn't
ever
have
to
see.
That's
my
opinion.
B
We
should
not
add
to
that
they're
all
that's
required
and
some
extra
for
backwards
compatibility
to
make
a
package.json,
and
I
think,
if
we
ever
want
to
have
anything
more,
it's
going
to
be
a
different
way
to
declare
also
without
having
to
make
your
own
package
a
different
way
to
declare
these
fields
also
should
be
in
my
package
json,
which
could
be
its
own
thing,
but
that's
the
direction.
I
think
we
could
support
anything
else.
B
I
don't
know
that
I
am
in
favor
of
adding
any
new
questions
to
that
command
ever
just
because
of
the
can
of
worms
that
it
represents.
If
we
want
to
support
that,
it
needs
to
be
something
we
support
dynamically
like
a
way
to
support
all
the
ones.
Anyone
would
want
by
adding
some
thing
somewhere
themselves
without
having
to
publish
the
module,
so
that
makes
sense.
E
So
my
hand
is
raised
just
to
reply
to
that
for
individual
fields.
Maybe
that
position
makes
sense.
I
definitely
have
a
question.
I
want
eventually
to
be
added
to
npm
in
it,
but
it's
not
controlling
one
field.
It's
is
this
an
application
or
a
package.
Are
you
intending
to
publish
this
thing
or
deploy
and
run
this
thing
and
that
because
that
that
will
set
some
different
fields,
but
because
that
actually
is
is
asking
about
intent,
which
is
different,
and
so
I
I
just
we
can
debate
that
at
future
and
I.
E
Just
want
to
make
sure
that
there's
no
implication
that,
like
there's
a
ban
on
any
changes
in
it,
but
more
that,
like
you,
know
that
we
can
discuss
that
in
the
future,
but
that,
like
yeah.
Thank
you.
A
I
think
I
agree
with
everybody.
I
don't
think
there's
no
dissent
from
anybody.
What
I
would
say
is
a
while,
though,
is
that
this
group
unfortunately
represents
a
very
small
part
of
the
ecosystem
and
and
very
much
we
are,
are
different
power
users
and
and
also
legacy
users
of
this
tooling
right,
so
net
new,
you
know
somebody
who's,
just
getting
started
in
and
javascript
and
node
potentially
has
different.
A
You
know
different
needs
than
we
do
and
as
maintainers
of
of
this
piece
of
software,
that
we
understand
is
likely
people's
first
method
or
a
way
of
interacting
with
the
ecosystem
and
package
packages
and
creating
their
own
packages
getting
started
creating
their
own
packages.
We
should
just
be
mindful
of
that
persona.
That
is
not
us
right
like
just
to
help.
A
I
think
exactly
to
your
point,
jordan,
about
that
question,
about
who
am
I
as
a
consumer
or
if
I'm
want
to
be
a
maintainer
that
might
be
even
tough
to
answer
for
for
somebody
who's
new
right
like
so
that's
why
you
know
we
have
to
always
think
about
that
through
that
lens,
like,
I
think,
for
a
lot
of
us
and
it
becomes
a
power
tool
and
we
can
configure
it
once.
We
know
how
to
answer
all
those
questions
very
easily,
but
it's
sort
of
the
gateway,
at
least
for
somebody
starting
a
brand
new
project.
C
Yeah,
it's
just
that
something
garb
mentioned
real,
quick
and
made
me
think,
because
I
left
that
example
using
pkg
sat
to
just
put
the
type
module
in
your
package.json.
If
you
want
so
maybe
just
a
way
to
just
template
like
give
more
power
over
running
npm
in
it
and
then
like
kind
of
a
template
of
some
sort
that
you
can
drop
in
your
npm
rc.
That
just
like
allows
you
to
do
a
bunch
of
npm
pkg
set
for
things
that
you
won't
usually
want
to
have.
C
A
A
Forgot
about
that
right,
so
you
can
use
an
init
module.
Today
I
mean
you
can
like
that's
what
a
lot
of
people
do,
but
what
might
be
more
like
a
bit
kinder,
a
little
bit
easier
and
friendlier
to
end
users
might
be.
A
You
know
like
a
template
like
an
init
template
or
package
json
fields
that
will
be
more
than
what
we
do
today
to
allow
you
configure
more
fields
than
you
do
today
and
maybe
like
arbitrary
numbers
of
fields,
and
we
utilize,
as
you
say,
under
the
hood,
npm
pkg
or
under
the
package,
json
module
that
you've
built
to
set
those
by
default
right.
So
that's
that
may
be
like
we
could
spec
that
out,
and
that
might
be
easier.
A
I
think
there's
something
in
between
those
two
options
for
users,
which
is
maybe
here's
a
way
you
can
specify
arbitrary
packages
on
our
json,
and
we
will
set
that
for
you
or
those
fields,
arbitrary
fields
for
your
initial
package
json,
and
we
will
set
those
fields
for
you
and
that's
how
what
npm
it
does
or
in
it
template
does.
I
think
there's
something
there
like
in
terms
of
a
middle
ground,
but
in
terms
of
this
specifically,
this
question
specifically,
I
think
we've
talked
it
to
death.
I'm
I'm
very
much
on.
I
guess.
A
Jordan's
side
here
in
terms
of
the
the
need
from
the
community
to
adopt
type
modules
is,
is
not
a
need,
so
asking
that
question
I
think,
is
just
yeah.
It
causes
more
confusion.
A
It
gets
into
the
concept
of
like
our
runtime
or
are
we
going
to
help
with
building
new
dependencies,
but
I
feel
like
we
should
be
helping
you
figure
out
if
you're
in,
like
a
broken
state
as
a
package
manager,
we
should
help
you
get
the
right
packages
into
your
project
and
if
you
can't
use
a
specific
package,
because
it's
esm
or
whatever
and
you're
going
to
have
to
change
your
code.
That's
a
breaking,
that's
breaking
for
you
and
we
should
be
able
to
help
you
it
like
figure
that
out.
A
So
I
I
feel
like
we
are
going
to
eventually
bleed
into
the
that
that
area
in
terms
of
like
runtime
and
build
build
just
to
be
able
to
get
some
analysis
out
of
packages
to
help
you
but
but
yeah.
I
think
there
is
a
future
where
we
we
help
the
community
sort
of
adopt
esm
in
a
way
that,
like
we
also
don't
we
protect
people
that
might
be
broken
by
adopting
that
right.
So
I
don't
know
any
other
thoughts
or
feedback
on
this
one.
A
I
think
we
could
probably
close
it
as
a
dupe,
I'm
not
sure
if
somebody
else
wants
to
do
that
or
we
can
just
like
flag
it
specifically
and
and
sort
of
speak
to
options
that
we
have
in
terms
of
creating
an
rfc.
For
specifically
like
the
template,
like
what
you're
speaking
to
roy,
I
think,
is
a
great
idea
like
hey.
A
We
could
leverage
pkg
somehow
to
let
you
set
arbitrary,
json
or
configure
that
so
that's
one
opportunity
if
the
person's
interested
in
creating
an
rfc
for
that
so
cool,
we
only
have
about
15
minutes
left
and
I
know
there's
a
number
of
extra
items
on
the
agenda
today,
roy
since
you're
here,
maybe
we
can
bubble
up
your
add
the
query
command.
Can
we
take
this
off
the
agenda.
A
E
B
A
A
I'm
not
sure
if
you
want
to
give
an
update
here
if
there
is
one
to
even
give
this
is
the
615
rfc
exportable,
config
definitions.
B
Yeah
this
is
like
old
lore.
This
has
always
been
the
intention
back
when
I
started.
I
pointed
out
that
config
shouldn't
live
in
two
different
places.
We
basically
just
need
to
consolidate
our
config
in
into
one
area.
It's
it's.
I
don't
even
think
this
needs
to
be
an
rrc.
This
is
on
our
agenda.
We
just
need
to
make
sure
this
is
represented
status
board,
so
we
know
it's
the
direction
we're
going.
This
is
already
something
we
already
decided
to
do.
A
B
Another
some
something
that
npm
has
access
to.
I
don't
know
if
it's
a
banner
or
something
for
windows,
to
bootstrap
itself,
to
call
that
instead
of
the
full
cli
defined
with
a
prefix,
when
it
does
this
little
prefix
stance
he's
saying
once
once
our
config
is
exported.
All
we
need
is
that
and
three
lines
of
code
to
do
that,
little
dance
and
then
we
could
call
the
proper
again
yeah.
So
that
could
be
something
that
falls
out
of
that
eventually
sure
we'll
just
plant
that
seed
in
our
heads.
A
Awesome
yeah
yeah
and
then
we
assign
it
to
you.
That's
right,
that's
what
happens
is.
A
It's
open
source
right
you,
I
can
continue
yeah
cool,
we
have
about
nine.
We
have
about
11
minutes
left,
let's
jump
in
see
if
we
can
get
to
a
few
other.
These
ones
that
got
pulled
up
there
was
this
rrfc
619,
a
new
ci
flight
for
npm,
outdated
commands,
go
ahead.
B
Yeah,
this
makes
a
lot
of
sense.
I
think
we
should
like
share
the
name.
I
don't
think
I
think
ci
is
confusing,
and
we
need
to
do
this
with
the
flag
that
we
want
to
add
to
mbm
query
in
mind,
because
that
feels
like
a
similar
thing
and
if
you
recall
npm
query,
we
want
to
add
a
flag
that
makes
it
change
status
codes
based
on
if
it
found
anything
or
not,
and
now
we're
talking
about
making
npm
outdated
change
status
codes
based
on
if
it
found
anything
or
not.
E
Mean
another
alternative
would
be
for
the
net
for
npm
9
or
whatever,
like
re-evaluating
like,
I
feel
like
the
default
command
behavior
of
every
command
on
the
shell
should
be
if
it
worked,
give
a
zero
and
if
it
didn't
give
it
non-zero
and
like
maybe
I
don't
know,
I
haven't
thought
about
it
too
hard
for
npm
outdated,
but,
like
maybe
npm
outdated,
should
just
do
this
stuff
by
default
and
people
who
don't
want
that
behavior
should
like
can
just
use
decade
old,
shell
idioms
to
you
know,
get
whatever
exit
code
they
want
like.
E
We
still
might
want
a
flag
or
something
in
npm
eight
for
it,
but
yeah
just
like
I
I'm
not
sure
my
suspicion
is
that
if
all
of
these
things
are
audited
that
there
won't
actually
end
up
being
any
use,
cases
for
anything
except
having
the
exit
codes
be
proper
for
whatever
that's
deemed
to
be
for
each
command.
B
E
E
A
A
It
just
came
up
about
five
days
ago,
so
within
the
last
week.
I'll
share
it
here
for
folks.
If
you
want
to
take
a
chance
to
look
at.
C
A
I
see
your
comment
here
from
the
earlier
discussion
about
leveraging
wrappers
generators
and
apis
for,
for,
I
think,
that's
npm
in
it
you're
speaking
to
them,
so
go
ahead
and
okay.
B
Like
a
new
life
cycle
event,
because
there's
there's
a
part
of
their
given,
given
the
script
debug
property,
I
would
only
recommend
that
we
we
treat
that,
like
a
life
cycle
event,
so
we'll
just
pre,
debug
and
post
and
not
just
a
bug
just
so
that
we're
not
getting
into
the
case
of,
I
think,
what's
the
command
npm
start,
that's
this
or
npm
end,
which
is
this
weird
thing.
That
runs
one
thing:
if
the
script's
present
and
another
thing,
if
there
isn't,
we
should
be
really
intentional
about.
This
is
a
life
cycle
event.
E
E
It
is
really
annoying
to
like,
like
you,
can
set
the
node
options,
environment
variable
and
set
inspect
break
and
and
then
just
do
whatever
you
want,
and
it
just
works
so
like
that
would
be
a
workaround
to
avoid.
This
is
no
just
set
node
options
and
then
it'll
just
do
the
right
thing,
but
being
able
to
wrap
wrap
around
that
as
npm
debug
seems
powerful.
E
Alternatively,
though,
maybe
it
should
be
node,
debug
or
something
I
don't
know
for
the,
but
like
the
looking
up
the
bin
in
the
main
and
like
that,
that
seems
within
npm's
arena
and
whether
or
not
there's
a
script.
So
I
commented
about
like
there
are
lots
of
packages
that
both
have
been
and
a
main,
even
though
that's
not
a
good
practice
anymore
and
like
they'd
want
to
be
able
to
debug
both,
but
that's
like
a
technical
type
of
like
that's,
not
a
existential
question
for
the
rfc
but
yeah.
E
So
I
I
I
did
just.
I
haven't
only
looked
at
this
for
the
last
30
seconds.
So
I
haven't
thought
about
it.
A
lot,
but
it
seems
making
debugging
easier,
seems
valuable.
However,
you
know
the
we
should
be
very.
We
should
make
sure
it's
very
clear
that,
like
this
is
the
better
the
proper
workflow
and
this
meets
the
use
cases
and
so
on.
A
Yeah,
I
think
just
the
setting
the
environment
variable,
I'm
not
sure
if
they
understand
that
they
could
do
that
to
work
around
like
we
don't
need
less
support,
I'll
comment
that
faster
yeah.
I
think
that
might
just
be
like
a
gap
like
they.
They
are
aware
of
the
flag
and
they
don't
know
that
they
can
pass
the
that
through
to
node,
and
they
think
that
we
have
to
like
essentially
support
this
but
to
pass
it
through
to
our
process.
A
B
Just
to
comment
on
the
part
about
the
bin,
I
think
that
that
needs
some
rethinking.
I
don't
know
if
maybe
we
want
to
because
no
debug
yeah,
we
need
signals
to
differentiate
between
exec
and
run
right
or
because,
if
you
do
no
dot,
that's
the
main.
If
you
do
npm
exec,
that's
the
bin,
and
so
I
would,
I
would
want
to
bug
not
to
muddy
those
waters.
So
I
agree
with
what
jordan
said
about
giving
pause
to
the
whole
bin
thing.
C
Yeah,
it's
just
that
in
the
past
we
kind
of
had
other
life
cycle
scripts
like
build,
come
up
right.
People
want
to
have
that
as
a
top
level,
and
we
pushed
back.
So
I
guess
there's
got
to
be
a
really
strong
story
like
if
we
want
to
kind
of
have
this
one,
not
the
other
ones
right,
because
otherwise,
why
not
have
ill
but
not
have
dev.
A
Oh
open
the
floodgates
right,
don't
even
talk
about
this
yeah.
I
thought.
I'd
put
this
to
rest,
and
really
I
mean
I'm
gonna.
This
is
what's
gonna.
Make
me
roll
in
my
grave.
Don't
don't
bring
up
dev
one,
don't
bring
up
build
whatever
those
are
the
two
yeah
bad
guy.
B
E
C
Also,
the
from
what
I
understood
very
quickly,
parsing
through
the
the
rsc,
looks
like
they're,
proposing
like
this
default
kind
of
behavior
when
the
script
is
not
there,
which
is
already
very
confusing
for
start
and
everything
else
today.
Right,
it's
very
confusing,
I
know
start
has
a
default.
I
think
it's
know
the
index
or
node
server.
C
A
Apologies,
I
was
just
taking
notes.
We
have
two
minutes
left,
I'm
not
sure.
If
we're
going
to
be
able
to
get
to
any
other
rc's.
What
I
will
say
is
the
next
one
which
is
610
from
evan
carroll,
the
parallel
script
execution.
When
setting
when
a
value
is
set
to
an
array
of
text,
I
don't
think
we
should
do
any
kind
of
like
inference
ever
with
that
kind
of
stuff.
We've
talked
a
lot
about
sort
of
advanced
workflows,
doing
concurrent
or
parallel
execution
of
scripts.
A
I
think
that
should
be
like
an
explicit
like
opt-in
and
I
think
it
has
to
do
with
like
script
execution,
which
we've
also
spoken
to
with
like
topological
ordering
with
like
build
scripts
and
those
types
of
things.
I
think
this
probably
I
haven't
read
this,
but
I
think
this
probably
is
in
line
with
you
know,
adding
or
introducing
a
new
parallel
flag
or
config
to
run
script
and
exactly
those
types
of
things.
B
E
But
I
mean
you
can
already
do
this
with
concurrently
or
parallel
shell
and
I'm
sure
there's
others
and
then
also
both
of
those
have
have
user
like
ux
issues
and
like
I've
seen
issues
with
them,
where
they
don't
do
the
right
thing.
When
specific
subtasks
fail,
they
don't
fail
the
overarching
command
and
so
on,
yeah
npm
and
all
thank
you
so
like
I.
E
I
think
it's
if
there
was
a
like
impressive
user
land
solution,
that
a
lot
of
people
were
using
and
it
always
did
the
right
thing
with
exit
codes
and
that
like
had
worked
through
these
ux
issues,
then
I
think
it
would
be
a
pretty
compelling
rfc
to
try
and
say,
let's
bake,
that
into
npm.
But
I
you
know,
I
don't
think
that
exists,
and
I
would
love
someone
to
prove
me
wrong,
because
I
need
that.
But
it
doesn't
exist.
I
think
so
like
I'm.
E
I
I'm
really
nervous
I'd,
be
really
nervous
about
npm,
adding
it
if
userland
can't
even
figure
it
out,
because
you
know
all
the
folks
working
on
npm
and
all
the
folks
on
this
call
like
as
great
as
all
of
us
hopefully
are
like
we're
still
part
of
user
land.
So
if
nobody's
figured
it
out,
how
are
we
gonna?
You
know.
A
Well,
we
can
potentially
look
at.
Can
we
be
as
good
as
one
of
those
like
the
most
popular
version,
concurrently,
npm
rental?
Can
we
provide
the
same
level
of
value
or
more
right
like?
Potentially,
there
is
something
that
we
can
learn
from
their
implementations
that
we
can
do
differently.
That,
ideally
gives
you
a
better
outcome
as
a
end
user,
but
I
I
do
think
this
is
something
that
we
should
try
to
break
into
npm.
It's
a
we've
been
asked
about
it
so
much
and
the
stats.
A
If
you
look
at
concurrently
empty
and
run
all
a
bunch
of
these,
like
people
want
to
be
able
to
run
their
scripts
in
parallel
and
they're
they're,
looking
to
other
build
tools
and
and
needing
to
include
new
dependencies
to
do
it,
and
I
don't
think
that
there's
any
reason
why
we
couldn't
at
least
you
know,
match
the
same
level
of
experience.
People
get
today
optionally,
like
opting
into
that
experience,
I'm
not
making
it
something.
That's
default
right,
but
yeah.
E
A
Two
minutes
over,
I
apologize
folks
if
there
was
something
we
missed,
hopefully
you'll
be
on
next
week
with
us.
We
will
definitely
have
some
more
to
talk
about
then
and
appreciate
it.
We're
jumping
on
today,
some
familiar
faces
hopefully
continue
to
come
and
yeah.
I
will
see
you
all
next
week
cheers.