►
From YouTube: Open RFC Meeting - Wednesday, October 13th 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
A
And
we're
live,
welcome
everyone
to
another
npm
openrc
call.
Today's
date
is
wednesday
october
13th,
2021
we'll
be
following
along
in
the
agenda.
That
was
posted.
I
believe
in
issue
number.
A
And
I'll
just
copy
and
paste
for
folks
that
just
joined
the
meeting
note
stock
in
the
chat
feel
free
to
add
yourselves
as
attendees
as
usual.
We
ask
that
folks
that
are
joining
on
these
calls
and
are
communicating
with
us
on
the
rfc's
repo.
Please
abide
by
the
code
of
conduct
and
please
be
kind
and
thoughtful
to
each
other
and
respectful
of
each
other.
A
When
we're
speaking,
please
raise
your
hand
if
somebody
else
is
speaking
and
you
would
like
to
add
a
comment
and
just
quickly
in
terms
of
announcements,
I
wanted
to
note
that
last
week
we
did
cut
a
major
version
of
the
mpm
cli
npm-8,
which
was
essentially
the
primary
breaking
change,
was
dropping
note,
support
and
updating
a
few
depths,
including
no
chip.
A
So,
if
you
haven't
already,
please
go
grab
the
latest
version
of
npm.
If
you
can
and
yeah
we've
essentially
just
dropped,
node
10
support
in
that
major
want
to
give
some
space
for
folks.
If
anybody
else
has
other
announcements,
they
wanted
to
share.
B
Actually,
just
wanted
to
attack
on
what
you
just
said
darcy,
I
I
think
the
the
big
thing
too,
one
of
the
big
things
to
take
away
from
this
major
release
is
that
effectively,
you
know
we're
still
working
on
the
same
set
of
bugs
that
were
this
doesn't
mean
that
that
that
that
npm
7
is
is
quote
finished.
It
just
means
that
we're
continuing
to
work
on
npm,
seven
in
npm,
eight.
A
That's
great
note,
unlike
six
to
seven,
this
wasn't
a
massive
refactoring
of
code
as
or
as
much
of
a
change.
So
the
hope
is
that
we're
going
to
continue
to
address
bugs
that
would
have
been
filed
already
against
v7
and-
and
I
think,
a
few
of
these
issues
that
we
have
on
the
agenda
today
speak
to
that.
So
any
other
announcements
or
comments.
I
guess
on
on
that.
A
If
not,
then
we
can
dive
right
into
the
agenda.
The
first
item
that
we
have-
and
I
think
the
one
that
is
probably
the
most
important,
is
the
rfc
472.
This
was
created
by
rebecca.
I
think
this
is
follow-up
to
an
issue
that
you
filed
a
little
while
back
but
I'll.
Let
you
speak
to
some
of
the
context.
C
Sure
so
this
is
a
npm
7
behavior.
That
makes
it
so
that,
under
certain
circumstances,
scoped
modules
are
impossible
to
install
and
specifically,
if
you're,
using
a
third-party
registry
that
returns,
that
does
not.
You
know
that
is
a
you
know,
partial
proxy,
so
yeah
you
publish
some
private
modules
to
it.
Maybe,
but
the
rest
of
it
is
just
returning
the
public
registry
urls
for
this
packages.
C
In
that
scenario,
and
only
for
scoped
modules,
the
the
package
urls
get
rewritten
to
follow
the
npm.js
registry
format,
but
on
the
currently
specified
registry,
rather
than
using
the
package
url,
the
tarball
url
specified
in
the
pacument
and
so
yeah.
So
the
repro
that
I
put
up
you
can
it
just
sets
up
a
a
proxy
that
does
this
and
then
tries
to
run
and
install
with
it,
and
then
it
breaks.
So
that's
the
that's
the
heart
of
the
problem,
some
of
the
like.
C
C
D
Yeah,
I
think,
if
I
remember
correctly-
and
I
haven't
looked
at
it
in
a
little
while
the
the
scoped
versus
unscoped
seemed
like
a
red
herring
in
the
in
the
example
that
I
s
that
I
saw,
I
think
the
the
issue
just
had
to
do
with
how
the
like
it
was
proxying.
D
D
But
that
said,
I
completely
agree
with
everything
else.
You
know
we
we
in
npm6,
I
think
it.
I
think
this
might
have
even
gone
back
further
like
way
back
to
the
dark
ages
of
like
npm
one
or
two.
The
registry.npmjs.org
host
name
was
kind
of
treated
as
a
little
bit
of
a
sort
of
magic,
placeholder
string.
So
if
you
change
your
registry,
it
would
be
like
okay
well,
I
was
getting
this
from
the
public
registry,
but
you
want
a
different
registry.
D
So
let's
do
this
other
thing
not
everywhere
and
not
entirely
consistently,
so,
rather
than
strip
out
all
the
magic
which
we
started
in
npm
seven,
and
then
that
ended
up
breaking
some
things.
We
were
like
okay,
well,
let's
at
least
make
it
consistently
magical.
So
that's
the
way,
the
way
that
it
went.
I'm
I'm
surprised
and
disappointed
in
myself
that
we
didn't
think
to
just
like
why?
Don't
we
just
track
the
registry
url
in
the
lock
file?
That's
like
an
obvious
in
retrospect
and
genius
idea.
D
So
we
should
totally
do
that
and
then
that
gives
us
a
step
towards
de-magicking
the
whole
thing
by
saying:
okay!
Well,
your
your
registry,
url
is
the
same
as
the
last
time
you
installed,
so
these
resolved
urls.
I
can
just
trust
them
or
your
registry
url
is
your
top-level
registry.
Url
is
now
different,
so
any
resolved
url
is
kind
of
it's
no
longer
trustworthy.
I
need
to
look
up
the
actual
package
metadata.
D
I
think
that
would
solve
a
lot
of
problems
or
the
the
downside,
which
I
call
that
in
the
issue,
pretty
not
completely
uncommon
use
case
is
to
have
a
like
an
nginx
proxy
or
just
some
other,
like
real,
simple,
simple
proxying
registry,
that
all
it
does
is
pass
through
the
data
exactly
from
the
public
registry.
D
D
So
that's
sort
of
my
my
two
cents
on
this.
I
think
I
I
I
don't
off
the
top
of
my
head,
see
anything
that
should
really
change
in
this
suggestion.
A
C
Yeah,
the
the
proposal
in
the
rrfc
is
that
the
registry
that
was
used
to
create
the
lock
file
is
recorded
in
the
lock
file,
which
helps
that
like
pull
reproducibility
story
and
then,
if
the
registry
that
the
user
is
installing
with
is
different
than
the
one
in
the
log
file,
then
we
invalidate
all
of
the
resolved
urls
and
go
recompute.
Those
from
the
I
should
say
from
the
pacument
data
from
the
whatever
register
you
are
using
now,
rather
than
trying
to
do
magic.
D
Yeah,
so
the
one
so
two
potential
questions
that
come
to
mind.
One
is
if
we're
invalidating
the
the
tarball
url
should
we
also
be
invalidating
the
integrity?
D
D
C
D
D
It
already
yeah
good
point,
so
the
other
thing,
if
we're
storing
the
lock
file,
if
we're
starting
the
top
level
registry
for
lock
files,
we
also
store
the
registry
that
might
be
assigned
to
any
given
scope
and
that
I'm
sort
of
a
little
more
torn
on,
because
that
can
I've.
D
I
have
seen
people
put
user
names
and
passwords
in
their
scope
registries,
and
we're
also
going
to
be
very
careful
that
we
don't
put
a
username
or
password
in
the
document
registry,
so
it
basically
needs
to
do
you
know
sort
of
a
a
nerf
darting
of
that
registry
for
what
we
actually
store.
E
Yeah,
I
was
mainly
just
wondering
if
the
change
all
sounds
fine
right
have
no
disagreement
with
anything.
I
was
just
curious.
Is
this?
What
impact
is
this
going
to
have
on
lock
file
diff
churn,
like
the
like,
knowing
what
I
know
now?
E
If
I
could
go
back
in
time,
I
would
probably
suggest
really
strongly
that
the
registry
domain
name
like
that
that
part
of
the
tarball
url
not
actually
be
stored
with
each
package
that,
rather
than
storing
it
three
thousand
times
that
it
be
stored
like
in
one
place,
for
every
for
bare
things
and
one
place
for
scope
for
each
scope
and
then
like
have
just
the
sub
path
be
in
there,
because
that's
that
would
avoid
all
the
churn,
but
obviously
that's
not
worth
suggesting
now
but
like
is
there,
I'm
hoping
this
improvement
will
will
reduce
that
churn.
D
E
And
I
don't
mean
that
the
log
file
now
shows
up
in
git
status.
I
mean
like
that,
if
it
any
entry
that
isn't
related
to
a
package,
I'm
installing
should
ideally
not
get
updated,
but
in
particular
that
something
that
I've
often
seen
over
the
years
is
the
that.
E
The
when
we're
using
an
internal
registry
that,
depending
on
what
the
local
user
does,
sometimes
they
will
update
every
registry
in
their
lock
file
to
point
to
the
public
one,
and
then
we
have
to
do
some
sort
of
said
hacky
grossness
to
like
automatically
transform
it
back
to
the
internal
registry
url
on
their
behalf,
and
maybe
this
is
an
unrelated
problem
it
just.
I
wanted
to
ask.
D
Yeah
that
does
seem
like
it,
wouldn't
really
be
affected
by
this.
That's
good
and
we
wouldn't
be
re-evaluating
anything
that
we
don't
have
to
re-evaluate
right.
If
the
dependency
is
there
and
it's
fine,
we'll
just
leave
it
there
and
we
won't
have
to
look
at
it.
C
D
D
That's
an
interesting
question:
let's
say
I
I
have.
I
have
a
bunch
of
stuff
in
my
tree.
You
know
all
my
dependencies
are
there.
I
change
my
registry
and
do
like
I
do.
Npm
install
foo
dash
registry
equals
something
else
at
that
point
now
I'm
doing
an
install
and
I'm
changing
my
registry,
but
only
a
very
small
portion
of
my
tree
needs
to
be
sort
of
evaluated
or
looked
at
so
currently
we
don't
re-resolve
all
of
those
dependencies
right.
D
The
question
would
be
like:
will
that
cause
everything
in
my
lock
file
to
get
its
resolved,
url
re-updated
to
the
new
registry,
or
just
the
things
that
actually
had
to
be
looked
up
as
that
as
part
of
that
install,
because
if,
if
it's
the
first
one
we're
gonna
be
adding
potentially
quite
a
lot
of
lock
file
churn
and
in
fact,
when
I
do
npm
install
foo
dash
dash
register
equals
bar
like
everything,
my
everything
else
might
not
even
be
on
that
bar
registry.
D
C
D
A
F
I
have
a
question,
so
is
this:
how
is
this
like?
The
in
the
lock
file?
What
is
the
structure
of
this
being
proposed
because,
like
the
one
that
I
can
see,
making
the
most
sense,
given
we
want
to
support
multiple
registries
is
like
having
the
registry
as
a
key
and
then
basically,
whatever
the
current
status
of
like
all
of
the
packages
that
fall
under
that
registry.
F
As
you
know,
the
value
in
their
current
syntax
or
having
like
an
identifier
that
you
at
attach
to
each
one,
but
that
sounds
like
it
adds
a
much
larger
json
file
than
than
you
want.
D
As
I
understand
it,
and
rebecca
definitely
correct
me,
if
I'm
wrong,
what
we're
talking
about
is
way
way
smaller
than
that
we're
talking
about
adding
a
a
single
string
at
the
top
level,
that
is
just
registry,
colon,
url,.
C
D
Right
right,
so
in
that
case
perhaps
as
well,
I
mean
that
might
come
back
to
that
that
thing
of
like
well,
then
we
shouldn't
just
store
this
go
the
current
top
level
registry.
We
shouldn't
include
all
the
scope
registries
and
then,
if
those
are
different
in
an
install
process-
and
we
have
to
resolve
one
of
those
things,
we
update
their
their
resolved
fields.
F
I
I
don't
I
mean
I
guess
in
that
situation
like
I
maybe
I'm
slightly
misunderstanding,
I'm
mildly
struggling
to
follow
what
you're
saying,
but
I
I
think
in
that
situation.
Like
you
know,
the
way
I've
done
in
the
past
with
verdaccio
was
like
that
scope
will
always
be
that
specific
registry,
like
it's,
never
going
to
be
a
public
registry.
There's
no,
it's
it's
not
really
changing
it's
very
static,
and
so
like
it's,
it's
less
of
a
like.
F
This
may
come
from
one
register
or
the
other,
but
it's
it's
always
gonna
come
from,
and
that's
kind
of
where
that
syntax
I
was
kind
of
asking
about
is
potentially
coming
from,
is
like
basically
just
having
a
key
and
then,
like
you
know,
a
key
and
value
where
the
value
is
the
current
structure
of
how
you
know,
package
lock
is
defined
and
the
key
is
whatever
the
registry
comes
from
and
in
most
cases,
that'll
be
a
one-liner,
but
in
like
you
know
more
niche
cases
that
are
more
enterprise-y,
that'll
that'll
end
up
being,
like
maybe
five
lines,
total.
F
That's
that's,
that's
the
simplest
way
I
can
think
of
it.
I'm
sure
I'm
sure
you
all
could
probably
figure
out
something
different
as
well
or
you
could
have
you
know
a
single
like
you
know,
an
object
at
the
top.
I
mean
quote-unquote
object
at
the
top
that
has
all
of
your
registries
and
then
have
like
a
registry
entry
property
on
every
every
package,
but
I
feel
like
that
has
way
too
much
noise.
It's
completely
unnecessary
if.
F
D
D
Yeah
and
it's
really
just
a
change
detection
right
like
it's
just
well,
is
this
the
same
registry.
I
used
to
generate
this
lock
file.
If
so,
I
don't
need
to
re-resolve
these
things.
I
can
just
fetch
their
tar
walls.
D
You
can
use
one
one
top
level
registry
and
a
registry
attached
to
each
scope,
yes
yeah,
so
if
any,
if,
if
the
registry
for
a
given
scope
has
changed,
then
similarly,
I
need
to
re-resolve
anything
at
that
scope.
I
can't
just
fetch
its
tarball.
F
Perhaps
you
could
just
do
at
the
top
level
at
that
top
level.
Entry
like
have
a
similar,
ui
or
structure
for
ui
structure
for
for
scopes,
where
it's
like
the
scope
and
then
whatever
that
registry
value
is
like
that.
That's
a
potential
solution
that
just
addresses
it
in
the
same
way
without
having
yeah.
D
Yeah
yeah,
we
could,
I
mean
we
could
even
have
you
know
at
foo
colon
registry
as
the
key,
and
then
the
value
is
a
url,
and
just
if,
if
that
config
has
changed,
then
we
know
that
we
can't
trust
anything
at
that
url
or
can't
trust.
Anything
at
that
scope
that
its
result,
value
is,
is
valid.
So.
A
D
D
D
Is
we
could,
we
could
add
the
field
and
we
could
do
the
re-resolution
but
not
strip
out
any
of
the
magic
right
and
that
would
be
doable
in
a
in.
D
And
that
would
not
because
it
we
would
still
preserve
that
you
know
improper
proxy
kind
of
use
case.
We
could
also
have
a
warning
or
something
to
say:
hey
like
you
know,
your
your.
Your
proxy
says
that
it's
tarballs
are
on
registry
npmjs.org,
but
we're
not
actually
fetching
them
from
there.
So
just
fyi,
that's
gonna,
break
or
change
someday.
A
Okay,
in
terms
of
actually
queuing
this
up
and
and
maybe
curating
this
rebecca,
were
you
interested
in
making
this
like
national
rc
from
the?
If
not,
we
can
get
somebody
on
our
team.
I.
A
And
then,
from
our
side
we
can
try
to
figure
out
if
this
can
land
in
in
a
minor.
I
guess
it's
definitely
sounds
like.
A
D
I
think
it
could
stay
in
lock,
file
version
two.
C
Yeah
I
I
would
agree
because
I
think
that
should
really
be
reserved
for
like
substantia,
like
things
that
break
compatibility,
because
there
is
code
that
is
like
no,
I
refuse
to
run,
and
I
don't
know
this
lockfile
version
I'm
not
going
to
try.
F
D
A
Okay,
so
given
that,
then
the
hope
is
that
we
could
potentially
land
this
in
a
minor.
I'm
just
concerned
about
churn
again
like
in
people's
package
locks.
A
Because,
as
soon
as
we
ship
this,
it's
everybody's,
lock,
files
are
gonna,
start
start
updating
and
add
this
new
information
right.
D
Yeah,
I
mean
it's
not
any
different
than
anything
else
that
we
start
resolving,
though
it's
like,
if
you,
if
you
do
an
install
and
you
do
an
install
with
a
save,
we
are
going
to
edit
your
log
file
like
that.
That's
how
it
works
today.
I
don't
think,
there's
anything
dramatic,
that's
going
to
change
here,
we're
not
talking
about
adding.
You
know
thousands
of
lines
of
changes
in
the
normal
case
unless
you
switch
to
a
different
registry
which
has
different
resolved
urls,
in
which
case
you
actually
want
that
right.
Okay,.
A
Okay
seems
straightforward,
then
I
will
add
this.
A
Okay,
any
other
comments
before
we
move
on.
A
If
not
feel
free
to
continue
to
add
to
the
notes-
and
you
can
see
some
folks
adding
things
there-
I
do
my
best
to
try
to
capture
conversation
but
don't
always
get
it
accurate,
so
feel
free
to
modify
and
update.
Accordingly.
A
Moving
on
to
the
second
item
we
had
in
the
agenda,
this
is
issue
473,
npm,
outdated,
returns,
incorrect
stats
code.
I
think
this
is
like
a
matter
of
opinion.
I
saw
rebecca
already
commented
back
to
the
author
of
this.
E
So
I
would
converse
a
lot
on
there.
I
I
don't
actually
have
a
strong
opinion
about
whether
mpm
outdated,
specifically
should
return
the
code.
In
this
specific
case,
I
just
really
strongly
pushed
back
against
the
argument
that
it
was
somehow
like
violating
some
law
or
like
improper
for
it
to
do
so.
Yeah.
I
totally
can
see
the
argument
both
ways,
keeping
it
the
same
or
changing
it
back.
E
H
I
don't
have
strong
opinion
either.
It's
just
that,
I'm
on
the
receiving
end
of
reviewing
those-
and
I
just
want
a
record
of
the
decision.
So
I
can
say
this
is
how
npm
works,
I'm
glad
to
keep
it
as
it
is.
I
understand
having
an
exit
one,
just
like
npm
ls,
which
a
lot
of
people
do
in
ci
to
make
sure
things
are
good.
It
makes
a
lot
of
sense
to
me.
D
Yeah,
I
seem
to
recall
that
there
was
a
npm
six
used
to
exit
one
if
there
were
outdated
packages
and
then
in
npm
seven,
we
mistakenly
got
rid
of
that
behavior
and
at
some
point
we
said
oops
and
we
fixed
it
and
every
time
you
fix
something
you
break
something.
That's
just
never
more
apparent
than
when
it
comes
to
exit
codes.
So
it
sounds
like
we're
all
in
agreement.
This
is
working
as
intended.
A
So
it's
just
giving
the
feedback
and
officially
I
guess,
blessing
response
so
to
car's
point.
Somebody
on
our
team
can
can
comment
back
and
we
can
use
that.
E
I
think
it
would
be
useful
to
like,
like,
for
example,
I
have
a
medium
opinion
that,
like
dash
dash
json,
should
not
ever
affect
the
exit
code.
It
only
affects
the
output
format,
for
example,
it
seems
useful
to
come
up
with
this,
like
sort
of
set
of
these
ideologies
for
npm,
on
the
command
line
and
write
them
somewhere
in
the
docs
and
just
be
like
here
is
how
we
expect
everything
to
work
if
it
doesn't
work.
This
way,
please
file
a
bug
and
then,
like
we
can
say,
like
every
command
should
either
like.
E
If
you
pass
json,
it
should
give
you
a
json
version
of
the
output,
or
it
should
error
like
if
you
pass
json.
The
exit
code
should
always
be
the
same
as
when
it's
not
there
and
like
things
like
that,
because
that
will
give
guidance
for
future
rfc
calls
as
well
when
deciding
what
is
the
appropriate
behavior.
F
Yeah,
I
just
learned
a
second
that
that
docu
like
having
that
in
the
mpm
docs,
actually,
I
think,
would
be
a
good
thing,
largely
because
I
could
like
if
this
is
documented,
then
it's
easy
to
point
to
here
are
the
official
npm
docs
and
like
it
also
helps
us
in
the
future.
If,
like
there's,
you
know
a
decision
that,
like
oh,
we
just
nobody
ever
uses
this
and
like
realistically
how
many?
F
How
often
are
people
using
like
npm,
home
or
npm
repo
package,
like
not
probably
not
a
lot
like
far
less
than
install
and
like
that,
might
do
something
weird
with
some
flag,
so
just
documenting
it
for
that
and
either
being
able
to
change
it
or
change.
The
feature
is
a
good,
a
good
decision.
Log.
C
Okay,
yeah,
there
is
actually
kind
of
to
jordan's
point
there.
There
is
actually
weird
behavior
in
npm
6,
which
I've
not
tested
in
npm,
8
or
7..
Just
from
when
I
was
looking
at
the
source
code
to
verify
the
older
behavior
is
that
it?
It
does
not
set
the
error
code.
If
you
use
parsable
or
json,
it
only
sets
the
error
code
in
normal
output.
D
D
But
yeah,
I
think,
to
tierne's
point
documenting
those
output
ideologies
would
be
super
super
handy
because
we
get
into
other
other
weird
cases
like
there's.
There
are
some
commands
where,
if
you
do
json,
then
some
json
gets
written
to
standard
error,
but
it
also
writes
a
whole
bunch
of
logs,
which
are
definitely
not
json
and
so
there's
no
way
you
can
possibly
parse
that
without
stripping
out
all
the
log
output.
D
A
Okay,
I've
took
in
the
action
item
for
us
to
document
some
of
these
like
ideologies
and
decisions
in
the
npm
docs.
So
we
can
definitely
cue
that
work
up
and
and
and
try
to
like,
even
have
like
a
one
pager
with
some
of
this
and
just
continue
to
expand
on
it.
As
these
conversations
come
up
and
we
can
try
to
document
like
the
thoughts
feelings
and
to
give
us
like
a
explicit
place
to
point
to
when
people
bring
these
kinds
of
issues
to
us.
A
D
H
H
Currently,
it's
my
understanding
that
exit
code
is
not
determined
by
whether
or
not
you're
doing
json
or
parcel,
so
it
would
be
safe
to
put
that
into
the
docs
now,
as
this
is
how
it
does
work,
and
we
expect
it
to
work
if
we
want
to
change
that
we
can.
But
I
think
that
would
be
worth
at
least
also
adding.
A
Yeah
we
can
have
a
whole
section,
that's
like
nuances
or
quirks
that
maybe
deviate
from
our
wants
from
from
future
work
right
as
well.
So
like
it
may
be
the
case
that
that's
not
what
we
intend
to
do
in
the
future,
but
just
like,
as
you
said,
document
how
how
things
are
operating
today,
so
cool.
I
want
to
quickly
move
on
to
the
last
item,
which
may
also
be
fairly
quick
conversation.
A
This
is
rfc
issue
471.
This
is
someone
recommending
that
we
exclude
new
modules,
explicitly
excluding
modules
from
time,
machine,
backups
or
any
other
kind
of
like
and
backups
like
dropbox.
I
think
jordan.
You
had
responded
to
this
as
well.
They
do
make
a
note
in
here.
I
don't
believe
they're
on
on
the
call,
but
do
you
make
a
point
that
rust
has
taken
the
the
aim
of
excluding
these
by
defaults?
A
That
may
not
make
any
difference
to
us,
since
obviously,
npm
has
a
legacy
of
12-ish
years,
so
this
could
be
have
a
bigger,
be
a
bigger
breaking
change.
Potentially,
if
we
implemented
something
like
this,
so
I'm
not
sure.
E
Jordan,
if
you
want
to
my
interest,
is
that
it
for
many
years
has
driven
me
nuts,
that
both
dropbox
and
time
machine
and
spotlight
all
look
at
node
modules
and
get
ignored
things.
I
yeah
the
anything
that
can
improve
that
scenario.
That
situation
sounds
good
to
me
and
as
far
as
like
it's
it's
sort
of
a
mac,
only
consideration
for
time,
machine
and
spotlight,
but
it
seemed
like
this
was
some
of
the
later
comments
on
it.
E
It
seems
like
you
could
just
check
for
the
presence
of
like
x-actors
or
something
and
shell
out
to
it,
if
it's
there
and
just
not
to
do
that
code
path.
If
it's
not
a
mac,
basically
don't
know.
D
I
I
I
feel
like
there's
very
little
downside.
It
should
be,
maybe
opt
out
if
you
really
want
your
node
modules.
B
D
Backed
up
in
time
machine,
but
I
think
the
overwhelming
majority
of
people,
just
if
they're,
if
they're
backing
up
their
node
modules,
folder
it's
because
they
don't
notice,
like
you,
have
a
log
file,
it's
that
is
that
is
compiled,
generated
machine
generated
stuff.
Basically,.
E
A
E
So
is
it
reasonable,
if,
if
we
suspect,
there's
there's
virtually
nobody
and
but
we
know
from
experience
that
somebody
will
always
pop
up
when
we
think
it's?
Nobody
is
an
opt-out,
sufficient
to
say
hey
like
we
didn't
realize
we
were
gonna,
break
anybody
or
like
we
didn't
expect
to
break
anybody
in
practice.
Here's
how
you
can
get
back
the
behavior
you
want,
or
is
that
are
we
trying
to
adhere
to
the
you
know,
adhere
to
the
the
idea
that,
like
what
works
in
a
major
should
always
work.
A
I
see
owen
since
right
so
I'll.
Let
you
speak
before
I
respond.
G
G
We're
assuming
that
you
know,
there's
no
need
to
not
ignore
your
node
modules,
so
we're
going
to
ignore
your
known
modules.
But
if
you
don't
want
us
to
do
that,
then
you
know
pass
this
flag
instead,
so
you
could
use
maybe
the
state
of
the
repo
as
a
way
to
present
the
message.
You
could
always
present
a
message,
but
you
could
you
know
toggle
the
behavior
based
on
certain
artifacts.
As
present,
you
know
whether
it's
breaking
is
quote
unquote.
Breaking
you
know
is
a
fuzzy
decision
to
make.
G
F
To
that
I,
I
would
definitely
say,
don't
base
it
on
package
lock,
like
I
know,
a
number
of
package
maintainers
intentionally
turn
off
package
lock,
because
it
can
be
problematic
for
building
modules
but
not
like
for
applications.
It
absolutely
makes
sense.
It's
not
really
useful
for
modules
in
the
way
that,
like
a
yarn,
lock
necessarily
is
because
of
other
like
because
it
doesn't
get
sent
to
the
registry
basically
and
also
yeah.
I
I
love
multiple
reasons
but
yeah.
F
I
would
definitely
say
that
it
should
probably
be
like
kind
of
all
or
nothing
with
an
opt-in
flat
or
opt-out
flag
or
an
opt-in
flag.
I
I
would
personally
prefer
like
the
thing
I
try
to
avoid
is
like.
F
Oh,
I
I've
been
writing
javascript
for
three
years
and
I
didn't
know
this
was
a
thing
and
I
could
have
had
this
the
whole
time.
That's
like
a
painful
dx
to
me
rather
than
a
positive
one
whereas
like
if
someone
is
like.
Oh,
I
really
wish
node
modules
were
showing
up
in
spotlight
search
for
whatever
reason
I
I
know
I've
screamed
the
opposite
before,
but
you
know,
if
someone
wants
that
they
can
go
say
they
can
go
search.
How
do
I
get
node
modules
in
spotlight
and
then
they
have
an
answer?
F
Where's
the
other
you're
not
going
to
search
for
because
you're,
just
not
gonna,
think
about
it
and
same
for
you
know
same
for
for
time
machine
as
well
right
like
you're,
you
can
realize
that
your
node
modules
weren't
there
but
you're
not
gonna,
think,
oh,
how
do
I
get
rid
of
all
my
node
modules
from
npm?
Like
that's,
not
gonna,
be
a
thing.
Someone
thinks
about
it.
F
A
Okay,
so
next
steps
with
this
is
we
can
backlog
this
issue
and,
like
work
item
just
based
on
everything
else,
that
we've
got
ahead
of
us.
I'm
I'm
wondering
if
it
won't.
Even
it
might
almost
make
sense
that
this
could
would
be
landing
like
around
the
time.
Let's
say
of
even
mpm9
like
it
potentially
could
line
up
with
a
major
release
for
us,
depending
on
when
we
can
actually
get
to
something
like
this,
which
isn't
like
super
high
priority.
D
Yeah,
the
most
conservative
approach
would
be
that
we,
we
add
it
as
opt-in
today
in
a
minor,
and
then
it
becomes
opt-out
in
the
next
major
again.
This
is
this
is
all
assuming
that
I,
if
we,
if
we
can
set
that
x,
attribute
that
extended
attribute
from
within
node,
then
this
is
really
easy
to
implement.
If
we
have
to
rely
on
the
x,
adder,
binary
and
or
ship,
you
know
a
binary
node
add-on
only
for
darwin,
that's
possible
it
just.
D
It
gets
into
some
like
code
signing
issues
and
like
shipping
compiled
code
that
can
sometimes
set
off
some
some
security
alerts.
So
there's
there's
a
little
bit
of
implementation
hassle
here
and
it
might
even
be
worth
adding.
You
know
sending
a
pr
to
node
and
saying
okay.
Well,
when
node
gives
us
this
field,
then
we'll
start
using
it.
A
A
If
not
I'll,
give
you
12
minutes
back
of
your
days
and
appreciate
everybody.
Jumping
on
today,
hopefully
see
you
next
week
and
talk
to
you
async
and
rc
issues
and
pull
requests
themselves,
cheers.