►
From YouTube: Node.js Foundation Modules Team Meeting 2019-02-20
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
You're
now
live
on
YouTube
with
the
Wednesday
February
20th
2019
meeting
of
the
node.js
modules
team,
we're
joined
by
a
handful
of
passionate
individuals
who
care
quite
a
bit
but
modules
we're
kind
of
following
up
from
where
we
left
off
on
the
last
meeting.
So
I'm
gonna
go
ahead
and
share
my
screen
and
cross
my
fingers
that
I
don't
share
the
wrong
one,
but
we
see
the
roadmap
here.
A
Let's
do
a
quick
review
of
what
we
discussed
last
time,
make
sure
we're
all
on
the
same
page
about
that
make
sure
nothing
needs
to
change,
and
then
we
can
iterate.
So
first
off
we
talked
about
the
timeline
replace
the
flagged
immitate
implementation
in
node.js
core
before
no
gs-12
ships
in
April,
2000,
19,
there's
actually
now
a
potential
date
for
this,
which
I
believe
was
April
23rd.
A
A
We
reach
consensus
on
two
features
that
we're
considering
to
be
out
of
scope
for
this
timeline.
Specifically,
that
was
VM
modules
and
package
exports
proposal.
Now
it's
possible
that
the
package
exports
proposal
could
end
up
back
in
if
we
find
that
it's
necessary
for
one
of
the
features
that
we're
trying
to
complete
could.
B
I
just
add
to
that
you
know
we
just
updated
the
proposal
to
be
current
with
where
the
implementation
stands
with,
like
you
know
the
type
field,
and
all
that
there
already
was
a
PR
for
it
for
earlier
so
now
the
PR
needs
to
be
updated,
but
there
is
a
chance
at
that
PR
be
updated
to
work
with
the
current
implementation
like
soonish.
Yes,.
A
But
I
would
say
that
just
because
it
can
work
doesn't
mean
it
should
package
exports
and
what
we
were
talking
about
impact
your
package.
Exports
is
a
significant
change
to
how
people
write
code
and
can
potentially
be
a
massive
change
to
the
ecosystem
and
there's
something
that
we
add
I
personally,
think
it's
something
that
we
should
be
adding
later
potentially
but
like
definitely
before
it's
unflagged,
but
I.
Don't
think
that
that's
something
that
we
should
be
rushing
out.
It
was
also
something
that
we
had.
A
Consensus
could
be
brought
to
the
node
core
project,
something
that
could
maybe
be
used
for
common
jeaious
modules
as
well.
So
I
do
think
that,
for
the
scope
of
at
least
like
this
first
replacement,
its
out
of
scope,
I
think
that's
what
we
had
reached
consensus
on
in
the
last
meeting.
Does
anyone
object
to
that.
A
Okay,
so
this
is
where
we
got
stuck
on
some
things.
Last
time
which
was
specifically
about
named
exports,
we
did
have
consensus
that
we
should
continue
to
pursue
dynamic
modules
at
tc39.
Tc39
is
still
open
to
this
landing.
It
could
be
a
cember
minor
as
an
enhancement
from
default.
There
was
no
reason
to
not
pursue
in
that
work
needs
it
just
needs
to
happen.
I
have
a
doc,
that's
starting
to
track.
You
know
kind
of
what
changes
need
to
happen,
but
we
should
be
kicking
that
off.
A
You
know
pretty
soon
the
other
one
was
should
we
rely
on
out
of
order
execution,
that's
plural
quest
number
31,
and
we
had
eight
against
in
five
four
in
the
meeting
that
we
had
last
time,
which
was
13
people.
Is
there
anyone
on
the
call
right
now
who
is
not
in
the
meeting
when
we
voted
on
this
last
time,.
A
Okay,
so
for
what
it's
worth,
you
know
we
have
18
people
in
in
the
group,
which
means
that
we
were
like
essentially
one
vote
away.
I
think
there
were
people
who
abstained
from
this
as
well,
though
I
wish
we
had
I
think
we
have
longer
notes
in
the
notes
and
there's
definitely
the
video
that
we
can
double-check
on,
but
this
seems
to
be
airing
towards
not
doing
out
of
order
execution.
A
So
then
we
started
getting
into
the
default
behavior,
and
this
is
kind
of
where
we
ran
at
a
time
which
is
we
were
talking
about
like?
Can
we
ship
named
exports?
If
we
only
ship
default?
Is
that
okay?
Or
are
we
okay
with
shipping
without
common
jeaious
interoperability
at
all?
In
you
know
the
first
implementation,
the
things
that
are
still
left
on
the
agenda
is
to
finish
this
discussion
around
default
behavior
and
try
to
reach
some
degree
of
consensus
there
or
vote.
We
then
have
to
move
into
the
file
extension
resolution
stuff.
A
A
A
A
A
A
A
Yeah
Jordan,
maybe
we
can
talk
about
the
CJ
s
thing
before
we
get
into
the
file
extension
resolution
conversation.
We
can
find
a
couple
minutes
to
chat
about
it,
so
I
think
with
named
exports.
I
think
we
have
a
path
towards
having
still
towards
having
having
them
with
the
dynamic
modules.
I,
don't
think
anyone's
I
know
some
people
are
discouraged
from
continuing
working
on
it,
but
I
think
there's
still
a
path
forward
to
it.
So
I
think,
and
it
looks
like
we
don't
want
to
move
forward
with
out
of
order
execution.
A
A
B
If
you're
talking,
Jeffry,
you're,
muted,
alright
I
was
just
thinking
since
we
already
have
default
only
in
this
implementation
and
I
was
also
in
the
experimental
models.
Implementation
I
think
changing
that,
like
getting
rid
of
that
like
if
we
give
up
on
named
exports,
because
we
can't
make
it
work
on
whatever
reason
I
was
thinking
like
if
we're
gonna.
B
If
we're
talking
about
replacing
the
upstream
experimental
modules
soonish
in
a
few
weeks,
then
why
don't
we
punt
the
changes
of
default
only
if
it
comes
to
that
after
that
point
just
so
that
it's
not
like
part
of
the
you
know,
part
of
the
PR
update
to
the
broader
community
of
not
only
is
there
a
new
experimental
models
implementation,
but
we
got
rid
of
all
interoperability
altogether,
I
think!
If
that
change
happens,
we
should
probably
do
that
as
its
own
thing,
like
sometime
between
replacing
the
upstream
and
unflagging
it
Brad.
A
B
A
B
A
E
A
A
Everything
else
is
flagged
right
now,
because
if
the
debate
that
we're
having
right
now
is
whether
or
not
we
should
ship
default
at
all,
but
the
plumbing
is
there,
people
can
do
it
and
they
could
do
it
today,
but
we
may
remove
it.
That
seems
like
the
appropriate
way
to
move
forward
where
we
have
an
additional
flag
to
make
it
clear
to
people
that
they're,
enabling
something
extra.
A
So
I
think
I
think
the
the
path
that
we're
talking
about
and
Wes
I'll
put
you
up.
Next
is
if
we
cannot
get
this
dynamic
modules
proposal
through
at
tc39,
and
we
cannot
find
a
way
to
do
named
exports
in
a
spec
compliant
way,
and
the
only
thing
that
we
can
do
from
an
interoperative
is
default.
Exports
there's
a
number
of
individuals
on
the
modules
team
who
would
like
to
not
ship
that
form
of
Interop
at
all.
F
Wes,
would
you
like
to
chime
in
then?
No
here
seems
reasonable,
just
as
long
as
you
make
it
explicit
that
that's
a
strategy
so
like
not
that
this
is
called
interrupts
mode.
But
this
is,
you
know,
defaults
imports
for
Interop
or
something
like
that.
But
otherwise
it
seems
like
a
reasonable
thing
to
do.
A
C
A
Jeremy,
oh
when
you
say
that,
does
that's
not
an
option.
Are
you
saying
that
you
would
object
to
it?
Because
if
we
do
have
a
vote
in
the
votes
outweigh
you
and
then
it
goes
back
to
the
core
and
it
goes
to
the
TSC
and
the
tea
SEO
weighs
you
I
feel
like
not
an
option
is
not
the
right
way
to
frame
it.
Well,.
C
G
Mean
I
think
it's
clear
that
everything
is
an
option
if
the
votes
outweigh
like
not
an
option
should
generally
mean
in
a
process
where
there
cannot
be
votes
and
can
only
be
consensus,
it
would
never
happen
and
it
I
think
we
should
be
I
think
we
should
treat
having
to
vote
as
a
bit
of
a
failure
of
the
process.
Even
if
we
have
that,
as
our
you
know,
even
if
we
use
that
as
our
way
out.
D
Bradley
I
just
well
two
points,
one
I
I
believe
this
situation
is
complex
enough.
Having
unanimous
consensus
is
not
going
to
happen
anytime
soon,
so
voting
is
where
we
will
end
up.
Also,
when
we're
talking
about
these
things,
we're
also
going
to
be
talking
about
supporting
multiple
module
formats
in
the
future.
Maybe
we
can
push
this
discussion
later
into
what
just
the
base
module
formats
we
want
to
support
before
unflagging.
A
B
B
So
Jeffrey,
what
are
you
suggesting
as
an
alternative,
I'm
suggesting
we
we
merge
this
upstream,
we
announce
it.
There
are
no
changes
to
interrupt
from
a
user's
perspective,
I
think
well,
I,
guess
they
file
extension
thing,
but
there's
no
changes
in
terms
of
this
comma
J
s,
import,
stuff
and
then
sure,
like
a
week
later,
we
make
the
change
of
putting
it
behind
a
flag.
Just
doing
that
has
consensus.
What's.
B
Having
it
so
that
so
that
we're
not
so
that
so
that
it
doesn't
become
like
part
of
the
publicity
around
there's
a
new
modules
implementation
that,
oh,
my
god,
they
got
rid
of
Interop,
you
know,
or
it
looks
like
they're
getting
rid
of
Interop
or
something
to
that
effect.
You
know
that
might
still
happen
before
we
unflagging,
but
that
would
just
be
its
own
thing.
You
know
separate
from
this
I
think.
A
If
we're
gonna
do
it,
we
should
do
it.
You
shouldn't
like
delay.
It
agreed
I,
also
think
that
if
we
don't
have
consensus
on
this
and
it's
a
possibility
that
we're
gonna
remove
it,
putting
it
behind
an
additional
flag
is
the
most
honest
thing
that
we
can
do
and
if
people
want
to
have
problems
with
that,
we
can
hear
that,
and
that
can
be
a
reason
why
we
remove
the
flag.
But
this
seems
to
be,
in
my
personal
opinion,
the
only
solution
forward
that
allows
us
to
move
forward
right
now
and
make
that
decision
later.
C
Okay,
so
related
to
this
topic
and
on
default,
behavior
I
mean
the
consensus
might
be
otherwise,
but
it
I
mean
it
seemed
to
be
kind
of
mixed.
Last
week
when
I
brought
this
up
or
was
it
two
weeks
ago,
I
don't
even
remember
on
default
behavior
that
we
need
to
be
spec
compliant
I.
Don't
actually
agree
on
that.
I
would
rather
have
it
actually
work
for
people
rather
than
be
spec
compliant.
If
tc39
is
unwilling
to
make
things
work
reasonably
for
us,
I
think.
A
B
With
regards
to
this
being
dishonest
because
it
might
get
removed,
we
have
a
consensus
that
we
want
named
exports
to
work
and
we're
pursuing
that
through
tc39
like
if
anything
leaving.
This
is
enabled
with
this
with
this
would
imply
that
we
want
more
to
come,
is
in
a
sense,
even
more
honest,
of
where
the
consensus
of
the
group
certainly
is
versus.
There
might
be
a
bare
majority
or
a
slight
majority
for
removing
it
entirely,
but
that's
certainly
a
less
preferable
option
from
the
group
overall
than
just
trying
to
make
everything
work.
A
G
What
kind
of
meta
comment?
In
general
this
whole,
the
entire
working
group
has
been
a
lot
of
debating,
of
course,
about
a
lot
of
things
that
we
all
are
very
passionate
about.
It
seems
there's
a
number
of
cases
where
certain
choices
have
to
be
made
to
allow
for
use
cases
and
making
a
different
choice
is
only
possible
if
you
shut
down
those
use
cases.
G
I
G
This
has
come
up
a
lot
around,
like
I.
Don't
know,
like
extension,
look
up
recently
right
like
there's.
If
you
want
to
always
have
to
specify
extensions,
you
will
be
able
to
do
that
regardless
the
but
there's
a
lot
of
debate
as
to
whether
we
should
allow
people
to
be
able
to
omit
them
and
I
feel
like
in
general.
The
difficulty
we
have
coming
to
consensus
on
stuff
is
a
tension
between
the
people
who
want
to
allow
for
things
and
the
people
who
want
to
restrict
things
and
I've
been
on
both
sides
of
that.
G
So
this
is
not
like
a
judge.
You
know
throwing
blame
kind
of
thing,
but
like
I,
wonder
if
it
might
help
our
discussions
if
we
try
to
enable
as
many
use
cases
as
possible
and
think
very
carefully
about
places
where
we're
restricting
things,
and
that
includes
by
default,
you
know,
meaning
like
because
it
requiring
a
flag
is
a
restriction,
even
if
it
still
enables
it
so
like
we
should
kind
of
think
about
how
we
want
that
to
look
in
the
final
product
and
how
that
can
affect
our
decisions.
J
It's
just
the
specifics
of
those
changes
that
we
haven't
nailed
down
yet
and
since
we're
confident
of
those
two
points,
why
can't
we
just
ship
named
exports
with
our
spec
proposal
that
we
know
is
going
to
change,
but
the
parts
of
it
that
are
going
to
change
are
gonna
be
completely
unobservable
to
anyone
who's,
not
writing
the
implementation.
No
one
will
know
that
it's
changed
underneath
them
I,
don't
see
why
we
like?
Is
it
just
because
floating
the
v8
catch
is
difficult
for
us
and
we
want
to
avoid
doing
that.
A
D
J
Changes
in
terms
of
like
code
that
people
write
like
observable
changes,
is
it
like
I?
There
are
things
that
I
cannot
export
or
import
with
names
like.
The
point
is
like
we're
good
we're,
gonna
write
code
that
allows
people
to
use
named
exports.
That's
the
goal,
how
the
spec
achieves
that?
No
one
writing
code
cares
about,
and
so
like.
Whatever
we
need
to
apply
to
v8
in
the
meantime
is
fine.
Whatever
the
spec
text
comes
out
to
be
in
the
end
is
whatever
it
only
matters
for
us
I.
A
Have
the
objections
on
the
screen?
Let's
go
through
people
we've
gone
over
this
by
a
couple
minutes,
but
you
know
this
is
one
of
the
most
contentious
bits:
let's,
let's
try
to
only
do
another
ten
minutes
here
and
then
spend
20
minutes
on
the
file
extensions
and
then
assume
that
we
have
to
push
to
the
next
meeting
to
actually
finish
this
out.
Brad.
E
Guess
I
just
want
to
like
clarify
what
people
are
saying
Wes
so
like
the
changes
that
have
been
proposed
by
lots
of
people
for
named
exports
have
all
had
observable
issues
with
them
like
making
certain
types
of
imports,
throw
or
loosening
the
loosening.
How
static
static
moth-like,
like
normal
module
records,
are
in
there
like
static
analysis,
things
that
have
observable
impact
beyond
like
they're,
not
just
internal
changes.
They're
observable
changes,
but
don't
watch
is
how
is
loosening
that
quote.
E
J
The
same
thing
with
all
winter
is
because
they
all
work
on
trans
palled
code.
As
you
know,
an
author
works
like
a
linter
I,
don't
like
the
static
analyze
ability.
Part
of
es
imports
is
the
thing
I
care
about
the
least
because
no
real
es
imports
existed,
but
but
other
other
people
care
about
more
care.
A
G
So
all
those
improvements
miles
are
only
gonna
be
a
problem
in
the
scenario
if
node
core
remains
having
CJ
s,
that's
treated
as
CSM,
so
like
four
node
core,
this
isn't
an
obstacle
whatsoever
as
far
as
linting
I
maintain
es
Lin
plug-in
import,
which
they
are
BV
style
guide
uses
which
does
cross
file
import
checking,
and
this
already
is
something
they
have
to
deal
with
with
CJ
s.
So
this
restriction
wouldn't
be
a
problem
at
all.
It
would
actually
be
quite
easy
to
lend
for
and
the
other.
B
G
Is
as
far
as
comity
folks
I
want
to
say
this
earlier
comity
folks
that
have
objections.
Many
of
these
objections
have
seemed
to
me
along
the
same
thing
as
the
people
who
didn't
like
the
MJS
extension.
It's
not
something.
Tc39
gets
a
vote
on
it's
something
that
the
people
are
basically
expressing
their
ickiness
about,
and
the.
I
G
Of
the
t39
has
consensus
that
we're
going
to
accommodate
node
and
if
what
is
needed
to
accommodate
notice
to
move
source
text
module
module
records
out
of
the
spec,
then
we
will
do
that
and
we
will
find
a
way
to
make
it
palatable
whether
the
committee
likes
what
node
has
to
do
with
it
is
kind
of
irrelevant
and
then
separately,
there's
nothing
in
the
spec
that
forbids
someone
from
making
export
star
us
an
early
error.
Already.
It
just
means
they've
only
partially
implemented
the
spec.
J
So
I'm
just
saying
the
minor
differences
in
how
named
exports
behave
is
a
smaller
future
potential
change
than
this.
Whether
or
not
we
have
even
defaults
change,
we're
talking
about
and
so
I
think
going
with,
whatever
version
of
named
exports
that
we
know
isn't
going
to
be
the
final
version
because
we're
still
iterating
on
it
and
then
taking
that
and
iterating
on.
It
is
the
more
same
thing
to
do
here
so.
F
J
Either
side
of
that
right,
and
if
we're
saying
that,
like
anything
that
we
ship,
we
can't
unflagging
till
we're
confident
in
it
anyway,
it's
like
we're
already
saying
that
we're
not
gonna
ship,
something
that's
not
final
like
in
the
end
like,
so
why
don't
we
do
the
thing?
That's
more
aligned
with
what
our
actual
ideal
final
end
goal
is
I.
D
Would
make
a
counter
point?
We
should
take
the
likely
one
that
we
can
ship
regardless
already,
rather
than
the
one
that
may
not
work
out.
The
deals.
Export
option
is
something
we
could
ship,
but
we
we
can
choose
to
remove
it
for
whatever
reason
the
named
export,
we're
not
sure
we
could
even
ship
yet.
J
We're
saying
we
could
ship
it,
but,
as
we
wrote
in
the
notes
for
the
last
meeting
like
we
were
leaning
towards
not
shipping
default,
interrupts
at
all.
As
long
as
like
named,
exports
were
still
on
the
table
and
like
the
tc39
was
still
talking
about
them.
I'm
not
sure
I
got
that
from
my
Under
standing
up
last,
finding
its
what
was
written
in
the
roadmap
notes,
yeah.
A
At
least
in
the
in
the
roadmap
Docs,
as
we
went
through
it
last
week,
there
seemed
to
be
a
leaning.
It
was
not
a
consensus
but
a
leaning
that
there
were
more
people
who
wanted
to
remove
Interop
altogether
if
it
was
only
defaults,
but
perhaps
actually
something
that
Jeff
just
suggested
in
the
comment
is
maybe
a
more
accurate
split.
The
difference.
If
we
have
a
general
sentiment
that
we
don't
we're
not
really
palpable
with
shipping
defaults,
but
we
would
like
to
try
to
ship
named
exports.
A
It's
a
pain
in
the
ass
and
it's
something
we
don't
want
to
do
if
we
don't
have
to
I
think
reading
these
objections
from
the
dynamic
modules
proposal
and
I
know
that
the
web
assembly
group
is
also
proposing
in
Jordan
I,
don't
know
if
this
is
something
you
could
take
a
peek
at
or
if
it's
landed
yet
I
know.
Lynn
Clark
had
an
open
floor
request
for
introducing
what
was
necessary
for
having
the
I
think
it
was.
It
was
the
async
module
record.
Oh.
G
A
D
A
Okay,
so
are
we
any
closer
to
any
decisions
here?
It
seems
to
be
like
there's
some
confusion
in
the
chat
here.
So
I'm
going
to
reiterate
a
few
things
about
the
comments
here.
So
there
was
never
any
point
where
we
were
talking
about
shipping
named
exports
and
not
shipping
default
that
wouldn't
make
sense.
Those
are
both
from
the
spec.
The
thing
that
was
contentious
was:
can
we
even
ship
named
exports?
If
named
exports
are
not
on
the
table,
would
we
ship
only
a
default
export?
A
In
the
last
meeting,
there
were
more
people
who
seemed
to
be
on
the
side
of
we
actually
just
shouldn't
support
importing
commonjs.
If
we
can
only
export
a
default,
there
have
been
discussions
about
better
interoperability,
stuff
that
we
can
do
such
as
import
nodejs,
slash,
require
and
have
a
require
function.
That's
available,
import
meta
require
is
another
better
API.
A
That's
been
tossed
around
as
a
way
to
do
this,
although
it
both
of
these
come
with
their
own
concerns
and
edge
cases
to
be
explicitly
clear
there,
there
will
always
be
some
form
of
Interop
a
way
to
do
inter
on
it's
just
whether
or
not
that
mechanism
will
be
import
is
what's
on
the
what's
on
the
table,
so
I
would
like
to
suggest
something
that
I
think
at
least
can
maybe
help
us
with
moving
forward
right
now.
Could
we
move
forward
with
adding
the
dynamic
module
stuff
behind
an
additional
flag?
So
we
do
not.
A
If
you
want
to
do
any
interrupt,
that
involves
import
and
command
J
s,
you
need
to
apply
this
additional
flag,
but
that
will
include
everything
up
to
and
including
the
named
exports
using
the
dynamic
modules
proposal.
We
will
work
as
a
group
for
those
who
are
stakeholders
to
engage
in
tc39
to
try
to
determine
a
process
that
could
actually
work
on
unblocking
this.
We
can
still
move
this
upstream
with
that
flagged,
especially
if
it's
not
affecting
other
things
in
the
eCos
in
the
in
the
module
system,
and
what
we
can.
A
B
H
John
I
would
object
I.
Also
don't
like
the
idea
of
presenting
the
the
current
proposal
of
dynamic
modules
as
something
that
should
be
implemented
it
to
me.
If
we're
going
to
do
that,
we
might
as
well
implement
it
fully
to
have
fully
supported
named
exports,
even
if
that
deferred,
namespaces
or
a
second
validation
pass.
Why
not
just
implement
it
to
the
fullest
extent
possible,
since
the
current
proposal
is
not
does
not
have
tc39
approval
and
neither
does
a
more
feature-rich
alternative.
H
A
Sir
John
speaking
to
that
directly,
what
I
would
imagine
you
would
do
is
we
have
a
proposal?
Our
implementation
would
reflect
that
proposal.
We
would
actively
work
on
improving
that
proposal
and
getting
approval
and
landing
of
that
proposal,
but
I
would
personally
be
uncomfortable
with
the
implementation,
not
reflecting
the
proposal
on
what
we're
trying
to
bring
to
the
committee.
H
On
that,
before
it's
it's
export
star,
it's
the
export
star
times
to
case
it's
I
mean
like
I
I,
don't
see
the
dynamic
modules
proposal,
as
is
as
any
kind
of
option,
and
unless
we
are
willing
to
actually
add
the
things
that
are
necessary
for
it.
It's
it's
still
going
to
be
a
non
option.
So
I
think
that
we
should
right
now
the
dynamic
modules
proposal
was
proposed.
The
way
it
was
right
as
it
is
today,
because
it
was
seen
as
the
least
amount
to
get
buy-in
from
the
tc39.
H
But
if
we're
actively
trying
to
solve
the
problem,
I
think
we
should
implement
it
fully,
it's
technically
possible
to
implement,
and
then
we
should
take
that
and
push
for
it.
I
don't
see
any
purpose
in
shipping,
something
that
was
like
the
first
draft
of
a
failed
proposal
to
the
tc39
that
that
does
not
hold
value
to
me.
D
H
Doing
I'm
sorry,
I,
I
I
do
don't
think
that,
just
because
one
person
puts
an
effort
that
it's
a
rubber
stamped
approval,
I'm
not
going
to
do
that,
but
you're
stating
that
it
is
a
failed
proposal.
While
we
are
continuing
to
move
forward
well,
I'm
telling
you
that
I'm,
a
delegate
and
I
would
I
would
obstruct
or
ordinary
or
block
the
current
proposal,
as
is,
and
there's
already
other
members
of
the
tc39
that
had
problems
with
the
current
proposal,
as
is
so.
D
H
I'm
fine,
what
I
want
to
say
is
that
I
don't
think
we
should
ship
the
current
draft
one
proposal
behind
the
flag.
I
think
that
we
should
our
goal
should
be
to
add
full
support,
and
so
our
implementation
should
reflect
that
and
then
we
should
adjust
the
spec
or
a
proposal
proposed
spec
to
also
reflect
that
I.
Don't
think
we
should
stop
at
at
the
throwing
behavior
and
assume
that
that
is
the
gold
standard
or
like
the
the
top
bar
that
we
want
to.
We
want
to
reach
so.
A
G
H
Default
right
now
doesn't
require
any
spec
changes,
so
it's
an
easy
go-to.
It's
also
aligns
with
some
of
the
proposed
export
support
for
things
like
JSON
in
the
browser.
So
for
me,
that's
like
a
good
baseline
to
build
from,
whereas
the
other
one
sets
a
precedence
of
like
throwing
on
syntax
and
then
having
to
work
our
way
out
of
throwing
on
syntax
and
then
build
build
from
there.
So
I
would
rather
start
from
a
solid
like
a
low
effort
to
no
effort
spec
work,
which
is
where
the
default
export
is
and
build
from
that.
A
H
Named
exports
aren't
supported
the
it's
not
like
the
syntax
for
exports.
Star
would
throw
exports
star,
doesn't
account
for
the
default
export.
It
skips
it.
So
it's
not
you're,
not
we're,
not
creating
syntax.
That
throws
we're
creating
bindings
that
don't
exist.
It's
not
syntax
that
throws
the
bindings
just
are
not
exported
as
as
as
bindings.
So
you
only
have
a
default,
and
that's
that's.
That
is
a
I'm
more
comfortable
with
that.
I
mean
that's,
that's
why
I
was
silenced
and
let
it
you
know,
go
through.
A
Ii4
right
now,
but
we
have
ten
minutes
left
and
I
would
like
us
to
get
to
file
extensions
I'm
going
to
draft
up
propose
based
on
this,
which
is
somewhere
to
start,
and
we
can
iterate
forward,
but
it
seems
like
we
have
consensus
right
now
to
bring
back
in
importing
from
the
default,
but
behind
an
additional
flag
likely
with
its
own.
You
know
additional
warning
or
something
like
that,
one
last
time
for
anyone
to
object
to
that,
let's
revisit
the
other
stuff
in
the
next
meeting.
I
think
we
could
dig
into
this
for
hours.
A
Okay,
let's
try
something
equally
contentious
the
file
extension
resolution.
So
right
now
there
is
a
resolution
algorithm
that
node
offers
in
common
Jas,
specifically
automatic
file
extension
resolution.
So
you
can,
you
know,
require
a
file
without
an
extension
and
will
search
through
a
handful
of
extensions
to
determine
what
to
actually
require.
We
also
allow
you
to
have
an
index.
Dais
inside
of
a
folder
is
one
of
the
things
that
it
searches
for.
A
Currently,
the
minimal
kernel
does
not
support
this
resolution
algorithm.
There
is
a
desire
within
the
team
to
not
support
this
resolution
algorithm.
There
is
a
desire
within
this
team
to
support
the
legacy
resolution.
Algorithm
I'll
just
leave
it
to
the
floor.
Does
anyone
have
anything
to
add,
or
is
this
just
something
that
we
should
send
straight
to
a
vote?
Read.
D
At
least
previously,
we've
managed
to
reach
consensus
by
kind
of
figuring
out
the
minimal
subset
of
behavior
that
works
across
all
of
our
options,
and
then
we've
used
other
mechanisms
for
configuring
things.
So
I
personally
would
be
in
favor
of
just
starting,
at
least
with
out
any
sort
of
searching
behavior,
and
then
we
can
have
people
either
opt
into
searching
behavior.
D
If
we
choose
that
it
needs
to
be
flagged
somehow
or
we
can
treat
it
as
similar
minor
as
long
as
there
are
no
changes
that
we
see
as
problematic
if
we
make
it
a
default
behavior
in
the
future.
So
we
have
two
paths:
if
we
just
go
without
searching
and
we
can
kind
of
discuss
which
is
the
better
of
those
two
paths,
I'd
prefer
us
to
kind
of
do
that
and.
A
I
guess
I
guess
Brad.
Perhaps
then
what
we
can
try
to
reach
consensus
on
before
I'll
bring
it
back
to
the
floor
is,
it
seems,
like
we
didn't,
have
consensus
that
adding
the
behavior
later
would
be
semver
minor
and
perhaps
reaching
consensus
on
that
which
is
not
a
decision.
But
rather
you
know
an
opinion
about
semantic.
Versioning
may
help
us
with
making
that
decision.
Jeffrey
but
who's
gonna
say
something.
I
can.
B
B
The
only
question
is
whether
it's
something
that
the
user
needs
to
opt
in
or
not
I'm,
fine,
with
the
user
opting
in
whether
it's
a
configuration
or
loader,
and
that's
if
that's
like,
if
there's
not
a
majority
in
the
group
to
make
this
like
by
default,
then
I
think
we
should
just
get
going
on
like
someone
proposing
a
design
and
so
on,
and
then
the
question
is
whether
or
not
that
feature
needs
to
hold
up.
You
know
merging
this
upstream
or
if
it's
gonna
come
later
Jordan.
G
So
while
it's
certainly
an
interesting
discussion
to
decide
the
CEMP
earnest
of
adding
features
in
this
case,
I,
don't
it
doesn't
matter
to
me
if
it's
ember,
minor
I
would
object
to
shipping
without
it
unflagged
just
period?
The
issue
is
that
I
guess
similar
to
JD
these
concerns
about
export
star
this
shipping.
Without
it
that's
a
precedent
and
that
forces
people
to
start
specifying
their
extensions
and
even.
I
I
E
Just
I
want
to
just
like
pose
a
I
guess,
a
bit
of
a
question
to
the
the
people
who
don't
want
to
ship
it
by
default.
I
am
confused
right
if
we
ship
it
by
default.
I.
Think,
like
Jordan
said
this
earlier,
you
can
still
write
all
of
your
things
in
full
paths
which
will
not
use
extension
resolution.
It
won't
use
folder
resolution
because
you've
manually
specified
those
and
then
people
who
still
want
to
use
the
feature
can
still
use
the
feature.
I'm
curious.
Why
that's
not
an
acceptable
like
place
to
leave
this
like
what?
A
So
guess
the
biggest
thing
for
me
is
dependencies
in
the
ecosystem
and
what
is
considered
best
practices.
So
as
it
is
right
now,
you
know
people
rely
on
not
having
extensions
and
I
would
I
think
it's
safe
to
say
that
the
majority
of
dependencies
and
the
majority
of
specifiers
that
are
passed
to
a
require
do
not
have
extensions
in
them
now
for
bear
specifiers,
that's
fine,
but
for
internal
specifiers
that
could
become
problematic
or
we're
talking
about
wanting
to
have
an
ecosystem
of
modules
that
can
be
shared
across
environments
and
across
runtimes
I.
A
A
Without
requiring
a
build
step,
if
we
make
the
default
that
that
is
not
possible,
people
can
still
and
I
think
we
should
make
it
really
easy
through
a
flag
or
through
a
loader
or
through
the
package.json,
to
enable
this
feature.
But
it
needs
to
be
opt-in
and
explicit
that
you're
opting
out
of
that
of
that
behavior.
If
you
are
opting
into
that
behavior.
If
it's
an
explicit
opt-in,
it's
something
that
the
application
level
can
easily
happen
to
make
application
code
better.
But
will
it
will
encourage
library
authors
to
make
portable
code
okay.
G
J
G
A
Import
maps
are
not
being
designed
for
you
to
create
import
map
key
for
every
single
file
in
your
entire
module.
That
expands
exponentially
to
the
number
of
modules
in
which
you
have
in
your
tree.
Import
maps
are
generally
supposed
to
be
for
one
their
import.
Potentially
a
couple
bear
imports,
but
not
for
every
single.
E
G
If
you
import
maps,
isn't
being
designed
for
this,
and
given
that
that's
something
that
you
currently
would
need
for
CGAs
patterns,
then
maybe
that's
a
failure
in
the
import
map
design
that
needs
to
be
addressed.
The
solution
isn't
to
node.
The
solution
is
restrict
node.
Excuse
me:
the
solution
is
to
improve
the
import
Maps
designed
to
make
that
organ
on
ik.
E
Gus,
did
you
have
anything
else
to
add,
or
should
we
of
one
more
thing
if
it's
just
comes
down
to,
like
my
opinion
of
what's
good
in
node
versus
your
opinion
of
what's
good
and
node
and
like
the
users
like
people's
opinions
of
what's
good
in
node,
and
you
know,
I'm,
not
I,
don't
think
I'm
ever
going
to
my
mind
on
this
and
I
assume
others
aren't
going
to
change
their
minds.
I
think
the
least
destructive
option
is
the
one
that
enables
the
most
use
cases
by
default,
which
would
be
leaving
it
in.