►
From YouTube: Node.js Foundation Modules Team Meeting 2019-03-13
Description
A
We
are
now
live
on
YouTube
with
the
March
13th
2019,
almost
pi
diet,
Pi
Day,
edition
of
the
newest
modules
team.
We
are
joined
by
myself
and
eight
other
hyper
Li
involved.
Individuals
in
this
modules,
discussion
just
enough
to
have
quorum
and
the
main
kind
of
subject
and
we'll
be
going
over
today
is
making
sure
they're
all
on
the
same
page
about
what
we're
gonna
upstream
to
node.js
core
real,
close,
so
kind
of
just
jumping
right
into
the
agenda.
The
first
thing
that
we
wanted
to
kind
of
go
through
here
is
a
handful
of
NPR's.
A
We've
got
PR
date
that
are
open,
that
we
just
need
to
kind
of
get
consensus
that
we
can
land.
They
all
appear
to.
You
know
the
have
approvals
upstream.
The
first
is
number
58,
which
is
CPC
refactoring,
ensuring
avoiding
duplicate
packaged
cash.
I
just
dropped
a
link
to
that
into
the
chat.
I
believe
that
this
was
broken
out
of
number
33
I
believe
it
was
either
Jordan
or
jdd
who
requests.
B
A
A
Okay,
cool
so
we'll
go
ahead
and
land
58
the
next
one
that
we
can
and
I
don't
know
if
anyone
can
help,
but
if
anyone
can
help
with
notes,
that'd
be
really
appreciated.
The
next
thing
we
have
is
number
53,
which
is
at
experimental,
JSON
loader.
That's
my
pull
request.
This
is
based
on.
You
know
like
what
is
currently
being
specified
in
the
what
working
group,
the
HTML
spec
to
what
JSON
modules
could
potentially
look
like
in
the
browser.
A
It's
gone
through
review
from
a
handful
of
you
folks,
the
most
important
bits
about
it
is
that,
like
it
does
the
parse
during
the
load
phase,
and
then
it
shares
the
common
J's
cache.
So
I
believe
that
this
has
all
the
behavior
that
people
were
expecting.
We
have
tests
that
are
documenting
it.
I
think
it
would
be
really
cool
if
we
could
actually
I
know.
A
A
I'm
not
hearing
any
objections,
so
I
will,
unless
anyone
says
anything
in
the
next
three
seconds,
I'm
just
going
to
make
a
note
that
we
can
go
ahead
and
land
it
last.
One
that
we
have
here
has
been
open
a
little
bit
longer.
It's
number
37
and
it's
warned
about
type
with
shebang,
and
this
is
I
believe
a
doc
update
from
Yan
cremes
yan.
Are
you
on
the
call
right
now?
A
B
A
So,
let's
punt
on
this
and
come
back
to
it,
then
then
the
next
one
that
we
have
is
we
have
two
PRS
that
don't
currently
have
consensus.
One
is
the
scopes
type
CPP
like
refactoring
and
the
other
one
is
the
ESM
format
avoid
reading
package.json
when
extension
is
ambiguous.
I'm
gonna
go
out
of
order
here,
number
33,
which
is
parsing
things
when
they're,
not
ambiguous,
Jordan
I
believe
that
you
were
one
of
the
people
who
are
objecting
to
that.
A
B
I
think
it
because
it's
premature
optimization,
if
we
did
that,
then
what
we
would
see
is
a
larger
than
normal
speed
decrease
when
we
added
those
other
features
and
I
don't
want
that
to
be
a
distraction
in
the
discussion
of
what
are
the
stuff
we
want
in
package.json,
so
I
think
I
think
that's
something
that
this
is
something
that
we
will
likely
not
want
to
land
and
at
the
point
where
it
is
and
it
will.
It
is
a
forever
unobservable
optimization.
We
could
just
squeeze
it
in
to
any
minor
okay.
A
Okay,
so
we're
gonna
go
ahead
and
not
land
whoever's,
taking
notes
that
was
never
mind.
You
got
it
in
the
right
order.
Okay,
cool
and
I'm.
Just
gonna
go
ahead
and
remove
the
agenda
label
from
this,
and
we
can,
you
know,
add
it
back
to
the
agenda
at
a
later
point
when
we're
ready
to
revisit
it.
The
next
one
that
we
have
is
scoped
typed,
C++,
refactoring
Jordan.
Is
this
the
one
that
you
were
just
talking
about
regarding
whether
type
is
a
mode
or
not
and
having
to
clarify
some
of
that?
Yes,.
B
So
if
this
is
57
I'm
yeah,
then
57,
would
you
like
to
that
discussion?
Sure
it
seems
like
there
has
been
some
confusion
to
kind
of
different
understandings
about
the
type
flag.
One
understanding
is
that
when
it
is
set,
all
Jas
files
are
interpreted
as
ESM
like
when
the
type
is
set
to
ESM
or
whatever,
when
the
type
is
set
to
commonjs.
B
All
ejs
files
are
interpreted
as
commonjs,
and
the
other
viewpoint,
which
is
the
one
I
have
held,
is
that
its
intention
was
to
solely
be
a
means
to
specify
the
parsing
goal
for
the
entry
point,
the
file
that
you're
running
note
on
so
regardless
of
how
it
was
communicated
or
why
there's
misunderstandings?
We
need
to
get
clarity
on
which
of
those
two
things
it
is,
it
should
be,
and
the
my
general
position
is
that
files
with
an
extension
already
have
an
explicit
indicator
of
what
they
how
they
should
be
parsed,
that's
the
extension.
B
If
they
have
a
package.json
available,
then
that
package.json
will
have
mechanisms
to
alter
that.
You
know
to
give
a
different,
explicit
signal
and
which
case
that
would
take
precedence,
and
that's
fine,
but
the
only
time
where
an
explicit
signal
is
actually
needed
is
with
a
one-off
script
that
lacks
a
package.json
or
with
a
file
that
doesn't
have
an
extension
and
similarly
doesn't
have
a
package.json
to
the
could
remap
it.
So
to
me
it
doesn't
seem
I,
don't
understand
the
benefit
or
sustainable.
C
B
Thing
or
standard
in
thank
you,
our
eval,
so
so
like
in
all
those
cases.
We
need
in
a
way
to
pass
an
explicit
signal.
If,
if
type
is
a
mode,
we'd
need
a
different
one,
I
think
to
just
specify
that
and
I,
but
in
general
I,
think
I
kind
of
object
to
the
concept
of
a
mode
MJS
is
es
m.
That's
it.
J
s
is
common
j
s.
Always
people
should
be
able
to
alter
those
things
and
have
any
extension
parsed
as
any
particle.
They
want.
B
That's
fine,
but
the
defaults
are
the
defaults,
that's
what
they
are
and
they're
there
for
a
reason
and
that's
what
it
means
and
the
concept
of
a
mode
is
like,
like
there
just
shouldn't
be
a
mode
where
J
s
is
something
else
by
default
than
you.
Then
then
comma
J
s,
because
that's
what
it
is
and
that's
my
thoughts.
A
Okay,
so
just
for
what
it's
worth,
everyone
I
want
to
extremely
timebox
this.
So
if
everyone
can,
please
keep
what
they're
saying
to
a
minute.
Just
I
have
two
very
quick
clarifying
questions
before
we
get
into
the
discussion.
Guy
is
the
person
who
implemented
this
change?
Is
there
any
functional
changing
in
this
pull
request
like?
Is
that
updating
the
behavior?
What
is
the
current
behavior
on?
What
is?
How
is
that
behavior
changed
by
this
pull
request?
A
C
I
think
that
the
use
cases
are
a
great
starting
point,
as
jordan
was
mentioning.
So
if
you
have
a
JS
file
that
doesn't
have
a
package.json
or
an
extension
of
file,
and
you
want
to
indicate
that
it's
a
module,
then
that's
the
use
case
for
type.
The
problem
is:
what
happens
if
that
file
has
a
relative
import
to
sibling
in
the
same
folder?
That's
also
a
JS
file
and
then
suddenly
that's
gonna
break.
C
This
type
has
effectively
overridden
all
the
other
rules.
So
what
this
means
is
that
if
another
file
were
to
import
your
entry
point
as
a
dependency,
it's
getting
a
different
interpretation
of
that
file.
Because
it's
already
kept
your
registry,
then
it
would
have
if
it
wasn't
that
entry
point,
so
the
idea
was,
should
we
rather
think
of
the
type
as
being
the
same
as
putting
a
package.json
in
the
folder
of
the
file
that
contains
that
type.
C
So
it's
creating
a
scope
in
that
folder
and
then
all
the
siblings
are
gonna
behave
as
expected,
and
that
way
it
really
is
a
type
because
we're
just
typing
the
folder
of
the
entry
points
and
it
described
as
like
a
virtual
package
JSON
as
if
there
was
this
virtual
package,
JSON
folder
with
this
type
and
then
the
the
type
conflicts
and
everything
else
kind
of
gets
worked
out
around.
That
is
that
the
current
behavior
or
is
the
current
behavior
that
it's
only
the
edge
the
current
behavior.
C
A
D
I
guess
it's
it's
sort
of
sort
of
art,
even
so
I'm
just
gonna,
say
basically
like
type,
is
a
really
blunt
tool
to
use
and
basically
the
the
case
here,
that's
being
considered,
which
is
a
file
that
has
been
affected
by
type
importing
another
file.
I
mean
you're
out
like
at
the
point
that
you
have
a
you
know:
a
random
file
on
your
computer
that
you
need
to
tell
know
the
type
of
then
there's
another
random
file
next
to
it.
But
it's
importing
I
think
at
that
point.
D
You're
gonna,
you're
gonna
project
and
you
should
be
using
a
package
Jason
like
that.
It's
like
they
like
from
a
design
standpoint,
I
think
we
should
be
telling
people
at
that
point
that
they
need
a
package.json
file
and
that
that
way,
the
CLI
flag
becomes
a
very
more
of
a
precise
tool
that
you
can
use
to
override
a
specific
file.
And
so
we,
then
that
in
that
way,
are
able
to
support
both
cases.
A
I
do
think
that
you
know
the
flip
side
of
it
where
it's
like.
Not
an
entry
point
like
where
you're
thinking
that
more
is
like
flagging
the
entry
rather
than
flipping
the
mode
is
still
useful.
I
find
it
a
little
bit
more
confusing,
but
I
do
think
that
at
the
very
least,
if
we,
if
we
land
on
that
developer
experience,
that
we
should
probably
not
have
the
command
line
flag,
be
type
because
that's
inconsistent
with
the
expected
behavior
of
putting
type
in
the
package.json.
A
E
E
The
syntax
of
this
file
will
behave
as
it's
an
ESN
module
that
does
not
really
import
in
come
next
to
it
and
I
think
the
distinction
is
is
very,
very
big
for
a
feature
that
someone
would
want
to
use
from
the
command
line
as
in
it's
accessible,
irrespective
of
what
exists
around
it.
It's
an
overload.
So
that's
my
opinion.
B
Importing
something
doesn't
mean
anything
about
the
thing
you're
importing,
because
you
could
be
importing
a
wasm
file
or
an
HTML
file,
so
I
think
it's
whether
something
is
a
one-off
script
or
not
like
I.
Think
conceptually,
you
wouldn't
want
to
import
something
else,
but
like
the
fact
that
you're
importing
something
doesn't
say
anything
about
the
file
format
or
the
extension
that
you're
trying
to
import
because
we
have
more
than
just
ESM
tjs.
That
was
what
I
wanted
to
know.
A
F
Hey
yeah
I
actually
was
tripped
up
over
this
cuz
I
was
implementing
it
in
my
own
implementation,
and
I
had
assumed
that
the
typed
flag
was
just
another
way
to
do.
The
type
functionality
of
the
package.json
field,
so
I
was
mminton,
anticipate
that
it
was
actually
different
and
only
found
that
out
by
looking
through
the
list
of
open
pr's
to
review.
So
for
me,
yeah
I
kind
of
side
with
miles,
but
it's
like.
F
If
you
have
it,
it
should
should
mimic
the
the
thing
that
has
already
been
done
so
like
the
package
that
JSON
type
so
the
like,
creating
the
virtual,
the
virtual
scope
or
something
that's
fine
with
me.
That's
how
I
ended
up
doing
it
on
my
end,
basically,
if
you
passed
the
type
and
as
a
command-line-
and
it
doesn't
have
a
package
that
JSON
specified,
then
it
chooses
that
to
run
as
if
it
was
in
specified
with
that
type
else.
It
looks
for
like
an
environment
variable,
because
I
allow
that
too
so
cool.
G
I'll
try
to
be
quick
this.
Basically,
if
we
don't
have
it
be
this
type,
meaning
the
same
as
the
type
field
and
then
basically
type
Eagles
Auto
isn't
possible
other
than
for
like
a
single
file,
project
and
I.
Don't
think
that's
very
useful
as
a
feature
and
I
haven't
heard.
Anyone
say
why
we
shouldn't
just
make
this
be
the
same
as
the
type
field
I
understand.
Maybe
that
wasn't
what
people
understood?
G
I'm,
sorry
for
the
misunderstanding,
but
if
it
applies
to
the,
if
it
applies
like
this
type
field
or
it's
a
scope,
then
it
still
solves
the
one-off
file
case,
but
it
also
allows
these
use
cases
like
you
just
check
out
someone's
old
project
and
they
haven't
renamed
their
files
to
MJS
and
they
haven't
added
a
type
feel,
but
you
can
still
try.
Hey
Ken
node
try
to
execute
this
as
ESM,
let's
find
out
without
having
to
like
edit
files
to
do
so
so
I
mean
I
feel
like
unless
there's
a
reason
not
to
do
this.
B
A
Taking
it
to
a
vote
before
we
get
to
that
and
before
we,
you
know
state
objections
or
votes
or
anything
I'd
like
to
make
a
proposal,
and
you
know
perhaps
this
can
meet
people
where
we
are.
We
have
an
implementation
that
calls
it
type
right.
Now
we
literally
wanted
to
open
a
pull
request
like
this
week,
if
possible,
I
think
that
the
general
consensus
so
far,
there's
kind
of
two
things
whether
explain
at
all
but
like
what
the
behavior
should
be.
A
C
A
H
B
F
H
F
With
the
API
design,
so
when
I
say
something,
that's
wrong,
take
it
with
some
weight
that
it
comes
with
my
experience
and
in
this
case
I
I
disagree
with
it.
So
I'll
just
say:
I
I,
don't
think
being
a
different
name
is
better
than
it
being
the
same
name
and
having
completely
different
functionality.
So
that's
a
win,
but
ideally
I,
wouldn't
I
mean
to
me.
This
seems
like
this
is
gonna,
be
a
thing
that
won't
be
used.
F
B
G
Wait
can
I
get
an
answer
to
my
question.
Thank
you.
It
seems
like
we're
doing
we're
going
through
all
this
trouble,
rather
than
just
approving
this
PR,
just
because
people
are
opposed
to
letting
the
user
override
the
files
like
you
have
to
edit
it,
instead
of
just
passing
a
flag.
What
why
is
that
important?
Why
do
we
want
that?
G
B
B
So
could
be
a
flag
sure,
I
guess
I
I
am
concerned
about
a
world
where
someone
everyone,
just
instead
of
invoking
node
in
folks,
node
ESM
in
das
mode
and
kind
of
paves
over
all
the
important
compatibility
reasons
why
MJS
exists.
I
don't
want
that
to
be
easy
to
do,
even
though
you
can
obviously
do
it
with
a
loader
at
some
point
you
know.
E
Your
interrupt,
but
I
think
that's
like
really
patting
it
for
someone
who
doesn't
know
how
to
invoke
a
command
line
flag
or
make
sure
that
it's
not
invoke,
if
you
prefer
always
to
run
with
the
command
line
flag
on
and
that's
useful
for
you,
you
will
get
the
results
you
expect.
If
you
don't,
then
you
will
get
a
bad
result
and
you
will
fix
your
scripts
or
whatever
you
use
to
invoke
with
the
command
line
flag
always-on.
E
Accordingly,
it's
it's
up
to
people
to
actually
make
sure
they
do
the
right
thing
when
they
use
the
right
thing,
but
revisiting
mode
again.
I
think
we
are
going
to
be
creating
these
circles
around
things
that
seem
to
have
some
consensus
and
some
disagreement,
but
everything
has
some
consensus
and
some
disagreement
and
we're
all
accepting
that,
because
we're
trying
to
deliver
at
this
point.
A
So
Jordan
I
I
do
genuinely
believe
that
keeping
it
as
type
and
keeping
the
behavior
equivalent
to
the
package.json
is
a
much
better
approach.
It's
one
less
thing
that
people
need
to
learn
and
know
the
difference
of
and
I
am
genuinely
concerned
that
if
we
introduce
the
separate
entry
point
which
has
its
own
specific
behavior
is
like
a
whole
other
thing.
We
need
to
document
a
whole
other
thing
that
people
need
to
learn
and
I
genuinely
don't
find
it
particularly
a
particularly
relevant
or
useful
feature.
A
B
B
I
see
it
either
we
revert
it,
we
rename
the
flag
or
like
we
aren't
going
to
be
able
to
upstream
soon,
because
we
have
not.
We
don't
have
the
time
to
reach
consensus
on
a
mode
which
is
not
something
we
have
consensus
on.
Okay,
any
of
those
are
fine
with
me
I,
just
I
I,
don't
I
think
it's
fine
to
rename
the
flag
and
then
just
drop
it
later.
If
we
go
with
a
mode
but
I,
don't
think
we
have
I,
don't
think
an
urgent.
A
G
B
Mean
in
general
I
think
you
I
think.
If
pull
requests,
land
and
the
scope
of
the
changes
wasn't
properly
discussed,
it
is
reasonable
to
just
revert.
It
I
think
that's
the
obligation
of
the
PR
author
to
be
sure
that
all
of
the
changes
made
are
discussed.
I
know
I,
don't
necessarily
need
it
reverted,
but
I
think
that
if
we
can't
agree
on
how
to
proceed
now,
then
that's
a
valid
option.
Jordan.
A
B
That
on
the
PRI,
I
explicitly
asked
and
was
told
it
was
just
the
entry
point.
So
we
could
have
had
this
discussion
a
week
or
two
ago,
if,
like
you
know
whether
it
was
a
mistake
or
disingenuous
is
irrelevant,
like
I
was
given
an
answer,
that
it
was
only
for
the
entry
point
and
it
turns
out
that
that
may
not
have
been
the
intention.
So
we
have
you
know:
I've
we've
been
deprived
of
like
weeks
of
discussion
time
on
it.
A
I,
don't
think
it's
oh
well,
I
think
we
have
a
majority
of
people
in
this
room
that
think
that
a
certain
behavior
seems
reasonable
and
we
can
change
the
flag
and
remove
it
just
as
easily
to
change
it
later
and
your
seem
to
be
suggesting
something
as
an
alternative
that
multiple
people
are
objecting
to.
So
I
really
I
would
appreciate
if
you
would
be
willing
to
concede
on
this
under
the
precipice
that
this
will
be
completely
revisited
moving
forward
and
we
will
spend
the
time
talking
on
it.
I
I'm,
not
gonna,
concede
on
this.
C
Guy's
PR
guys
I
know
it
sounds
like
children
is
the
the
luck
to
hear,
but
this
has
always
been
something
that
has
never
seemed
particularly
clear
to
me
either
and
I.
Think
the
more
elegant
behavior
is
for
the
type
to
work
in
a
scope
level.
Definitely
but
I,
don't
think
it's
obvious
either
and
I.
Don't
think
that
I
don't
feel
like
there's
an
obvious
answer
here:
either
I
do
like
explicitness
of
a
top-level
flag,
so
I
have
no
idea
which
which
I
prefer
you
haven't
their
opinion.
C
But
if
that's
the
case-
and
we
as
a
group
have
no
opinion,
then
surely
what
is
the
harm
in
renaming
the
flag?
And
then,
if
we
decide
to
go
back
with
the
scope,
we
can
just
introduce
a
type
flag
and
remove
the
the
format
fire
Jeffrey.
Maybe
if
you
could
explain
your
objection
to
that.
G
C
E
Well,
you
don't
get
the
right
data
if
people
expect
it
not
to
work
like
the
type
flag.
If
you
want
to
get
data
to
validate
something,
you
have
to
make
people
assume
the
right
thing
when
they're
using
it,
you
will
not
get
data
for
people
telling
you.
Oh,
we
didn't
use
X
flag.
That
did
something
he
didn't
really
care
for.
Okay,.
A
That
we're
in
I'm
sorry
I've
got
to
just
stop
this
for
35
minutes
into
the
meeting.
We
have
a
ton
of
other
stuff
to
talk
about
I'm
gonna,
just
call
two
things
really
quickly
to
see
if
we
can
reach
consensus
on
them
and
if
not
look,
we're
just
gonna
push
forward
with
what
we
have
in
there
right
now
and
see
what
happens
because
we
managed
to
reach
consensus
on
what's
in
there
today.
A
And
does
anyone
object
to
landing
guys
current
pool
request,
yeah?
Okay?
So
let's
just
leave
it
exactly
the
way
it
is
right.
Now
we
may
get
some
issues
saying
hey.
This
is
confusing
and
let's
talk
through
it
properly
and
iterate
forward.
You
know
it's
I
think
that
what
we
have
right
now
is
confusing
is
the
worst
for
everyone.
A
Okay,
cool
because
we're
it
doesn't
seem
like
we're
gonna
reach
consensus
today
and
we're
just
gonna
we're
talking
in
circles
a
bit
okay.
So
you
know
another
thing:
fun:
to
talk
about,
discuss,
CJ
s,
Jordan
put
this
on
the
agenda.
I
would
like
to
time
backs
it
to
six
minutes.
I
can.
If
this
is
possible,
I
would
love
to
very
quickly
just
say
why
we
need
CJ
s
when
we're
in
the
module
mode,
there's
no
way
to
import
common
J
s
without
that
extension.
B
If
you,
if,
if
you
have
sugar,
that
only
remaps
the
J
s
extension
and
doesn't
create
a
new
one
for
common
jest,
then
you're
right,
there's
no
way
to
have
common
j
s,
but
I'm
not
a
fan
of
modes
and
in
the
existent
with
the
existence
of
extensions
map
or
something
similar.
You
can
make
any
extension.
You
want,
you
know,
dot,
common
or
something
be
calm
and
j
s,
and
that's
not
really
an
issue
so
I
think
like
until
we
have
a
really
strong
consensus
on
on
modes
and
especially
a
strong
consensus.
We.
A
Had
modes
it
landed,
I'm,
saying
like
it's
in
there,
it
wouldn't
have
landed
if
we
didn't
have
a
degree
of
consensus
and
the
current
workflow
that
we're
talking
about
upstreaming
does
not
work.
Without
this
doesn't
mean
we
can't
land
it
something
in
the
future
that
removes
it,
but
removing
it
now
essentially
makes
the
developer
experience
of
what
we're
shipping
upstream,
not
really
usable.
B
So
by
saying
that
miles,
you're
saying
that
the
concession
that
I
made
on
that
PR
to
allow
it
to
land
is
something
I.
Probably
shouldn't
have
done.
I
should
have
strongly
more
strongly
objected
and
stuff
with
that,
so
that
will
inform
future
decisions
because
I
explicitly
said
this
is
something
that
I
think
shouldn't
exist
when
we
have
extensions
maps.
Yes,.
A
B
A
For
what
it's
worth
as
it
works
right
now
with
Commons,
yes,
you
can
require
something
with
the
CGS
extension
and
it
just
works
in
node
unflagged.
Yes,
since
when
it's
always
because
if
you
require
an
extension
that
doesn't
exist
in
the
lookup,
it
falls
back
to
common
jeaious
by
default,
so
a
dot
cj's
extension
already
works
backwards,
compatible
without
any
changes
that
we
do.
People
can
already
write
that
today
and
will
just
work
yeah.
It's
super
cool.
B
B
A
A
The
only
thing
we
have
in
there
is
that
one
connection
that
connects
CJ
s
to
the
common
J's
translator,
but
that
can
be
overridden
by
the
export
Maps
that
you're
talking
about
the
we
do
not
have
that
behavior
right
now
in
our
loader,
where
an
arbitrary
extension
will
become
something
else,
I'd
have
to
double-check
what
what
works
and
what
doesn't
work
right
now.
I,
actually
think
that
in
the
common
J's
mode
it
will
fall
back
to
common
J
s
and
in
the
ESM
mode
it
will
fall
back
to
es
m.
B
B
It
is
I
think
that
that
it
would
be
unfortunate
that
the
it
is
useful
and
necessary
to
add
introduced
a
new
extension
for
a
new
parsing
goal.
That's
what
they're
for
CJ
s,
isn't
a
new
parsing
goal
and
I'm
concerned
about
creating
any
expectation
in
the
ecosystem
that
CJ
s
belongs
in
a
dot
C
J's
file,
because
the
precedent
that's
long
been
established
is
that
CJ
s
is
in
the
dot
J's
file,
so
I'm,
but.
A
There's
there
is
no
way
to
have
an
es
M
mode
where
we
import
J's
files,
where
we
make
it
easy
for
people
to
import
common
j
s
from
the
same
scope
without
requiring
a
whole
bunch
of
extra
metadata.
Without
that
extension,
that
extension
removes
all
of
the
need
for
that
extra
code.
I'm
not
saying
that
export
maps
are
not
useful
in
necessary
and
something
that
we
should
have
on
top
of
it.
But
people
shouldn't
have
to
opt
in
to
import
Maps
just
because
they
want
to
have
J
s
become
es
M.
E
It
would,
in
effect,
if
you're
working
with
common
J's
files
purely
and
require,
but
it
will
just
make
it
more
problematic.
I'm
not
mistaken.
Can
somebody
verify
you
know
if
it's
going
to
be
more
problematic
to
work
with
comma
J
s
and
an
es
M
mode
if
we
do
remove
CJ
s
as
a
privileged
or
a
predetermined
or
predefined.
B
D
D
Said
I
was
kind
of
uncommitted
to
this.
This
discussion
either
way
until
the
the
notion
came
up,
which
I
guess
is
the
root
usage
of
CJ
s
which
I
didn't
consider
before,
which
is
basically,
if
you
want
to
use
if
you
hit
like
hate
MJS,
so
much
that
you
want
to
use
J
s.
But
you
also
therefore
need
to
rename
all
of
your
common
J's
files.
Why
not
just
rename
your
J
s
files
to
MJ
s,
I'm
confused
on
that
front
like
what?
What
what
the
like
I
like
on
the
surface?
G
I
mean
there
are
people
who
need
to
use
J
s
for
various
reasons,
as
I've
said,
like
CoffeeScript
needs
to
use
J
s,
and
so,
if
we
need
to
mix
you
know,
files
that
are
es
m
and
files
that
are
coming
to
us.
That's
is
the
only
option
if
you're
forced
to
use
js4
es
m
for
other
reasons,
because
your
build
tool,
because
your
transpiler
etc.
Then
this
gives
you
the
option
of
still
mixing
them.
The
same
way
that
MJ
s
and
J
has
to
your
building
somehow
magically
aware
of
a
dot.
G
A
F
Hi
yeah
I
I
was
just
gonna,
say
I,
like
the
symmetry
of
it.
If
we
have
MGS
CGS
works,
there's
also.
A
lot
of
people
want
to
see
J
s
just
JavaScript
in
general,
a
future
facing,
and
so
when
you're
dealing
with,
like
echo
modules,
you
want
to
be
able
to
use
j/s
and
they
see
something
like
common
JSA's
legacy
right
and
so
then
the
the
toggle
there
is
that
there'll
be
less
and
less
common
Joe.
Yes,
so
the
wort
of
the
extension
grows
less
over
time.
F
B
I
went
real,
quick
I
really
am
NOT
a
fan
of
keeping
it.
I
would
like
to
find
it
and
I'd
like
to
find
another
solution,
and
Wes
already
pointed
one
out.
All
you
have
to
do
is
put
your
files
in
a
different
view.
Common
gesture
files
in
a
different
folder
add
a
package.json
in
there
and
it
works
a
little.
B
A
Disagree
with
that
assessment,
the
problem
that
we're
gonna
have
right
now
Jordan
is
you
know:
we've
had
a
couple
weeks
since
this
has
come
out.
We
have
no
other
code,
that's
sitting
there
with
an
alternative
approach
aside
from
I
guess
what
you're
saying
is
that
we
remove
that
CJ
s
lag.
That's
in
there.
Does
anyone
object
to
removing
the
current
reference
to
CJ
s.
G
Like
that,
the
whole
point
of
like
being
able
to
be
like
node
filed
at
MDS
and
have
it
explicitly
start
to
start
your
app
as
MDS
and
versus
node
filed
at
CGS
and
does
the
same
thing.
There
is
value
in
that.
That
means
that
we
can
some
day
flip
the
default
where
the
default
is
ESM,
etc,
like
if
we're
giving
users
to
explicitly
say,
via
extension,
that
this
is
the
SM.
We
should
give
them
the
same
way
to
explicitly
say
that
this
is
kind
of
Jackass.
Okay,.
A
A
Does
anyone
today
object
to
sticking
with
what
we
have
right
now,
so
we
can
move
forward
under
the
you
know,
the
hindsight
that
both
CJ
SN
type,
it's
similar
to
type,
is
one
of
the
main
things
that
we're
going
to
be
working
on
after
we
upstream,
as
figuring
out,
you
know
if
we
want
a
proposal
that
doesn't
involve
it,
how
we
do
that?
Does
anyone
object
to
just
kind
of
continuing
forward
with
what
we
have
today?
You.
A
If
you
don't
have
a
proposal
that
we
have
consensus
with,
we
have
code,
that's
on
master
right
now.
The
only
alternative
that
we're
talking
about
is
a
deadlock,
and
this
is
now
the
second
time
on
this
call
in
which
you're
forcing
a
deadlock
and
bringing
alternative
solutions
here.
So
I
really
don't
know
what
to
do
with
that.
B
B
A
A
Extensions
map
that
could
work
right
off
the
bat
would
be
like
a
package
dot
extensions
that
has
a
combination
of
on
one
hand,
the
extension
that
you're
mapping
and
then
the
mode
that
you're
mapping
it
to,
and
we
have
like
a
handful
of
translators
that
currently
exist
that
we
can
map
it
to.
But
that's
not
a
proposal
that
we
have
written
up.
That's
not
an
implementation
that
we
have
done.
That
was
written
up
the.
I
Like
also
on
the
note
of
like
loaders
right,
it's
kind
of
unclear
to
me
really,
if
or
when
loaders
are
actually
going
to
happen,
because
we've
discussed
them
in
so
many
forms
over
the
years
and
there's
all
still
seems
to
be
a
lot
of
confusion
and
what
we
can
or
what
we
would
want
to
do,
or
what
like
people
would
really
how
they
used
or
anything
like
I.
Don't
I,
don't
see
that
and
just
like
magically
solving
itself
either
ones
once
we
have
like.
You
know
this
other
stuff
sort
of
solved,
yeah.
A
B
There
is
nothing
that
requires
someone
to
write
code
to
share
an
objection
or
have
an
opinion
so
and
I
content
that
continued
implication.
The
the
implementation
is
irrelevant.
We're
talking
about
decisions,
so
I
realize
in
implementation
is
relevant
for
meeting
and
reaching
a
timeline,
but
it
is
not
relevant
for
discussing
what
people
object
to
and
what
they
put
what
they
agree
to
and
what
consensus
we
have.
B
Yes,
I,
like
I,
filed
an
issue
for
the
extensions
map
because,
like
I
finally
found
the
time
to
do
it,
but
I've
mentioned
it
and
it's
a
pretty
straightforward
thing
that
didn't
even
really
require
write-up.
It's
been
mentioned
for
like
a
year
and
a
half
so
like
at
some
point.
They
if
the
responsibility
does
not
only
fall
on
the
objectors.
If
someone
wants
to
ship
something
someone's
objecting
to
the
person
who
wants
to
ship,
it
has
to
do
the
work
to
make
those
people
happy.
B
That's
how
consensus
works
so,
like
I
have
been
talking
about
extensions
Maps
as
a
mechanism
for
a
year
or
two
a
year
and
a
half
or
whatever
it
is
a
year.
So,
if
folks
want
to
ship
the
type
flag
in
the
ways
that
they
want-
and
my
objections
are
I
want
the
extensions
Matt
first,
they
can
implement
that
and
they
also
haven't
so
is
like
please
stop
framing.
This
is
this
is
just
me
objecting
and
nothing
else
and
like
I'm,
not
writing
code,
because
that's
not
a
requirement
here.
I.
A
B
F
B
The
entire
thing
is
an
enhancement.
We
could
remove
it
right
now
and
we
still
are
shipping
and
implementation.
People
just
have
don't
have
the
freedom
to
alter
their
yeah
people.
Just
don't
have
the
freedom
to
alter
their
file.
Extensions
they'd
be
forced
use.
The
defaults,
that
is
the
majority
of
the
implementation
altering
the
defaults,
is
an
enhancement
on
top
that
we
could.
You
know
that
I
think
people
should
be
able
to
have,
but
but
removing
that
doesn't
make
the
implementation
useless,
but.
B
That
was
what
what
I
explicitly
said
is
something
I
think
we
might
want
to
do
once
we
had
extensions.
Maps
went
in
the
comment
on
the
pr
for
it
where
I
said,
but
we
can
go
ahead
anyway,
because
we
can
remove
it
later.
So,
yes,
that's
something
I
think
is
still
on
the
table.
B
A
B
Well
again,
I'm
not
proposing
that
we
remove
the
type
field
from
package.json
right
now.
That's
it's
not
time
for
that
yet,
and
that
I
explicitly
said
it
shouldn't
block
up
streaming.
I
am
saying
that
that
the
its
presence
in
the
implementation
does
not
imply
consensus
for
it,
and
it
should
that
we
should
be
careful
about
letting
it
accelerate
other
ideas
without
understand
that
it
may
not
have
full
consensus
eventually,
because
our
goal
is
not
just
upstream.
B
So
I
this
is
I,
understand
that
it's
frustrating,
if
I
like
I'm,
about
to
say
a
suggestion,
but
not
I'm,
not
gonna
have
the
time
to
work
on
it
like
to
do
it,
so
someone
else
would
have
to
do
it
and
that's
must
be
frustrating
for
everyone
to
hear
and
I'm
sorry
in
advance.
What
I
would
like
to
see
is
the
extensions
map
go
in,
because
then
your
statement
earlier
that
CJ
s
is
the
only
way
to
you
know.
B
Organ
ama
CLE
have
CGS
when
your
type
is
es
m
that
no
longer
applies
and
then
the
extension
is
no
longer
as
critical,
because
then
people
can
you
do
it
with
an
extensions
map
and
then,
if
it
might
at
that
point,
having
type
es
m
be
sugar
for
a
specific
extensions
map
which
includes
the
CJ
s.
Extension
I
have
to
think
a
little
more
about
it,
but
I
think
I
find
that
a
lot
less
problematic
than
the
current
scenario
and
I
find
specifically
I.
B
Think
that
that's
that's
the
more
general
and
most
flexible
configuration
that
provides.
It
does
not
force
any
opinions
about
file
extensions
on
anyone.
It
just
says:
here's
the
defaults
make
them
into
whatever
you
want
for
your
package,
and
that
makes
me
feel
better
about
shipping
the
type
sugar,
because
then,
instead
of
us
saying
this
one
extension
pairing
you
know
flip
is
magic.
We're
saying
this
is
the
one
that's
most
common,
but
you
can
do
any
of
them
that
you
want
and
then
it
feels
less
like
us
blessing
one
specific
pattern.
B
So
really
that's
what
I
would
like
to
see
is
the
extensions
map
to
go
in
and
then
the
discussions
we
can
have
about
types
and
modes
and
stuff
are
you
know
in
virtual
package.json
or
whatever
I
think
are
gonna,
be
a
lot
more
pleasant
and
smooth,
because
at
that
point
there
we're
talking
about
sugar
and
refinements
on
top
of
the
general
flexible.
Mostly,
you
know
maximally
flexible
ability.
A
C
It's
it's.
It's
saying
that
some
kind
of
technical
foundation
comes
before
the
usability
disk,
which
is
absolute
rubbish.
That
is
not
an
argument,
because
it's
all
about
the
user
experience,
and
that
is
what
we're
designing
it
doesn't
matter
if
there's
some
more
foundational
way
of
defining
extensions,
what
matters
is
that
users
are
able
to
achieve
what
they
want
to
achieve,
and
that
is
what
we're
designing:
we're,
not
designing
the
perfect
specification
of
modules
and
node
we're
designing
a
user
experience
of
modules.
In
your
in
note,
I'm.
E
B
A
E
So
my
point
is:
were
throwing
experimental
modules,
the
old
one-
hence
the
default.
/
MJ
s
is
throwing
command.
J
s
the
default.
Mj
s
does
not
exist,
except
in
the
old
experimental
modules
we
joined
to
fix
issues
that
were
spiraling
from
that
we
started
fresh.
There
was
no
default
in
fresh,
so
MJ
s.
B
E
A
A
B
I'll
be
quick,
so
guy
I
think
we
are
trying
to
design
the
most
perfect
system.
We
can
I
mean
we're
the
platform.
It's
the
same.
When
you're
doing
language
design
I
mean
the
we
can't
possibly
know
how
these
things
will
be
used
in
the
future,
and
usability
comes
from
ability
and
I
agree
that
if
the
specific
use
case
is
I
want
to
run,
write
my
ESM
and
DOJ's
files,
it
shouldn't
be
a
huge
pain
in
the
ass
to
do
that.
But
that's
not
the
same
thing
as
saying.
B
We
must
only
support
that
and
we
must
not
support
than
many
people
who,
in
the
future
will
want
to
use
arbitrary
extensions
for
arbitrary
module
formats,
and,
like
I
mean
that
is
exactly
what
required
out.
Extensions
has
permitted
for
the
last
decade,
and
people
have
done
it
a
lot.
They've
used,
coffee
or
JSX
or
TS
or
TSX,
and
so
on
so
I
think
claiming
that
people
don't
want.
That
is
short-sighted
and
I.
C
I
understand
that
these
are
things
they
can
waste
a
lot
of
time,
but
just
to
respond
briefly,
I
I
believe
those
use
cases
of
float
by
loaders.
We
have
a
load
of
flag,
it's
not
the
final
thing.
We
will
have
something
to
replace
it,
but
that's
the
way
in
which
that
gets
solved
and
the
idea
that
someone
wants
to
map
extensions,
I
think
Lloyd
is
other
more
powerful
mechanism
for
doing
that,
and
the
use
cases
around
what
we've
got
already
are
built
up
around
the
direct
use.
C
It
means
and
I
I
mean
I,
don't
have
a
problem
with
extension,
but
I
also
just
don't
see
where
it
gets
us
from
a
consensus
perspective,
because
we
still
have
a
type
flag
and
CJ
s.
So
if
the
problem
is,
we
don't
want
those?
How
is
the
extension
might
get
us
that
any
close?
That's
where
you
want
to
be
so
I,
also
just
don't
see
how,
though
I
like
human
ribs
this
for.
H
B
H
Not
wholly
true
I
said
that
we
have
no
traffic
on
arbitrary
extensions.
However,
we
have
regular
and
continuous
traffic
on
how
we
can
how
we
read
modules
and
JavaScript
files
and
on
supporting
MJS,
because
notice
starts
to
support
it.
So
what
you
make
available
as
a
default
in
which
you
say
our
best
practices
or
what
matters
arbitrary
freedom
is
nice,
but
unless
you're
telling
a
lot
of
people
to
use
it,
a
lot
of
people
don't
and
so
like
having
freedom
is
nice.
H
A
If
I
can
suggest
something
that
perhaps
can
be
a
concession
we
can
get
behind,
Jordan
you
describe.
That
type
could
eventually
be
sugar
for
a
preset
export
map,
extension
and
yeah
I.
Think
it's
reasonable
I,
don't
hear
anyone
explicitly
objecting
independent
of
whether
or
not
it's
ijen
ass,
but
that
in
the
mode
of
module
where
Jas
is
mapped
to
yes,
M,
it
is
highly
likely
that
we
will
want
to
map
another
extension
to
the
common
Jas
goal,
to
mean
that
you
can
import
common
J's
but
require
and
file
it
files
and
packages.
A
In
all
this,
it
seems
reasonable
to
me
then
that,
since
at
the
very
least,
we
have
some
degree
of
consensus
on
C
J's
as
a
potential
extension
for
that
that,
from
the
user
land
perspective,
there
is
not
much
of
an
actual
plumbing
of
a
difference.
There's
a
plumbing
difference,
but
there
isn't
a
user
experience
difference
between
the
type
flag
being
sugar
for
setting
up
a
mode
that
has
that
extra
extension
versus
us
eventually
having
the
exports
map
so
the
extensions
map.
B
From
a
technical
angle,
I
think
you're
completely
correct.
I
disagree,
I
mean
I,
agree
with
all
of
that.
I
think
that
my
concern
is
not
technical
here.
My
concern
is
about
the
message
that
we
send
and
the
best
practice
we
are
implicitly
or
explicitly
suggesting
and
what
the
ecosystem
will
generally
adopt
and
I
think
that
modules
is
a
place
where
it's
dangerous
to
to
create
those
implicit
recommendations.
Without
you
know,
I
think
we
should
be
making
explicit
recommendations
and
avoiding
unintended
consequences,
but.
A
But
I
guess
what
I'm
saying
is
like
if
we
eventually
track
that
exact
train
of
thought,
we
eventually
have
the
extension
map
that
you're
talking
about.
We
are
going
to
want
a
sugary
default
for
a
J
s
as
the
SM
input,
and
if
we
have
that
sugary
default,
we're
going
to
need
this
extra
extension
and
so
I
don't
really
see
how
we
don't
eventually
get
to
the
exact
same
thing.
Anyways.
A
B
Might
but
but
III
think
that
there's
a
difference
between
getting
there
by
having
the
general
mechanism
and
then
eventually
having
a
specific
one
or
shipping
them
both
together,
I
think
that's
better
than
shipping,
the
the
specific
one
and
then
later
tacking
on
the
general
one
I
think
those
send
very
different
messages
and
enable
very
different
forms
of
experimentation
and
enabled
very
different
kinds
of
feedback
that
we
would
receive
about.
It.
B
A
What
more
discussion
than
what
we
just
had?
Are
you
expecting
to
have
around
CJ
s
that
will
like
to
me?
It
seems,
like
we've
reached
the
finality
of
this
conversation,
which
is
like
we're
either
gonna
have
surgery
defaults,
or
we
won't
to
be
honest
with
you,
I'm,
not
even
actually
sure
that
I
would
approve
of
the
extension
Maps.
The
way
in
which
you're
describing
them.
Anyways
I
think
that
mapping
extensions
make
sense
of
the
sense
like
for
for
wiring
loaders,
but
arbitrary
extension
Maps
out
of
the
box
right
away
just
creates
like
infinite
possibilities.
A
The
way
is
that
people
do
things
and
I
actually
think
that
there's
a
lot
of
value
in
having
ecosystem
defaults
for
a
pattern,
that's
going
to
be
pretty
consistent
instead
of
a
hundred
different
things.
That's
going
on
so
I
think
that
there's
a
bit
of
this
that
like
there
is
maybe
an
assumption
that
you're.
Having
that
you
know
these
extension
maps
are
gonna
even
reach
consensus,
mm-hmm
well,.
B
B
I
mean
I'm,
not
saying
necessarily
that
we
have
to
implement
and
ship
extensions
maps,
but
if
we
got
consensus
on
doing
that,
it
doesn't
have
to
match
exactly
what
I
sketched
out
as
an
implementation
suggestion,
but
like
let's
say
we
got
consensus
on
some
implementation,
I
I
would
I
think
it's
very
likely
that,
after
some
thought,
I
would
remove
my
blocks
on
this
one
and
be
content
going
forward
and
then
implementing
the
extensions
map.
You
know
after
upstreaming
well.
A
B
E
I'm
not
objecting
I
just
have
a
clarification
that
might
help
us
make
a
more
informed
decision
on
blocking,
or
you
know,
reject
the
proposal
you
mentioned.
You
are
not
able
to
commit
time
to
implement
it.
I
think
it
would
be
a
very
useful
decision
for
the
a
useful
detail
for
the
group
to
be
aware
of
is
assume.
We
say
yes
and
we're
going
to
implement
there.
There
needs
to
be
the
Willing
blueness
within
the
group.
Some
people
will
say.
E
E
B
E
I
didn't
mean
it
that
way:
I
don't
do
a
lot
of
codes
for
node
like
I
anyway.
So
the
point
is
anybody
else
and
the
group
willing
to
speak
up
and
say
yes,
I'm
toward
I
want
to
implement
it,
and
we
think
it's
going
to
take
that
long,
because
with
that
detail,
other
people
are
really
able
to
give
informed
decision
that
affects
not
just
opinion.
You
know,
driven
from
other
proven
or
unproven
tests.
C
C
You
know
if
someone
wants
to
get
an
implementation
together.
Certainly
I
mean
it
doesn't
feel
like
we're
there.
Yet
on
the
proposal
and
I,
as
we
say
under
the
experimental
flags,
we
can
do
any
number
of
things
once
we've
up
streamed,
I
think
the
important
thing
is
to
get
out
of
streaming
consensus
and
given
that
this
meeting
is
already
gone
over,
I've
still
don't
see
how
we're
any
getting
any
closer
to
that
consensus.
G
Think
this
is
never
gonna
go
away.
We
can
keep
kicking
the
can
down
the
road,
but
I
mean
I
feel
like
refusing
to
vote.
Just
gives
people
individual,
vetoes
and
I.
Don't
think
that's
making
a
better
implementation.
We're
gonna
end
up
with
something
that's
designed
by
committee.
That
has
features
that
one
person
wanted
and
the
rest
is
kind
of
went
wrong
with
it,
because
otherwise
they
like
wielded
a
video
I'm,
not
sure
that's
really
better
than
preserving
the
unanimity
yeah.
E
C
Jordan
I
mean
what,
if
we
say
that
we
put
in,
we
have
what
we
have,
which
is
a
common,
just
expense
and
a
type
laggin.
But
if
we
say
we
will
put
as
specific
items
to
evaluate
these
when
we
have
the
time
available
and
we
could
say
they're
pretty
cool,
we
could
remove
documentation
on
these
features
potentially
and
reduce
the
level
of
documentation
on
these
I.
Don't
know
it's
their
middle
ground
to
be
found
there.
That
allows
us
to
move
forward
with
upstream
I.
B
This
runs
the
risk
of
creating
ecosystem
turn
whenever
we
need
to
do
some
sort
of
blog
post
or
announcement,
there's
a
risk
that
bundlers
and
tools
will
still
sort
of
support
them.
Somehow,
and
you
know,
we've
talked
about,
we
told
talk
the
whole
thing
idea.
The
whole
time
we've
been
talking
about
a
minimal
kernel
with
the
intention
of
under
shipping,
not
over
shipping,
so
that
we
don't
send
the
signal
that
we're
shipping,
something
that
might
go
away
so
because
of
which
usually
ecosystem
impact,
would.
C
B
Appreciate
that
you're
attempting
to
find
a
you
know,
compromise
I,
think
that
would
be
an
improvement
regardless
I
I
still
think
I
would
feel
better
if
we
got
consensus
on
doing
some
form
of
extensions
mapping
even
yeah,
just
regardless
of
the
specifics
of
the
implementation.
I
mean
the
in
my
issue
that
I
proposed
it.
The
loader
that
we
currently
have
does
in
extensions
map
like
with
minimal
assuming
we
can
get
the
value
of
the
package.json
field.
It's
minimal
code
to
just
make
it
work
with
our
current
loader.
B
B
If
the
objection
is
I,
don't
see
how
that's
useful
I,
don't
think
it's
useful
to
run
ASM
and
dot
J's
files
I
respect
that
other
people
find
it
useful,
but
the
fact
that
I
don't
think
it's
used
doesn't
make
a
difference.
So
you
simply
don't
find
extensions,
Maps,
useful
I.
Don't
think!
That's
a
sufficient
to
be
an
objection
if
people
have
objections
beyond
that,
I
think
that's
very
much
worth
talking
about.
I
am.
A
Genuinely
concerned
about
the
patterns
that
may
be
created
by
extension,
Maps
without
them
being
properly
coupled
with
loaders
I,
actually
don't
see
the
value
in
an
extensions
map
that
is
separated
from
our
loaders
implementation
and
our
loaders
implementation
is
not
out
of
place
right
now,
where
it
would
be
a
mapping.
But
I
would
imagine
that
the
eventual
implementation
of
loaders
would
be
the
extension
map
and
the
loaders
that
we
point
to
are
either
the
built-in
loaders
or
custom
loaders.
A
So
I
am
concerned
about
us
prematurely
creating
an
extensions
map
that
is
a
whole
other
place
in
the
package.json
that
we
need
to
track
on
a
per
module
basis
that
we
need
to
be
standing
for
in
a
way
that
we
aren't
currently
standing
for.
That
also
introduces
like
we're.
Adding
extra
lookups
now
we're.
B
A
B
A
We
need
to
track
that
we
need
to
deal
with
it.
I
am
NOT.
A
personally
like
I
would
like
us
to
have
as
little
stuff
in
the
package.json
as
possible.
I,
like
type
specifically
because
of
the
parallel,
would
type
module
inside
of
a
script
tag.
I,
think
that's
something
that
makes
sense.
It's
something
that's
easier
for
people
to
follow,
and
it's
easy
to
educate
people
on
I
think
that
loaders
is
something
that
we're
going
to
be
having
some
sort
of
package.json
configuration
as
well.
A
E
E
E
A
B
F
B
F
E
F
F
G
If
I
could
just
add
something
like
there
are
going
to
be
things
that
are
in
this
implementation,
that
people
don't
like,
like
I've
accepted,
like
MJS,
is
going
to
ship
and
I'm.
Just
never
gonna
use
it
and
that's
fine.
If
someone
else
will
like
it,
someone
else
will
use
it.
Jordan
will
certainly
like
it
extension
map
same
thing:
I'm
never
gonna
use
it,
but
if
it
makes
somebody
happy
fine,
it
doesn't
hurt
me
it
doesn't
hinder.
Anything
I
need
to
do.
I
mean
that's
kind
of
how
I
hope
others
would
feel
about
CJ
s.
A
A
B
G
B
A
E
G
Prank,
it
also
add,
like
I,
feel,
like
a
lot
of
objections.
I've
seen
on
a
lot
of
stuff
lately
has
been
just
more
like
I.
Don't
like
this,
and
not.
This
should
be
better
in
this
way
or
I.
Think
this
could
be
improved
by
this
I
I
would
prefer
a
lot
more
of
the
latter
than
the
former
if
we
can
kind
of
shift
in
that
direction.
So.
A
A
Finalized
phase
2
in
the
planning
document,
it
seems
like
we
need
to
add
the
documentation
for
phase
3
around
the
type
flag
we
implement
and
of
the
missing
phase.
2
features
which
was
reading
the
upstream
loader
and
extension
folder
resolution.
Those
are
both
landed.
We've
updated
the
documentation
to
reflect
the
latest
implementation.
A
G
If
your
entry
point
imports
a
J's
file,
then
it'll
be
loaded
as
coming
to
us
unless
you
have
the
type
flag
in
addition
or
something
to
that
effect,
so
that
people
aren't
surprised
and
if
there
any
other
things
that
land
like
import,
Jason
or
whatever,
then
we
need
to
document
those
well
yeah,
it's
it's
mostly
done.
It's
basically
done
that,
then.
A
E
Yeah
so
I've
been
I've
been
I'm
off
trying
to
build
the
most
current.
Can
we
put
together
a
quick
guide
if
people
will
be
testing
this
in
the
next
week
or
so?
Can
we
just
put
a
just
even
on
the
most
reliable
ways
to
get
it
done,
because
I've
been
running
into
issues,
and
it's
really
my
inexperience
at
this
point
I
think.
A
A
E
Every
time
I
keep
forgetting
what
I
just
last
time.
It's
it's
just
me
being
you
know
forgetful
I,
guess
at
this
point,
but
it
like
I,
I
built
and
I
created
like
sprits
awhile
back,
and
then
we
moved
from
our
piece
to
the
actual
repo,
the
echo
script
modules
repo.
So
just
just
the
place
where
we
say
this
is
where
you
get
the
most
current
and
these
committees
are
guaranteed.
I
can
help.
G
A
Then
we
need
to
make
sure
we
have
the
messaging
on
the
upstream
PR.
It's
likely
that
we're
gonna,
maybe
have
some
pushback
or
some
people
asking
for
some
stuff
I
can
handle
that
we
have
a
blog
post.
We
have
that
I
believe
we
have
a
pull
request
open
right
now,
number
291
that
has
Jeff.
What's
the
state
of
that
right
now,
I
made.
G
Most
of
the
changes
that
people
wanted,
or
at
least
the
ones
that
were
like
directly
implementable,
I,
think
there's
just
we
just
have
to
vote
on
whether
we're
capitalizing
em
or
not
in
ES
module
I
was
assuming
we're
not
because
you
wouldn't
capitalize
the
M
and
the
phrase
common
tasks.
Module
Jordan
feels
so
strongly
about
it
that
he
keeps
opening
like
issues
to
to
change
it.
I
mean
we
should
match
the
way
that
they
do
it
upstream.
We
should
match
exact
a.
G
A
E
One
point
of
input
that
that
would
just
clarify
this.
When
you
are
saying
ESM,
you
have
to
write
an
es
model
when
you
are
saying
ACMA
script
modules
like
commonjs
modules,
when,
when
stylistically
you're,
just
saying
es
modules,
not
referring
to
the
thing
called
an
es
M
file,
then
you
actually
can
write
it
as
a
the
es
is
prefix
and
and
module
is
what
this
thing
is.
A
Okay,
so
with
that,
we
have
our
modules
LKG,
our
branch-
it
is
you
know
up
to
date.
It
will
the
only
changes
that
will
land
right
now.
Between
now
and
opening,
the
PR
is
the
refactoring
from
guy
bedford,
the
json
experimental
support
and
there's
one
PR
that
has
approval.
That's
some
doc
fixes.
I
would
like
to
open
the
pull
request
that
includes
all
of
these
changes
right
after
this
meeting
I'll
do
a
little
bit
more
cleanup.
Does
anyone
object
to
me
opening
that
pull
request
based
on
modules?
Lkg?
Are
this
week.
A
I
hear
no
objection,
so
I
will
move
forward
with
doing
one
last
past
pass
and
making
sure
that
that
branches
in
a
good
condition
to
upstream
that
every
single
individual
commits
lands,
I
am
I,
am
urging
a
bunch
of
commits
that
have
to
do
with
the
same
stuff.
So
all
the
doc
changes
will
be
in
one
commit
all
the
implementation
deals.
Details
for
specific
things
will
be
in
one
commit
and
I'm
adding
co-authored
by
to
keep
all
of
the
committers
for
the
various
commits
that
are
getting
squashed
together.
A
I
will
open
something
either
today
or
tomorrow.
The
sooner
we
can
get
it
in
front
of
people.
In
the
sooner
we
can
start
getting
feedback
from
upstream
the
better
off
we
will
be
I.
Think
the
hope
would
be
that
right
now
we
would
open
this.
You
know
today
or
tomorrow,
and
we
will
have
a
meeting
on
the
27th,
but
perhaps
if
there's
any
major
concerns
from
upstream,
we
can
hopefully
handle
with
that
out-of-band.
A
Okay
and
Jordan
I
want
to
offer.
If
you
want
to
work
together
with
me
on
trying
to
make
that
export
the
proposal,
at
least
getting
the
proof
of
concept
of
it,
I'm
definitely
willing
to
work
on
it,
although
I
do
want
to
throw
out
there
that
you
know,
as
I
said,
I
think
that
this
is
something
that
is
tightly
coupled
with
loaders,
so
it
would
be
a
lot
of
the
same
logic
for
that
mapping.
So
I
think
that
it's
worthwhile
to
get
that
implementation
together.