►
From YouTube: Open RFC Meeting - Wednesday, February 9th 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
I
just
copy
and
paste
for
folks
that
just
joined
the
meeting
notes,
talk,
feel
free
to
add
yourselves
as
attendees
we'll
be
following
along
in
the
agenda
that
was
created
in
the
rc's
issue,
526,
which
I'll
also
copy
and
paste
for
folks
and
just
quickly
a
quick
reminder.
This
call
and
all
comms
on
the
rfc's
repo
are
covered
on
their
code
of
contacts,
which
we
ask
people
to
please
abide
by.
A
Please
be
kind
to
others
on
these
calls
and
raise
your
hand
if
someone
else
is
speaking,
we'll
call
on
you
and
and
hopefully
have
a
good
discussion
quickly
want
to
give
some
time
for
any
announcements
folks
might
have.
A
The
one
that
we've
been
shouting
out
in
the
last
couple
weeks
that
I
know
of
is
the
openjs
world
conference
has
their
cfp
open
and
it
will
be
closing
next
week.
I
believe
it's
next
friday.
So
please
get
your
talks
in
our
team,
hopefully
we'll
be
joining
others
at
that
conference
and
joining
in
also
in
the
collaborator
summit,
so
we'd
love
to
see
y'all
there
and
hopefully
folks
feel
like
they've
got.
A
B
Sure
yeah,
this
is
basically
for
rfc
to
make
sure
anyone
working
on
workspaces.
Most
users
would
expect.
When
you
navigate
to
a
nested
folder,
then,
when
whatever
command
you
run
there,
it
will
just
behave
as
just
a
connected
workspace
to
your
root
project
so
yeah.
This
is
basically
the
proposal
to
make
npm
kind
of
aware
of
that
and
auto
switch
the
context,
depending
on
whether
you're
navigating
a
workspace
currently
or
not
and
yeah.
So,
basically
we're
already
working
on
it
and
we're
ready
to
ratify
this
like
prove
this
rfc.
B
Unless
someone
screams
a
last
minute
objection
to
to
it,
but
I
guess
we
kind
of
already
worked
out
through
the
comments.
Jordan.
C
A
B
C
C
So
it
seems
like
it
needs
a
fresh
review,
since
it's
changed
a
lot
since
then.
C
The
the
hope,
I
think,
was
that,
because
there's
there's
different
models
of
workspaces
right,
some
of
them
are
one
model-
is
that
child
packages
only
only
should
be
used
in
the
context
of
the
larger
monorepo.
C
Is
it
you
know,
and
everything
is
part
of
the
workspace,
but
that
can
be
explicitly
changed
so
that
into
you
know
so
that
my
use
case
can
can
go
with
it
and
then
npm
would
respect
that.
After
that,
the
exact
details
of
the
implementation
are
not
as
important
but
the
the
ability
to
commit
and
to
get
something
that
tells
npm
that
I
want
that.
A
I
I
can't
speak
to
the
exact
implementation
that
nope
has
been
working
on
so
roy.
You
might
not
know
this
because
I
believe
you
did
review
it
so,
but
yeah.
I
would
expect
that
we
would
still
be
able
to
potentially
opt
you
out
like
that's.
If
we
don't
have
that
mechanism,
then
jordan
you're
right
that
there
needs
to
be
something
like
that
to
explicitly
opt
out,
and
I
actually
do
think
it
exists.
It's
just.
The
workspace
is
flagging,
equal,
false
and
so.
C
C
D
A
A
You
need
to
auto,
detect
this
like
there's
so
many
people
that
are
actually,
on
the
other
end
of
the
spectrum
that
aren't
right,
like
like
power
users,
let's
say
of
workspaces
that
are
falling
into
the
trap
of
cding
into
a
project
and
then
and
creating
you
know
numerous
lockers
yeah.
C
C
C
A
B
A
Cool
happy
nowhere
on
the
same
same
page
there,
so
this
this
is
one
that
I
think
we
put
on
the
agenda
because
we'd
like
to
ratify
it,
but
it's
great
that
we
play
on
here
just
to
like
ensure
everybody's
on
the
same
page.
Any
any
other
comments
or
questions
about
about
this.
For
from
folks.
B
I
believe
one
thing
we
just
we
just
mentioned
that
I
might
review
and
add
last
minute
here
before
accepting,
but
also
it
could
be
nice
to
add
a
a
note
on
how
users
can
use
an
npmrc
with
workspaces
false
to
opt
out
like
we
just
mentioned
the
example
here
right.
I
think
you
know
using
no
workspaces
or
setting
workspace
to
false
is
already
in
there
as
a
way
to
opt
out,
but
I
think
it's
also
nice
to
have
the
example
of
having
it
as
part
of
the
university
of
a
workspace.
A
Awesome,
I
think,
that's
a
great
last
step
before
we
ratify
it,
where
I
thank
you
for
doing
that,
and
thank
you
for
championing
this
all
along
the
way
I
continued
to
eat
eat
my
own
words
a
year
ago.
So
thanks
thanks
for
pushing
this
through
cool
moving
on
to
the
next
rfc,
which
I
think
we
also
want
to
maybe
quickly
not
quickly
but
we'd
like
to
to
make
some
work
happen
on
this,
which
is
rc
516.
A
This
is
essentially
improving
the
deprecated
packages
user
experience
and
we
think
this
is
a
great
incremental
step.
I've
just
copied
pasted
the
rc
here
roy,
I
think,
has
just
this
morning
cleaned
up
the
rc
a
little
bit
added
a
few
more
examples
and
we've
we've
gone
further
down
the
road
of
outlining
what
the
sub
command
deprecations
looks
like.
So
maybe
you
can
speak
to
that
right.
B
B
Really
sorry
about
it,
but
I
was
going
to
say
that
the
main
changes
here
is
that
we
got
rid
of
the
the
augmenting.
The
other
related
commands.
Like
alas,
explained
it
was
there
originally
we
decided
to
scope
narrow
the
scope
to
just
removing
the
warning
message
during
npm
install
and
getting
that
notification
at
the
end
there,
and
now,
as
darcy
alluded
to
we
kind
of
expanded
a
little
bit
more
on
the
top
level
command,
so
the
npm
deprecations.
B
We
also
give
it
some
some
more
examples
here
and
thanks
to
jordan
kind
of
copying
a
little
bit
of
his
rationale
from
his
module,
the
applications
module.
So
you
can
also
npm
the
applications,
a
single
package
to
retrieve
basically
the
application
input
for
for
a
given
package.
B
So
you
can
have
that
in
either
json
output
or
or
human
printable,
which
will
be
the
default
in
the
npm
client,
so
yeah.
I
think
we
landed
in
a
very
good
place
here
with
this
rfc
now,
and
I
think
it
should
be
ready
to
be
approved.
C
Looks
awesome
to
me:
I
just
approved
it
with
some
like
a
tldr
of
my
understanding
of
the
current
state.
If
all
of
that
understanding
is
correct,
more
or
less,
then
I'm
super
on
board.
E
Does
does
this
provide
any
path
on
how
to
address
it
like
how
to
address
deprecations,
or
is
it
just
assumed
that
that's
what
people
will
put
in
the
deprecation
message.
C
It
actually
doesn't
take
multiple
packages.
I
was
just
there's
an
example
in
that
rfc
that
implied
that
it
took
multiples,
which
was
unless
no,
I.
A
C
A
A
I
mean
accepting
a
package
for
deprecation,
so
like
npm,
deprecations
and
then
package
would
work
similar
to
like
mpmls
package
spec.
Whereas,
like
I
think
your
your
personal
npm
deprecations
package,
you
can
run
deprecations
foo
bar
yeah.
C
B
B
C
D
B
B
A
That
might
be
I'm
I'm
a
bit
concerned
about
folks
being
confused
about
what
they're
seeing
there,
because,
if
we're
yeah,
I
just
might
be
confused
because
the
we're
changing
what
information
we're
bubbling
up.
Really,
because
it's
with
no
arguments,
no
positional
we're
showcasing
things
that
are
local
deprecated
packages.
A
C
C
D
B
C
If
I
want
to
see
deprecations
in
my
current
project,
but
only
the
deprecations
of
run
time
depths,
because
who
gives
a
crap
if
dev
depths
are
deprecated
or
if
I
only
want
to
see
the
deprecations
of
dev
depths,
because
I
only
want
to
fix
the
easy
stuff
that
won't
risk
breaking
production
right
now,.
C
B
C
B
B
So
yeah
I'll
try
to
document
this.
All
these
details
a
little
bit
better
here,
but
I
think
what
we
really
want
to
land
on
that
is,
like
the
rc
say,
it
has
to
be
similar
to
ls
kind
of
inspecting
the
current
tree
most
all
of
the
time.
But
then
maybe
if
we
are
using
anything
if
we're
at
a
tag
or
a
specific
version,
look
up
the
registry,
so
at
least
people
have
the
option
of
just
looking
up
the
register
directly.
I.
C
B
That
sounds
good
yeah.
Oh
I'm
going
to
look
into
that
and
I'm
gonna
expand
a
little
bit
more
on
these
details
before
landing,
but
otherwise
we
might
even
just
land
it
during
the
week.
Okay
sounds
good.
Thank
you.
A
Maurice
and
then
just
so
I
clarified
jordan
npm
show
is
npm
view
right.
That's
what
you
mean
by
that
they're
just
aliens
yeah.
C
A
Yes,
nobody
knows
about
that
v9.
That
will
be
changed.
I
promise
awesome
any
other
feedback
on
the
deprecations
rc
cool,
so
we'll
clean
that
up
add
some
more
docs
roy
and
then
ideally
we'll
we'll,
ratify
and
then
we'll,
hopefully
get
to
work
or
backlog
it.
The
next
item
we
had
was
issue
523.
This
is
the
just
recently
created
by
jordan.
Mpm
explained
should
work
even
with
an
absent
log
file.
Did
you
want
to
speak.
C
Yeah,
someone
filed
an
issue.
Their
issue
was
in
a
brand
new
project.
Npm
install
failed
for
them,
so
they
didn't
have
any
lock
file
or
node
modules
or
hidden
lock.
File
and
npm
explain
thus
doesn't
work,
but
given
that
you
don't
need
any
of
those
things
for
arborists
to
be
able
to
build
a
fictional
tree,
you
know
just
like
npm
audit,
there's
zero
reason
why
it
shouldn't
work
in
a
completely
brand
new
project.
C
That's
never
been
installed
before,
like
arborist
has
what
is
it
actual
ideal
and
virtual
and
ideal
works
without
anything
already
present
on
the
disk?
So
why
can't
we
just
use
it,
and
in
this
case
it
would
have
helped
this
user
figure
out,
which
top
level
dependency
is
responsible
for
the
transit
dependency,
that's
failing
their
overarching,
install
and
completely
blocking
them
from
doing
anything.
B
Yeah,
I
do
like
the
idea,
but
it's
it
will
definitely
be
something
novel,
different
usage
of
arborists
for
sure
right
now,
it's
always
just
inspecting
at
the
current
which
we
have
right,
I
mean.
B
C
Package
aud
right
and
like
it's,
if
you
currently
are
supporting
two
of
them
right,
because,
presumably
I
guess
I
don't
know
how
npm
explain
works.
Maybe
it's
all
load
node
modules
but
like
in
in
either
way
you're
you're
using
arborists
to
build
a
tree
and
then
once
arborist
gives
you
a
tree.
You
don't
really
care
where
it
came
from
so
like
all
you
need
is
just
to
get
the
tree
and
you
can
build
that
just
from
package.json.
C
D
C
B
B
True
right,
what
ideal
tree
might
return?
You
does
not
reflect
what
might
actually
end
up
there
and
because
today
we
use
always
the
result
of
loading
the
actual
tree.
So
the
things
there
are
actually
in
the
file
system
right
in
your
modules
and.
B
Almost
because
it
still
lacks,
if
I
recall
correctly,
still
miss
bundle
dependencies
and
shrink
wrap
at
that
point
that
only
gets
placed
there
refly.
So
it
might
differ.
B
Right
so
that's
kind
of
the
risks
we
have
to
wait
like
some
ecosystem
will
rely
heavily
on
them
right,
that's
some
sure.
Other
different
ecosystem,
like
you
might
come
up,
come
on.
Nobody
uses
it
right.
So
I
think
it's
two
very
valid
points
of
views,
and
so
we
just
need
to
be
very
careful
to
not
harm.
You
know
what
different
ecosystems.
C
A
simple
thing
would
be:
if
bundled
dependencies
are
spread
is
present,
then
you
can
error
out
and
say,
because
you're
using
bundle
dependencies,
you
have
to
have
something
installed.
First,
like
that's,
probably
not
as
good
as
npm
can
do,
but
that
would
be
an
easy
way
to
handle
that
concern
for
the
many
nines
of
use
cases
that
don't
have
bundle
dependencies.
C
Well
and
separately,
I
would
say
that
the
ideal
tree
should
probably
be
including
the
stuff
like
in
arborist
should
probably
be
including
the
bundle
dependencies
anyway
like
it
should
be.
Taking
that
or
you
know,
there
should
be
a
way
to
to
get
the
ideal
tree,
combine
it
with
final
dependencies
and
get
what
npm
install
is
about
to
do,
and
if
that's
not
currently
an
arborist,
then
that
seems
like
a
gap
in
arborist.
B
No,
it
might
be
already
there.
Actually,
I
might
be
also
confused
so
yeah.
It's
just
that
this.
The
reason
why
it's
not
there
today
for
npm
explain
is
that
it's
just
looks
at
the
actual
tree
that
that
is
re-found.
So
that's
the
reason
why
so
building
the
ideal
tree
and
looking
at
that
is
a
possibility
for
sure
awesome,
but
yeah.
We
just
need
to
be
aware
of
okay.
It
might
have
these
pitfalls
and
like
how
we
navigate.
A
I
mean,
I
don't
think
we're
against
this
right,
like
we're.
Definitely
for
this,
I
think
it's
just
requires
some
work.
Yeah.
A
C
So
yeah
well
and
I
haven't
tried:
npm,
explain
with
just
a
lock
file
and
no
node
modules,
but
should
work
that
theoretically
should
work
too,
and
if
that
does,
work
then
like,
as
I
would
expect
it
to.
If
I
can
do
npm
install
pat
like
package
lock
or
what
is
it
package
lock
only
if
I
can
do
that
and
make
a
command
work,
then
npm
knows
how
to
do
that
without
me,
typing
that
so
like
the
command
should
support
it
anyway.
C
C
C
Not
for
npm
explain
because
this
wasn't
my
use
case
like
initially,
if
it
doesn't
work
for
the
lock
file
and
it
could
then
that's
you
know,
that's
another
bonus
for
explain.
Yeah.
B
B
C
And
I
would
also
be
very
content
with
if
I
run
npm,
explain
or
npm
audit
or
whatever
else,
and
it
says.
Oh
sorry,
you
need
a
lock
file
or
no
modules
present
or
you
can
pass
dash
dash
fake,
lock
file
and,
like
that's
fine
with
me
too
and
like
you,
can
explain
the
caveats
you
can
say
warning:
this
may
not
account
for
optional
dependencies,
bundled
like
I
don't
care
about
either
of
those
things
in
any
of
my
projects.
So
like
that
sounds
great
with
me.
C
A
Yeah,
I
think
also
the
warning
or
erroring
is
important
here.
It's
like
we're
not
even
giving
enough
information
for
the
end
user
today
to
explain
why
they
can't
run
that
command.
I
think
so
yeah,
so
it
took
some
good
notes
there
appreciate
if
we
can
follow
up
or
keep
this
on
our
radar
for
now.
A
Moving
on
to
rfc
438,
I
believe
this
was
added
by
myself
and
roy
this
morning,
actually
sort
of
to
tie
it
together.
Also
with
the
package
distributions
rfc
that
we've
put
together,
which
is
pr
519
and
so
the
first.
A
Let's,
let's
quickly
go
through,
I
guess
the
the
first
issue
here,
the
lipsy
fields
to
help
select
optional
dependencies
I'll
quickly
reference
it
for
folks,
there's
quite
a
bit
of
discussion
on
this,
and
I
know
roy
actually
linked
this
thread
over
to
package
distributions,
but
it
sort
of
goes
ties
back
to.
I
think
something
you
were
saying
during
last
week
with
improving
the
optional
dependency
story
before
even
introducing
distributions,
so
I
haven't
had
enough
time
to
really
like
look
through
this
thread.
A
To
be
quite
honest,
I
haven't
had
a
lot
of
time
to
follow
up
on
on
the
package
distributions
feedback.
Yet
quite
yet
either
notably
I'm
I'm
taking
a
bit
of
sto
this
week,
but
yeah
just
want
to
bring
these
up
and
try
and
I
see
your
hands
up
so
feel
feel
free
to
yeah.
C
So
because
I
don't
do
a
lot
of
work
with
native
native
packages
right,
I
did
not
realize
that
a
top
level,
os
cpu
and
maybe
others
fields
mattered
in
package.json.
That
seems
sort
of
gross
to
me
that
they
have
to
be
top
level
like
it
seems
like
it
might
make
sense
to
add
a
top
level
field.
C
That
says
something
like
that.
That
relates
to
the
things
that
optional
dependencies
or
package
distributions
or
ever
look
at
and
have
that
thing
contain
all
the
conditions
and
then
whatever
is
in
that,
whatever
is
eligible
to
be
in
that
list.
That's
the
things
that
engines
checks
or
that
you
know
I
don't
know.
I
don't
know
if
that
makes
sense
for
engines,
but
like
I'd,
have
to
think
this
through
more
but
then,
rather
than
adding
lib
c
to
the
top
level
of
package
json,
we
could
add.
C
Add
it
to
this.
Like
nested
config
object
that
npm
owns
that
that
you
know
schematically
matches
whatever
npm
will
check
for
and
obviously
you
can't
remove
the
top
support
for
the
top
level
fields
that
are
already
there,
but
they
could
be
like
soft
deprecated
and
supported
in
the
new
format.
You
know,
and
things
will
eventually
move
to
that
and
that
that
seems
like
a
cleaner
way
to
like,
because
there
will
be
new
things
in
the
future
right
like
libsy.
C
A
B
B
I
wanted
to
highlight
this
issue,
but
I
wanted
to
propose
yeah
follow-up
rfcpr,
which
expands
the
scope
a
little
bit
right,
because
I
see
you
mentioned
in
the
deadpool
request
already
like
it
would
be
nice
to
filter
by
different
types
of
things
right
like
a
browser
or
or
have
a
distribution
that
has
tests
or
not.
I
know
that
in
the
ecosystem,
people
want
these
different
kinds
of
use
cases,
and
maybe
it's
a
good
way
to
tie
them
all
together.
B
So
I
think
evolving
the
conversation
instead
of
just
having
adding
yet
another
top
level
key
like
libby's
lipsey
right,
like
do
kind
of
a
clean
up
and
bring
together
everything
that
might
be
related
to
an
optional
dependency
filtering
them
out
right.
It
might
be
a
very
good
way
to
steer
the
conversation
here
and
propose
something
that
will
be
just
like
the
foundation
for
building
the
package
distributions
on
top
of
it.
So
try
to
clean
up
yeah.
B
I
think
that's
a
great
idea,
so
maybe
we
can
propose
like
a
optional
dependencies,
meta
or
maybe
a
shorter
key
just,
but
I
do
think
that's
a
good
idea
and
then
we
can
kind
of
deprecate
the
current
ones,
but
like
probably
soft
duplication
that
that's
probably
going
to
take
a
long
while
for
the
ecosystem
too
yeah.
So
yes,
so
I
kind
of
like
surfaced
that
to
darcy
that
we
probably
want
to
have
this
conversation
kind
of
alongside
of
the
package
distributions
and
yeah.
A
Yeah,
it
does
seem
like
I,
I'm
gonna-
have
to
do
a
bit
of
reading
some
some
of
my
time
off
this
week
just
to
follow
up
on
some
of
these
conversation.
It's
async.
A
A
There
is
going
to
cover
enough
of
the
use
cases
that
make
sense,
but
then
also
not
ideally
open
up
pandora's
box
to
allow
for,
like
infinite
conditionals
yeah,
I'm
probably
going
to
sit
on
this
for
for
another
week,
hopefully
to
to
get
some
some
more
context
myself
and
then
I
know
that
folks
from
for
sale
have
jumped
in
on
the
specifically
the
distributions
rfc
and
I've.
Given
some
feedback
as
well-
and
I
know
they'd
be
very
happy
if
we
we
were
able
to
support
their
use
case
so
yeah.
A
Do
think
there
needs
to
be
a
separate,
probably
rc,
for
for
as
alluding
to
some
sort
of
like
optional
dependencies
rc
to
improve
those.
So
I
I
would
be
mindful
of
nesting
this
information,
though
I
would
love
to
find
ways
where
we're
not
creating
too
many
new
like
paradigms,
and
I
know
that
the
existing
ecosystem
does
rely
on
some
of
these
top-level
fields,
for
other
other,
you
know
needs
so
if
we
can
get
away
with
potentially
reusing
the
existing
top
level
like
information.
A
D
Yeah,
if,
if
we're,
if
we're
going
the
road
of
patching
this
up,
one
of
the
things
that
we
really
want
to
do
is
a
basic
on
off
switch.
Can
I
even
build
native
modules
on
this
platform?
D
Maybe
it's
cleaner
now
than
it
was
three
years
ago,
but
we
can't
assume
that
everybody
even
has
a
working
c,
compiler
or
c
plus,
plus
or
whatever,
on
their
machines
these
days
and
actually
sounds
to
me
like
we're,
starting
to
describe
the
sort
of
like
a
parallel
host
environment.
So
we
look,
you
know,
as
node.js
is
a
host
environment
for
v8,
we're
kind
of
talking
about
like
a
host
environment
for
npm,
ish
stuff
that
isn't
node,
and
if
we
wound
up
making
that
list
and
branching
it.
D
Maybe
we
just
turn
around
and
and
that's
where
that
info
goes,
you
know,
do
you
have
the
availability
of
a
compiler?
Do
you
have
an
amd
chip?
Do
you
have
64-bit
stuff
and
then
we'd
be
able
to
patch
a
bunch
of
that
stuff
away?
You
know
for
what
I'm
doing.
We
actually
have
a
really
big
headache
to
try
and
solve
these
days,
which
is
how
do
we
ship
our
native
component
with
our
npm
stuff?
D
Right
now
we
go
npmi
package
and
then
we
go
oh
and
copy
this
binary
and
it
is
horribly
ugly.
It
would
be
really
really
nice
to
have
tooling.
That
would
help
us
do
that.
One
of
the
problems
that
we
have
is
that
we
can't
we
can't
do
global
installs
with
native
packages
because
running
even
running
a
from
inside
npm
with
dash
dash
global
presents
a
barrier
that
developers
can
get
around
easily,
but
most
end
users
can't
and
that's
the
permissions
issue
where
it
tries
to
it,
gives
up
permissions.
D
D
So
that's:
okay,
that's
out
of
scope,
but
if
I
start
to
look
at
that
stuff,
it'd
be
really
helpful
to
put
some
thought
space
in
there,
and
maybe
I
should
do
some
thinking
offline
too.
A
We
are
definitely
looking
at
that
just
so
you
know
we
were
poked
by
the
build
working
group.
The
node.js
build
working
group
which
I
think
is
looking
at
potentially,
and
this
is
long,
probably
very
long
term,
but
deprecating
no
chip
itself
or
finding
a
way
yeah
sure.
But
then.
A
You
know
it
often
here
in
the
distance
but
yeah
you're
right,
like
we
are
interested
in
how
we
move
forward
like
in
in
general,
how
we
support
these
communities
in
this
tooling,
like
in
more
general
sense
and
we're
talking
with
like
the
node
project,
on
how
like
potentially,
we
like
the
debundle,
nodejib
potentially
and
then
maybe
it's
something
that
in
the
interim
comes
as
a
depth
of
node
and
then
we
can
get
it
out
of
npm,
and
then
we
can
start
to
like
clean
up
the
interface
that
we
or
other
package
managers
or
tools,
like
essentially
interface
with.
A
D
But
yeah
a
binary
can
it
compile
if
you're
doing
optional
depths
might
not
be
a
bad
one
to
think
about.
B
Yeah,
I
was
just
going
to
mention
the
example
of
a
yes
build
folks.
I
think
it's
mentioned
in
the
rfc
there,
but
they
do
this
similar
sort
of
setup
using
optional
dependencies.
Today
there
is
a
little
bit
more
hacking
involved,
but
I
don't
think
it's
that
much,
but
it's
basically
checking
for
the
os
and
the
architecture
at
the
moment
of
your
npms
though,
and
can
can
basically
filter
and
only
like
you
only
get
installed
the
optional
dependency
that
matches
your
currently
current
os
and
architecture.
A
Yeah,
basically,
you
can
imagine
anything
that
node,
like
a
node
processor,
would
have
access
to
in
terms
of
like
environment
variables
or
like
process
information,
the
architecture
platform,
information
os,
like
any
of
that,
is
sort
of
the
scope.
I
would
say
of
this
initial
package
distributions
conditionals,
because
we
would
just
use
that
information
to
then
apply
against
the
the
dependencies
and
and
then
that
you
could
use
those
to
essentially
distribute
different
versions
of
your
package
like
that.
A
Have
pre-built
like
binaries
for
that
that
specific
environment,
what
I
would
say
is
sort
of
what
we
have
to
figure
out.
How
we're
going
to
do
is
kind
of
like
jordan's
use
case
for
for
other
types
of
information
or
other
types
of
conditionals
that
are
outside
of
maybe
that
information
we
would
get
from
the
process
yeah
like
browser
information,
potentially.
Does
that
mean
we'll
read
package.json
and
then
just
like
parse,
that
at
the
project
level
or
the
consumer
level
and
yeah
make
that
available?
A
Somehow
I
don't
know,
that's
that's
up
for
debate
how
we
try
to
like
you
know
design
around
that
so
or
we
try
to
make
it
easier
right,
like
detecting.
A
In
this
case,
like
detecting
whether
or
not
you
know
you
have
this
c-lip
like
right
cool,
I
want
to
quickly
be
mindful
of
time
we
have
12
minutes
left.
I
quickly
moved
to
the
next
item,
which
is
removing
shrink,
wrap
files
from
the
unignorable
list.
I
know
we
had
a
bit
of
preamble
before
the
I
started
recording
here
on
this
item,
but
it's
number
511
I'll
share
the
link
to
for
folks,
jordan.
This
is
yours
not
sure
what
we
noted
just
before
we
started
recording.
C
C
C
However,
outside
of
that
scenario,
I
don't
think
it
would
break
anyone,
and
so
my
hope
is
that
when
someone
isn't
using
a
files
field
that
shrink
wrap,
it
can
be
ignorable
as
a
semver
patch,
even
maybe
a
minor
but
like
not
a
major
and
that
when
they
are
using
a
files
field
that
does
list
the
shrink,
wrap
file,
nothing
changes
for
them
and
when
they're,
using
a
files
field
and
no
shrink
wrap
file
is
present,
then
nothing
changes
for
them.
C
But
if
they're
using
a
files
field,
there's
a
shrink,
wrap
file
present
and
they
haven't
listed
it.
Then
it
would
still
include
it
for
now,
but
give
them
a
warning
and
say
this
will
be
changed
in
you
know
a
future
version
of
npm
and
then
december
major
part
would
be
changing
that
and
that,
if
we
were
cool
with
that,
then
that
would
allow
my
use
case
to
be
met
immediately
and
eventually
would
do
the
more
consistent
thing
of
just
having
it.
A
B
C
I
I
made
a
shrink
wrap
file
because
I
was
testing
a
package
that
reads
it,
but
I
don't
use
lock
files
in
any
of
my
packages
and
I
have
all
the
three
common
lock
file
format,
file
names
listed
in
git,
ignore
and
npm
ignore
in
every
single
project.
As
a
result,
I
never
want
an
npm
shrink,
wrap
file
included
with
a
package,
and
even
if
I
was
using
package
lock
like
I,
you
know,
I
want
the.
C
I
wouldn't
want
to
ship
a
lock
file,
because
when
you
ship
a
lock
file
with
a
package,
you
prevent
the
consumer
from
being
able
to
dedupe,
and
you,
like
you
know,
I
that's
something
that
there's
very
few
use
cases
in
my
eyes,
where
that's
not
a
user
hostile
thing
and
I
actually
broke
because
the
package
I
was
the
shrink
file
I
was
generating,
was
not
the
correct
one
for
the
package
it
was.
I
was
tap
playing
with
things.
It
broke.
C
My
consumers,
when
I
published
of
many
of
those
consumers,
were
me,
but
nonetheless
it
broke
my
consumers
because
that
wasn't
expected
to
be
included,
and
so
my
hope
is
that
by
listing
it
in
get
ignore,
slash
npm,
ignore
that
it
like
every
other
file
except
readme
and
package
json,
and
I
think
that's
it.
There's
a
show.
I
mean
there's
sure,
there's
a
few
others,
but
it's
a
very
short
list
like
I
would
expect
it
to
be
ignored,
and
so
the
rfc
the
rfc
is
to
ask
that
it'd
be
ignorable.
B
Yeah:
okay,
okay,
thank
you
for
explaining.
So
the
way
I
see
it,
it's
the
npm
shrink,
wrap
it's
a
very
explicit
contract
like
and
people
using.
It
really
want
it
to
behave
that
way,
right
and
and
just
a
little
bit.
It's
just
that
to
me.
It
sounds
like
a
really
big
change
to
just
drop.
Just
just
do
not
consider
npm
shrink
wrap
like,
like
you
know,
like
the
package
json
and
the
readme,
that
you
cannot
ignore
right
like
well.
C
File
any
pro
node
project
that
was
created
on
npm,
five
or
later
we'll
use
packagelock.json
by
default
right,
and
so
my
expectation
is
that
and
then
corporate
applications
it
doesn't
matter
because
they're
never
published,
so
these
people
aren't
affected
regardless
and
all
of
the
places.
I
know
that
have
a
file
named
npm-shrinkwrap
are
corporate
applications,
but
I'm
sure
there's
more,
it's
just
that's
the
ones
I've
encountered.
C
B
C
A
A
C
Think
that
if
we
did
a
josemnid
search
or
whatever
the
npm
registry
search,
I
would
be
very
shocked
if
we
found
fi
packages
that
included
a
shrink,
wrap
file
and
used
the
files
field
and
omitted
it
omitted
the
shrink,
wrap
file.
Name
from
it.
I,
like
I,
I'm
not
saying
that
I
let
me
rephrase,
I
wouldn't
be
shocked
if
there
were
non-zero
I'd,
be
shocked.
C
If
that
number
is
two
digits
like,
I
would
expect
less
than
10
packages
to
be
accidentally
benefiting
from
this,
and
if
any
of
those
package
has
been
published
in
the
last
five
years,
I
will
personally
go
fix
that
for
them
before
making
npm
makes
this
change.
If
that
would
be
sufficient,
but
I'm
I
am
that
confident
that
it's
just
not
a
thing
that
matters,
it's
a
conceptual
breaking
change,
which
is
why
I
can
I'm
not
arguing
that
we
try
to
make
it
outside
of
december
major
for
that
use
case.
C
D
Observation,
this
actually
comes
down
to
the
fact
that
we're
using
npm
ignore
and
get
ignore,
as
if
they
have
the
exact
same
precedence.
If
this
was
ignored
in
npm,
ignore
jordan's
use
case
be
immutable
because
be
able
to
ignore
it.
That's
true,
maybe
there's
a
way
that
we
could
look
at
it
and
say
hey
if
it's
ignored
in
np,
if
it's
ignored
and
get
ignored,
keep
the
current
behavior
if
they
ignored
an
npm,
ignore
actually
ignore
it,
and
that
would
be
the
only
change
that
it
would
be
at
that
point.
D
C
So
I
agree
with
your
real
logic
and
I
have
to
go
real,
quick.
That's
why
I'm
cutting
off
just
not
all
of
my
projects
have
an
npm
ignore
the
only
ones
that
have
an
npm
ignore
are
projects
that
have
some
form
of
a
build
process
and
many
of
my
projects
don't
so
like.
I
do
have
a
lot
of
projects
that
just
get
ignore
it,
and
then
I
expect
that
that
is
sufficient.
B
So
I
still
think
it's
a
lot
of
tweaking
and
implementation
to
make
it
happen,
because
currently,
information
crap
is
just
part
of
these
essential
files,
but
that
I
could
see
like
could
make
sense
right.
You
you're
explicitly
explicitly
putting
the
npm
tuning
grouper
app
in
your
npm,
ignore
you
probably
don't
want
it
there,
so
that
I
think
makes
sense
but
yeah
just
just
removing
it
completely.
I'm
still
kind
of
very
worried
that
that
could
be
a
big
problem.
C
Yeah,
so
I
mean
that
that's
fair
and
if
you
want
to
treat
it
all
as
sember
major,
so
be
it.
I'm
like
I
of
all
people,
I'm
not
arguing
that
that
it's
a
good
idea
to
like
violate
sound
bird,
even
if
it's
not
gonna,
actually
break
anyone,
but
I'm
still
convinced
it
won't
actually
break
anyone
and,
like
I
think,
if
we
did
a
search
of
the
public
registry,
I
suspect
that
there
are
some
potential,
conclusive
results
that
would
come
out
of
there.
C
A
Yeah,
we
can
definitely
circle
back
on
this
next
week.
I
know
we
only
have
a
couple
minutes
left
here
and
also
give
async
feedback
please.
If,
if
you
commented
here,
I've
tried
to
take
some
notes
as
well
with
the
one
minute
we
have
left.
A
I
just
wanted
to
note
that
there
were
four
other
rcs
that
we
didn't
get
to
today
for
42.60,
which
is
the
adding
a
refi
hook
which
we're
still
discussing,
and
I
think
it's
going
to
stay
open
for
a
while,
and
then
this
4
42-27.
A
I
think
we
just
have
forgotten
to
take
this
off
the
agenda.
This
is
essentially
something
that
has
already
been
closed
and
we're
not
going
to
change
the
defaults
of
save
prefix
so
took
that
off
for
now.
Let
me
know
if
folks
think
that
we
want
to
bring
that
back
up
next
week
and
then
the
last
two
we'll
keep
on
the
radar
for
next
week,
notably
they'll,
require
some
changes
from
our
team.
A
A
If
we
did
and
then
also
525,
which
is
an
outstanding
issue
that
we've
been
having
with
carrying
around
an
integrity
value
for
git
depths
which
we'd
like
to
consider
dropping
in
the
next
major,
so
those
are
just
the
outstanding
prs
and
rfcs
if
you're
interested
in
giving
some
async
feedback
we'll
try
to
get
to
the
next
week,
but
appreciate
everybody
jumping
on
today
and
hopefully
see
you
next
week,
cheers.
Thank
you.