►
From YouTube: Node.js Foundation Modules Team Meeting 2018-11-07
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
now
live
on
YouTube.
This
is
the
November
7
2018
edition
of
the
modules
team
meeting.
We
have
a
full
agenda
and
we
have
quorum
right
now,
which
is
exciting,
we'll
jump
right
into
it.
The
first
agenda
item
that
we
have
is
adding
raizou
koukin
as
an
observer.
Does
anyone
object
to
adding
them
as
an
observer
to
the
meeting
no
objections
we
can
move
forward
with
that
I'll
take
care
of
adding
them
in
the
github.
I
am
the
next
one
that
we
have
at
is
be
McNaughton
requesting
for
an
observer
status.
A
Do
we
have
any
objections
to
that
awesome
that
goes
through
next,
we
have
ESM
refactor,
dynamic
modules.
I
believe
that
this
was
something
that
Gus
was
running
with.
Gus
is
your
microphone
working
today
could
be.
It
appears
to
be.
Do
you
want
to
explain,
what's
going
on
here
with
issue
with
the
pull
request,
9
on
echo
script
modules,
sure.
B
Okay,
basically,
following
a
big
refactoring,
slash
feature
edition:
I
did
two
core
I
was
able
to
change
our
dynamic
module,
wrapper
to
use
a
single
module
wrap
instead
of
two
module
wraps
yeah.
It's
it's
not
a
behavioral
change,
it's
just
a
refactoring,
so
I
mean
it's
just
like
a
pretty
basic
optimization
to
you
know
help
with
making
this
go
faster.
B
C
C
B
It
is
still
there
basically,
instead
of
calling
a
function
when
the
second
module
is
evaluated,
I
call
a
function
when
the
first
module
is
evaluated
and
the
basically
the
second.
There
were
two
modules.
The
first
one
was
evaluated
immediately
contained
a
mapping
of
exports
and
the
second
one
was
inserted
into
the
actual
big
module
graph
and
evaluated
in
the
correct
place
where
it
should
yeah.
A
B
The
rest
of
valuation
I've
effectively
gotten
rid
of
the
first
one.
The
second
one
is
the
only
one
that's
left,
and
basically,
instead
of
calling
the
function
that
is
injected
into
it
via
the
completion
value
of
evaluating
it,
it's
doing
it
by
calling
import
metadata,
which
is
injected
like
basically
like
bye-bye
lazy
evaluation
of
initializing.
The
import
data
object.
Okay,.
A
C
A
Gonna
interrupt
for
a
second
I'm
sorry,
but
this
is
specifically
about
approving
the
PR.
Isn't
it
necessary
to
dig
into
for
the
abroad
and
that's
why
that's
why
I
can
get
more
details,
laughs,
I'm,
sorry,
yeah,
no
problem
so
quickly
to
those
in
Gus
and
Salah.
Sorry
for
cutting
you
off.
We
just
have
a
limited
agenda
time
for
this
item.
Do
we
have
any
objections
to
landing
this
PR
and
then
an
extra
question
for
you
all,
because
this
is
changing,
something
that
exists
in
the
upstream
implementation
and
we
have
to
rebase.
A
Salah
you
have
your
hand
up.
Is
that
in
relations
to
this
no
I
acted
them
lower
it!
Sorry
Gus.
Would
you
be
able
to
take
the
action
item
of
landing
this
in
the
ACMA
script
modules,
repo
and
up
streaming
it?
You
know,
okay,
awesome
thanks!
Everyone
onto
the
next
item
on
the
agenda
is
another
five
minute
item
ads
ad
formal
distinction
to
Phase
two.
We
could,
potentially,
you
know,
use
less
time.
That'd
be
nice
guy.
This
is
yours.
Would
you
be
able
to
start
the
discussion
on
this
sure.
D
A
Looks
like
we're
good
to
land
it
guy.
Would
you
would
you
take
the
action
item
of
landing
that
pull
request
and
kicking
off
the
necessary
discussions
to
move
it
forward?
Sure
I
can
do
that
excellent.
Thank
you.
So
we
have
a
very,
very
quick
update
on
progress
from
Sola
about
the
surveys.
This
is
a
one
minute
item
so
lot
to
you.
Yeah.
C
C
E
Sorry
I
forgot
about
the
hand
rising.
Is
there
a
specific
list
of
what
we
still
need
to
do,
or
is
it
basically
just
a
big
okayed
of
stuff
that
needs
to
be
done.
C
I
think
it's
at
a
point
where
people
really
have
to
to
come
up
with
the
questions
they
want
to
see
answered.
I,
don't
want
to
push
questions
which
I
know
should
be
answered
because,
like
I'd
rather
be
the
one
who's
orchestrating
and
helping
the
process
doing
whatever
needs
to
be
done,
but
the
questions
have
to
come
from
people
who
you
know
have
direct
relationship
with
the
outcomes
of
those
questions
I'm
happy
to
help,
but
I
cannot
do
it
on
behalf
of
them,
because
it
will
be
very
counterproductive
to
get
results
from
such
questions.
E
So
the
reason
I'm
asking
is
because
this
survey
yeah
so
the
reason
I'm
asking
is
because
we
have
this
survey
topic
open
for.
While
now-
and
it's
seems
like
the
last
couple
of
meetings-
it
was
always
a
I
guess
we
should
make
progress
and
please
let's
make
progress
but
I'm
missing
the.
What?
What
are
the
thing?
That's
right.
So
if
I
don't
have
additional
questions,
what
can
I
do
anything
should
I
make
decisions
on
anything?
Should
I
sign
off
on
anything
to
make
it
happen.
The.
C
Conclusion
was
the
questions
that
we
have
so
far
were
like
dummy
questions.
At
best
they
were
questions
with
a
lot
of
effort
and
a
lot
of
thoughts,
but
they
were
not
the
questions
that
people
wanted
to
see
in
the
survey,
so
so
the
then
we
left
it
at
okay.
So
what
questions
would
everyone
like
to
see
there
I'm
not
in
the
position
to
write
those
questions
unless
I
get
input
from
people?
Who
would
like
to
see
the
questions
written
in
a
particular
way?
Hey.
A
Okay,
thank
you
very
much.
The
next
item
that
we
have
on
the
agenda
is
keeping
echo
script
modules
up
to
date.
This
is
one
I
believe
it
was
opened
by
Gus.
We
have
the
echo
script
modules
repo.
Now
that
has
not
been
actively
rebased
against
master.
We
do
need
to
be
like
kind
of
keeping
an
eye
on
things
and
making
sure
if
there's
conflicts,
those
are
getting
fixed.
There
is
a
process
in
place
that
has
been
done
by
other
Forks
that
we
use,
such
as
our
canary
fork
and
our
v8
fork.
A
I
believe
that
Michael
who's
on
the
call
can
talk
a
little
bit
about
that
so
I'll
just
kind
of
leave
it
to
everyone.
We'd
love
to
reach
consensus
in
this
meeting
about
specifically
how
we're
going
to
manage
that
repo,
how
we'll
rebase
it
and
whether
or
not
we
want
to
have
you
know,
pull
requests
open
or
some
sort
of
way
of
like
auditing
when
it
was
rebased
and
what
changes
were
you
needed
to
be
made
so
I
kind
of
leave
it
to
the
floor.
A
D
Wondering
if
we
could
not,
because
it's
a
regular
process
and
it's
nice
to
be
able
to
have
review
on
it,
but
it's
difficult
to
review
when
it's
the
kind
of
a
forced
push
process.
So
if
we
could
maybe
have
some
kind
of
two
branch
model
where
we
have
the
the
last
good
rebase
and
then
someone
does
a
new
rebase
like
a
current
rebase
branch
and
then
we
can
check
the
diff
afresh
against
and
then
we
have
a
yeah
exactly
last
known
good
revision.
And
then,
if
we
have
another
branch,
that's
tracking
node
master.
D
We
could
run
a
PR
from
the
latest
rebase
against
master
review
it
on
that
PR
and
then
have
an
actual
make
sure
that
it's
it's
had
some
kind
of
sign
off,
maybe
even
in
the
meetings
to
say,
let's
review
the
latest
rebase
or
something
just
in
case
there
are
conflicts.
I
am
not
familiar
with
the
other
processes,
but
that's
just
what
I
was
thank
you.
G
D
Guy
who's
got
your
hand
up.
So
just
agreeing
with
Jordan
there
and
kind
of
what
I
was
in
visited
visiting.
If
we
could
do
a
PR
model
was
each
PR
would
be
the
full
implementation
of
the
minimal
repo
rebased.
So
it's
every
commit
from
our
first
commit
on
the
minimal
repo
to
the
last
for
each
each
time
being
reviewed.
Do.
A
D
A
H
So
of
just
to
wait
here,
this
is
pretty
much
exactly
what
we
do
on
the
cannery.
For
so
what
happens
is
there's
a
CI
job
that
runs
daily
and
it
just
auto
read
basis
and
force
force
butters
to
that
branch,
and
in
case
there
are
any
like
build
failures.
If
there
are
any
much
conflicts,
then
it
just
sends
an
email
to
to
Michael
and
me,
and
somebody
just
looks
into
it
and
souls
the
issue.
A
A
B
A
Raizou
again,
if
you
could
take
the
action
item,
I'm
just
kind
of
documenting
what
you
just
said
inside
of
the
issue,
and
maybe
we
can
have
the
build
working
group
about
spinning
this
up.
It
seems
like
it
would
be
more
or
less
a
copy/paste
of
the
canary
one,
just
changing
the
target
repo
totally
take
that
up
yeah
and
then
what
all
we
would
need
to
do.
H
Totally
just
one
single
problem,
as
we
discussed,
it's
usually
a
mess
to
review
those,
but
as
soon
as
like,
once
the
like,
the
conflicting
commits
minus
one
commits
our
force
pushed.
Then
it's
pretty
easy
so,
like
maybe
you
could
find
out
another
way
to
just
reach.
Consensus
on
you
know,
force
pushing
everything
except
for
the
change
that
needs
to
be
done
to
turn
CI
agree,
because
otherwise
it's
just
too
much
of
a
mess
to
review.
Those
feels,
like
just
months,
went
into
one
of
those
if
I'm
not
wrong.
Okay,.
A
Do
you
want
to
then
just
suggest
the
full
process
that
we
can
move
forward
with
and
I
guess
like?
Maybe
in
the
meantime,
we
can
just
do
a
one-off
with
Gus
rebasing
keeping
it
up
to
date
with
where
it
currently
is
because
I
think
we're
a
couple
weeks
behind
and
Gus.
If
there's
any
conflicts
in
where
it
is
right
now
we
can
just
open
an
issue
to
manage
like
sign
off
on
that
one
conflict
or
open
a
pull
request
to
fix
that
one
conflict
that
seemed
to
work
for
everyone,
I'm.
A
A
So
that
wraps
up
that
agenda
item
the
next
one
that
we
have
coming
up
is
a
ten
minute
item
from
guy
on
the
Dinah.
The
status
of
dynamic
modules,
I'm
gonna
have
to
drop
now.
So
if
someone
else
can
take
up,
sharing
I've
made
Brad
the
host.
If
someone
else
can
would
someone
else
volunteer
to
be
managing
the
time
clock
and
moderating
I
can
help
with
that.
Okay,
thanks
guy,
everyone
have
a
great
meeting,
sorry
to
have
to
leave
early
excited
about.
D
D
We
only
know
the
export
names
after
we've
exported
the
module
and
everything's
been
written
on
to
the
exports
object
and
that
being
a
server
breaking
of
invariance,
because
in
common
jeaious
you
don't
want
it
executing
out
of
order
with
everything
else
in
the
es
module
tree.
You
want
commonjs
execution
failures
to
happen
at
their
correct
point
of
execution
in
the
graph,
and
you
want
predictable
execution
when
you
have
ordered
imports.
D
And
so
we
basically
got
what
ended
up
as
an
Ogier
specification,
which
is
at
the
github
repo
dynamic
modules
on
the
no
JS
organization
and
that's
a
spec
to
basically
allow
the
special
type
of
dynamic
modules
to
define
their
exports
during
the
execution
phase,
which
is
currently
not
permitted
in
the
es
module
semantics
that
are
defined
in
equal
to
six.
Two
and
there's
a
few
s
tarek
edge
cases
around
that
stuff.
Like
what
happens
if
you've
got
a
dynamic
names
namespace
in
a
circular
reference
that
star
e
exports
from
a
dynamic
module.
D
And
then
you
don't
know
what
the
export
names
are
and
we
kind
of
solved
those
by
creating
a
sort
of
a
tdz
and
throwing
in
those
cases,
all
of
that
stuff
worked
out
fine
and
it
involves
a
very
small
spec
change
to
tc39,
which
tc39
said
they
wanted
implementation
feedback.
So
we've
got
an
implementation
in
v8.
Now
that
does
all
the
stuff
does
all
the
error,
handling
and
I've
worked
with
George
and
yang
on
it
and
they've
given
feedback.
D
So
the
situation
at
the
moment
is,
it's
all
worked
out,
it's
all
possible
and
the
it's
going
to
be
mentioned
that
the
tc39
meeting
at
the
end
of
this
month
and
the
goal
with
that
is
basically
to
get
a
provisional
approval
of
the
the
spec
changes
that
we
need
in
equity.
Six
to
a
provisional
approval
that
if
v8
wants
to
merge
it,
then
tc39
will
be
behind
it
and
then
that'll.
D
Allow
us,
as
noted
to
say,
do
we
want
to
merge
it
and
if
we
want
to
then
v8
converted,
so
it's
kind
of
a
three
layer
thing
and
we're
getting
permission
from
the
lower
layers
that
we
know
it
can
work
out
at
the
end
of
the
day.
What
it
means
is
that
we,
as
a
modules
working
group,
can
assume
that
we
can
support
named
exports
from
common
J's
while
respecting
execution
order
in
the
graph.
D
If
anyone
wants
to
go
into
the
deeper
details
on
the
spec,
please
feel
free
to
open
an
issue
and
discuss
any
of
the
stuff
with
it
honored
with
me.
But
apart
from
that,
if
we
wanted
it's
there,
if
we
don't
want
it,
it
doesn't
have
to
go
through,
but
that's
basically
what
what
the
situation
is
today,
Jordan
yeah,
have
you
got
your
hand
up
there.
G
Yeah
I
was
just
gonna
say
we
I
got
that
on
our
radar
that
pr2
the
spec
for
the
editor
group
today.
So
we
should
hopefully
have
it
to
a
point
where
it's
mirja
Bowl
with
consensus
and
run
the
meeting
at
the
end
of
this
month.
Hopefully,
I
don't
know
if
that
would
be
soon
enough
to
get
that
consensus,
but
the
sooner
we
can
merge
that
the
better
great.
D
D
There
were
two
small
spec
changes
that
were
needed:
I'm
just
seeing
if
I
can
find
the
link,
for
you
know
in
the
status
issue,
though
so
there's
a
link
to
the
PR,
but
basically
two
things.
The
one
is
that
we
need
to
be
able
to
throw
during
the
instantiation
phase.
If
you
have
starry
exports
from
a
dynamic
module,
then
it
in
turn
being
imported
as
a
namespace
in
an
in
a
circular
graph
with
a
leaf.
D
That's
necks,
acute
'add
that
exposes
that
namespace
to
functions
before
the
dynamic
module
itself
is
executed,
so
that
that
was
just
saying
that
we're
allowed
to
throw
in
the
get
exported
names
function
and
then
the
other
one
is
just
because
of
the
fact
that
you
need
to
track
those
namespaces
to
kind
of
say
if
you've,
if
you've
got
a
namespace,
that
star
exports
from
one
of
these
dynamic
modules
and
that
namespace
is
exposed.
D
We
need
a
way
to
know
what
all
those
namespaces
are,
because
those
namespaces
are
created
during
instantiation
and
then
need
to
be
extended
with
the
exports,
the
dynamic
module
that
were
added
at
execution,
because
the
the
sort
of
phases-
and
so
just
adding
one
parameter
to
the
get
exported
names
function.
So
we
can
track
all
the
namespaces
that
star
export
from
dynamic
modules.
It's
it's
super
esoteric,
I'm.
Sorry,
I
can't
explain
it
more
clearly.
I.
I
Think
I
understood
well
frankly,
first
of
all
I'd
like
to
say
this
is
a.
D
I
D
D
B
D
D
D
D
Alright,
so
resolve
a
spec,
it's
PR
number
12
and
equity
work
modules,
and
the
goal
of
this,
as
I
say,
is
to
create
a
an
exact
spec
that
exactly
follows.
What
our
current
in
minimal
implementation
has
implemented
for
the
resolver
to
treat
the
spec
is
a
source
of
truth,
so
we
can
have
P
AHS
against
the
spec
and
in
the
process
of
also
included
some
refinements
to
the
resolver
and
some
improved
error
handling
to
give
an
idea
of
the
types
of
refinements.
There
was
some
legacy
code,
referencing,
indexed
or
MJS.
D
We
don't
currently
have
any
main
entry
point
implemented,
so
I've
removed
that
it
removes
some
unnecessary
error
handling
code.
It
creates
a
single,
not
found
error
type.
We
have
three
at
the
moments.
It
adds
some
extra
contextual
information
and
fixes
a
very
specific
case
of
package
falls
through
for
subpart
requires.
So
here's
an
example
of
the
type
of
thing:
it's
a
if,
for
example,
you
import
a
local
module
that
doesn't
exist
right
now
in
the
minimal
implementation,
you'll
get
a
module,
not
found
error
and
it'll
say,
cannot
find
module
dot
forward.
Slash
does
not
exist.
D
Now.
There's
a
few
things
that
are
tricky
here.
Yes,
modules
are
quite
different
to
require
in
require.
When
you
get
a
module
not
found,
you
can
see
the
exact
require
that
causes
the
bug,
but
in
in
yes
modules,
because
it's
a
resolver
that's
happening,
and
it's
not
running
in
through
executed
code.
You
don't
know
which
file
caused
the
issue
necessarily,
so
the
debugging
information
can
be
quite
hard
sometimes
so.
D
The
other
thing
is
that
the
current
node
pattern
is
error
under
school
and
then
the
error
code,
whereas
this
is
module
not
found
without
the
error,
prefix
and
there's
no
quotes
around
the
specifier.
So
it's
just
updated
these
things.
It's
it's
an
error,
underscore
module
not
found,
as
quotes
around
the
specifier,
and
it
includes
the
importing
module
in
the
text
so
just
trying
to
improve
that.
D
Another
case
is
if
the
file
would
have
been
found
by
the
combination
resolver.
So,
for
example,
currently
we
don't
resolve
extensions
if,
if
the
module
would
have
been
found,
then
you'll
get
this
error.
Module
resolution
legacy
error,
which
is
distinct
from
the
module
not
found
error
when
in
fact,
they're
still
the
same
kind
of
error.
So
I've
just
unified
those
still,
including
the
information
saying
that
the
legacy
require
would
have
found
it
at
this
path,
but
just
unifying
that
a
bit
and
then
in
the
spec
itself.
D
One
of
the
things
that
that
spec
does
is
it
has
a
package
main
resolve
section,
because
this
is
something
that
we
need
to
think
about
how
we're
going
to
define
the
package
main
tourism
resolution
and,
at
the
moment,
there's
nothing
in
there.
It's
an
empty
slot
in
the
spec
for
us
to
determine
further,
and
this
is
something
we
can
run
PRS
against
and
discuss
proposals
against
at
the
moment.
This
is
called
only
for
bear
package
imports
like
package
or
scoped
ford,
slash
package.
D
I
Oh
I
have
three
concerns:
I
went
over
it
today,
mostly
concerning
that
the
tweaks
you
did
and
and
and
making
it
basically
different
from
common
Jas
so
to
to
enable
the
package
fallback
thing
which,
which
is,
which
is
a
good
thing.
You
had
to
parse
the
package
name.
You
have
to
understand
that
it's
it's
either
one
directory
or
at
directory.
D
So
that
kind
of
fell
out
of
the
fact
that
at
the
moment
we
don't
have
directory
indexes,
so
we're
only
providing
the
main
if
you
import
a
package
form.
So
if
you
import
a
package
without
any
sub
path,
and
then
you
need
to
know
if
a
bear
specifier
has
a
sub
path
or
not
and
to
know
if
a
given
bear
specifier
has
a
sub
path
or
not.
We
have
to
pass
the
package
name,
because
you
need
to
tell
that
it's
just
a
package
name
yeah,
so
it
kind
of
fell
up
from
that.
D
I
mean
personally
I
would
love
it
if
we
could
get
agreement
on
kind
of
getting
this
merchant
if
we
want
to
add
directory
indexes
or
take
away
the
package
fallback
to
do
that
with
successive
PRS,
just
because
it
would
be
nice
to
get
this
kind
of
spec.
Otherwise,
if
people
are
having
difficulty
with
it,
I
could
take
out
that
behavior
and
just
Whittle
back
this,
this
PR
to
something
that
we
can
all
agree
on.
So
please,
let
me
know
what
works
for
you.
I
would.
I
That's
a
discussion
that
we
can
have
I
would
prefer
director
industries.
I
would
prefer
packages
and
directors
to
be
symmetrical
and
basically
the
same,
but
that's
arguable,
that's
arguable
and,
and
the
other
thing
is
I-
think
there's
a
bug
with
with
built-in
modules,
but
again
that
we
can
hash
out
in
the.
In
my
comments.
D
So
that
the
passing
is
because
if
you
have
a
so
you're
saying
check
all
the
folders
that
my
yeah
I
mean
you
could
stack
down
the
sub
paths
and
that
would
give
you
the
main
thing.
If
you
take
the
first
pound
package,
boundary
package.json
boundary
and
you
treat
that
as
the
package,
it
does
mean
that
and
if
you
have
something
in
node
modules
without
a
package.json,
then
we
can't
have
like
a
default
index.
Support
for
that.
F
F
The
one
person
using
it
was
actually
basically
setting
up
a
series
of
things
where
they
would
keep
nesting
node
modules
in
adding
files
for
different
situations.
For
their
case,
it
was
for
production,
environments
versus
development
environments
and
loading
config
files,
either
way
when
you
instrument
policies-
and
if
you
want
to
talk
to
the
noted
security
working
group,
things
get
really
weird
if
we
allow
fall
through
of
packages.
F
F
So
if
you
require
body
parser,
slash
a
import
body,
parser
slash
a
the
problem,
is
it
can
fall
through
back
to
the
vulnerable
version?
Even
if
you
try
to
say
it's
okay
for
you
to
import
body
parser
from
a
package,
you
generally
don't
want
them
to
import
body,
parser
/a,
which
could
be
something
above
you
and
node
modules,
and
so,
instead
of
having
to
do
policies
that
work
on
one
other
package,
you
have
to
do
it
on
everything
that
could
cascade.
F
D
D
For
what
it's
worth
the
resolver
in
writing
out
the
resolve
the
spec,
it's
amazing
how
few
stats
we
have
it's
been
really
great
to
see
the
minimal
implementation
looks
like
if
we
like.
If
we
looked
at
the
performance
of
it,
I'm
sure
you'd
find
huge
gains
over
the
current
marriage
result.
That's
an
aside!
Jill!
Could
you
maybe
try
and
look?
We
can
bring
the
rest
of
the
discussion
to
the
to
the
PR.
D
What
I
can
do
is
is
if
this
is
something
that
you're
against
what
I
can
do
is
see
if
there's
a
way
that
we
can
maybe
remove
that
aspect,
but
my
the
only
issue
is
that
that'll
also
mean
removing
the
main
placeholder
which
we
can
do
and,
and
we
can
just
take
it
out
entirely
and
then
bring
come
back
to
the
main
discussion.
So
does
that
sound
like
a
suitable
way
forward?
Oh.
I
D
E
Right
now,
the
behavior
of
beer
imports
is
very
well
bare
and
so
far
we
don't
have
a
clear
way
of
a
handling
deep
imports,
especially
once
that
canonically
don't
have
extensions.
Like
react:
Tom
server,
nobody
writes
rare
Tom,
slash
service
dot.
Yes,
even
though
that's
the
actual
fire
most
likely
behind
it,
and
we
don't
have
a
way
to
actually
specify
the
main
field
specifically
because
of
concerns
about
ecosystem
collisions
with
the
module
field
name
and
all
that
kind
of
stuff.
E
So
we
went
out
and
we
got
together
and
we
try
to
brainstorm
a
what
are
the
concerns
and
also
what
is
a
potential
solution,
and
we
ended
up
with
this
proposal.
It's
it
to
first
draft
off
what
a
solution
might
look
like,
so
we
are
looking
for
somebody
to
poke
holes
into
it,
so
they
can
see
that
we
harden
it
over
time.
There's
already
some
open
issues
on
this
repository,
but
the
basic
idea
is
not
too
surprising,
I
hope
for
most
people,
which
is
there's
a
field.
It
Maps
imports.
E
One
of
the
important
pieces
is
that
it's,
it
is
explicit.
It
actually
defines
a
public
interface
for
a
module
and
does
not
allow
arbitrary
imports
of
nested
files
inside
of
the
package.
So
you
actually
declare
what
you
the
public
interface
of
this
module
is
and
module
name
slash.
Foo
no
longer
means
literally
the
file
called
foo
in
the
packages
root
directory
that
allows
some
na
nice
things
like,
for
example.
E
If
you
want
to
expose
all
the
files
in
sauce
util,
you
can
actually
say
hey
all
directory
imports
relative
to
this
will
be
forwarded
to
this
directory,
and
that
is
my
public
API,
but
you
can
also
map
the
actual
specifier.
You
can
map
any
sub
specifier
and
we
tried
very
hard
to
keep
this
inter
face
as
simple
as
possible.
E
So
the
left-hand
side
is
a
simple
string
concatenation
on
the
specifier,
so
the
first
one
adds
an
empty
string
to
moment
yes
moment.
So
it's
just
moments
moment.
The
second
one
adds
the
trailing
slash
which
is
kind
of
lifted
from
the
import
Maps
proposal
that
are
trading.
Slash
signifies
namespace
that
can
be
used
for
to
append
additional
things,
and
then
you
can
define
arbitrary
other
entry
points
so
yeah
we.
E
F
Read
this
over
a
bit
I'd
like
to
see
some
mentioned
at
least
of
the
problems
in
graph
twelve
and
a
few
others
were
having
when
you
do
ship,
multiple
modes
of
modules
and
I'd
also
like
to
see
how
this
is
expected
to
be
propagated
to
a
loader.
If
there
is
an
API,
if
there's
not
maybe
I'm
not
really
hearing,
but
just
like
how
a
loader
would
be
able
to
either
interrupt
this
or
look
it
up
if
possible,
and
that's
it
for
me.
J
J
E
The
issue
I
think
that
Bradley
is
talking
about,
is,
if
you
have
anything
that
exports
a
class
react
graph,
QL
and
other
parts
of
that
same
library
are
using
instance
of
checks,
for
example,
to
verify
that
what
you're
passing
it
in
is
an
instance
of
the
class
Crete
provided
by
this
module.
If
you
have
both
a
common
shares
version
and
an
import
version
and
there's
any
chance
that
two
different
code
paths
might
get
one
or
the
other,
you
know
now.
E
I
have
two
instances
of
the
class
and
if
you
create
an
instance
in
the
you
know,
common
gos
module
in
your
application
and
then
try
to
render
that
component
in
a
year
six
module
file
in
your
in
the
same
application.
They
actually
run.
Two
different
versions
against
two
different
versions
of
the
class,
so
instance
of
check
would
just
fail
because
it
is
two
different
instances
and
file.
F
F
I
know
the
salah
in
have
been
having
this
like
kind
of
awesome
conversation
on
github,
so
we
are
probably
going
to
set
up
a
meeting
outside
of
this
one
about
what
me
and
yon
we're
trying
to
take
offline
last
meeting
just
like
tension.
So
if
anybody
is
interested
in
shoving
in
memory
modules
into
the
module
graph,
I'll
be
putting
that
on
github
just
watch
out
for
that's
it.
J
And
I
would
say
for
this:
please
go
to
this
repo
make
some
open
issues,
so
we
could
try
to
organize
the
discussion
for
feedback
and
improvements
of
this
and
yeah.
Please.
You
know
at
least
the
four
of
us
I
think
would
be
eager
to
join
any
more
conversations
that
people
want
to
have
about
this
stuff
of
the
module
loading.
The
URL
is
in
the
issue
for
today's
meeting.
It's
in
the
agenda.