►
From YouTube: Open RFC Meeting - Wednesday, Jan 8th 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.
GitHub Agenda Issue:
https://github.com/npm/rfcs/issues/87
Notes:
https://docs.google.com/document/d/1ZAeCaLv4s_oul7AbjrCXratfCfw_LdwSfiIjs645cqg/edit
A
And
we're
live
so
welcome
everybody
to
the
first
open,
RC
call
of
2020.
My
name
is
starchy
click
I'm.
Your
lovely
host
for
these
calls
usually
and
appreciate
everybody
jumping
on
today
quickly
for
a
folks
that
just
joined
awesome.
Thanks
for
being
the
notes,
talk
feel
free
to
add
yourselves
as
attendees
and
Daniel's
kindly
offered
to
take
notes
today
so
again
quickly.
Some
housekeeping.
A
The
intention
of
this
call
is
again
to
sort
of
provide
a
mechanism
for
us
to
work
closely
with
the
community
to
overview
and
look
at
potential
conversations
and
net
new
features,
bugs
issues
that
the
community
wants
us
to
put
some
focus
around
and
just
another
communications
channel
that
we
have
available
here
at
IPM.
These
are
bi-weekly
meetings
that
we
have
and
we
have
a
global
and
public
events
calendar
that
you
can
subscribe
to.
So
you
don't
miss
these
calls
going
forward
and
we'll
be
trying
to
ensure
that
the
agenda
gets
created
in
the
alternating
weeks.
A
A
This
is
public
and
live
streamed
on
YouTube,
and
so
just
be
mindful
that
and
I
think,
because
it
is
the
new
year,
I
wouldn't
mind
doing
a
round
of
introductions
and
just
say
who
you
are,
what
you
do
and
who
you
work
for
maybe
and
I
can
get
started
by
saying:
I'm,
just
click
I'm
the
engineering
manager
for
open
source,
new
community,
MPM
and
I
work
with
quite
a
few.
The
folks
that
are
on
you
in
one
capacity
or
another
who'd
like
to
to
say
hi.
My.
A
A
A
A
For
sure,
well,
we'll
start
pinyon,
folks
and
again
I
apologize
for
the
rough
edges
as
we
kick
off
the
new
year
here,
so
we're
just
all
getting
right
back
up
after
the
holidays,
so
we're
hoping
that
these
calls
do
get
a
larger
audience
as
we
go
forward
and
again,
a
number
of
the
folks
that
are
on
this
call.
I
know
that
we
get
together
in
other
capacities
and
other
foundation
working
group
meetings,
etcetera,
so
I
think
there's
gonna
be
a
lot
of
opportunity
to
connect
here
in
2020,
so
so
to
get
started.
E
A
E
A
E
A
Thank
you
very
much.
Do
you
want
start
without
them
Michael
and
speak
to
that
I.
E
The
update
is
quite
simplistic,
I
think
it's
a
bit
of
a
misnomer
in
that
it
was
something
that
was
particularly
difficult,
but
there's
a
package
called
NPM
package
in
it
I
believe
the
NPM
org
that
carries
the
default
plus
the
like
prom
logic,
so
I.
Don't
particularly
think
that
package
has
seen
well
one
the
light
of
day
and
to
any
love
in
quite
some
time.
So
it
might
be
worth
doing
something
about
that.
But.
E
Ability
to
have
like
a
selective
type
thing-
and
it's
basically
like
is
the
default
answer.
Your
answer.
It
doesn't,
if
you'd
like
the
one
of
these
two
things
kind
of
prompt,
so
we
have
to
either
add
the
better
figure
how
to
update,
not
particularly
but
anyways.
All
of
this
is
that
the
default
templates
in
there
or
something
at
the
moment
like
a
first
pass,
could
be
just
like
the
template
type
is
just
colleges
and
configure
it.
I,
don't
like
I'll,
be
the
prompt
so.
A
Thanks
for
the
link
right,
so
yeah
I
think
the
only
concern
is
if
we
don't
have
an
interactive
selection
option,
because
I
don't
know
any
other
sub
command
that
actually
implements
interactivity
really
right
now
in
it
has
like
flags.
So
maybe
we
could
do
this
via
flag
for
now.
If
we
really
want
to
get
this
in,
let's
say
NPM
six,
but
we're
sort
of
focused,
at
least
for
now
on
on
NPM,
seven
right
now,
which
might
mean
that
we
would
plant
this
or
backlog
this
for
once.
A
C
C
F
Not
speaking
for
the
module's
team,
but
I
will
say,
the
problems
with
type
module
right
now
are
too
complicated
to
set
as
the
default
like
people
will
just
not
understand
it
and
they'll
poorly
implement,
and
then
the
thing
won't
be
consumable
by
common
jeaious
modules,
like
that's
just.
Unfortunately,
the
fact
of
the
current
situation
so
I
don't.
F
B
C
A
E
Like
the
end,
take
to
your
point
about
lending
this
to
and
em7
I,
like
that,
the
quick
pass
of
just
like
adding
type
equals
calm
jazz
to
the
like
defaults
and
just
like
kind
of
having
it
there
without
even
giving
the
user
a
prompt
just
to
say
it
like
it.
Let
you
go
into
your
package,
adjacent
file,
change
it
afterwards
and
then,
when
we
get
to
NPM
7,
it
would
be
nice
to
because
I'm
wanted
to
point
us
in
it
would
be
nice
to
give
that
package
or
something
love.
E
F
Also,
I
think
that
the
even
when
we
get
better
support
I
think
it's
gonna
be
like
a
tree
of
questions,
so
cuz
you're
gonna
have
to
say:
ok,
if
it's
a
module,
then
is
it
a
dual
module
like?
Does
it
have
a
common
Jes
and
a
and
a
module
export?
Then,
if
it
does,
what
are
the
entry
points
for
those
different
things
right
because
main
is
no
longer
gonna
be
a
thing.
It's
gonna
be
the
exports.
A
Yeah
I
would
like
to
see
this,
so
this
was
created
as
an
issue
I'd
like
to
see
maybe
the
actual
PR
for
this,
so
that
we
can
sort
of
discuss
the,
and
this
was
kicked
off
the
scientist
by
Owen
yeah.
So
we
can
discuss
like
the
actual
implementation
of
how
this
might
look.
So
at
this
point,
like
the
the
different
branching
decisions
that
we
might
want,
our
props
that
we
might
want
to
give
users
on
in
it,
we
can
figure
it
all
that
out
and
then
we
can
sort
of
ratify
that.
A
That's
the
approach
we
want
to
take
so
that
we
can
then
backlog
that
without
work
and
so
I
think
I
think
we
all
agree
that
this
is
definitely
something
we
want
to
add
to
in
it.
So
I
first
pass
at
what
the
actual
implementation
or
RFC
would
look
like
would
be
good,
so
I'm
not
sure
if
we
want
to
go
back
and
ask
Owen
to
turn
this
into
a
PR.
But
that
would
be
my
recommendation
on
this.
So
yeah.
E
C
Yeah,
it's
a
very,
very
simple
one
too.
It's
just
after
to
work
on
the
file
explorer
right
as
soon
as
you
navigate
a
little
bit
around
packages
on
the
registry.
You
see
how
much
how
many
files
that
should
not
really
be
published
or
ending
up
in
every
single
version
of
that
it's
there.
So
it's
just
that
I
see
like
the
the
list
of
default.
You
know
where
files
can
be
expanded.
There
are
some
stuff
that
really
shouldn't
mean
a
published
package,
but
you
can
always
we
smell
is
the
contentious
subject,
but
I
think
this
one.
C
A
I'd
like
to
see
if
we
could
get
some
more
eyeballs
on
this
to
like
fold,
make
a
more
fully
fleshed
out
list
and
then
just
pull
to
you
know
pull
to
ensure
that
those
are
indeed
what
the
community
is.
Okay
with
us,
you
know
we
also
are
gonna,
have
a
very
long
sort
of
beta
stage
for
NPM
seven,
so
people
could
say:
I
went
and
I
didn't
impact
and
I
noticed
that,
like
you
took
it,
you
ignored
X,
Y,
&,
Z
and
I.
Wasn't
expecting
that
or
things
like
that.
Yeah
they're,
like
yeah.
F
Seen
some
user
land
implementations
this
before,
but
maybe
this
would
be
something
also
for
you
all
to
look
into
is
analyzing
which
packages
will
be
affected
by
these
changes.
If
you
even
just
publicize
the
list-
or
you
know
even
better
yet
automated
opening
up
an
issue
on
there
and
just
saying
hey
we're
making
some
changes
in
NPM,
seven
you're-
probably
going
to
be
affected
by
them,
because
your
package
is
currently
contain
a
editor
config
file.
If
you
don't
mean
that
to
be
published,
you
know
close.
F
The
issue
ignore,
if
you
do
you
know,
please
join
the
discussion
here
or
something
like
that
would
I
think
be
really
helpful.
Outreach
way
to
to
preemptively
fix
the
issues,
let's
be
honest,
you're
right
most
people
probably
didn't
mean
to
commit
them.
It'll,
probably
all
be
like
oh
oops,
I
didn't
know.
I
did
that.
Thank
you
so
much,
but
the
like
one
person
who's
using
NPM
to
manage
their
editor,
configs
well,
I,
say
one
person
but
I'm.
A
D
Ahead,
go
ahead,
yeah
as
I
say,
along
that
same
train
of
thought,
I'd
be
interested
in
seeing
some
analytics
registry
side
of
what
impact
these
changes
will
actually
have
fun.
Module
sizes.
I
was
looking
at
these
files
locally.
They
beat
the
smallest
part
of
my
projects
and
maybe
some
analytics
across
what
directories
are
common
across
different
modules
that
contribute
to
package
bloat
and
maybe
using
that
to
prioritize
what
we
go
after.
A
Yeah
for
me,
I'm,
looking
through
the
the
why
here
and
I
think
about
it.
Why
should
not
necessarily
be
focused
on
like
sizing?
It
should
be
more
on
the
the
case
that
West
is
sort
of
identified.
It's
like
I
did
not
mean
to
do
like
packed
and
like
package.
This
up,
like
I,
do
not
mean
to
distribute
this
more
and
more.
Just
like
that.
E
A
The
focus
again
should
probably
not
be
you
fascist
because,
as
you
say
like
they
are
a
lot
of
times
super
small.
So
it's
not
it's
not
that
weird
loading
packages,
it's
more
so
that
yeah
we
just
don't
want
people
checking
things
that
the
name
means
do
so
I
really
like.
What's
what
you
noted
and
I
hope,
we
do
have
a
note
about
it
about
being
proactive
about
notifying
users
about
some
of
these
changes.
A
If
we
do
intend
to
switch
how
we
are
packing
and
publishing
packages,
so
I
think
we're
gonna
be
extremely
mindful
of
that
going
forward.
So
and
again,
as
you
say,
we
could
potentially
do
some
some
initial
scraping
to
see
like
who's
who's
got
some
of
this
and
potentially,
if
you're
logged
in,
we
could
potentially
give
you
a
little
like
pre-emptive
alerts
or
a
notification
on
the
package
page
or
something
like
that
where
we
say
you
might
be,
we
noticed
you
have
XY
and
Z
files
as
of
NPM,
seven
we're
looking
to
actually
you
know.
A
Did
you
mean
to
do
this?
Please
go
to
this
RFC
and
give
us
a
comment
or
or
something
like
that.
I
think.
There's
a
bunch
of
ways
we
could
potentially
ensure
that
you
know
we
communicate
this
really
well,
because
we
don't
want,
as
you
say,
like
somebody
who
is
using
NPM
to
distribute
let's
say
config
like
their
editor
configure
or
something
else
like
that,
for
whatever
reason
they're
doing
it
through
a
package,
then
we
don't
want
to
like
disrupt
that.
So
go
ahead.
Mike
you
got
your
handle
yeah.
E
E
I
have
published
packages
where,
like
switched
branches
and
had
things
that
were
a
contract
and
they
just
got
published
because
packages-
everything
that's
in
my
current
working
directory,
so
I'm
like
I've,
shipped
features
that
I
didn't
like
they
were
just
broken
because
I
accidentally
switched
branches
and
it
wasn't
clean
that
should
be
a
problem
somewhere
else
around
that
I
don't
know
if
Atlas
is
very
pleased
for
that,
but
yeah
anyway.
So
this
is
all
I
thought
of,
like
accidentally
publishing
something
I
had.
D
Well,
all
of
our
internal
service
platform,
tooling,
that
we've
been
working
on
with
my
team,
actually
goes
through
and
does
that
check
and
requires
to
get
working
directory
be
clean
before
we
allow
the
publish
with
an
explicit
force
flagged
overwrite
that.
D
A
It
seems
like
a
sane
saying
default
to
be
checking
for
like
a
dirty
State.
So
if
you
wouldn't
mind
my
taking
the
the
a
on
creating
a
separate
RC
for
that
and
or
opening
an
issue,
againsts
I,
don't
know
where
the
the
right
repo
would
be
for
that.
But
if
you
want,
you
can
just
make
an
RFC
for
for
changing
that
or
adding
that
capability.
A
A
I
think,
though,
what
we're
trying
to
do
there
is
include
as
many
same
defaults
that
help
like
really
help
to
change
the
ecosystem
for
the
better
right
in
seven,
and
this
is
like
the
like,
the
next
time
we
would
have
a
brakeman
change
would
potentially
be.
You
know,
like
twelve
months
out
at
Mott
is
my
expectation
would
be
like
the
earliest
that
we
would
have
like
and
breathe
and
change
unless
there
was
something
major
we
really
want
to
include
in,
like
an
NPM
me.
A
C
One
in
particular,
I
think
it
goes
along
well
at
the
order
someone
had
attended
out
last
time
also
the
idea
of
just
changing
the
published
behavior
so
that
we
take
more
advantage
of
like
just
basically
having
the
user
go
through
a
dry
run
kind
of
so
it
may
be
having
a
prompt
like
just
not
like
just
not
just
yeah
yeah
yeah
I.
Remember
that
this
idea
has
kind
of
been
invented
out
already
before
and
I
think.
C
It
goes
well
with
that
idea
of,
like
let's
have
a
confirmation
step
before
actually
published
because
yeah
some
people
actually
like,
because
when
you
enable
OTP,
you
kind
of
have
that
confirmation
time
before
actually
publishing
your
package
to
the
registry,
so
that
kind
of
changing
behavior
might
be
a
good
thing
to
go
in
seven
and
maybe
bundle
all
these
ideas
together
and
kind
of
have
a
real
work
around
publish
all
together.
Yeah.
E
A
I,
do
not
think
that
we,
you
put
anything
together.
That
was
substantial,
okay,
so
you're,
okay
with
taking
that
on
them
like
something,
even
though
first
pass
it.
What
that
would
look
like
gated
yeah,
which
might
include,
as
as
like
a
part
of
the
is
let's
say
recommendation,
also
is
like
no
dirties.
They
like
for
a
get
like
right,
like
a
git
branch,
I.
F
Would
I
would
really
like
to
see
this
implemented
as
a
optional
feature?
You
can
turn
on
not
a
default
to
start
you're
gonna
break
a
ton
of
CI.
I
bet
you
any
money,
you're
gonna
break
a
ton
of
people
see
is
implementation.
If
you
turn
this
on
by
default,
that's
from
you
I
mean
I,
don't
know!
That's
why
I
say
I
think
it's
gonna
be
really
contentious.
Yeah.
A
Has
a
number
of
tools
that
essentially
are
for
doing
like
some
of
this
work
to
ensure
that,
like
so
it's
it's
like?
Do
we
want
to
pull
in
some
of
the
good
ideas
from
the
usually
and
like
the
the
existing
tooling
that
we
know
that
package
maintainer
czar
using
like
do?
We
want
to
pull
in
some
that
that,
like
those
concepts
and
to
your
point
like
we
could
potentially
put
this
behind
a
flag,
opt-in,
opt-out
of
some
of
this,
like
auditing
or
like
yeah?
A
E
G
Here
for
sure,
okay
behind
the
flag
for
a
while
is
a
better
idea
anyway
and
then
changing
the
default
in
a
major
like
in
general.
All
of
the
things
that
NPM
or
anything
has
done
in
a
breaking
version
that
were
controversial
in
my
experience
are
always
things
that
are
sudden
breaking
changes,
as
opposed
like
that.
There's
no
workaround
for
in
the
previous
version
lag
then,
if
I
want
to
guarantee
that
I
don't
break
when
the
next
major
comes
out,
I
set
the
flag
to
the
current
default
explicitly,
and
then
it's
there's
no
break.
G
So
you
recommend
the
way
that
node
rolls
out.
I
mean
I,
don't
know
that
note
specifically,
but
in
general
yeah,
like
I've
heard
for
every
package,
I
maintain
I,
always
ship,
try
to
ship,
assembler,
minor
thing
and
then
change
the
default.
I
never
add
a
new
feature
in
a
major
I,
only
change
the
default
of
a
flag
so
that,
if
somebody
doesn't
like
the
break,
they're
not
stranded
on
the
previous
major,
they
can
still
upgrade
to
the
latest
major,
which
is
what
we
all
want
to
encourage.
G
A
E
G
F
A
You
know,
hopefully
we're
gonna
continue
to
build
off
these
things,
so
cool
and
I
think
I
would
also
offload
the
stress
that
we're
feeling,
right
now
with
some
of
the
freaking
changes
that
we
like
to
make
with
MPM
stove
and
so
is
to
be
to
happen
more
yeah
like
a
flag.
First
approaches,
it's
good,
so,
okay,
cool,
let's
move
on
then,
and
we
got
a
couple
action
items
from
there.
I
think
Daniel.
One
also
would
be
like
ideally
codifying
that,
like
how
we
roll
out
a
feature
should
be
openly.
A
Everybody
should
see
like
how
we
are
rolling
out,
like
a
major
feature,
should
be
out
in
the
open,
so
that
process
so
number
four
I
item
number
four,
which
is
issue
or
PR
77.
So
this
was
opened
by
my
friend,
West
boss.
A
A
I
did
have
a
bit
of
a
back-and-forth
with
him
about
this,
and
Isaac,
unfortunately,
isn't
on
the
call
to
talk
to
this
and
I
think
there
was
a
bit
of
a
miscommunication
or
misunderstanding
around
our
output
versus
PMPM
or
human
yarns
output
in
these
scenarios,
because
after
asking
him
to
do
a
bit
of
research,
he
was
finding
the
exact
same
type
of
log
output
was
was
being
generated
in
the
other
package
managers.
So
you
there
are
ways
to
obviously
like
silence
and
and
not
have
a
ton
of
output,
but
I.
B
F
And
so
I,
like
the
focus
on
new
user
experience,
I
think
that's
very
important.
A
experienced
user
can
always
turn
a
flag
that
just
turns
it
on
and
gets
the
output
they
want
because
they
need
it.
The
new
user
won't
know
about
said
flag,
so
it's
a
lot
better
to
protect
them
more
I.
Think
from
like
as
a
design
standpoint.
That
said.
F
The
screenshots
he's
posting
like
you're
gonna,
there's
gonna,
be
weird
output
from
all
sorts
of
things
right.
It's
not
just
your
output
you're
controlling
it's
all
the
modules
you
install
that
decided
to
post
install
logging,
and
so
this
kind
of
choice
affects
all
of
them
and
that
that's
what
I
think
makes
it
hard.
F
A
B
Anybody
else
Lots
on
those,
so
I
wonder
like
if
you
could
end
the
log
output
with
just
a
simple
this
worked,
or
this
didn't
work
and
still
keep
the
Robo
City,
but
then
have
a
final.
This
is
the
outcome
of
everything,
above
as
a
maybe
a
step
in
the
direction
towards
making
a
friendlier
to
newer
users.
A
Yeah
so,
like
I,
think
you
to
that
point,
then
you'll
have
to
do
right
like
to
some
extent
like
the
output
at
the
end
of
an
install,
isn't
very,
like
doesn't
isn't
very
like
successful,
like
tada
like
we
should
have
emojis
and
party-party
emojis
that
you
know
things
were
successful.
We
also
don't
necessarily
know,
though
whether
or
not
something
did
air
so
that
it's
kind
of
we
don't
also
don't
want
to
give
a
false
sense
of
security
there
either.
F
So
it
seems
to
me
to
err
on
the
side
of
accuracy
over
that,
unless
you
can
find
the
really
good
balance
right
and
I
think
you
know
the
ecosystem.
Today,
it's
going
to
be
pretty
tough.
To
find
that
balance,
you
know
actually
be
much
worse
to
output.
It
all
worked
at
the
end
with
a
nice
green
checkmark
and
it
didn't
actually
work
for
those
new
users,
then
to
output,
a
ton
of
logs
that
they
have
to
read
through
yeah.
A
A
Okay,
I'm
not
sure
what
the
action
is
then,
for
like
this
specific,
like
PR,
are
in
fact
this.
They
ain't,
really
even
I
mean
this
doesn't
really
have
necessarily
a
a
action.
Well
like
looks
like
a
first
pass
and
like
yeah,
that's
yeah.
A
C
E
E
B
E
F
A
A
Okay,
yeah
well,
so
a
couple
of
things
will
take
away
there,
we'll
leave
it
on
the
agenda
and
and
I'll
try
to
tap
tap
West
to
actually
join,
because
he
has
great
insights,
obviously
to
that
entire
community.
As
you
said
west
like
like,
he
really
understands,
you
know
those
those
people
who
were
just
getting
ramped
up
and
it's
a
good
lens
for
us
to
keep
it
keep
in
mind
as
we
build
features
going
forward.
A
D
D
Why
isn't
an
internal
company
you
might
want
to
validate
that
you're,
using
or
at
a
company
you
might
want
to
validate
that
you're
using
your
internal
registry
and
that
your
developers
are
accidentally
calling
from
the
public
registry,
especially
if
there's
a
risk
of
naming
collisions
because
you
haven't
been
school.
Big
you're,
probably
packages
correctly.
So
this
is
just
a
way
of
adding
an
extra
signature
generated
by
the
registry.
D
A
The
actual
implementation
of
this
will
probably
not
be
the
team
you
see
here
on
this
call
for
us
at
NPM,
but
would
be
folks
internally
in
other
parts
of
the
engineering
work,
so
we
would
have
to
backlog
that
work
if
we
do
approve
that,
but
I
definitely
think
that
you
know
this
does
unlock
some
capabilities
and
I'm
totally
down
on
on
the
fact
that
it's
yeah
it
provides
that
level
of
like
safety,
security.
Understanding
like
that.
This
is
what
you
expected.
You
know
you
have
the
right
thing.
F
Just
to
be
clear,
there
is
a
CLI
component
that
I
think
would
be
so.
The
CLI
component
would
be
actually
validate
those
right
and
then
also
so
then,
if
you
did
that
you
can
actually
do
that
decoupled
from
NPM
registry
providing
the
signatures
and
then
other
implementations
could
start
providing
the
signatures
right.
So
you'd
look
at
so,
if
you
look
at
the
RFC
there's
two
new
NPM
RC
fields,
document,
signature,
key
and
basically
I.
Think
if
you
like,
looked
for
the
existence
of
those,
you
could
then
turn
on
validating
side
keys
right.
F
So
in
that
case
you
would
be
able
to
you'd
not
set
that
by
default
for
most
people.
But
then,
if
you
built
it
in
the
CLI,
then
it
people,
like
you
know:
wills
referencing,
like
our
team's,
could
start
providing
those
signatures
on
our
own.
Without
you
know,
the
Public
Registry
necessarily
having
them.
A
D
I
define
how
this
tooling
would
approach
this,
and
it's
a
entirely
throwing
PMRC
I'd
be
interested
in
doing
an
example
in
our
implementation
against,
like
registry
static,
I.
Think
that's
I
think
where
the
biggest
risk
is
is
a
lot
of
existing
nearing
solutions
like
I
remember
there
was
a
note
conference
I
went
to
that
was
out
in
the
middle
of
nowhere,
and
we
used
registry
stack
to
set
up
simple
mirror
on
site.
The
thing
with
those
is
they're
all
simple
file
system
based
mirrors
that
you
throw
in
Gen
X
there.
D
So
if
you're
doing
things
with
signing
with
headers
and
stuff,
you
have
to
assume
that
your
web
server
is
capable
of
generating
those
had
like
headers
and
they're,
not
always
capable
of
doing
that.
So
finding
something
that
works
with
these
super
simple,
mirroring
solutions,
I
think,
is
important.
So
well,
yes,
I,
agree,
I,
don't
think.
There's
I
think
there
is
value
outside
of
the
actual
registry
hosting
this
or
providing
this
feature.
D
I
think
the
values
are
very
diminished
if
NPM
proper
doesn't
support
this
in
the
registry,
but
I
think
if
we
don't
also
put
thoughtfulness
into
supporting
the
simple
hearing
solutions
at
the
same
time
and
land
those
side-by-side
and
validate
it's
going
to
work
for
other
use
cases
I
think
we
won't
on
the
community
a
disservice.
If
that
makes
sense.
A
No,
it
does
make
a
lot
of
sense.
Yeah,
okay,
I
see
also
like
a
secondary,
like
considering
some
other
validating
environments
and
config
recently
in
the
community,
there's
been
some
sentiment
of
it
like
validating
locked
files,
etc
and
I've
been
considering
whether
that
should
be
thrown.
It's
like
NPM
doctor
as
an
extra
check.
This
would
be
something
similar
as
well.
I
could
imagine
will
add.
D
There's
a
thing
I
missed
here
in
the
trade-off
for
there's
the
external
tooling
solution,
which
I
proposed
and
I
think
there's
a
trade-off.
I
miss
there,
which
is,
if
we
do
this
as
external
tooling,
it
requires
the
installation
to
happen
first,
which
means
all
of
your
posts,
install
scripts
and
everything
have
already
executed.
So,
if
you
pulled,
which
you
trust
already
yeah
you've
already
like
been.
D
A
F
A
Want
to
be
mindful
of
time,
but
I
also
want
to
talk
up
on
this.
Just
to
let
folks
know
that
our
haven't
been
privy
to
like
all
their
internal
discussions,
but
definitely
commuting
communicating
and
providing
more
clarity
about
where
you
got.
Something
is
definitely
on
our
radar,
especially
when
it
comes
to
something
like
references
to
like
the
tar
balls
that
you
know.
We
say
we
downloaded
from
like
in
a
package
lock
if
you
change
the
registry
in
NPM
RCE
or
you
change
the
configure
whatever
for
the
registry.
A
That
is
not
necessarily
like
accurate,
so
you
can
essentially
go
and
fetch
like
something
like
a
package
from
a
different
source.
And
that's
you
know
what
we're
considering
ways
in
which
we
could
potentially
remove
the
registry
like
domain
from
from
those
like
paths,
so
that
the
source
of
truth
is
always
going
to
be
whatever
you've
defined.
A
As
the
registry,
like
your
register,
URL
so
yeah
just
to
just
to
like,
essentially
top
up
we're
considering
like
how
we
handle
that
in
MPM,
seven
now
and
whether
or
not
we
put
essentially
like
a
placeholder
instead
of
like
the
the
registry,
URL
so
cool.
But
it's
definitely
something
we're
mindful
of
it's
like.
We
want
make
sure
it's
clear
where
you've
gotten
something
from
and
and
it'd
be
great.
If
we
can
also
like
let
you
know
that
we
ensured
that
it
was
you
pulled
down
what
you
thought
you
were
pulling
up.
A
So
this
this
is
like
I
said
this
is
something
I
want
to
implement
for
sure,
so
cool,
so
I'm,
not
sure
your
action
items
there
here
is
probably
just
to
get
more
folks
to
look
at
this
and
then,
if
we
agree
with
the
approach,
we
can
essentially
ratify
it
and
then
backlog
the
work
so
and
then
we
can
also
consider
like
coordinating,
as
you
were
saying
well
like
coordinating
with
a
use
case.
Our
example
with,
as
you
say,
like
a
mere
implementation
because
again
like,
as
you
said
like
it,
doesn't
make
sense.
A
E
Don't
think
I
understand
enough
about
this,
which
is
why
I
have
this
question,
but
so
tell
me
if
I'm
really
out
base.
But
if
you
are
in
a
situation
where
you
didn't
have
you
know
the
best
network
at
Newsweek
rid
of
the
static
weird
registry?
And
you
want
to
do
the
validations,
it
would
still
potentially
be
another
network,
crest
right,
and
so,
if
you're,
installing
something
that's
like
a
thousand
packages,
does
that
negate
like?
E
Does
it
become
moot
them
that
it's
a
static
registry,
because
you're
still
making
a
thousand
requests
anyways
to
you,
just
not
downloading
a
thousand
tarballs
but
you're
still
making
the
requests
for
the
like
key
to
do
the
validation
I'm
just
curious,
I'm,
curious
about
like
overhead
that
this
adds
to
the
game
feel
like
not
that
I
don't
think
we
should
do
it
because
this
is
definitely
a
really
important
thing.
That
file
explorer
enlighten
the
number
of
garbage.
E
That's
in
the
registry
at
the
moment,
and
so
like
the
idea
that
we
should
be
able
to
validate
things.
It's
really
really
really
important,
but
I
worry
about,
though,
like
people
would
complain
that
NPM
stuff,
faster
I
like
to
see
lies
not
fast
enough
and
so
with
NPM
7
we're
making
installs
quite
a
bit
faster
with
our
wrists
and
so
I.
E
D
E
D
Request
packages,
signature
or
package
signatures
be
validated
if
that
header
isn't
there.
You
then
follow
up
with
a
request
for
the
file
itself.
Maybes
like
network
is
things
usually
work
is
you
will
have
one
person
show
up
at
the
conference
before
everybody
else
and
they
have
like
a
dedicated
network
connection
that
doesn't
have
like
600
attendees,
trying
to
use
it
and
they'll
set
up
their
mirror
beforehand
or
they'll
show
up
what
their
mere
pre-configured
and
then
that
will
have
all
of
those
files
already
on
there.
So
all
the
network,
all.
A
Ok,
cool
thanks
for
that.
Well,
okay!
So
moving
on,
probably
to
the
last
time
we'll
get
to
being
mindful
did
anybody
want
to
actually
move
something
up,
considering
that
we
only
have
about
ten
minutes
left
or
about
eight
minutes
at
this
point,
if
not
I'll,
just
keep
moving
on
to
item
six,
so
this
looks
like
it's:
just
the
fixed
files
list
should
be
not
exclude
bundle
dependencies,
so
this
is
number
46
at
an
NPM
Pacus.
A
E
E
E
A
E
H
A
E
A
E
A
Well,
we
may
have
to
I
have
to
add
that
life
capability,
yeah,
okay,
four
minutes
left-
might
be
able
to
get
through
one
more
thing.
Actually,
because
we
have
George
and
do
you
want
to
jump
to
item
11
I
know
you
have
a
head
open
up
a
PR
for
multiple
funding
sources
and
because
we
have
about
you
on,
did
you
want?
A
G
E
G
Obviously,
you
guys
you
folks
call
but
then
I've
been
begun,
work
on
an
implementation
PR
that
Roy's
been
helping
me
with,
and
we've
got
another
block
of
time
scheduled
for
tomorrow.
So
hopefully
we
can
make
that
work.
G
For
me,
then
does
that
show
up
as
50
packages
with
51
URLs
listed
or
does
that
show
up
as
like
it
like
one
entry
with
50
packages
in
51
URLs,
or
does
that
show
up
as
50
entries
with
or
sorry
one
entry
with
50
packages
and
the
github
sponsors
URL
and
then
50
entries
each
with
one
tied,
lift
URL?
It's
pretty
much
either
one
of
those.
Otherwise,
it's
weird
and
I,
don't
know
which
one's
better
but
I
have
an
intuition
that
Roo
and
I
Rory
and
I
have
been
talking
about,
is.
A
A
G
The
a
URL
is
either
going
to
be
specific
to
a
package
or
specific
to
a
person
or
specific
to
an
organization
which
is
kind
of
the
same
as
specific
to
a
person.
So
it's
either
like
one
package
or
broadly,
and
that's
really
the
only
bit
that
matters
here,
because
if
it's
specific
to
the
package,
it
should
only
show
up
under
that
packages
name.
But
in
my
in
my
opinion.
G
But
if
it
is
not
specific
to
a
package,
then
it
should
be
duped
and
the
likelihood
is
that,
based
on
the
current
design
of
funding
is
that
the
uniqueness
of
the
URL
will
give
you
that
information
in
that
my
github
sponsors
URL,
is
the
same
for
every
package.
However,
I've
noticed
at
least
one
user
I
think
cinder.
G
Does
this,
where
you
can
put
the
repo
URL
with
question
mark
sponsor,
equals
one
and
that
pops
up
the
specific
packages
repo
with
a
sponsor
pop-up
so
by
him
doing
that
his
thousand
packages
will
never
be
d
tubes
because,
instead
of
you
know
and
that's
his
choice,
I
suppose
he
what
he
would
rather
flood
the
list
with
vertical
entries
than
have
one
massive
like
look?
How
many
packages
I
make
that
you
depend
on
I
prefer
actually
the
other
way.
But,
like
you.
F
G
F
G
Well
and
and
I
I,
imagine
that
sometime
in
the
future,
all
of
my
funding,
your
fields
will
be
replaced
with
a
single
like
URL.
That
points
me
to
an
NPM
doc
is
comm
page.
That
then
lists
all
the
various
information
of
all
the
contributors
and
so
on,
but,
like
you
know,
we
want
it
to
be
extensible
beyond
that.
Well,.