►
From YouTube: Open RFC Meeting - Wednesday, September 29th 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
C
Okay,
I
will
have
to
update
that
with
a
live
version
of
that.
C
Make
sure
that
we're
live
here,
yeah,
nice
awesome,
the
studio
was
just
not
updating
here
for
me
on
my
side,
awesome
so
welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
september.
The
29th
for
folks
that
have
just
joined
us
feel
free
to
add
yourselves
to
the
meeting
notes,
doc
that
I've
just
copied
and
pasted
the
hackmd
notes
there
and
add
yourself
as
an
attendee.
C
You
will
be
following
along
the
agenda
that
was
actually
posted
just
this
morning
in
issue
468
in
the
mpm
rfc's
repo
I'll
copy
and
paste
reference
to
that
as
well.
For
folks
and
just
a
quick
acknowledgement,
these
calls
and
all
comms
on
the
rfc's
repos
are
covered
by
our
code
of
conduct.
We
ask
that
folks,
please
be
kind
and
respectful
of
each
other,
especially
on
these
calls
and
give
each
other
time
to
speak.
C
If
you'd
like
to
comment
when
others
are
speaking,
please
raise
your
hand
and
we'll
call
on
you
and
also
want
to
just
quickly
give
some
time
for
any
announcements
that
folks
may
have.
If
you
have
anything
that's
going
on
in
the
community
and
want
to
shout
out
feel
free
to
now.
C
If
not,
I
guess
the
one
major
announcement
from
our
camp,
our
team.
We
are
planning
on
cutting
the
mpm
dex
major
version
of
npm
next
week,
so
that's
going
to
be
nfpm8.
We
put
it
on
folks
radar
and
it's
the
first
item
here
that
we've
got
queued
up.
C
That
we've
been
talking
about
in
issue
four
four:
five
in
the
npm
rfc's
repo,
we
sort
of
outlined
the
intentions
behind
this
major
release,
cut
primarily
being
that
we
want
to
increase
and
ensure
that
the
supportability
of
the
project
is
manageable,
for
our
team
and
and
dropping
unsupported
versions
of
node
is
a
part
of
that
and
and
will
ensure
that
we
can
be
successful
for
a
long
time.
I'm
not
sure
if
anybody
had
any
comments
or
want
to
share
anything
from
that
thread.
I
know
gary.
D
Yeah,
just
that
sorry,
a
little
frog
in
my
throat
where
we've
landed
is
is
whenever
12
and
14
went
into
lts.
That's
the
minimum
we're
going
to
support
and,
of
course
no
is
going
to
be
part
of
that
initial
update.
It
technically
still
supports
parts
of
10,
but
we,
I
think,
that's
in
in
the
spirit
of
this
update
and
that's
the
only
anything
close
to
a
breaking
change
that
should
go
innate
and
then
so,
and
the
node.js
folks
are
aware
and
they're
on
board
awesome.
C
Thanks
for
updating
that,
if
there's
no
other
comments
on
that
issue,
we
can
move
on
also
to
the
next
item
which
I
shuffled
around
here
since
I
know
that
there
hasn't
been
much
to
update
and
I
think
we
had
a
few
action
items
from
our
last
call
around
audio
assertions.
So
this
is
pr422
toony.
I
know
I
think.
C
Last
week
we
just
basically
said
we
don't
know
exactly
like
what
the
next
steps
are,
but
there
could
be
a
separate
rfc
created
for
potentially
paired
down
version
of
the
npm
audit,
resolver
supported
local
schema
or
or
sort
of
some
sort
of
like
resolutions
schema
that
we
actually
do
support.
So
I
think
we
have
it
on
our
plate
on
our
teamsplit
to
essentially
make
that
rfc
and
yeah.
I
just
want
to
essentially
update
that
we
haven't
backlogged
that
yet
isaac
any
comments
on
your
side.
I
see
you're
unmuted.
C
Is
there
any
anything
on
your
side?
No,
that
sounds
good
moving
along
then
to
the
net
new
issue.
Here,
jordan,
I
see
just
npm
publish
dash
if
needed.
This
is
rfc
466
I'll
comment,
the
or
reference
the
issue
here.
Did
you
want
to
give
a
quick
synopsis
of
of
this
joint.
E
However,
npm
publish
is
not
repeatable,
which
means
that
if
you
run
it
twice
in
a
row,
the
second
time
errors.
So
if
a
ci
job
gets
re-ran
for
any
reason
of
which
there
are
many
legitimate
ones,
it
will
fail
and
there's
not
really
a
good
work
around
for
this,
because
if
we
make
the
job
succeed,
even
when
it
fails,
then
that
will
mask
real
publishing
errors
and
the
the
work
around
is
that
I've
described
in
the
issue,
we're
not
even
sure
if
this
will
work.
E
This
was
just
the
idea
for
a
workaround
and
we're
planning
on
trying
it,
but
essentially
the
proposal
is
some
sort
of
way
to
make
npm
publish
like
like
when
you
run
a
command,
there's
two
kind
of
philosophies.
One
is
if
it
doesn't
do
the
thing
it's
meant
to
do,
then
it
should
fail.
But
another
philosophy
is
if,
at
the
end
of
the
command
the
desired
thing
is
done.
It
should
succeed.
E
So,
for
example,
if
you
remove
something
that's
already
removed,
it
ends
up
not
being
there
so
that
I
want
that
to
succeed,
and
in
this
case,
if
I
am
trying
to
publish
a
specific
set
of
a
specific
tarball
of
you,
know,
file
contents
that
are
the
same
add
a
certain
version
number
and
at
the
end
of
my
publish
command
those
are
there.
Then
it
succeeded,
even
if
it
was.
E
E
So
that's
the
semantic
I'm
looking
for,
and
I
suggested
it
as
an
option.
Isaac
has
suggested
it
could
be
by
default.
I'm
totally
happy
with
that.
I
just
kind
of
default
to
asking
for
an
option,
because
that
has
it's
a
lot
easier
to
then
ask
to
change
the
default
than
it
is
to
you
know
at
the
beginning.
So
that's
the
summary.
B
B
It
should
work
the
second
time,
possibly
with
some
response.
It's
something
in
the
response
body
that
says
yeah.
I
didn't
actually
do
anything,
but
this
was
already
there,
so
we're
good.
So
yeah,
I
don't
see
any
reason
why
and
the
npm
published
ply
command
couldn't
have
that
semantic.
E
B
No,
it
wouldn't
work
for
other
versions
of
the
client,
because
the
npm
cli
doesn't
even
try
to
publish
if
it
sees
that
that
version
is
already
there.
Okay
right,
it
just
gives
up,
but
we
could
go
ahead
and
you
know
pack
the
artifact
and
then
check
if
the
version
there
matches
the
same
integrity
as
we're
about
to
write
right.
E
B
I'm
just
not
gonna
do
that
post,
I'm
gonna
say:
okay,
it
worked
and
if
it,
what
we
could
also
do
is
say:
if
it's,
if
it's
something
there
and
it's
different,
then
we
fail.
Unless
we
do
force,
in
which
case
we
go
ahead
and
post
it
and
the
server
will
tell
us
no
right
and.
B
A
registry
that
allows
clobbering
versions-
you
know
ill-advisedly,
perhaps
then
npm
publish
dash
f,
will
will
come
back.
It
just
won't
ever
be
allowed
on
the
public
registry.
A
B
B
D
All
right,
I
saw
your
hand,
was
up
at
one
point
what
the
what
I
was
gonna
bring
up
got
covered
in
the
discussion,
so
we're
good.
Well,
just
the
force
option
or.
D
I
was
just
asking
I
was
going
to
ask
if
there
are
registries
that
allow
republishing
and
the
force
option,
you
know
yeah
it.
I
have
no
questions
based
on
the
spec
we're
talking
about
and
I
would
agree
the
cla
should
just
be
like
yeah
yeah.
It's
published
we're
fine,
because
that's
the
thing
you
asked
it
to
do
has
already
been
done.
C
Awesome,
so
is
the
idea
that
dash
like
repeatable
is
not.
We
don't
want
to
do
that.
We
just
want
to
basically
change
the
behavior
today
and
potentially
provide
us
force.
E
E
E
E
And
isaac,
this
is
sort
of
off
topic,
but
is
there
a
reason
why
reverting
and
unpublish
isn't
something
that
could
be
permitted
like?
I
understand
why
publishing
different
contents
on
the
same
version
number
should
never
be
allowed
but
like
if
I
accidentally
unpublish-
and
I
want
to
unpublish-
is
that?
Is
there
a
like
philosophical
reason
why
that
couldn't
be
allowed.
B
E
B
Got
it
it
would
be
a
almost
100
percent,
a
server-side
change,
though
the
reason
is
that
unpublishing
and
locking
down
the
version
number
came.
You
know
arrived
prior
to
our
current
way
that
we
do
integrity
checking.
So
it's
completely
an
accident
of
history
that
we
don't
track.
It.
E
E
E
C
In
terms
of
the
last
item
we
have,
this
is
prrc434.
C
I
believe
we've
spoken
about
this
at
length
in
the
last
couple.
Rc
calls.
I
think
there
was
an
action
item
for
you
isaac.
I
think
maybe
just
to
look
at
this
and
potentially
clean
like
give
feedback.
This
is
the
support
package
lock
at
json,
v3
and
mpm7.
I
think
this
is
just
the
yeah.
This
is
the
package
lock
version
field,
yeah.
B
I
I
provided
some
feedback.
This
is
this
can
probably
just
be
turned
into.
Like
I
mean
I
haven't
reviewed
the
the
thing,
but
I
guess
the
the
action
that's
left
here
is
just
review
it
and
ratify
it
and
then
get
on
implementing
it.
I
mean
it's
not
really
that
controversial
of
a
thing.
C
Okay-
and
that
brings
us
essentially
to
the
end
of
our
agenda
today-
did
it
folks
have
anything
else
they
want
to
bring
up
or
any
discussion.
D
Just
to
publish
stuff,
you
know
this
is
an
open
source
project.
If
this
is
something
someone
wants
and
wants
a
handhold
on
how
to
implement
it,
reach
out
to
me,
I
can
at
least
help
you
out
there.
There's
no
reason
if
this
is
something
you
need
it
has
to
sit
in
the
backlog.
That's
goes
for
any
anything.
D
We
really
want
to
encourage
figuring
out
where
the
pain
points
are
on
external
contributions.
So
please
reach
out
to
me.
Rathgar
github.com,.
A
Good
to
know
one
thing
that
got
brought
up,
I
I
managed
the
no
twitter
account,
and
one
of
the
things
I
saw
in
one
of
the
threads
was
an
older
topic
that
I
believe
we
discussed
with
miles
a
while
ago,
but
it
was
I
hate
that
my
camera
focuses
on
my
mic.
A
Basically,
the
global
cache
being
scoped
to
the
user
by
default
is
that
something
people
would
still
be
interested
in,
like
I'm
happy
to
try
to
throw
up
an
rfc
for
it,
but
I
figure,
since
we
have
40-ish
minutes
there,
it
might
be
good
to
get
feelings
on
that
before
I
do.
What
is
this
idea?
So,
basically,
very
often
it's
suggested
that
people
change
the
prefix
of
global
modules
to
be
a
like,
a
a
directory
that
their
user
owns
and
yeah
and
just
making
that
default.
A
So
people
don't
run
stuff
as
pseudo
would
be
nice,
and
I
I
know
that
this
has
been
discussed
before
so
I
wanted
to.
But
I
realized
there
was,
I
don't
think,
there's
an
rfc
for
it,
part
of
it.
Yeah.
B
You
want
to
be
able
to
npmi
dash
ge
foo
and
then
the
food
binary
is
in
your
path
already
and
there's
nowhere
under
home,
that's
sort
of
by
default.
In
the
past,
in
sort
of
stock,
munich,
setups,
right,
yep,
okay,
cool.
We
bite
that
bullet
on
windows
by
the
node
installer,
adding
the
npm
global
location
to
your
path.
B
We
could
print
a
you
know.
If
we
detect
that's
the
situation,
we
could
print
a
warning
that
says:
hey
like
the
global
bin,
I'm
installing
a
global
thing,
but
a
global
bin
is
not
in
your
path.
So
here's
what
you
need
to
do
to
fix
that,
and
I
you
know
I
I
think
it's.
B
C
B
And
mac
also
already
like
locks
down
user,
like
user
band
and
user
lib.
A
And
I
think
the
use
case
for
this
is
is
largely
the
same
use
case
for
npm
audit.
Whatever
the
pr
is,
it's
basically,
first
time,
users
who
don't
know
a
lot
about
javascript,
don't
know
what
they're
doing
with
package
managers
don't
necessarily
know
a
lot
about
computers,
not
that
they
don't
know
enough,
but
they're,
not
necessarily
completely
familiar
with.
A
You
know
what
doing
that
looks
like
and
what
that
means,
and
all
of
that
it's
more
of
a
dx
improvement
for
the
early
early
career
developer,
rather
than
someone
who's
a
little
bit
more
familiar
with
how
how
stuff
works.
E
Well,
presumably,
these
users
are
using
like
presumably
that
they're,
not
downloading
the
tarball
and
like
make
configuring
themselves
right,
they're
using
a
node,
it's
an
official,
node,
installer
or
they're,
using
a
version
manager
or
they're
using
you
know
like
apt
or
whatever
their
linux.
Distros
thing
is
like
nvm
and
maybe
nave.
They
modify
the
path
for
you.
So
like.
B
E
Yes,
and
so
the
nodes
they
install
are
already
like
that
just
happens.
What
you're
asking
for
it's
already
the
case,
the
node
installer,
it
seems
like
it
could
just
do
that
and
npm
wouldn't
have
to
be
involved
at
all,
because,
like
npm
will
just
work
like
if
the
if
npm
is
installed
inside
the
user's
home
directory
npm
root
g
will
be
there
too,
and
if
not,
then
that
can
be
overridden
with
the
prefix
config,
which
node
could
supply
in
a
built-in
npm
rc
in
the
npm
at
ships.
Are
you
absolutely.
A
Like
sorry,
I
I
I,
I
would
definitely
recommend
that
we,
like
I
don't
know,
I
don't
want
to
rely
on
the
node
installer
to
do
stuff
like
I
I
cause,
then
it
gets
into
stickier
questions
of
like
well,
what
about
yarn
or
what
about
pmpm
or
what
about
you
know
whatever
pm
like,
I
generally
want
to
try
to
solve
these
things
at
the
project
level
rather
than
the
node.
Does
it
for
us
and
we're
lucky
that
it
does
it
for
us.
E
I
mean,
I
think
the
past
thing
just
means
that
like
npm
could
do
it,
but
it
would
there
would
have
to
be
instructions,
hey
user,
put
this
in
your
path
or
you
won't
be
able
to
use
global
modules
and
the
very
users
you're
trying
to
help
probably
won't
know
how
to
do
that
unless
an
installer
has
done
it
for
them
yeah.
So,
like
I,
I
like
I'm
on
board
with
the
goal.
You
know
I'm
just
I'm
not
sure
how
feasible
it
is
to
do
it
at
the
package
manager
level
versus
at
the
installer
level.
D
A
Yeah-
and
I
think
that
this
discussion
was
also
partially
tied
with
having
an
official
node
nvm
ish
thing
previously,
so
that
makes
sense
cool.
C
Awesome
is
there
any
other
discussion
topics
folks
want
to
bring
up
or
want
to
discuss
now.
E
E
I
understand
this
is
old,
unsupported
npms,
that
work
on
old,
unsupported
nodes,
and
so,
if
nobody
wants
to
do
any
work
on
it
like
I
get
it,
but
the
nvm
has
a
feature
called
nvm
install
latest
npm,
because
npm
has
never
consistently
there's
never
been
a
way
to
consistently
identify
for
a
given
npm
version,
which
node
version
it'll
work
on
now
it's
starting
to
use
engines
reliably,
but
npm
is
in
posix.
It
doesn't
have
a
sember
parser.
E
So
but
the
goal
is
you
can
run
that
function
on
every
version
of
node
ever
and
it
will
get
you
to
the
latest
possible
working
version
of
npm.
I
utilize
this
in
ci
to
make
sure
that
I
can
like
as
much
as
possible
get
the
latest
npm
available.
E
E
Is
there
any
way
that
old
npm
can
be
like
and
to
be
clear,
the
can.
The
strict
ssl
false
config
is
not
sufficient
to
to
work
around
this
problem.
Is
there
any
config,
I'm
unaware
of
any
way
to
make
npm
one
be
able
to
connect
or
is
it
just
ship
is
sailed?
It
doesn't
have
tls
1.2,
so.
B
E
B
E
Okay
and
they're
not
aware
of
any
work
around
to
get
a
later
version
of
npm,
and
but
I
guess
that,
wouldn't
matter
because
you're
saying
the
node
version
itself,
okay,.
B
So
if
you
actually
want
a
workaround
yeah,
the
workaround
would
be
compile
node
0.8
against
a
newer
version
of
openssl
which,
since
I
believe
that
there
have
been
api
changes
and
abi
changes
in
openssl,
is
probably
going
to
require
that
you
fork
node
0.8.
So
at
this
point
I
hate
to
say
it,
but
I
I
think
the
universe
is
really
trying
to
find
the
limits
of
your
backwards
compatibility
right
right.
E
Well,
I
mean
the
workaround
I've
done
for
my
packages.
I
think
at
the
moment
is
I
jump
to
node
0.10
and
I
install
the
depths
and
then
I
jump
back
and
that
has
been
okay,
but
tests
that
are
failing
right
now
are
nvm's
own
tests
for
the
install
latest
npm
logic,
but
it
doesn't
seem
like
I
have.
It
doesn't
mean
there's
going
to
be
a
workaround
for
that.
E
B
It's
software,
as
I
say
you
you
could
you
could
do
it
but
you're
going
to
have
to
have
a
you're
going
to
have
to
have
an
engine,
an
http
client
that
can
speak
the
version
of
tls,
that's
required
and-
or
I
guess
technically
a
tls8
client,
not
a
http
client,
and
if
you
don't
have
that,
then
there's
gonna
not
be
any
way
to
connect
right.
B
Yeah
I
mean
you:
could
you
could
run
an
older
npm
on
a
newer
node
there's
going
to
be
some
overlap
there,
where
it
will
keep
working?
I
believe
that
I
believe
that
note
that
npm,
zero
dot
or
npm
one
might
not
work
on
node
16..
B
There
were
some
breaking
changes,
I
believe
in
the
like
12
or
14
era.
I
could
be
misremembering
here
which
required
that
we
update
things
so
yeah.
This
is
this.
Is
some
deep
archaeology
you're
doing
here.
B
B
C
Any
other
topics
folks
want
to
bring
up.
Well,
we
have
each
other's
time.
C
If
not
I'll,
give
you
all
back
roughly
a
half
hour,
thank
you
again
for
jumping
on
board
and
hopefully
we
can
make
some
progress
in
the
next
week
or
so.
I
look
forward
to
seeing
you
all
next
week
and
continue
on
the
conversation.
Async
cheers.