►
From YouTube: Extra Special Modules - Myles Borins, Google
Description
Speakers: Myles Borins
The Node.js modules team has finally got there! With Node.js 12.x we shipped a new implementation to our EcmaScript Modules (ESM) implementation with plans to unflag by LTS. This talk will cover the history of ESM in Node.js, the iterations of the implementation, and catch you up as to how things currently work.
This talk will cover content for Node.js application developers, Front End application developers, module authors, and anyone who is interested in how platform decisions get made.
A
A
A
I
could
just
do
this
for
20
minutes,
but
it
started
as
like
an
exercise
for
myself
to
just
kind
of
like
relax
during
a
talk
and
get
like
more
present,
but
but
over
time
it
actually
became
like
a
little
test
for
the
audience
because
I'm
a
little
silly
and
if
you
all
don't
laugh
at
that
I'm
in
like
big
trouble,
but
you
all
seem
pretty
cool.
So
this
should
probably
go
well.
A
So
my
name
is
miles
and
I
work
at
Google,
but
developer
advocate
focused
on
the
node.js
JavaScript
ecosystem
and
Google
cloud
platform,
and
then
you
know
this
thing
at
the
bottom
kind
of
laser,
so
I
can
show
to
you.
The
opinions
are
stressed
on
the
talk
on
my
own
I.
Don't
know
I
put
that
out
all
the
time
I've
never
gotten
in
trouble.
So
no
maybe
it
works
before
we
get
started
here.
A
I
started
doing
this
in
some
talks
a
bit
of
a
glossary,
so
the
topic
of
echo
script
modules
has
a
whole
bunch
of
like
buzzwords
that
we
use
and
a
handful
of
them
are
made
up
like
most
words,
so
I
thought
I
could
spend
some
time
going
through
them.
The
first
one
is
ESM,
which
is
short
form
for
FMF
scripts
modules,
ekkuva
being
the
European
computer
Manufacturers
Association,
which
is
where
the
JavaScript
language
is
specified.
A
You
may
not
be
able
to
read
my
handwriting,
so
I'll
walk
you
through
it,
but
at
the
top
we've
got
an
import
at
the
bottom.
We've
got
an
export,
so
this
is
a
little
bit
different
from
CJ
s,
also
known
as
common
J
s,
where
you
require
a
module
and
then
can
call
module
dot
exports
to
export
what
will
be
imported
by
someone
else.
These
are
two
fundamentally
different.
Loaders
CJ
asses
that
note
has
been
using
prakasha
deck
over
a
decade.
A
A
This
is
an
extremely
important
thing
for
our
ecosystem,
because
we
have
a
giant
repository
online
of
many
many
modules
and
moving
to
ESM
should
not
be
a
time
where
we
say
okay
well,
like
smell
you
later,
guy
is
you
know
we
want
to
keep
those
modules
being
able
to
be
used,
and
the
flip
side
is
when
we
have
a
whole
new
ecosystem
of
new
modules.
We
don't
want
to
necessarily
shut
folks
out
from
being
able
to
use
them.
We
can't
necessarily
make
it
as
ergonomic
as
possible.
A
We'll
do
our
best,
transparent
interoperability
is
the
ability
to
require
ESM
and
CGS,
or
import
CGAs
and
ESM
without
having
to
know
the
module
type
of
the
dependency.
We'll
talk
a
little
bit
more
about
transparent
interoperability
later
but
spoiler
alert.
It
doesn't
work.
Sorry,
we
tried
really
hard.
A
There
is
a
thing
called
the
goal,
which
is
a
pairing
of
a
top
level
grammar
and
a
top
level
execution
model,
and
don't
worry
if
it
doesn't
make
sense
to
you.
I
have
to
reread
what
that
means.
Every
time
I
give
this
talk,
we'll
dig
into
that
a
bit
more
later,
a
specifier,
that's
the
string
that
a
runtime
will
use
to
locate
a
module
so
right
there
you
can
maybe
see
at
the
top
it
says:
dot,
slash,
module,
J
s,
that
is
the
specifier.
A
Specify
our
resolution
is
an
algorithm.
That's
used
to
convert
that
specifier
into
the
path
of
a
module.
So
when
we
see
something
like
dot
slash,
how
do
we
figure
out
what
that
is?
If
we
in
node,
don't
include
the
dot
jeaious?
How
do
we
figure
that
out?
That's
the
specifier
resolu
barré
imports
is
a
specifier
that
does
not
start
with
a
relative
or
absolute
paths.
You'll
notice
in
here
require
underscore
import.
A
Lo,
there's
no
dot,
there's
no
slash,
there's
just
a
specifier
that
is
called
the
bare
specifier
and,
as
we
all
know,
that's
how
we
grab
things
from
the
node
modules
directory
and
it's
a
pretty
key
part
of
you
know
the
developer.
Experience
of
writing
modules
because
it's
really
nice
to
not
have
to
write
like
dot
dot,
slash,
underscore
a
node
underscore
module,
slash
and
like
know
the
path
to
all
the
things.
A
That's
kind
of
the
worst
dual-mode
modules
is
supporting
both
common
J
s
and
e
sm
entry
points
with
a
single
specifier
similar
but
different
than
transparent
Interop.
It
can
end
up
with
a
lot
of
the
same
behavior
that
we
wanted
to
see
in
transparent
Interop,
where
it's
like,
hey
I've
got
a
module
and
I
can
require
it
and
I
can
import
it.
A
But
it's
not
exactly
the
same
thing
because
we're
talking
about
you
know
like
kind
of
having
two
different
entry
points,
potentially
even
two
different
items
in
the
graph,
which
gives
me
the
willies,
but
I
got
over
it
and
then
finally
existential
dread,
which
is
the
feeling
I
get
trying
to
get
CJ
ass
and
ESM
to
play
nicely
together.
You
can
tell
that
I
have
a
theme
in
my
talks
today,
but
a
question
that
you
may
have
is
like:
how
did
how
do
we
get
here?
There's
a
lot
of
different
things
going
on.
A
Unfortunately,
it
was
ripped
out
of
the
standards
track
and
never
seen
again
and
es
for
as
a
whole
as
far
as
I
know,
never
really
became
a
thing
other
than
ActionScript,
which
I
think
was
an
implementation
of
it.
But
commonjs
was
then
introduced
afterwards
with
some
members
of
tc39
working
on
it.
But
it's
important
to
note:
common
jeff's
was
not
done
in
a
standards
track
and
it
was
primarily
created
specifically
for
server-side
JavaScript.
A
Some
of
the
decisions
that
they
made,
especially
having
asynchronous
inline
execution,
which
we'll
talk
more
about
afterwards,
is
very,
very
specific
to
the
sir
and
doesn't
really
work
well
for
the
browser.
No
js'
implements
a
variant
of
command
J
s
and
we
could
arguably
say
like
the
primary
reference
implementation
of
common
jeaious.
As
it's
known
today.
A
So
AM
D
was
only
like
SPECT
by
requirejs.
It
was
more
of
a
convention.
It
was
nice
because
it
was
a
synchronous.
It
worked
better
for
the
browser.
If
any
of
you
did
angular
back
in
the
day,
it
was
basically
AMD
and
UMD
was
a
thing
too.
In
case
you
like
couldn't
make
up
your
mind
and
just
wanted
to
ship
something
that
all
the
things
could
load.
It
was
really
fun.
I
used
to
I
used
to
use
browserify
to
make
UMD
bundles
all
the
time,
but
es
modules
landed
in
equi
to
62
in
2015.
A
So
you
know
we
could
have
the
future
of
modules
yesterday,
but
they're
not
here
yet
so
why
did
it
take
so
long
and
I
do
have
an
explanation
for
you
and
part
of
why
it
took
so
long
is
the
concept
of
a
loader
and
the
loader
is
actually
not
specified
in
equi
6?
This
is
actually
one
of
the
really
interesting
standards
hacks.
If
you
need
to
like,
if
you're
trying
to
standardize
something
you're
generally
like
building
consensus
around
a
large
group.
A
So
if
you
have
part
of
it
that
you
can't
build
consensus
around
the
easiest
way
to
get
over,
that
is
not
to
try
to
build
consensus,
but
just
not
specifying
it
so
the
loader
was
actually
never
specified
because
consensus
couldn't
be
reached
on
it.
So
the
loader
ends
up
being
defined
by
the
runtime
and
there's
kind
of
these
phases,
which
are
specified,
but
the
implementation
happens
in
the
embedder.
So
the
loader
has
these
different
workflows.
It
has
fetch
and
then
transform
and
then
evaluate.
A
Commonjs
has,
as
I
mentioned,
a
synchronous
note
load
an
inline
execution.
So
if
you
say
node
index
Jas
no
just
starts
executing
index.js
from
the
beginning
and
the
second,
you
hit
a
require
I'm.
Sorry
to
tell
you,
we
literally
do
FS
refile
sync
on
that
thing.
We
grab
that
thing
and
then
we
start
executing
that
thing
in
and
we
just
run
your
program
until
it's
done
and
if
you
have
things
on
the
event
loop
that
are,
you
know,
keeping
things
up
and
we
don't
stop
your
application.
A
But
it's
nothing
fancy
it's
just
like
we're
running
the
code
and
every
time
you
have
a
reference
to
another
module,
okay
cool.
We
run
that
code
and
one
of
the
important
things
here
is
that
there's
no
explicit
load
step.
It
just
kind
of
all
happens
at
once,
and
this
is
actually
how
Babel
originally
implemented
ESM
and
a
lot
of
how
people
first
experienced.
The
SM
was
like.
Oh
like
this
is
the
same.
A
We're
just
like
we'll
turn
all
the
imports
into
requires,
because
we
can
read
a
regular
expression,
but
it
turns
out
that
this
doesn't
work
because
es
modules
specify
an
asynchronous
load
and
a
synchronous,
execution
and
the
load
goes,
and
it
starts
from
the
the
root
of
your
graph.
It
fetches
that
it
parses
it.
It
finds
all
of
the
other
references
within
that
and
then
it
fetches
it
resolves
those
specifiers
and
then
it
loads
all
of
those
references.
And
then
it
figures
out
all
the
specifiers
and
those
modules
and
recursively
grabs
every
single
module.
A
That's
in
your
graph
that
goes
to
then
to
a
linking
phase
that
needs
to
have
the
graph
in
memory
and
then
in
pre
traversal,
oder
order.
So
going
from
the
root
down.
It
links
your
graph
removed
cycles
and
make
sure
that,
like
the
graph
is
laid
out
properly,
so
we
talked
to
a
pre
traversal
order.
So
if
this
was
your
graph
of
route
ABCD
in
the
fetch
phase,
the
first
thing
that
would
happen
would
be
that
we
would
load
the
route
we
would
parse
the
specifiers
of
the
route,
which
would
say:
hey.
A
A
So
if
we
wrote
this
graph
in
common
J
s
and
had
all
of
our
requires
statements
at
the
top
of
the
graph
and
all
of
our
module
that
export
statements
at
the
bottom
of
the
graph
we'd
have
very
similar
behavior,
but
because
command
J
s
is
in-line
synchronous.
If
you
had
any
statements
in
between
the
require
calls.
You'd
have
slight
differences,
because
ESM
will
always
execute
in
this
order,
where
the
first
node
that
executes
is
the
bottom
most
left,
node
C
will
execute
because
it
has
no
other
dependencies.
It
will
then
export
its
symbols.
A
Then
D
will
execute
and
export
its
symbols,
then
a
because
it's
dependencies
are
now
available
will
similarly
execute
an
exported
symbols.
Then
B
will
execute
an
exported
symbols
and
then,
finally,
last
but
not
least,
the
root
can
execute
and
what's
fundamentally
different
about
this
compared
to
common
Jas
is
there's
no
way
that
the
root
will
execute
anything
before
the
rest
of
the
graph
is
done,
whereas
commonjs
you
could
have
a
whole
bunch
of
things
before
a
require
statement,
and
all
of
those
would
be
guaranteed
to
execute
now.
I
made
a
bunch
of
strong
claims.
A
Top-Level
await
kind
of
makes
this
a
little
bit
less
clear.
It
changes
the
synchronous,
execution
guarantees
specifically
like
in
this
graph.
If
we
said
that
like
see
how
to
top-level
await
here,
C
would
defer
D
would
execute
and
export
its
symbols.
If
C,
it's
still
not
finished
resolving,
then
B
would
execute
and
export
its
symbols
and
then
finally
C
and
then
a
and
then
the
root
we
do
bookkeeping
within
the
VM,
so
that,
like
disconnected
graphs,
are
able
to
execute
generally.
A
If,
if
you
have
top-level
await
you'll
continue
getting
the
the
execution
order,
that's
expected,
except
for
the
parts
of
the
graphs
that
deferred
but
like
this
loader
is
not
entire
entire
ly
specified
as
I
mentioned,
and
it's
implemented
by
the
embedder,
and
as
I
mentioned,
you
can't
simply
convert
common
js2
es
m
and
just
a
little
bit
more
of
a
difference.
The
specifier
resolution
algorithm
that
I
mentioned
is
also
not
specified,
and
it's
different
so
to
see.
A
30
leaves
it
to
the
hosting
environment
to
determine
how
you
take
a
specifier
and
then
turn
it
into
a
resource.
Nodejs
and
common
jeaious
has
a
very
specific
resolution
order,
which
many
of
us
are
probably
familiar
with.
It
supports
bear
imports,
which
are
great,
because
that
allows
you
to
npm
install
stuff
and
just
get
them
by
the
symbol
that
you'd
know
it
by
it
allows
you
to
import
JSON.
It
can
support
that
and
understand
what
JSON
is
it
allows
importing
native
dependencies.
It
allows
optional
file
extensions.
A
You
don't
need
to
include
the
file
extension
for
the
module
that
you're
importing.
It
also
allows
you
to
require
a
directory
that
has
an
index
index.
Cas
in
it,
if
you're,
if
you're
ever
curious,
to
learn
more
about
the
CJS
resolution
algorithm,
if
you
look
at
modules,
dot,
markdown
or
just
the
modules
documentation
inside
of
the
node
repo
there's,
actually
a
spec
text
outlining
the
actual
algorithm
for
the
resolution
algorithm
in
in
common
Jas.
A
Now
this
is
like
a
problem
because
you
know,
if
we're
talking
about
wanting
to
have
interoperability
with
another
platform
like
the
web.
Well,
the
web
doesn't
support.
Bear
imports
so
like
right
away
from
that.
First
point
like
we
already
have
a
divergence,
but
thankfully
there
is
a
proposal
happening
at
ycg,
which
is
the
web
incubator.
Community
group
within
w3c
called
import
maps.
Import
Maps
would
allow
you
to
support
their
imports.
It
would
allow
you
to
do
deep,
traversal
by
filename.
It
would
also
allow
you
to
do
deep
module
traversal
by
reference.
A
This
doesn't
get
you
all
of
the
niceties
of
the
common
jeaious
algorithm.
It's
most
notably
missing
is
a
file
extension
resolution
and
directory
resolution,
but
it
gets
us
like
90%
of
the
way
there,
which
actually
may
bother
people
more.
But
what's
really
great
about
this?
Is
it's
like
a
consistent
thing,
and
this
is
what
an
import
map
would
look
like
a
very
straightforward
import
map
where
you
have
momen
and
lodash,
and
it
specifies
the
node
modules
folder
on
the
entry
point.
A
What's
really
cool
about
this
format
is
that
we
can
generate
this
from
the
package
JSON
zap
out
of
the
existing
packages,
so
a
tool
like
NPM
or
yarn
or
P
NPM
or
a
tool.
You
may
write
sometime
in
the
future
and
an
install
time,
install
all
your
modules
and
generate
an
import
map
for
you
so
that
you
can
have
the
same
node
modules
folder
be
supported
both
by
a
browser
and
by
node,
but
that's
also
kind
of
making
the
assumption
that
everything
else
works.
A
A
If
you
want
to
play
with
it-
and
you
know
see
what
the
the
future
of
modules
in
the
browser
would
look
like,
if
it
wasn't
enough
code
executes
differently
to
between
these
different
modes,
they
have
a
thing
called
a
goal
which
we
talked
about
before,
and
you
know
what
there's
four
types
of
goals
and
when
I
list
these
four
types,
then
all
of
a
sudden
you're
like.
Oh
that's
what
a
goal
is:
there's
script,
strict
script,
sloppy
es
module,
nodejs
cool,
that's
like
the
really
high
level
naive
way
of
thinking
about
it.
A
There's
old-school
scripts,
where
you
didn't
say
you
strict
at
the
top.
That
has
a
particular
thing
in
certain
features
that
are
available.
If
you
say
you
strict,
then
other
features
are
available
in
the
es
module
goal,
there's
even
more
restrictions
and
then
the
new
j/s
goal
has
like
you
know,
a
whole
bunch
of
things
that
are
specific
to
it.
So
when
we
talk
about
that
top-level
grammar,
that's
kind
of
the
strict
mode
versus
sloppy
mode
and
certain
things
that
are
limited
based
on
using
that
pragma.
A
But
the
module
goal
has
additional
grammar
changes
on
top
of
strict
mode,
so
it's
already
got
all
the
things
that
strict
mode
it
no
longer
allows
you
to
use
HTML
comments.
I
know
many
of
you
in
the
room
may
have
just
figured
out
that
you
can
use
HTML
comments
in
JavaScript.
So
sorry
to
take
it
from
you
right
when
you
got
it,
a
weight
is
a
reserved
keyword.
This
is
actually
really
important,
because
a
weight
being
a
reserved
keyword
is
exactly
what
a
carved
up
the
space
for
top-level
await
to
be
able
to
be
specified.
A
These
divergences
could
potentially
increase
over
time
in
general.
Tc39
has
a
matter
of
like
not
breaking
the
web,
so
I.
Don't
think
that
we
should
expect
any
significant
changes,
but
it
is
possible,
and
so
it's
possible
to
take
code
that
could
run
in
strict
mode
run
in
sloppy
mode
without
a
problem
would
throw
when
you
run
it
in
the
ESM
goal.
A
But
what
gets
really
strange
here
is
es
modules.
Don't
have
an
in
source
way
of
determining
the
goal,
so
there's
a
pragma
that
you
can
use
to
switch
between
strict
and
sloppy
mode,
but
there
is
no
in
source
way
of
doing
it
for
modules
in
the
browser.
If
you're
loading,
a
module,
you
say,
type
module
in
the
script
tag
and
the
script
tag
knows
to
send
it
to
the
right
parser
they
doesn't
exist.
There
is
no
pragmas,
so
for
node.
That
became
a
challenge
for
us.
How
do
we
know
the
difference?
A
And
on
top
of
this
there's
other
potential
future
rules
that
could
exist?
That
could
be
webassembly
HTML
modules,
web
package,
binary
AST?
These
are
all
potential
goals
that
could
be
imported
in
the
future.
Another
thing
that's
different
between
the
two
is
that
ESM
does
not
have
a
way
to
inject
lexically
scoped
variables.
A
Cj
s
has
lexically
scoped
variables.
Every
time
that
you
require
a
module.
We
wrap
that
module
in
a
lambda.
We
inject
a
whole
bunch
of
stuff.
I
mean
like
now
it's
a
little
fancier
v8
has
an
API
but
like
for
a
while.
It
was
literally
just
string,
concatenation,
sorry,
but
the
lexical
scope
variables
that
you're,
probably
used
to
using
include
underscore
underscore
file
name,
underscore
underscore
dur
name
require
and
module.
A
These
are
all
things
that
are
available
to
you,
as
if
they're
Global's,
but
they're,
not
actually
Global's
because
require
is
very
much
scoped
and
has
context
as
you
file
named
our
name
and
module
to
the
module
1,
which
is
running
and
when
node
execute
your
code.
We
are
instantiating
those
objects
based
on
the
file
path
of
your
module
and
then
injecting
them
into
the
closure
scope
of
the
module
when
it's
executing
echo
script
modules
have
something
kind
of
like
this.
It's
called
import
meta
and
we're
able
to
put
meta
information
in
to
import.
A
So
the
primary
one
that
we
use
in
nodes
is
module.
Implementation
is
import
meta
URL,
which
gives
you
the
URL
path
to
the
module
that's
executing
and
from
import
meta.
You
are
l.
You
can
recreate
a
lot
of
the
things
that
were
included
in
in
the
common
J's
lexical
scope
variables.
You
could
figure
out
the
file
name,
you
can
figure
out
the
directory
name.
You
can
use
an
API,
we
have
called
create,
require
to
make
an
instance
of
the
require
function.
You
know
is
not
perfect
that
it
gets
us.
A
It
is
equi
script
compliant,
and
that
does
make
it
harder
for
us
to
do
all
the
things
that
we
would
like
to
do,
but
it
also
makes
it
closer
to
having
an
environment
where
we
can
share
these
modules.
In
you
know
various
runtimes
es
m-files.
You
need
to
use
the
MJS
extension.
I
know
what
you're
thinking
unless
you
set
the
type
to
module
in
the
package.json
Jeff,
who
is
up
here
in
the
front
row,
is
one
of
the
people
who
helped
kind
of
get
that
going.
A
So
if
you
in
your
package,
JSON,
say
type
module,
then
you
can
use
js4
es
modules.
What
it
does
mean,
though,
is
you,
can
no
longer
use
Jas
for
common
J's
modules,
so
you
can
use
CJ
s.
There
is
support
for
bear
imports
and
support
for
dynamic
import,
so
dynamic
import
is
a
function.
You
give
it
a
specifier
and
it
returns
a
promise
to
evaluate
to
the
module
dynamic
import
along
with
top-level
Oh.
A
Eight
is
a
cool
way
of
recreating
some
of
the
dynamic
requires
stuff,
although
it's
not
necessarily
a
best
practice,
but
there's
times
where
you
may
want
to
do
that,
like
internationalization
or
lazy
loading
and
the
browser.
There's
reasons
why
you
may
want
to.
We
also
support
import
meta,
dot
URL,
but
there
are
some
limitations
to
our
implementation.
The
full
file
path
is
mandatory
and,
like
maybe
full
file
path,
is
not
the
right
way
to
put
it
because
you
can
put
relative
paths,
but
you
can't
you
have
to
include
the
extension.
A
If
there's
an
extension,
there
is
no
support
for
folder
resolution.
You
can't
import
a
directory
that
has
an
index
dot
JSON
in
index
c
JS.
If
you
import
a
common
J's
file,
there
is
no
named
imports.
Trust
me:
we've
tried
to
make
this
work
in
a
way
that
would
be
spec
compliant,
but
it
is
at
the
moment
not
possible
we're
going
to
continue
to
try
to
see
if
we
can
figure
out
a
way
to
make
that
work,
but
we
do
have
some
cool
things
that
we've
done.
A
I'll
show
you
in
a
minute
that
can
emulate
this
experience
with.
Just
you
know
a
little
bit
of
configuration,
there's
only
experimental
support
for
import
for
importing
JSON.
You
need
to
include
a
flag.
We
are
working
on
standardizing
that
upstream,
so
that's
some
stuff
that
we
are
still
working
on
and
there's
no
support
for
requiring
of
esm.
This
is
not
something
that
is
easily
accomplishable.
A
This
is
unflagged
in
13
today,
I
think
it's
one
of
the
coolest
things
that
we
worked
on.
It's
supported
in
both
commonjs
and
in
ESM
in
13.
It
allows
you
to
specify
the
exports
of
your
module.
This
creates
a
public
and
private
interface
for
your
module.
For
this
specific
module,
the
dot
is
the
equivalent
to
main.
So
if
you
import
it
or
required
it,
you'd
get
the
index
J
s,
and
if
you
imported
the
module,
slash
CJ
s,
you
would
get
index
TGS.
If
you
tried
to
deep
import
any
other
file,
it
will
throw.
A
So
this
is
a
huge
departure
from
how
things
had
worked
before
and
allows
you
to
define
the
interface
of
your
module.
It
allows
you
to
make
sure
that
people
are
not
going
to
be
deeply
going
in
and
grabbing
things
that
you
don't
want.
It
is
possible
with
it
with
the
export
map,
though,
to
use
an
asterisks
or
a
directory
to
map
directories.
So
you
can't
still
recreate
part
of
the
deeps
reversal
system,
but
it
would
be
you
know
more
defined
and
more
of
an
explicit
interface.
A
You'll
also
notice
that
there
is
a
main
here
that
main
will
get
shadowed
by
the
dot.
In
a
version
of
node
that
uses
exports,
it
will
never
load
the
main,
but
what
the
main
does
allow
you
to
do
is
have
legacy
support
for
versions
of
node
that
are
pre
exports,
so
you
can
transpile
a
version
of
your
package
that
will
work
on
older
versions
of
node,
throw
that
entry
point
into
the
main,
and
now
you
can
support
both
new
node
and
old
node.
A
So
this
is
an
experimental
thing
that
we're
really
excited
about
called
conditional
exports.
So
you'll
notice
here
that
we
have
the
dot
and
then
we
have
a
module
entry,
a
node
entry
and
a
browser
entry
node
will
only
support
the
node
of
module
entries
and
the
module
entry
will
work
for
the
ESM
loader.
The
node
entry
will
work
for
the
common
jeaious
loader
and
then
other
environments
can
extend
this
object
with
whatever
data
they
want.
A
We're
going
to
ignore
it,
but
a
tool
such
as
babel
or
web
pack
or
you
know,
roll-up-
could
use
the
browser
entry
to
know
hey
like
if
we're
in
a
browser
environment.
This
is
the
entry
we
want.
One
of
the
things
that's
really
cool
about
export
maps.
Is
you
almost
have
a
one-to-one
ability
to
convert
the
export
map
into
an
import
map?
One
of
the
things
that
we
worked
on
really
hard
is
that
the
module
loader
that
we
have
is
almost
feature
equivalent
to
the
browser
loader
when
import
Maps
land.
A
So
with
all
of
this
made
metadata,
you
could
have
a
tool
that
could
go
and
generate
import
map
for
the
browser.
So
node
would
know
how
to
read
the
node
modules
folder
and
load
all
the
files.
You
would
want,
and
then
in
the
browser
you
would
just
include
the
import
map
as
a
script
tag,
and
then
you
could
be
importing
all
the
same
modules
and
package
authors
would
be
able
to
hide
the
implementation
details
of
the
differences
between
packages.
A
In
my
talk
earlier
today,
I
talked
a
little
bit
about
universal
JavaScript
and
the
difference
between
kind
of
the
API
and
the
plumbing.
This
is,
in
my
personal
opinion,
the
exact
same
thing
in
action.
It
allows
package
authors
to
worry
about
the
plumbing
of
how
this
all
wires,
but
from
a
consumer
perspective
it
just
works.
The
conditional
exports
may
change,
so
we
may
be
changing
a
module
to
import
and
entry
and
having
a
require
flag.
What
there's
an
issue,
if
you
have
feelings,
check
out
the
modules
repo
we're
debating
it
almost
done
here.
A
Thank
you
for
your
patience.
This
is
one
of
the
coolest
ones.
I'm
really
excited
about
this.
This
is
called
self
reference
modules
and
you
could
turn
on
with
experimental
resolve
self.
Both
conditional
exports
and
self
reference
modules
can
be
turned
on
on
thirteen,
with
the
experimental
modules
flag,
with
self-referential
modules,
you
can
import
yourself
by
your
module
name
where
this
is
extremely
great
and
my
personal
opinion
is
for
tests
and
for
examples.
You
can
actually
test
the
interface
that's
exposed
to
people
who
are
using
your
package
with
export
maps.
A
This
is
extremely
important
because
it's
the
only
way
to
actually
test
the
interface
that
you're
exposing
with
the
export
map.
The
other
thing
that
becomes
really
cool
for
examples
is:
you
can
now
have
code
in
your
examples
that
can
literally
be
copy
and
pasted
and
just
work
previously.
You
were
limited
to
either
a
having
examples
that
didn't
work
inside
of
your
repo
or
be
having
examples
that
use
relative
paths
for
the
modules
or
you
have
to
do
some
gross
things
with
symbolic
links
which
never
works
out
well
to
kind
of
wrap.
A
A
There
is
the
possibility
that
we
may
come
up
with
another
alternative
way
of
accomplishing
this.
It
hasn't
come
up
yet
so
it
is
looking
like
conditional
exports
will
be
unflagged.
Then
we
are
aiming
to
back
port.
All
of
these
changes
to
node
J
s12
LT
s
and
q1
20,
but
still
behind
a
flag
unflagging
in
node
12
by
q2
20.
So
the
hope
would
be
that
at
some
point
in
the
second
quarter
of
next
year,
unflagged
modules
would
exist
in
both
12
and
13,
and
you
know
we're
all
hard
at
work
on
this.
A
To
ensure
modules
is
a
best-in-class
experience
and
node,
and
you
know
a
good
base
for
universal
packages,
and
so
thank
all
of
you
for
being
really
patient.
As
we've
figured
this
out,
it's
been
a
bit
of
an
uphill
battle,
but
I'm
pretty
excited
with
where
we're
at
on
this
right
now.
It
feels
like
we've
really
managed
to
cover
a
good
chunk
of
the
use
cases.
I
still
know,
there's
things
that
we
need
to
handle
with
loaders,
especially
when
we're
talking
about
like
testing
or
stubbing,
but
you
know
we're
still
working
on
it.