►
From YouTube: Node.js Foundation Modules Team Meeting 2019-02-27
Description
A
We
are
now
live
on
YouTube
with
the
February
7
2019
meeting
of
the
node.js
modules
team.
There
currently
10
members
on
the
call
all
active
members
of
the
team,
so
we
do
have
quorum
for
making
decisions
today
kind
of
let's,
let's
jump
into
right
into
the
agenda.
So
the
first
thing
that
we
have
on
the
agenda
right
now
is
to
review
some
open,
pull
requests
and
just
to
be
really
clear,
because
we
have
a
lot
of
other
things
on
the
agenda
right
now.
A
I'm
not
looking
for
this
to
be
a
place
for
us
to
dig
into
contentious
pull
requests.
So
you
know,
if
there's
objections,
we're
not
really
going
to
go
too
far
into
discussing
the
pull
requests.
We
can
discuss
that
later
in
the
meeting
as
part
of
the
features
just
want
to
like
unblock
and
land
things.
If
there's
things
that
can
land,
there
may
even
be
a
few
that
we
need
to
review.
So,
let's
start
with
the
first
one
is
M,
alias
type
module.
This
is
a
pull
request
from
Jeff.
It
is
currently
signed
off
by
guy.
A
B
I
mean
I
I,
guess
it
is
kind
of
like
I
mean
I,
guess
technically
we
did
have.
Can
consensus
on
this
I
didn't
realize
it
was
part
of
the
original
one.
I
guess
I
didn't
read
it
closely
enough
I!
Just
don't
think
this
is
a
good
flag.
I
have
nothing
wrong
with
people
running
things
as
the
SM
that
aren't
with
the
MJS
extension
I.
Just
don't
think
this
as
a
flag
is
like
a
good
flag.
It's
just
too
generic
changes
that
it
makes
two
nodes:
runtime
behavior,
that's.
A
B
A
C
A
A
Talking
just
about
39,
which
is
scope
specifically
just
to
em
I
know
you
have
another
pull
request
that
has
more
stuff,
but
I
wanted
to
keep
it
to
the
additions
that
are
in
the
other
poll
requests,
because
it's
out
of
scope
of
this
one
fix
sure,
okay.
So
let's
move
on
to
the
next
one,
it
seems
we
have
consensus
in
the
meeting
that
this
can
land.
And
then
you
know,
people
who
want
a
different
approach
can
work
on
iterating
it
out-of-band
do.
A
So
the
next
one
that
we
have
on
here-
let's
just
go
to
the
agenda
here-
45-
wasn't
in
the
agenda
that
one
second
census
can
land.
Also,
this
number
45
anyone
else
can
help
with
notes
that
would
help
me
move
the
meeting
along
faster,
so
45
includes
determine
type
based
for
symlink,
based
on
targets,
error
on
mismatch
type
flags.
A
So
this
one
includes
a
new
flag.
M
that
has
been
covered
in
the
other.
One
module
type
is
now
determined
based
on
assembling
target
rather
than
a
source.
This
allows
assembling,
like
user
local,
been
few
food,
a
point
to
users
or
local
node
modules
pseudonyms.
Yes,
the
type
is
determined
by
it
in
dot
MJS,
the
existing
node
flags,
preserved,
symlink
and
preserved
similans
main
are
still
supported.
This
would
called
the
type
deterministic
to
be
based
on
source.
A
Instead
with
tests
addressing
feedback
from
brad
mech,
it's
now
an
errors
thrown
when
type
and
file
extension
mismatch
or
when
type
and
package
scope
mismatch.
For
example,
no
am
file,
dot,
CJ
or
node
type,
comma,
j
s
index
duchy
is
where
the
nearest
parent
package.json
kitchen
contains
type
module.
The
spec
has
been
updated
to
account
for
this,
an
addressing
feedback
from
dev
snack
within
the
code
base.
The
new
type
strings
are
now
either
module
common
j
s
to
match
the
values
accepted
by
type.
A
A
A
C
We
just
want
to
clarify
miles,
I
think
it's
great
to
land,
this
I
just
stamped
it
on
github,
but
it's
happened
in
the
past
that
PRS
have
landed
and
not
everyone
on
the
call
has
been
fully
aware
of
all
the
changes.
So
I
want
to
just
be
clear
that
the
original
post
of
the
PR
describes
the
changes
and
as
long
as
that
is
accurate,
then
it's
fine
with
me.
A
Okay,
cool
I
am
okay
with
this
landing
as
it
is,
although
the
one
thing
I
would
like
to
do,
Jeff
is
I
just
want
to
review
the
semantics
around
symbolic
links
and
just
play
with
the
developer
experience
of
it
a
bit
because
in
the
past,
symbolic
links
working
in
unexpected
ways
has
just
broken
things
really
terribly
so
I
just
want
to
roll
through
that
once
I'm
not
blocking
it,
but
I'd
appreciate
if
you
waited
a
day
or
two
before
landing
before,
like
just
so,
I
can
try
to
make
sure
there's
nothing.
That
seems
off.
D
A
A
A
A
A
A
A
We
made
it
clear
that
we
aren't
digging
deep
into
these
issues
other
than
making
sure
that
if
things
can
be
reached,
consensus
will
move
forward.
Let's
please
revisit
this
later
in
the
call.
When
we
have
explicit
time
for
extension
resolution,
we
can
bring
it
up
then
so
the
next
one
we
have
is
ESM
at
experimental.
Json
support.
I
know
that
we
don't
have
consensus
on
that
right
now
and
I.
A
Okay?
So,
let's
kick
back
to?
Let's
kick
back
to
that
one
later
and
we'll
come
back
to
it
at
another
point.
Next
one
we
have.
We
have
number
33,
which
is
an
external
contribution
from
Matias
vine,
which
is
avoid
reading
package.json.
What
extension
is
ambiguous
sure
knew
of
an
objection
on
here.
Does
that
objection
still
stand.
A
C
So
I
think
for
the
same
question
is
extension
lookup.
My
objection
remains,
which
is
that
I
think
every
extension
must
always
be
over
rideable
or
no
extension
should
be
there's
nothing
special
about
es,
m
and
j
s
files.
Any
parse
goal
should
be
possible
to
be
in
any
extension
if
any
of
them
are
changeable.
Okay,.
C
It's
I
think
so.
I
think
yes
to
both
questions,
I
think,
yes,
obviously
until
we
have
the
ability
to
override
this
is
fine,
but
I
also
think
that
it's
a
premature,
optimization
and
also
the
dot
CJ
s
extension
was
something
that
in
kind
of
did
it
I
didn't
feel
like
we
explicitly
talked
about
it
in
the
meeting.
It
just
was
in
a
PR
that
happened
to
get
consensus,
so
I'd
also
love
to
revisit
that
extension.
A
Okay,
no
problem,
so
let's
leave
this
one
for
right.
Now,
it's
not
really
blocking
anything.
It's
an
optimization,
we'll
revisit
it
later,
just
making
sure
that
we
don't
miss
any
of
the
PRS
that
maybe
didn't
make
it
on
the
agenda.
There's
number
44,
which
is
additional
tests
and
fixtures.
This
was
just
I
added
some
extra
tests.
Does
anyone
object
to
these
tests?
Learning.
D
A
A
Okay,
we
got
we
wanted
to
spend
15
minutes
on
those
things
we
spent
13.
Congratulations.
We
actually
did
it
and
sorry
if
I
came
off
as
terse
at
all
there
I
just
wanted
to.
This
is
mostly
about
unblocking
things.
Oh
I,
think
there's
sorry.
We
have
two
minutes
I'm
going
to
use
it
just
looking
at
the
pull
requests,
we
do
have
an
updated
one,
which
is
to
update
explicit
rules
around
the
lkg
our
fork.
This
actually
already
has
like
basically
consensus
and
approvals.
A
Does
anyone
object
to
us
landing
this
on
the
modules
repo
to
be
explicit?
It
just
makes
sure
that
the
rules
that
we
have
for
landing
extends
to
new
GF
/
Ekman
script
and
also
adds
doc
fixes
tests
and
fixing
conflicts
with
a
rebase,
as
things
do
not
require
needing
approval
in
order
to
land.
I
think
that
that
will
be
useful,
especially
as
we
start
documenting
new
features,
any
objections-
okay,
great
I'm,
going
to
just
go
ahead
and
merge
that
right
now
it
is
merged.
D
A
A
The
the
next
topic
we'll
get
okay
cool,
so
are
there
any
other
PRS
other
than
the
roadmap,
one
that
are
open
that
people
wanted
to
discuss
today,
you,
okay,
cool
move
on
the
first
thing
that
we
can
do
here
is
just
as
I
was
saying,
a
quick
review
of
where
were
you
were
at
after
the
last
two
meetings,
so
we
went
through
the
road
map
dock,
which
was
an
attempt
to
to
attempt
to
capture
all
the
things.
Let
me
actually
I
will
go
ahead
and
screen
share.
A
A
Although
the
package
exports
proposal,
depending
on
what
it
meant,
was
something
that
maybe
brought
back
in
if
package
dot
exports
is
being
used,
as
we
saw
in
the
pour
request
that
we
were
just
talking
about,
although
obviously
that's
contentious,
we
had
contentious
topics
that
we
went
to
get
into.
Specifically
the
biggest
one
was
going
around
common
J's
Interop.
It
seems
like
we.
A
We
reached
a
consensus,
mostly
around
the
place
where
we
didn't
want
to
use
out
of
order
execution
for
for
and
exports,
but
we
did
want
to
continue
to
try
to
figure
out
dynamic
modules
upstream,
although
I
do
believe
that
guy
recently
closed
that
upstream
proposal.
So
we
may
need
to
like
revisit
exactly
what
that
means,
but
we
can
do
that
out-of-band,
not
right
this
moment.
Jordan
was
there
something
you
wanted
to
bring
up
related
to
this?
Well.
C
A
Think
later,
yeah
I
think
it
was
that
particular
solution.
But
let's
dig
into
that
when
we
get
to
it
on
the
agenda.
The
default
behavior
was
the
bit
where
we
got
stuck
and
spent
most
of
the
time
of
the
last
two
meetings,
specifically
about
like
whether
or
not
we
could
ship
named
exports,
and
if
we
were
okay,
just
shipping
importing
from
default,
it
seemed
like
we
were
leading
in
the
direction
of
not
shipping
default
if
named,
is
still
a
possibility
or
potentially
shipping
default
export
behind
a
flag.
A
Since
that
meeting
I
had
gone
through
done
some
experiments
with
introducing
that
flag
I
have
feelings
around
the
developer
experience.
We
can
come
back
to
that
when
we
get
there
and
then
we
were
also
talking
about
shipping
without
command.
J
s,
interoperability
and
Kevin
Smith
has
presented
a
potential
alternative
proposal
for
a
world
where
that's
the
case,
and
we
can
visit
into
that
afterwards.
We
started
to
get
into
file
extension
resolution,
but
because
the
common
J's
Interop
was
so
contentious,
we
didn't
really
get
into
it
too
much.
A
So
I've
actually
put
that
ahead
of
Interop
in
this
meetings
agenda
we
also
did
not
get
into
loaders
or
requirements
to
upstream
or
remove
the
flag,
so
that's
kind
of
where
we
are
today
and
where
we
left
off
in
the
last
meeting.
The
plan
that
I
have
right
now
is
Jeff,
went
ahead
and
let's
find
great,
pull
requests
and
created
this
pull
request,
which
was
revising
the
roadmap
based
on
the
current
discussion
that
we've
had,
and
so
the
first
agenda
item
that
I
wanted
to
do
here
was
I.
A
A
Talk
into
this
proposal,
so
if,
unless
there's
any
objections,
I
think
it
would
maybe
make
sense
as
a
first
thing
for
us
to
do
before
we
dig
in
any
further
would
be
to
review
this
document
and
try
to
reach
consensus
that
we're
okay
with
these
phases,
or
at
least
identifying
which
parts
of
the
phases
we
don't
have
consensus
on,
because
that
may
help
us
make
decisions
about
what
we
want
to
do
for
the
April
deadline.
Does
anyone
have
a
problem
with
that
as
the
way
to
approach
things
right
now,
I'm.
F
A
little
bit
concerned
about
trying
to
reach
consensus
on
phase
two
entails
since
phase
two
is
what
we're
going
to
upstream
short-term
and
for
us
to
attempt
to
reach
consensus
on
that
seems
difficult
and
restricting,
and
that
just
concerns
me
a
little
bit
I
mean.
Is
there
a
way
to
kind
of
phrase
this
process
so
that
we're
not
kind
of
bound
to
that
I.
A
C
I,
like
the
way
it's
phrased
in
the
doc,
but
I
have
a
kind
of
gut
reaction
to
the
word
deadline
and
I
really
want
to
stress
that
I,
don't
think
we
should
think
of
it.
In
those
terms,
I
say
if
it
would
be
obviously
ideal
if
we
can
hit.
You
know
as
soon
as
possible.
It'd
be
great
to
have
ship
this
yet
all
yesterday,
but
like
deadline
driven
development
is
not
something
I
think
we
should
do
in
a
in
general
or
in
a
platform
like
node
in.
A
A
So,
with
all
of
that
said,
let's,
let's
dig
in
unless
anyone
does
anyone
else
have
anything
else
to
add
right
now:
okay,
so
phase
0
and
phase
1
are
primarily
unchanged.
It
does
not
change
anything
about
what
we've
done
is
just
documenting
the
work
that
we've
done
up
until
now.
Does
anyone
have
any
problems
with
the
text
for
phase
0
and
phase
1
just
taking
it?
The
word
that
this
is
based
on
text
that
already
existed
cool,
so
let's
just
jump
into
the
fun
stuff,
so
they
is
the
minimum
viable
product.
A
So
it's
required
to
upstream
phase
to
fleshes
out
the
implementation
with
enough
functionality
that
it
should
be
useful
to
average
users
as
a
minimum
viable
product
at
the
completion
of
phase
2.
The
old
experimental
modules
implementation
is
replaced
with
this
new
one.
Still
behind
the
experimental
tool
modules
flag
in
the
things
that
we
want
to
have
accomplished
are
defined
semantics
for
importing
a
package
entry
point,
for
example
import
underscore
from
lo
the
proposal
file,
specify
resolution
proposal
covered
modules,
and
so
as
it
is
right
now,
we
can
use
the
main
field
for
that.
A
A
The
next
is
defined
semantics
for
determining
when
to
load
sources
as
commonjs
or
es
module
for
both
the
top-level
main
node
X
Jes
and
dependency
loading.
This
similarly
points
to
the
file
specify
resolution
proposal,
which
covers
import
statements
for
ESM
files
and
common
J's
file
package
entry
points
in
package
keep
imports.
This
is
what
allows
us
to
have
mode
CGS
and
mode
modules.
A
A
The
third
bit
for
phase
2
is
defined
semantics
for
enabling
ESM
treatment
of
source
code
loaded
by
a
vowel,
stdin
and
extension
list
files.
This
is
the
proposal.
Entry
points
proposal
covers
non
file
formats,
as
well
as
adding
a
type
flag
for
controlling
for
controlling
file
based
input.
This
is
the
type
module
or
the
M
proposal
that
we've
talked
about
similar
to
the
other
things.
The
solution
to
this
problem
space
could
change
between
now
and
when
we
upstream,
but
we
definitely
need
this
solve
before
we
upstream.
Does
anyone
object
to
this?
A
A
Finally,
dual-mode
commonjs
DSM
packages
support
packages
that
can
be
both
required
as
common
and
imported
as
ESM
with
separate
entry
points
for
each
there
is
the
proposal,
that's
open
right
now,
which
is
the
exports
proposal,
although
to
the
point
that
I
believe
multiple
people
on
the
call
have
made
today,
if
we
did
do
extension
searching
there
are
alternative
solutions
to
this
problem.
Does
anyone
object
to
this
problem
space
needing
to
be
solved
before
we
upstream
independent
of
the
solution.
C
A
C
A
G
Yeah
one
thing
I
would
like
to
add
to
the
evolves
that
extension
s
files
is
to
explicitly
call
out
shebang,
yeah,
so
fineries
implication
marks
UNIX
binaries,
because
I
think
that
will
influence.
Does
that
answer
and
I
think
shipping,
something
without
it
would
lead
us
down
a
potentially
into
well
this
path
that
doesn't
have
a
good
ending.
A
G
D
G
A
D
F
Can
I
just
add
something
and
we
should
probably
bring
the
discussion
offline
Yann,
but
there
are.
There
is
support
for
shebang,
because
the
combination
of
symlinks
and
the
package
boundary
will
support
it.
Let's
bring
that
discussion
offline
but
yeah,
whether
it's
in
phase
2
or
3.
Do
we
necessarily
have
to
decide
on
that
now.
A
A
So
so
I
guess
like
one
of
the
things
to
add
here,
that's
worth
considering.
If
we
want
to
upstream
this.
You
know
we
are
looking
at
you
know
less
than
six
weeks
and
there's
also
a
moratorium
on
semver
major
changes
and
things
won't
land
that
comes
a
little
that
come
a
little
bit
later.
So
you
know
this
is
something
that
we
probably
want
to
wrap
up
in
a
period
of
like
you
know
three
weeks
at
the
latest,
so
so
we're
very
limited
on
time
and
bandwidth
about
what
we
can
accomplish.
G
F
A
F
F
H
F
A
D
Didn't
hear
you
call
me
I
think
we
it
doesn't
I,
don't
think
it
necessarily
needs
to
be
in
phase
2
versus
phase
3,
but
I
think
we
definitely
need
it
or
else
there
are
going
to
be
lots
of
packages
on
NPM
that
have
to
like
basically
publish
a
second
package
like
low
and
low
yes,
so
that
they
have
like
versions
for
each
like.
D
You
know,
node
less
than
12
and
node
12
plus,
because
they
might
want
to
continue
to
like
introduce
features
to
the
common
das
version
and
not
just
like,
have
a
semper
meijin
break
and
then
the
CSM
forward
and
then
like.
If
you
want
new
features,
you
have
to
be
no
12
plus
so
I
think
to
avoid
a
big
disruption
in
the
NPM
registry.
We
need
to
support.
We
need
to
support
this
now.
Does
it
need
to
be
supported
before
we
upstream,
probably
not,
but
I?
D
A
C
Yes,
I
agree,
whichever
just
said,
and
I
I
think
that
the
all
of
this
stuff
we're
talking
about.
Obviously
it
has
to
be
figured
out
before
on
flagging,
but
like
as
to
what
what
shouldn't
be
upstream
door.
What
can
be
upstream,
this
kind
of
a
tricky
question:
I
think
that
in
general,
when
it's
gonna
affect
the
ecosystem
is
when
we
should
be
careful
and
unfortunately,
with
modules.
C
C
A
Think
I
think
based
on
this
and
then
I'll
get
to
you
in
just
a
moment.
Perhaps
we
can
keep
this
in
here
as
a
Phase
two
requirement,
because
it
is
or
maybe
we
can
move
it.
Maybe
we
can
move
it
to
Phase
three
because
as
it
exists
right
now,
we
cannot
do
this
in
the
implementation,
but
we
want
to
do
it
as
soon
as
possible.
A
But
I
guess
like
one
of
the
challenges
here
is
that
it
is
definitely
if
it's
something
we
want
to
do
something
that
we
want
people
in
the
ecosystem,
testing
for
in
advance
of
us
removing
the
flag.
So
you
know
with
that
being
said.
Perhaps
we
should
before
we
upstream
land,
something
that
can
allow
for
this
based
on
the
current
behavior
and
then,
if
we
decide
to
change
behavior
in
a
way
which
changes
the
way
in
which
it
can
be
done,
we
iterate
and
remove
things
as
necessary.
F
You
know
having
two
instances
and
if
there
are
debugging
problems
there,
but
hopefully
these
the
sort
of
things
that
we
can
reach
out
as
we
get
user
feedback
but
yeah.
It's
something
that
maybe
maybe
it
isn't
something
that
we
yeah
need
to
have
as
the
immediate
Phase
two
requirements,
and
maybe
I
did
those
that's
sort
of
a
difficult
dichotomy
between
file
extension
and
exports.
Yeah.
A
I
mean
to
be
honest,
and
then
maybe
we
should
move
on
I'll
call
the
three
comments
that
are
here
right
now
but,
like
maybe
the
the
idea
of
a
dual
mode
can
be
visited,
whether
or
not
it's
a
good
idea
or
whether
it's
a
foot
gun,
but
as
long
as
we
either
have
a
separate
entry
point
for
ESM
or,
alternatively,
have
file
extension
resolution
in
there
dual
mode
happens
by
default.
There's
no
way
that
we
can
avoid
it.
A
If
there's
two
different
places
that
there
can
be
entry
points
and
we're
not
introducing
breaking
changes
into
the
common
J's
resolution
algorithm
that
will
just
work.
So
you
know
that
is
something
for
us
to
to
take
into
account
that
there
are
limited
ways
for
us
to
actually
stop
this
from
happening
period.
F
I
think
it's
also
important
to
realize
that
people
are
interested
in
this
particular
feature.
Those
who
will
try
to
experiment
with
the
experimental
flag
on
are
likely
going
to
want
to
continue
experimenting
in
this
direction,
so
it
would
be
good
to
like,
even
if
it's
not
a
pleasing
experience
with
the
flag
as
we
improve
it,
it's
important
to
keep
it
there.
A
So
I
think
we
have
two
options
right
now
now.
Does
anyone
object
to
leaving
this
in
Phase
two
meaning
that
before
we
upstream,
we
need
to
have
some
sort
of
solution
to
this
problem
space,
even
if
we
decide
later
that
we're
just
going
to
remove
it
because
we
want
to
have
the
ecosystem,
try
to
decide
it
or
does
or
should
we
move
it
to
Phase
three,
so
does
anyone
object
to
moving
it
to
Phase
three?
A
A
D
A
G
And
kind
of
on
the
same
vein
as
this
point
of
hey,
this
is
not
just
about
technically
of
limitation
details,
but
also
about
do
we
want
to
do
it
at
all,
or
are
there
just
concerns
and
go
beyond
just
an
implementation
detail?
So
the
question
for
me
is
for
these
bullet
points
would
solving
the
bullet
point
in
also
count.
If
the
decision
that
we
have
is
it
just
won't
be
possible,
and
that
is
an
accomplishment
of
Phase.
A
D
C
A
Yeah,
but
that
okay,
we're
getting
way
too
into
the
weeds,
yet
I
think
like
what
we
are
getting
on
here,
though,
is
we're
going
to
move
this
to
Phase
three
and
reaching
concerned.
Maybe
even
the
point
is
reaching
consensus
about
about
packages
that
can
be
required
or
anyways
what?
Let's?
Let's
work
on
the
language
for
that
afterwards,
but
I
think
we
understand
where
we're
going
West.
You
have
one
more
thing
to
add.
A
No
hand
is
gone
okay,
so
it
seems
like
we've.
We've
got
faced
tooth
figured
out
specifically,
the
big
ones
are
adding
a
point
about
shebang,
as
well
as
the
dual
commonjs
moving
to
phase
three
here's,
what
we
have
in
Phase
three,
if
you
you
know,
I'll,
make
it
explicit
as
we
go
through
about
you
know.
What
are
things
that
we're
gonna
do
in
Phase,
three
and
I'll
give
you
a
chance
to
object
if
you
think
that
something
in
here
should
be
moved
to
phase
two.
A
So
the
first
thing
on
here
is
UX
improvements,
better
mechanism
for
creating
require
function.
This
is
either
something
like
import,
no
GS
call
and
require,
or
at
no
Jo
slash,
require
important
matter
require
or
only
create
require
from
path,
but
just
improving
that.
Does
anyone
object
to
that
being
a
phase
three
concern.
A
No
objections,
a
loader
solution
that
works
for
all
items
in
the
feature
readme,
so
just
loaders
in
general,
being
a
phase
3
concern,
guy
I
know
that
you
in
particular,
have
Fox
about
replacing
the
upstream
implementation
without
loaders
ready,
I.
Believe
brad
has
been
working
on
this
extensively,
but
there
are
like
a
really
obscure
memory
leak
that
we
may
not
be
able
to
solve
in
time
for
getting
this
out.
Is
this
something
that
you're?
Okay,
with
fixing
after
we
upstream
the
current
implementation?
A
F
Fixing
as
in
fixing
the
memory
leak
or
fixing,
as
in
fixing
the
up
streaming
of
loaders
either,
do
you
want
to
see
loaders
as
a
phase
2
concern?
Are
we
able
to
I
think
I
think
it's
quite
important
that
loaders
are
included
in
what
we
upstream?
The
reason
for
that
being
that
we
currently
have
the
ability
to
use
loader
as
a
way
to
kind
of
bypass.
F
You
know
all
the
default
loader
and
have
allow
third
party
tools
to
do
their
own
thing.
So,
for
example,
if
young
PNP
wants
to
use
es
modules,
look
like
tinkle
as
I'm
all
those
things
that
hook
in
to
the
the
module
pipeline
and
I
needed
for
my
own
project
as
well
and
so
to
remove.
That
is,
to
kind
of
just
force.
Everyone
under
experimental,
under
experimental
modules,
to
use
the
default
later,
which
seems
like
quite
a
big
step
back
to
me.
F
A
Guy
I
want
to
follow
up
with
Brad
on
this.
It
I'm
in
favor
of
doing
that
if
we're
able
to
land
the
loader
behind
a
flag
in
such
a
way
that
the
memory
leak
is
not
introduced
unless
the
flag
is
included,
but
if
it
introduces
the
memory
leak
even
without
the
flag,
that
may
not
be
something
we
actually
physically
can
upstream.
Would
you
be
flexible
in
that
situation?
A
A
Salt,
okay,
so,
let's
tentatively
say
that
will
move
loaders
to
Phase
two,
assuming
that
it
can
be
landed
in
a
way
where
the
memory
leak
does
not
affect
node
when
the
flag
is
not
used.
But
if
that
does
have
problems,
then
we
will
iterate
when
we,
when
we
figure
that
out
the
next
one
we
have
on
here
is
map
the
paths
within
modules
providing
similar
functionality
as
the
browser's
import
map
proposal.
This
is
yawns
exports
proposal.
A
A
Right,
the
final
one
is
automatic
entry
point,
module,
type
detection,
so
proposal
entry
point
proposal
includes
a
type
Auto,
so
this
is
similar
to
kind
of
dual
parsing
on
entry.
It's
just
trying
to
make
the
experience
of
entry
points
better.
Does
anyone
object
to
this
being
a
UX
improvement
as
part
of
Phase?
Three.
I
A
A
A
D
A
I
think
it
may
make
sense,
though,
maybe
just
adding
a
note
at
the
top
here
Jeff
just
that
phase
three
is
valuable,
based
on
evidence
that
we
find,
while
working
on
the
phase.
Just
that
way,
it's
explicit
so
that
people
who
are
part
of
this
group
who
see
the
doc
aren't
going
to
be
like
planning
things
based
on
what's
in
the
stock
and
assuming
that
it's
set
in
stone.
A
A
A
D
C
C
C
A
A
So,
just
one
more
time
does
anyone
object
to
because,
based
on
what
we
have
in
here
right
now
and
the
way
in
which
things
are
labeled
and
the
way
in
which
things
are
existing,
we
would
be
up
streaming
importing
commonjs
modules
using
the
current
IRP
proposal
and
only
allowing
default
exports.
Does
anyone
object
to
that
being
the
behavior
that
we,
upstream
as
part
of
phase
2.
A
Cool,
so
that's
something
that
we
can
dig
into
more.
We
can
document
it
and
figure
out
more
stuff
afterwards,
so
the
last
bit
here
is
file
extension
and
directory
index
returning
in
ESM.
This
is
currently
not
part
of
the
implementation,
and
we
have
it
as
something
as
part
of
phase
3.
The
reason
why
it's
been
put
here
as
a
phase
3
concern
and
Jordan.
This
is
very
much
to
the
things
that
we
were
talking
about
earlier.
Changes
that
we
have
right
now
to
the
implementation
are
making
assumptions
based
on
no
file
extension,
searching
and
I.
A
Think
going
to
this
like
dual
common
j/s
ESM
packages
is
a
great
example
of
something
where
whether
or
not
we
land
file
extension
path
searching
is
going
to
change
it.
Does
anyone
object
to
us
keeping
what
we
have
right
now,
which
does
not
include
file,
extension
and
directory
searching
and
having
that
be
something
that
we
work
on
in
phase
3
to
reach
consensus
boom.
I
I
think
it
would
be
nice
to
have
a
a
like
more
like
the
group
to
have
a
stance
on
this
because
I
feel
like
if
there
isn't.
This
could
be
contentious
in
actually
upstreaming
it
mostly
because
you
know
come.
Jeaious
obviously
has
this
and
it's
been
in
there
for
a
long
time,
and
users
may
expect
that
so
I
mean
we
should
probably
have
some
sort
of
good
reason.
If
it's
not
going
to
be
there
or
maybe,
if
it's
going
to
be
there,
no.
D
Wanted
to
say
that
I
think
that
the
the
exports
thing
with
dual
mode
can
doesn't
need
to
be
or
shouldn't
be,
coupled
with
this,
like
there's
plenty
of
reasons
to
have
extension,
searching
for
import
statements
and
then
not
have
it
in
a
package
of
Jason
fields
like
packages
Jason
for
other
tools.
If
you
want
to
have
separate
source
and
dist
folders,
you
know
like
we
can
certainly
have
extension
searching
in
the
runtime
itself
and
just
not
include
it
in
package
of
Jason
or
bring
it
to
package
of
Jason
later.
But
I.
A
G
Right,
we
were
talking
about
I,
completely
lost
track.
Okay
extension
said
I
think
what
exemption
searching
searching
also
implies
is
a
decision
about
gold,
slash
values
in
terms
of
what
kind
of
code
do
we
want
to
encourage
with
our
implementation,
because
if
we
go
for
extension
searching,
we
are
taking
a
stand.
That
code
should
not
be
written
in
a
way
that
runs
in
a
simple
HTTP
server.
In
a
browser.
G
We
encourage
people
to
keep
the
current
pattern
that
has
been
embraced
by
the
node
community,
which
is
to
write
code
that
runs
a
node
and
definitely
needs
compilation
to
have
any
chance
to
run
in
a
browser
just
in
terms
of
the
conventions
being
used.
Yes,
you
can
still
write
code
using
contact
when
using
the
extension.
But
you
know
the
usual
convention
in
node
is
something
that
would
not
work
in
the
browser.
You
would
have
to
explicitly
find
code
that
has
been
written
by
people
who
do
not
follow
the
usual
conventions.
D
Was
just
gonna
say:
I,
don't
know
if
this
can
find
consensus,
but
I
kind
of
like
there's
no
consensus
between
us
either
way.
Clearly,
that's
seems
clear,
so
I'm
kind
of
curious,
if
we
upstream
without
this
and
just
see
what
the
reaction
is
see
it,
what
cor
thinks
of
it
see
what
the
broader
node
community
thinks
of
it
I
mean
we
could
easily
add
it
in
a
week.
You
know
behind
a
flag,
but
I
think
this
is
a
much
bigger
question
about
like.
C
I
think
that
what
Jeffrey
said
is
actually
the
second
half
at
least
is
completely
true.
It
is
a
larger
question
and
I
think
that
if
we
forbid
extension
searching,
what
we
are
doing
is
making
a
statement
that
the
way
that
many
people
write
node
code
right
now
is
invalid
and
they
shouldn't
write
it,
whereas
if
we
allow
extension,
searching
we're,
not
forcing
people
to
omit
their
extensions
which
they're
not
forced
to
do
now,
what
we're
doing
is
permitting
more
than
one
style
of
code.
Writing
browsers,
cannot
do
extension,
searching
and
that's
fine.
C
You
don't
have
to
write
your
code
and
omit
extensions.
You
can
write
them
and
either
way.
You're
gonna
need
import
maps
for
all
of
your
third-party
modules.
So
the
fact
that
whether
third-party
modules
use
extensions
or
not,
is
irrelevant
in
your
first
party
code,
if
node
allows
extension
searching,
you
can
just
not
use
it,
and
then
you
get
that
property
of
all
the
code.
A
B
Yeah,
this
is
just
kind
of
just
because
people
keep
mentioning
browser,
compat
and
I.
Don't
get
how
the
existence
of
extension
resolution
somehow
means
that
or
let
the
rather
than
not
been
it
not
it
not
existing
somehow
means
that
you,
it's
somehow
safe
to
just
zip
up
your
node
modules
and
put
it
on
a
in
on
your
brat
on
your
server
to
serve
to
a
browser,
because
there's
always
gonna
be
common
j/s
in
there
and
like
package.json
flags
and
like
I,
don't
understand
how
this
is
somehow
breaking
browser
compile.
A
So
so
something
that
might
be
worth
suggesting
here-
and
perhaps
this
is
this-
is
a
place
that
we
could
agree
upon,
would
would
those
who
are
in
favor
of
extension
searching
be
open
to
us,
including
extension
searching,
but
behind
an
additional
flag
like
experimental
module
extension
search,
searching
something
that's
opt-in
rather
than
on
by
default.
That
way,
the
source
code
will
be
there.
The
code
path
will
be
there,
it's
something
that
we
can
have
within
like
the
this.c
implementation
of
the
resolution
algorithm
and
then
it's
something
that
we
can.
A
Let
people
experiment
with
and
see
what
people
think,
because
at
least,
if
we
have
it
as
something
that's
behind
a
flag
and
as
an
option,
then
people
are
still
able
to
experiment
with
it.
It's
not
as
strong
of
a
message.
It's
does
send
some
sort
of
message
that
hey
you
know
this
is
on
the
table
that
we
may
not
want
to
do
it,
but
at
the
very
least,
if
we
allow
experimentation,
we
can
see
what
people
prefer
and
then
iterate
based
on
kind
of
what
people
are
doing
and
what
the
ecosystem
responses.
C
I
agree,
I
think
a
flag
to
turn
it
off
would
be
fine
if
you
want
to
like
hamstring
your
node
process,
but
again
I
just
I,
don't
see
why
it
like
I
think
it
is
a
statement
that
not
everyone
belongs,
that
we
are
excluding
people
if
we
forbid
something
that
has
worked
in
node
forever,
I
think
if
we
allow
it,
we
are
still
allowing
for
the
people
who
have
that
desire
to
write
code
for
the
browser
without
a
build
process.
But
that's
not
everybody
and
we
shouldn't
pretend
it
is
so.
A
C
A
So,
to
be
extremely
explicit,
I
am
proposing
that
as
part
of
Phase
two
we
have
extension
searching,
but
it
is
behind
an
additional
flag,
an
experimental
module
path
resolution
if
we
can
bike
on
the
name
afterwards,
but
that
be
what
we
can
ship
upstream
that
way
it
is
clear,
but
we're
still
allowing
people
to
do
it.
Does
anyone
else,
aside
from
Gus
and
Jordan
object
to
that?
Maybe.
I
A
Fine,
the
only
reason
I
was
saying
that
is.
We
have
11
people
on
the
call.
If
no
one
else
objected
that
would
have
been
nine
people
on
the
call
who
would
have
been
in
favor
of
it.
So
had
it
gone
to
a
vote,
we
would
have
had
a
majority
of
the
group
voting
in
that
direction.
That
was
basically
where
I
was
trying
to
go
with
that
Matt
miles.
Can
I
just
make
a
point
on
that.
We're.
D
I
was
just
gonna,
say,
I
think,
regardless
of
which
way
this
ultimately
lands
before
we
unflagged
modules
I
feel
like
if
we
don't
release,
if
we
don't
upstream,
with
extension,
searching
either
missing
or
behind
a
flag,
then,
where
there's
no
way
to
kick
off
this
discussion,
because
then
it's
just
like
nothing
has
changed.
It's
the
status
quo
and
that's
you
know
it's
not
saying
to
people
hey.
Do
you
want
to
be
more
like
browsers
and
require
extension?
So
a
browsers
do
so.
D
The
only
way
to
have
that
discussion
on
on
a
bigger
level
is
to
kind
of
force
people's
attention
on
it
and
obviously,
if
you
decide
if
you've
already
decided
yourself
that
you
know
there's
no
way
in
hell,
you
want
extension
searching
to
not
happen.
Then,
of
course
you
don't
want
that
discussion
to
happen,
but
I
think
we
owe
it
to
the
community
to
prompt
that
discussion.
A
A
So
I
think
that
we
can
do
90%
of
the
work
that
we
need
to
be
able
to
upstream
this
in
a
timely
fashion,
while
working
on
the
extension
search,
searching,
out-of-band,
I'm
gonna
go
ahead
and
set
up
an
issue,
so
we
can
find
a
time
to
have
an
out-of-band
meeting
just
to
dig
into
extension,
searching
or
people.
Okay
with
that
sounds
good.
Okay.
A
So,
with
that
being
said,
I've
got
to
spin
down
this
meeting.
I
apologize
for
kind
of
cutting
off
the
conversation,
especially
when
it
has
been
such
a
productive
meeting.
Thank
you.
Everyone
for
the
time
everyone
who's
made
concessions
today,
I
really
appreciate
what
you've
been
willing
to
do.
I
want
to
point
out
the
fact
that
we
have
literally
gone
through
everything
right
now,
actually
having
a
boat,
it's
kind
of
nice.
A
We
had
a
semi
votes
last
time
that
we've
managed,
for
the
most
part,
reach
consensus
on
this,
which
is
extremely
hard
for
what
we're
working
on
I'll
work
on
getting
that
out
of
band
meeting
together
for
file
extension
searching
one
other
thing
that
I
wanted
to
mention,
which
we
didn't
think
about
before
we
do
have
to
upstream
this,
and
we
do
have
to
get
sign-off
from
upstream.
So
all
the
things
that
have
been
controversial,
that
we've
worked
through
as
a
group
still
needs
to
be
worked
out
with
the
upstream
group.
A
So
it's
important
that
we
have
a
collective
front
on
what
we're
presenting.
If
we
have
a
collective
front,
it
is
a
much
higher
probability
that
it
won't
be
nitpick
to
death
upstream.
But
with
that
being
said,
we
do
have
no
guarantee
that
is
not
going
to
be
kicked
back
to
us
to
work
on.
So
I
do
think
that
we
should
try
to
work
on
getting
something
that
we
can
upstream
in
an
order
of
one
to
two
weeks,
so
we
at
least
have
time
to
receive
feedback
iterate
and
try
to
get
it
landed
before
12:00.