►
From YouTube: Node.js Foundation Modules Team Meeting 2019-01-16
Description
A
And
we
are
now
live
on
YouTube
with
the
January
16
2019
meeting
of
the
node.js
modules
team.
We're
joined
right
now
by
nine
people,
one
off
from
having
quorum.
So
if
anyone
else
joins
here
at
the
meeting
I'll
make
mention
of
that,
but
I
don't
believe
we
have
anything
that
needs
to
land
today
or
requires
quorum.
So
it
shouldn't
be
an
issue.
We
have
a
full
agenda
for
today
and
we're
going
to
start
with
some
updates
slaw.
B
B
A
So
you
know
I
think,
might
get
on
it.
You
could,
you
know
I
think
you
need
to
most
likely
take
the
action
item
of
bringing
it
to
these
groups
and
on
boarding
them
with
how
to
use
it
since
using
something
like
this
is
requesting
and
requiring
extra
work
from
people
you're
either
going
to
need
to
get.
You
know
buy-in
from
those
people
that
they
want
to
do
the
work
or,
alternatively,
likely
you
know,
do
the
work
yourself.
So
I
think
that
this
is.
B
B
If
the
group
feels
that
this
will
help
the
activity
I
think
we
should
all
you
know,
do
what
we
can
like
I'm,
not
bringing
this
idea
onto
the
group
or
anything
I'm
trying
to
just
find
a
way
to
you
know
get
started,
but
if
the
group
in
general
does
not
feel
that
this
kind
of
organization
is
warranted,
I
think
we
should
decide
as
a
group
that
we
don't
want
to
go
on
with
the
board.
Okay.
A
So
we're
up
to
the
time
on
this,
so
I'd
advise
it
as
like
a
follow
up
to
this.
If
we
have,
you
know
a
process,
that's
in
place
right.
There
I
think
we
need
to
document
how
that
process
should
be
used
and
add
that
to
our
governance,
documentation
and
then
I
have
a
vote.
If
we
want
to
implement
that
as
governance,
because
I
think,
if
it's
not
explicitly
something
that
we
need
to
do
as
a
project
or
it's
not
documented,
my
gut
is
that
people
won't
do
it
the
next.
A
The
next
thing
that
we're
on
and
for
those
following
along,
we
have
ten
people
on
now,
so
we
actually
have
enough
for
quorum
because
we
have
the
PR
against
modules,
is
number
242
and
it's
updating
the
stage
two
regarding
dynamic
modules,
so
the
inn
now
reads:
implement
specific
changes
related
to
dynamic
module
records.
It
references
the
proposal
which
is
github.com,
slash,
no
GS,
/,
dynamic
modules,
and
it
has
a
note
saying
we'll
need
to
reach
consensus
on
appropriate
behavior
for
export
star
from
dynamic
module.
A
A
Okay,
great
I
think
we
can
move
forward
and
just
land
that
just
one
more
quick
request
if
anyone
like
on
the
call
has
able
to
help
with
the
notes,
please
do
because
it's
not
possible
for
me
to
do
all
these
things
at
once.
I.
A
D
A
D
D
We
then
built
out
of
that
the
import
file,
specify
resolution
proposal,
the
exports
proposal
and
what
I'm
bringing
to
the
group
today
the
mode
as
in
proposal,
and
these
are
kind
of
in
a
lot
of
ways
quite
also
agonal
proposals
that
kind
of
fit
together
and
then
there's
various
education
that
needs
to
be
worked
out
where
they're
interact.
What
this
is
is
it's
basically,
a
demo
of
all
of
them
are
running
together
and
the
way
that
they
run
together
is
just
what
seemed
sensible.
The
details
aren't
set
in
stone.
D
It's
just
kind
of
an
illustrative
demo
to
show
the
sort
of
stuff
that
we're
working
on
with
these
specs
and
to
kind
of
just
brings
some
clarity
to
that
in
terms
of
just
seeing
what
it's
doing
for
a
normal
user.
Writing
a
node.js
app
with
these
specs,
so
I'll
start
off
with
the
basics
of
the
file
resolution,
specify
proposals,
so
you'll
notice,
I,
don't
have
any
package.json
here.
I,
don't
mean
any
package
JSON
any
of
the
folders
down
into
the
project
and
I'm
running
this
node
with
modules.
D
D
I
can
then
run
that
just
directly
with
the
node
entry
point.
At
the
same
time,
I
can
write
a
J's
file
and
I
can
have
modular
exports
equals
common
J's
and
I
can
also
run
that
with
the
node.js
entry
point.
So
this
now
is
the
import
file
specify
resolution
proposal
in
terms
of
how
we're
distinguishing
between
J's
and
MJ
s
and
which
is
running
which
we
can
also
import
their
common
J's
from
the
local
comedy
s
file
and
we
can
log
it.
D
Called
it
extra
J's,
sorry
there's
this
weird
thing
with
the
error
messages
where
they're
getting
curly
brackets
around
them,
when
they're
coming
from
C++
I
have
no
idea
why?
But
ideally
we
should
fix
that,
so
we
can
get
both
running
together,
we're
using
the
default
because
we
don't
have
dynamic
modules
and
so
that's
kind
of
the
combined
way
of
working
with
these
things.
D
The
next
steps
that
you
might
want
to
do
is
see
what
happens
when
you're
loading
a
package
so
safer.
We
have
node
modules
package.
This
is
called
and
I'm
going
to
just
move
those
files
into
node
modules
package
and
then
I
want
to
have
like
an
app
MJS,
that's
going
to
say
import
package,
for
example,
and
I'm
going
to
go
directly
into
package
and
load
the
X
J's
that
we
created
first.
D
D
So
you
can
see
that
we're
loading
both
it's
worth
noting
here,
that
these
have
to
be
exact,
specifies
in
line
with
what
we've
specified
so
far
in
the
minimal
repo.
So
if
I
left
out
the
dodgiest,
there
I'd
get
a
not
found
error,
and
this
is
for
any
package
common,
just
as
amour
anything
the
only
time
we
get
the
default
resolution
as
if
it's
the
main.
D
These
are
fine-grained
behaviors
that
aren't
set
in
stone,
but
it's
just
what
is
currently
implemented.
It's
a
specific
gnome,
an
entry
point
for
package
era,
but
that
can
also
be
changed
to
a
customized
whatever.
So
that's
the
main
the
next.
So
this
is
kind
of
the
the
jeaious
and
MJS
babies
without
setting
the
default.
Jase
I
haven't
done
yet,
but
roughly
in
line
with
the,
with
the
way
that
these
specs
are
interacting
between
the
mineral
River
and
file
import
specifier
proposal.
D
If
you
set
your
main
entry
points
using
the
special
exports
functionality
instead
of
the
main,
what
we're
going
to
do
is
we're
going
to
block
any
sub
pods,
so
I
can
do
the
main
for
the
package
fine
still,
but
if
I
try
now
and
reach
into
that
package
and
reach
into
wider
J's,
for
example,
I'm
gonna
get
a
new
type
of
error,
which
is
that
we've
sort
of
got
a
security
model
now
for
the
package
or
you
say,
package
exports.
They
don't
define
this
Y
sub
path.
You
can't
you
can't
import
that
now.
D
We
could
block
that
as
well,
so
that
that's
sort
of
indeterminate
behavior-
and
these
are
the
sort
of
edge
cases
that
we
need
to
meet
iron
out,
but
for
now
it
does
the
full
the
full
encapsulation
only
when
you're
loading
it
as
a
package.
The
other
feature
that
exports
gives
you
is
the
ability
to
have
an
object,
obviously,
where
we
can
sort
of
define
those
sub
parts.
So
I
can
say
if
I'm
loading
dock
/y
digest
I'm
specifically
load
the
wider
JS
file.
D
We
can
skip
the
extension
on
the
sub
path
and
have
say
a
main
we've
kind
of
settled
on
a
dot
main,
but
that
can
be
changed
as
well.
So
when
you
expand
exports,
you
can
still
have
the
main
as
extra
jeaious.
So
with
that,
if
I
load
package
directly,
it
loads
the
as
a
main,
if
I
then
load
package
/y
it
loads
that
special
map
to
Y,
if
I
try
and
let
anything
else,
it's
a
security
violation
of
the
package
boundary,
so
you're
kind
of
getting
that
defined
boundary.
D
What
we
originally
had
for
this
export
spec
was
that
as
soon
as
I
put
in
exports,
it
would
also
immediately
treat
all
J's
in
their
package
as
yes
modules
and
what
I'm
kind
of
arguing
against
at
the
moment
is
saying.
Well,
we
don't
want
to
treat
all
the
J's
files
necessarily
because
all
I
wanted
to
do
is
set
the
exports.
I
didn't
say
that
I
want
to
treat
all
my
files
as
ism,
so
it
kind
of
feels
like
conflating
the
features
to
do
them
at
the
same
time.
D
It's
it's
not
it's
now
trying
to
load
wider
J's
as
an
es
module,
so
we're
effectively
using.
So
if
I
did
that
locally,
where
I've
got
this
app,
that
MJS
I
can
now
create
a
package.
So
this
is
the
use
case
of
like
I'm
running
a
liquid
I
want
to
write
a
J's
file
as
ism,
so
I
create
a
package.
Json
and
I
do
mode.
Azzam
I,
don't
have
to
think
about
what
my
main
is:
I,
don't
need
to
write
exports
and
do
all
that
I'm.
D
D
If
we
want
to
go
in
these
directions
in
in
the
package,
if
I
wanted
to
have
a
Jewelry
package,
that's
going
to
load
one
version
in
common,
yes
and
another
version
in
Azzam
we
can
use
the
main
and
exports
as
the
signifiers
and,
as
is
previously
worked
in
the
import
file
space
for
proposal
and
the
exports
proposal
to
use
exports
as
the
sort
of
main
main,
which
applies
only
in
ISM.
It
does
mean
I
get
encapsulation
if
I
wanted.
If
I
don't
want,
encapsulation
I
can
opt
out
of
it.
D
D
And
then
on
my
apt
rjs,
which
is
my
common
Jesperson
version,
I'm
gonna,
say,
require
a
package
so
reloading
the
same
package,
one
from
commonjs,
one
from
a
zoom
in
the
app
that
MJS
just
picks
up
the
type
over
there
same
problem
in
the
app
taht
MJS
I'm,
getting
the
ES
module
version,
Haller
ISM
and
in
the
app
dot
J's
version
I'm
getting
the
common
es
version.
So
it's
the
same
package,
the
same
specifier
and
we're
getting
this
sort
of
dual
mode
provided
because
you've
got
main
and
exports
which
also
specifically
overrides
the
SM
behavior.
D
So
that's
kind
of
all
the
specs
we
have
and
where
we
are
at
the
moments
I'm
advocating
right
now,
the
mode
ISM
but
all
the
other
behaviors
we've
actually
separated
the
implementations.
We
can
get
file
specifier
without
everything
else,
and
we've
got
exports
just
on
its
own.
We've
got
mode,
so
we
were
kind
of
just
playing
around
with
how
to
bundle
it,
and
this
is
for
the
demo
to
be
able
to
share
everything
running
together.
But
these
are
the
general
directions
we've
been
working
on.
A
Okay
and
one
thing
just
before
people
start
asking
their
questions,
keep
in
mind
that
we
went
a
little
over
and
we
have
agenda
items
specifically
for
the
import
file,
specify
resolution
proposal
for
the
dynamic
modules
proposal
for
the
ad
package
exports
resolve
respect
and
for
the
dynamic
modules
development.
So
if
your
questions
have
to
do
specifically
with
any
of
those
that
we
could
save
them,.
D
E
I'm
not
sure
if
what
I'm
asked
was
just
in
your
list
of
things
to
defer.
So
stop
me
if
it
is,
but
it
seems
to
me
like
exports,
is
a
super
useful
feature
that
we
should
like
rapidly
try
and
ship
normally
in
node
for
CJ
s,
and
then
it
just
kind
of
falls
into
place
for
ESM
as
we
build
that
so
that
that
sounds
awesome
I
mean
like
there's
a
whole
bunch
of
use
cases
for
it.
E
Just
the
last,
the
last
piece
was
that
I
think
you
have
a
really
good
case
for
Modi
SMS
Burgin
mcc's,
in
other
words,
to
in
concert
with
exports,
be
able
to
switch.
The
you
know,
alter
the
default
parsing
of
the
whole
package
I'm,
but,
as
I've
said
on
the
issue,
I
really
don't
like
an
enum
of
formats.
It's
considering
that
right
now
we
have
two
module
formats,
but
there's
going
to
be
three
four
or
five
six
in
the
future,
so
I
would
prefer
some
alternative
mechanism,
but
I
like
the
the
way
it
cuddles.
E
D
Concern
there
is
something
that's
short
too
tight,
so
I
don't
care
what
it
is
as
long
as
I
can
get
that
in
twenty
keystrokes
or
less
whatever.
It
is
I'm
happy
to
put
anything
in
its
place,
so
you
know
I'm
more
than
open
to
discussing
anything
else
that
can
do
that,
but
as
I
say,
the
main
thing
is
it's.
That
use
case
of
a
lot
of
this
is
a
good
developer
ergonomics.
D
That's
why,
in
terms
of
the
exports,
if
we
want
to
bring
it
to
common,
yes,
there's
a
complexity
there
because
say,
for
example,
to
find
some
exports
for
a
package
at
the
moment.
I
could
do
the
dual
mode
case,
because
exports
applied
specifically
in
the
Azzam
case,
but
it
didn't
apply
in
the
common
jairs
case,
so
that
provided
a
nice
sort
of
way
to
switch
between
the
two
modes
well
between
the
two
loaders
and
have
different
behaviour
between
the
loaders.
D
Now,
if
we
want
exports
to
go
to
common
J's
as
well,
then
we
need
to
provide
the
functionality
in
exports
to
be
able
to
provide
different
exported
values
between
common
jerison
isms.
So
maybe
we
need
to
have
an
object
where
you
say
here
are
the
common
GS
mappings
here
are
the
SM,
mappings
and
split
those,
so
it
adds
a
little
bit
more
complexity
to
the
spec.
D
If
we
do
that,
while
trying
to
maintain
the
the
dual
mode
sort
of
functionality
and
I
am
hesitant
to
pick
up
that
because
of
the
fact
that
it
adds
complexity
to
a
specular,
otherwise
is
really
nice
and
simple
in
something
that
we
can
get
out
soon.
But
if
we
determine
that
that
is
a
crucial
functionality,
we
can
certainly
extend
the
spec
to
cater
to
that
case.
Where
you
have
the
sort
of
C
J's
as
in
variations
between
the
two.
You
know
something
something
like.
D
E
A
G
D
So
I
can
also
clarify
the
behavior
without
the
mode
Azzam
spec,
which
I'm
presenting
now.
Is
that
what
you
just
described
that
as
soon
as
you
bring
in
exports,
you
get
J
s
as
ISM,
so
the
the
idea
is
that
exports
is
an
encapsulation
of
what
you
get
when
you
import
from
the
package,
and
it
can
encapsulate
everything
else.
It's
it's
possible
to
open
up.
D
The
exports
again
was
the
following
mapping,
so
it
does
actually
support
folder
mappings,
if
you
do
say
dot,
FOID
slash,
you
know
like
loaders
or
something
you
could
have
a
folder
ending
with
a
trailing
slash
which
which
maps
to
another
folder.
And
similarly
you
can
do
the
base
level
map
which,
if
you
have
that
is
your
exports.
It
opens
it
up
again
and
you
can
now
get
any
type
of.
D
You
can
import
anything
anything
again
from
the
package
without
needing
an
explicit
map
for
it.
So
there
is
an
opt-out
of
the
full
encapsulation
but
yeah
without
the
mode
azzam
spec.
As
soon
as
you
add
exports,
because
you
want
J's
files
as
ISM,
then
you
get
encapsulation,
which
I
felt
was
a
conflation
and
that's
why
I
think
we
need
the
separate
mode,
Azzam
spec,
to
say
this
is
an
ism
package
where
J's
files
are
ism,
but
I.
G
D
A
D
B
I
can
I
actually
propose
like
what
I
was
going
to
suggest
might
actually
hit
that,
like
directly
you're
using
Modi
SM
and
we're
just
thinking
of
mode
as
a
flag
that,
like
toggles
one
mode
or
another,
from
a
universal
perspective,
if
you're,
if
you
have
a
package
dot
mode,
you
can
actually
be
providing
a
mode
for
a
resolution
which
which
can
go
beyond
the
idea
of
just
ESM
or
whatever
you
could
say
browsers.
You
could
say
so
so
you
can
have
those
different
resolution.
B
B
D
So
it
could
be
extended
into
something
that
sort
of
enables
different
package
features
and
yeah
I
mean
maybe
I
mean
we
were
even
discussing
if
it
could
be
like,
maybe
in
future,
it'll
be
like
a
version
number
of
which
version
of
node
resolution
are
using
or
something
I
mean,
there's
lots
of
awful
things
that
could
turn
into
as
well.
So
I
don't
know,
but
it's
definitely
worth
discussing
further.
F
Hi
and
say:
hey,
you
know,
I
think
the
the
export
feature
seems
really
really
great.
So
it
gets
a
CSM
node
and
it
gets
this
encapsulation
and
it
seems
to
be
so
great
that
as
an
this
is
going
to
plate
the
and
in
general,
the
desired
way
of
using
it
and
so
I
guess
I'm
I'm
wondering
do
we
really
need
another
way
to
get.
D
D
But
the
argument
I'm
trying
to
make-
and
if
you
read
through
the
the
Reaper
there's
a
bunch
of
ergonomic
arguments
around
it,
which
is
like
I,
think
the
Col
one
comes
down
to
the
fact
that
if
you're
a
user
wanting
to
solve
a
problem,
you
want
the
cognitive
overhead
of
solving
the
problem
of
treating
J's
files
of
as
Azzam.
And
you
don't
want
to
now
be
dealing
with
encapsulation
and
all
these
other
ideas.
So
it's
kind
of
like
we're
shoving
a
whole
bunch
of
features
together
and
I
mean.
D
Maybe
that
is
fine,
but
I
just
feel
like
they
will
always
be
a
subset
of
people
who
won't
want
the
encapsulation,
and
because
of
that,
we
can't
assume
that
everyone
who
wants
Jase's
Azzam
must
also
now
get
encapsulation
by
default.
So
it
just
feels
like
yeah,
but
bundling
those
two
groups
together,
and
that
feels
like
a
recipe
for
frustration,
because
it
just
takes
someone
who
who
doesn't
like
the
encapsulation.
One
person
doesn't
like
encapsulation
to
voice
their
opinion
and
and
you've
got
it
you've
got.
D
You
know
that
frustration
there
and
it
and
there's
also
an
argument
for
like
primitives
that
are
as
simple
as
possible
and
solving
the
direct
need.
But
yeah
I
mean
there
are
some
like.
There
was
some
duplication
between
the
main
and
exports
there.
You
know
we
could
disable
the
main
for
ISM
entirely,
that
there
are
various
edge
cases
here.
They
can
be
discussed
and
worked
through,
but
I
yeah,
but
the
the
main
point
I
was
making
about
mode
ISM.
Was
it
exactly
throws
away
this
conflation?
That
Jeremiah
also
mentioned
as
well
as.
Why
is
this
coming?
D
F
H
In
the
agenda,
I
just
wanted
to
try
to
briefly
address
that,
just
to
mention
that
the
this
idea
of
adding
a
mode
flag
in
addition
is
like
something
that
we
added
like
kind
of
very
last-minute
like
we
was
just
started
discussing
a
few
days
ago.
If
you
look
at
the
the
two
proposals,
don't
really
mention
that
they,
like
the
the
experts
proposal
and
then
the
import
specifier
that
was
built
on
top
of
it,
though
assume
just
the
one
flag
of
exports
and
that
that
yeah,
it
kind
of
does
everything.
H
And
if
you
you
know
within
exports,
you
can
specify
the
main
within
exports.
You
can
open
up
your
entire
package.
You
know
common
das
style,
if
you
want
to
it
was
just
kind
of
we
were
thinking
that,
like
you
know,
yeah
like
like
I
said,
is
it?
Is
it
make
more
sense
for
you
yeah
like
what
are
you
showing
here?
That's
the
open
up
everything
version
of
it
and
there
now
he's
adding
the
main.
So
it's
more
to
see
you
X
concern
of
like
is
this
confusing
for
users?
H
Should
we,
you
know,
split
these
out
and
you
know
I
think
we're
we're
not
sure
and
I
think
that
we're
you
know
I'd
love
to
get
this
like
into
people's
hands
to
start
testing
it,
and
then
we
can
start
kind
of
just
seeing
what
people
struggle
with
or
have
difficulty
with,
but
yeah.
We
have
one
branch
for
each
each
way
of
doing
it
and
I
think
it's
I'd
love
to
start
pushing
it
forward
and
getting
more
feedback.
D
Yeah,
so
they
they're
kind
of
two
builds
IRP
implementation
and
IRP
mode
implementation
and
miles
I
value
your
suggestion,
if
there's
a
way
of
maybe
making
these
binaries
available
so
that
we
can
so
the
you
know,
people
who've
seen
that
the
demo
today
can
try
it
out
easily.
Would
there
be
a
way
to
do
that
or
yet
just.
D
A
Okay,
so
moving
forward
I
think
we've
kind
of
gone
into
a
whole
bunch
of
this
different
stuff.
We
have
20
minutes
left
in
the
meeting
and
we
have
three
items
on
the
agenda
right
now.
One
is
the
specify
import
file,
specify
resolution
proposal,
I
believe
that's
Jeffrey
proposal.
We
have
the
ad
package
exports
proposal
to
result.
Spec,
that's
someone.
E
A
D
Think
at
this
point,
the
way
the
discussions
have
gone
is
that
we're
currently
dealing
with
trying
to
work
out
other
alternatives
to
the
export
star
functionality.
So
it
would
be
better
if
Jay
Dalton,
it
was
not
terrible.
Well
Kevin
can
present
their
ideas
around
that
because
it's
really
out
of
my
hands
at
this
point.
C
D
Yeah,
no,
there
have
been
any
changes
if
we
punt
this
to
the
next
meeting.
I,
don't
know,
what's
gonna
happen
at
tc39,
but
you
know
last
we
discussed
this.
We
said
well,
it
shouldn't
push
back.
The
the
tc39
meeting.
I
am
NOT
actively
working
on
dynamic
modules
at
this
point,
because
I'm
still
waiting
for
a
feedback
on
the
on
on
the
concerns
around
export
star
and
so
there's
nothing
I
can
do
at
all
at
this
point,
so
I'm
not
actively
doing
any
driving
of
the
so
I've
just
yeah.
A
The
last
question
that
I
that
I
have
on
that
for
both
guy
and
Kevin.
We
have
you
know
the
next
tc39
meeting
is
coming
up.
It
actually
is
the
same
like
like
this
next
meeting,
we'll
be
running
during
tc39,
so
we
won't
have
an
opportunity
to
all
collaborate
again
before
then,
unless
it's
off
thread
is
there
anything
that
we
need
to
know
before
we
go
to
tc39
or
is
kind
of
the
thing
we
bring
to
tc39.
You
know
we
talked
about
it
after
last.
A
D
So
the
original
plan
was
to
have
consensus
on
not
supporting
export
star
and
then
allowing
that
to
get
spec
approval
in
tc39
to
allow
implementation
work
to
go
forward
so
that
we
could
get
a
you
know,
possibly
something
floated
in
node
in
the
next
four
months
at
the
moments.
If
we
don't
have
consensus,
we
can't
go
to
tc39
seeking
approval,
so
there
won't
be
any
movement
on
that.
D
A
Think
that
we
should
right
now,
because
we
know
that
Jade
Dalton
is
not
happy
with
this
and
we
do
have
quorum,
and
we
could
do
that
right
now.
It
doesn't
really
seem
in
the
spirit
of
how
we're
trying
to
do
things,
but
I
can
try
to
to
follow
up,
maybe
Kevin
and
guy.
Do
you
have
time
to
do
a
meeting
next
week
before
tc39
with,
like
maybe
get
Jay
Dalton
into
and
see?
If
we
can
all
sync?
Yes,.
D
A
H
I
don't
know
if
there's
anything
that
needs
to
really
well
I
guess
the
one
thing
I
would
say
is,
as
you
saw
with
guys
demo
were
you
know,
closing
in
on.
You
know,
we've
already
implementing
it,
so
it's
sort
of
like
any
any
more
notes
on
the
on
this
proposal
or
the
you
know
that
any
of
the
three
proposals
that
our
little
group
has
been
working
on
now
would
be
the
times
we
can
start
trying
to
start
trying
to
get
into
the
wrapping
up
portion
of
phase
two.
H
You
know
if
there's
anything
that
anyone
finds
so
so
objectionable
that
they
would
be
like
no
I.
Would
you
know,
refuse
that
this
implementation,
be,
you
know,
merged
into
our
new
kernel
or
something
like
that,
and
you
know,
let's
hear
you,
let's
hear
you
sooner
than
later.
If
you
don't
mind
I,
guess
that
would
be
okay,
so.
A
Call
to
action,
you
know
like
anyone
on
the
call-
and
you
know
other
people
online
who
may
have
opinions.
You
know
the
link
to
this
is
issue
number
19
on
the
equity
script,
modules,
repo
and
there's
also
like
a
whole
separate
repo
for
the
proposal.
Please
review
it
and
add,
add
notes,
Jeff,
I,
guess
one
question
would
be:
there
was
a
slight
change
of
behavior
that
was
introduced
in
guys
implementation.
That's
no
longer
using
it.
A
H
Yeah,
if
you,
if
the
proposal
was
written
kind
of
carefully
to
say,
like
you
know,
it
will
look
to
look
in
package
of
Jason
to
find
some
ESM
signifying
field.
You
know
whatever
that
may
be,
and
then
any
examples
that
talked
about
exports,
but
you
know
when
it
was
introduced.
It
was
like
this
is
outside
the
scope
of
the
proposal.
Whatever
it
turns
out
to
be
is
is
the
thing
if.
A
H
E
H
Think
that's
I,
don't
know
if
we
need
like
a
meta
proposal
to
to
describe
how
these
all
work
together,
but
like
it's
kind
of
like
whatever
we
decide
on.
If,
if
mode
is
gonna,
be
the
one
thing
that
turns
it
on
and
off,
especially
if
exports
then
applies
to
CGS,
so
then
it
shouldn't
be
considered
as
ESM
signifier.
You
know
these
are
all
easy
changes
to
make
when
I
don't.
A
A
I
think
it
might
be
a
good
idea,
then,
to
open
an
issue
on
the
modules
repo
I
was
specifically
to
discuss
like
what
can
those
mechanisms
in
the
package.json
be
because
it
sounds
like
that
may
actually
be
like
a
supplementary
proposal,
and
if
we
break
that
out,
that
may
also
make
it
really
clear
that,
like
hey,
the
algorithm
is
just
more
about
like
determining
it,
but
like
that
extension
to
the
algorithm
could
be
its
own
bike,
shed.
I.
Think.
H
D
So
the
modes
specification
is
only
like
eight
lines
because
of
the
way
it
fits
into
the
existing
proposal
is
so
simple,
so
it's
really
it's
actually
just
two
lines
and
then
the
most
the
rest
of
it
is
dealing
with
the
main
entry
point.
So
you
know
if
we
have.
If
we
want
to
look
at
other
options,
we
can
open
an
issue
to
maybe
explore
some
options
yeah,
but
but
that
spec
is
yeah
any
an
instance
of
what
what
the
package.json
feature
could
be.
D
Another
thing
just
to
mention
it
briefly
that
we
also
need
to
still
address
is
what
we
want
to
do
about
the
top-level.
If
we
want
to
have
a
special
flag,
that's
going
to
change
the
top-level
and
also
apply
to
evaluation,
and
we
probably
need
to
either
incorporate
that
into
one
of
the
existing
specs
or
add
a
new
spec.
For
that.
H
Okay,
if
I
add
to
that
miles
that
that
was
like
another
obvious
thing
that
came
out
of
your
feedback
miles
when,
when
you
looked
at
our
looked
at
the
proposal
was
like
I.
It
was
only
discussing
like
how
to
handle
an
import
statement
like
the
specifier
and
an
import
statement
like
import
file
that
Jas,
how
should
files
SJS
be
treated,
and
that
was
like
intended
to
be
the
scope
of
that
proposal
and
it
was
kind
of
like
well.
H
If
we're
actually
going
to
implement
this,
we
need
to
get
into
ESM
modes
somehow
from
outside,
like
node
space
main
dutch
is
or
whatever,
so
we
at
least
need
to
define
that
one.
So
then
we
added
that
to
the
spec,
but
it
does
raise
the
obvious
question:
it's
like
okay.
So
what
about
all
the
other
ways
that
you
can
you
know
get
into
launching
code
like
eval
or
standard
in
and
so
on
and
so
forth.
So
that
feels
to
me,
like
the
obvious
next
proposal,
that
we
need
to
write
and
hash
out
like
okay.
H
How
are
we
going
to
handle
all
these
other
cases?
I
think
that
could
be
a
standalone
proposal
unless
people
feel
otherwise
I
don't
know
if
it
should
be
part
of
stage
2
or
what
I
don't
know
if
it
is
part
of
loaders
or
tied
up
any
of
that,
but
you
know
I,
please
time
together.
What
did
you
guys
think.
E
Is
probably
getting
into
the
like
discussion
of
what
the
field
should
be
and
so
on,
but
I
continue
to
think
that
the
simplest
thing
is
a
straight
up:
map
of
extensions
to
default,
parse
mode
for
an
extension.
So
if
you
want
J
s
files
to
parse
as
if
they
were
MJ
s
files,
your
map
would
have
J
s
as
the
key
and
MJ
s
is
the
value,
and
that
would
continue
to
fit
in
well
with
required,
odd
extensions
and
also
with
you
know,
future
module
formats.
E
As
we
decide
what
the
default
extension
is
for
that
parsing
mode
I
feel
like
that
that
even
fits
under
your
20
character
requirement
guy
for
to
essentially
enable
Modi
SM
for
your
package
and
yeah
they're
like
Jeremiah,
is
asking
in
chat.
There
might
be
issues
to
work
through
there,
I
I,
don't
certainly
haven't
written
up
a
proposal
or
anything,
but
I
I
feel
like
whatever
solution
we
come
up
with
also
needs
to
not
privilege.
Esm,
like
you
know
what,
as
the
like,
the
one
module
format,
because
there
is
going
to
be
other
ones.
I
So
we
need
to
be
careful
when
we
talk
about
circularity,
almost
everything
where
we're
metaprogramming,
how
the
loaders
work
is
going
to
have
the
ability
to
claim
it
has
circularity
problems.
So
the
canonical
example
is
going
to
be,
if
I
add
a
loader
from
loader
j
s
and
that
loader
is
loaded
as
common
Jass
by
default,
because
we
haven't
changed
new
flags
and
that
loader
makes
all
dot
J's
files
treated
as
ES
modules,
not
as
common
J
s.
I
We
can
make
the
claim
that
it
has
a
circularity
problem.
That's
not
really
true.
If
you
look
at
how
other
environments
do
things
it's
around
this,
how
service
workers
work
and
things
like
that,
your
meta,
programming
and
instrumentation
are
treated
as
a
separate,
isolated
environment
and
they
use
the
runtime
guaranteed
primordial
forms
of
what
they
use.
A
Thanks
Brad
I
think
the
the
bit
that
I
was
curious
about
this.
So
like
we
have
the
mappings
that
you
were
talking
about
Jordan
as
a
possibility
and
I
guess,
you
could
have
like
ESM
as
like
one
potential
goal
or
like
CJ
s
or
wasm,
and
you
could
have
a
mapping
of
extensions
to
goals
or
minds.
But
we
may
have.
E
E
So
my
thought
was
whether
it's
extensions,
mimes
or
an
enum
of
mode
names,
which
that
one
doesn't
sound
very
scalable
to
me,
but
regardless
of
what
it
is,
it
would
be
in
a
package
JSON
and
also
you'd,
be
able
to
pass
those
values
by
command
line
flags
which
would
answer
the
you
know:
command
line,
questions
yeah.
A
E
A
E
Right
no
I
agree
with
that,
but
I'm
saying
that
if
we
cheers
so
you're
saying
a
mode
Assam
mode
string
that
could
be
later
expanded
to
be
in
mode
mapping
and
then
it's
just
a
question
of
what
the
value
of
the
string
is
and
it
could
be
an
extension,
a
mime
or
an
enum
yeah,
and
that
I
think
that's
reasonable.
I
think
that's
something
we
can
discuss
in
on
getting
up
somewhere.
Okay,.
D
You
sort
of
think
of
this
string
value
as
being
a
sort
of
the
IMDB
name.
Is
one
interpretation
and
then
you
know
we
could
add
new
ones
where
you
say
well
in
this.
In
this
mode,
you've
got
wasm
and
node
file,
so
load
automatically
or
another
nice
thing
is
we're
we're
no
longer
in
in
the
ezza
mode,
so
in
the
in
the
legacy
mode.
A
A
call
with
someone
from
any
p.m.
this
afternoon
I
can
bring
it
up.
We
have
one
meeting
one
minute
left.
We
still
have
quorum
really
cook
one
to
try
to
pass
through
before
we
closed
for
the
day.
We
have
the
package
exports
proposal.
We
didn't
actually
really
get
into
that,
but
a
quick
thing
on
that
proposal.
That
seemed
like
we
had
interest
in
bringing
that
proposal
just
to
note
court
as
something
that
could
work
in
CJ
s.
D
We
should
first
create
a
tracking
issue.
I
think,
to
track
how
the
spec
has
to
adapt
to
that
because,
as
mentioned,
it
requires
new
functionality
in
the
spec
that
doesn't
exist
right
now,
but
I
I
don't
have
any
objections
person,
sorry,
but
just
to
mention
that
clarification
on
this
bill.
Okay,
anyone
else.
H
I
think
we
would
have
to
describe
how
that
would
function.
What
the
UX
would
be.
We
were
talking
about
this
earlier.
What
would
the
UX
be
if
you
had
a
dual
mode
version
of
exports,
because
that
would
be
the
concern.
I
think
that
people
would
bring
up
would
be
like.
Is
this
too
complicated?
Now.
A
Okay,
let's
I
have
to
keep
that
in
my
native
rooms,
so
I've
got
to
end
this.
Let's
make
an
action
item
that
we
want
to
figure
out
some
of
those
edge
cases
before
we
bring
it
to
the
project,
but
it
seems
that
no
one
objects
to
this
being
beyond
just
the
module
goal.
Okay,
great!
Thank
you,
everyone
for
an
excellent
meeting
and
have
a
great
rest
of
the
week.