►
From YouTube: Node.js Foundation Modules Team Meeting 2018-10-24
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
So
we're
now
live
on
YouTube.
This
is
the
2018
October
24th
meeting
of
the
nodejs
modules
team.
We
are
joined
right
now
by
13
people
of
12
of
who
are
active
members
which
gives
us
quorum
and
a
member
who
is
requesting
to
join
as
an
observer
today.
So
perhaps
a
first
item
of
business
that
we
can
jump
into
that
could
be
really
quickly.
Is
we
have
an
open
pull
request
to
ads
sold
there
that
so
there
do?
You
want
to
introduce
yourself
really
quickly.
A
So
mic
issues
I
can
I
can
do
an
intro
Ryan
de
is
a
Google.
Employee
works
with
me
over
at
Google
is
really
interested
in
exploring
loaders
and
as
such,
wants
to
get
more
active
in
the
modules
team.
So,
as
a
first
order
of
business,
do
we
have
consensus
around
adding
so
there
as
an
observer,
so
the
modules
team?
If
anyone
objects,
please
you
know,
say
something
now
excellent.
Welcome
to
the
team
Ryan,
the
next
order
of
business
before
we
begin
is
anyone
up
for
taking
notes?
Oh
I
can.
C
D
A
Try
to
remain
productive,
sorry,
so
the
next
one
that
we
have
for
pr's
and
we
have
a
five-minute
time
box
on
it
is
creating
terminology
that
I
believe
was
that
was
your
PR
and
I
know
that
a
couple
people
from
the
group
have
approved
it.
There's
no
objections
right
now
in
the
PR.
So
what
can
you
give
a
quick
overview
of
it
and
what
we're
agreeing
to
land
yeah.
E
So,
basically,
a
while
back
I
realized
that
discussions
had
terminology
that
some
people
were
getting
with
different
ideas,
so
I
thought
I,
don't
understand
some
of
them.
Maybe
some
others
needed
also
a
reference
that
we
agree
on
on
what
a
turn
can
mean
and
cannot
mean.
So
if
we
have
a
term
that
is
a
little
loose,
we
can
try
to
give
it
a
better
definition.
E
Hence
terminology
we
created
the
branch
and
like
PR,
it's
been
there
for
like
a
long
time
over
time.
Some
modifications
were
made
to
a
basic
set
of
terms
that,
were
you
know,
agreed
upon
between
members
I
also
made
after
the
first
set
of
approvals.
I
also
suggested
a
second
way
to
do
turns,
which,
which
is
a
little
bit
more
stipulative.
So
a
term
that
is
within
the
group
has
a
lot
more
meaning
defined,
meaning
than
a
general
term.
E
A
So
one
quick
question
for
you
about
the
document
and
I
didn't
want
to
object
in
the
issue.
I
just
wanted
to
ask
the
question
here
on
line
118
you
mentioned
deprecated
terms
and
specifically
transparent
interoperability
is
listed
now
as
a
deprecated
term.
Would
you
and
does
this
imply
that
it
is
no
longer
able
to
be
used
in
meetings
or
notes,
deprecated
mean
here
so.
E
Deprecated
terms,
I
think
was
added
later
on
after
I
put
that
draft
up,
but
it
I
think
it
came
out
of
the
problem
that
we
had,
that
we
use
interoperability
to
mean
multitude
of
things,
including
CJ
s.
Es
m
versus
browser
I
think
there
was
a
need
for
us
to
stop
using
the
term.
What
can
cause
confusion?
E
You
know
because
it
gets
in
the
way
of
actually
having
a
good
debate
or
a
good
discussion.
Well,
maybe
deprecated
terms
is
not
the
best
terminology
when
we
land
this
weekend.
You
know
everybody's
welcome
to
actually
suggest
a
better
way
to
go
about
this,
but
I
think
you
know
the
general
sense
that
we
don't
want
to
use
transparent
interoperability
very
loosely
so
from
there
you'll
see
how
will
revise
the
document
to
to
better
reflect
things
like
that?
Okay,.
A
Can
I
make
a
request?
Would
it
be
unreasonable
to
request
that
we
remove
the
deprecated
terms
from
the
dock
when
we
land
it
and
open
a
new
pota
quest,
because
I
think
having
the
term
deprecated
there
without
a
policy
around
how
we
should
use
it
or
at
least
a
shared
understanding
of
what
deprecated
means
is
setting
us
up
for
a
problem?
Also,
we
could
land
it
and
then
iterate
I'm
good
with
either,
but
I
just
wanted
to
kind
of
throw
that
out.
As
it
asked
I'm.
E
F
F
Yeah
I
would
say:
let's
land
it,
because
in
the
last
couple
of
month
we
didn't
really
make
progress
and
I
would
much
rather
landed
now
and
then
iterate
and
if
we
feel
like
removing
the
deprecated
section
or
adding
more
language
in
the
decorated
section.
I
think
we
can
do
that
after
landing
and
just
use
this
as
the
basis
for
iteration.
A
Okay,
great
Congrats
Allah.
If
you
would
like
to
have
the
honors
of
landing
it,
please
go
for
it.
The
one
thing
I
would
ask,
is
there's
a
bunch
of
different
commits
in
there?
If
you
don't
mind
squashing
those
all
into
one
commit
when
you
land
it,
ok,
ok,
cool!
So
next
up
in
the
agenda,
we
have
an
update
on
progress.
We
have
a
four
minute
time
box
right
now
for
terminology
stipulative
terms
as
well.
I,
believe
that's
your
issue.
It's
number
184
is
this
something
that
we
need
to
dig
into
today.
I
guess.
E
We
just
landed
the
document
I'll.
Just
just
reiterate
that
people
should
look
at
the
section
for
syphilis
terms.
It's
it's.
It
has
only
one
definition,
but
it
could
serve
to
define
terms
that
need
a
lot
more
detail
to
them
in
the
future.
So
so
just
just
bringing
it
up
at
this
point
is
what
it
takes
really.
Okay,.
A
Great
and
so
people
take
a
look
at
184,
there's
stuff
in
there,
but
browser
and
drop
in
just
more
terms
that
we
could
be
better
defining.
So
that
thing
goes
next
into
issue
number.
Well,
it's
182
173
number
85
stuff
about
the
survey.
So
that's
also
you
thanks
for
doing
so
much
hard
work
update
on
the
survey,
perhaps
a
focus
on
what
happened
at
interactive
and
what
the
next
steps
are.
Yeah.
E
So
so,
at
this
point,
all
previous
stages
of
the
survey
I
think
are
concluded.
A
number
of
people
have
expressed
previously
in
internal
surveys
that
they
would
like
to
take
part
in
organizing
a
survey
that
goes
out
to
developers.
We
had
a
we
wanted
to
have
a
dry
run,
and
you
know
at
the
end
interactive
which
we
need
them
in
a
pan
out,
as
we
expected.
E
One
problem
really
stems
from
the
fact
that
I'm
hesitant
to
write
a
question
that
I'm
not
sure
you
know
if
it
really
reflects
what
other
people
in
the
group
wanna
have
asked.
From
my
perspective,
I
have
a
very
limited
commitment
on
in
terms
of
what
I
would
like
to
get
the
opinions
of
the
community
on,
but
I'm
sure
a
lot
of
people
here
have
certain.
E
So
we
were,
you
know
we
put
very,
very
non-committed
kind
of
questions
and
at
the
end
of
it
it
basically
was
well-received.
People
want
to
be
asked
questions
about
modules,
but
unfortunately
we
were
not
prepared
to
give
a
good
survey.
My
hope
is
within
this
group.
Other
people
would
step
up
and
we
basically
have
you
know,
divide
the
work.
People
take
particular
sections
particular
questions
and,
and
we
coordinate
this
effort
or
the
opposite,
we
decide.
E
A
D
Jeffrey
you've
got
your
hand
up.
Do
you
have
anything
you
want
to
add
in
yeah
I
guess
this
well,
we're
waiting
for
Salah
I
had
added
some
questions
that
somehow
I
didn't
get
the
ACE
they
got
deleted
before
it
was
sent
out
to
the
group
in
Vancouver
and
I.
Think
well,
there's
no
process
for
tracking
changes,
I
think
in
Google
form
so
I'm
sure
whoever
was
editing
it
to
know.
You
know
that
it
was
me
or
anything
like
that,
but
I
mean
I
was
kind
of
disappointed,
not
to
get
answers
to
those
questions.
A
E
I
think
the
transparency
on
what
I
found
works.
It
would
be
helpful
if
we
have
meetings
that
are.
You
know
separate
from
the
main
meeting.
Everyone
interested
would
join
those
meetings
because
not
using
Google,
Forms
and
drafting
elsewhere
makes
it
a
really
big
problem
to
actually
go
back
and
put
the
questions
in
Google
Forms
the
there's
a
lot
of
difference
between
what
you
think
you're
going
to
be
putting
in
the
question
and
when
you
get
to
actually
put
it
down
in
Google
Forms,
it's
very
different.
A
Okay,
two
things
that
I
can
maybe
suggest
to
follow
up
on
this.
If
people
are
interested,
the
calm
calm
has
a
user
feedback
initiative
that
they
run,
which
includes
their
own
meeting
calendar
and
meeting
notes,
scheduling
and
all
that.
Perhaps
this
is
something
that
you
could
collaborate
with
them
on
and
perhaps
having
you
know
like
some
sort
of
regularly
scheduled
meeting
for
the
team.
That's
gonna
run
with
this.
That's
outside
of
this
meeting
may
prove
very
effective,
but
perhaps
that's
something
to
kick
back
to
github.
Are
people
ready
to
move
on
to
the
next
topic?
A
A
A
D
D
It's
the
green
button
at
the
bottom.
Okay,
do
you
guys
see
it
now,
yep
all
right,
so,
at
the
last
meeting
we
discussed,
like
we
had
said,
Oh
who's
interested
in
helping
draft
the
next
stuff
for
Phase,
two
I
volunteered
miles
volunteered,
jdd
and
Salah
I.
Think
also
volunteered
for
like
a
forgetting
someone,
but
anyway
we
had
a
call,
and
we
drafted
this.
Let
me
he
had
another
call
I'm
you
revised
its
further,
and
so
here
it
is
and
I
hope,
we've
addressed
all
of
the
discussion
that
people
have
put
on
the
pull
request.
D
A
Cool
would
you
like
to
like
loop?
Perhaps
we
could
go
through
each
one
of
these
phases
individually
Jeff.
Would
you
like
to
introduce
each
of
the
phases
and
then
people
can
raise
hands
and
ask
questions?
If
we
can
reach
consensus
on
this
today,
we
can
actually
start
probably
digging
into
implementation
details.
So.
D
D
So
that's
like
why
we're
specifically
mentioning
it
here
and
certainly
there's
gonna,
be
you
know,
tweaks
from
the
earlier
stuff
that
will
address
and
face
for,
but
clearly
there's
a
lot
of
features
that
we
have
on
our
readme,
not
all
of
which
I'm
sure
will
end
up
getting
implemented,
but
clearly
we're
gonna
implement
more
stuff
than
phase
2
plus
loaders.
So
you
know
in
in
evitable
there
will
be
more
things
added
down
the
road.
You
know
after
phase
2
is
done,
and
we
start
talking
about
phase
3
or
in
phase
4.
D
D
So
yeah,
and
as
part
of
that,
it's
clearly
like
this
is
not
like
the
end
of
you
know
the
development
process.
It's
not
like
this
plus
loaders
and
then
we're
done
so
there's
clearly.
You
know
a
lot
more
work
to
be
done
so
yeah,
that's
the
overview
of
the
phases.
I
think
do
you
want
to
talk
about
this
one
miles?
You
know
better
than
me
about
this
they're.
A
E
Okay,
so
yeah
I
thought
we
had
a
discussed.
The
idea
of
bringing
back
the
module
from
source,
which
is
now
under
vm
I,
just
want
to
raise
a
point
about
the
current
state,
where
the
end
modules
were
stacks
really
creates
one
that
is
outside
the
module
map
of
your
loader,
and
at
this
point,
I
really
want
to
see.
If
you
know,
I
would
love
to
see
a
module
from
source
text
that
actually
belongs
him.
The
same
module
map
has
the
loader
as
a
means
for
tooling.
You
know
that
is.
G
D
That
would
be
great
I
guess
maybe
it's
some
other
point
I
should
make
it's
like.
We
tried
to
draft
this
as
as
loosely
as
we
could
to
try
to
avoid
getting
into
implementation
details
like
we're
trying
to
avoid
like
in
this
meeting
here,
having
an
argument
over
model
versus
main
fields.
You
know
what
I
mean
like
if
we
could
maybe
like
deal
with
that
in
the
in
the
PR
process,
I
guess
or
you
know
like
we
will
figure
out
an
implementation
of
this.
D
F
Yeah
I
I
feel
like
this
list
does
make
sense
overall
and
I
I
mean
III,
do
have
strong
opinions
on
the
first
bullet
point
on
in
terms
of
what
should
actually
be
that
interface
and
how
it
should
relate
to
the
loader
implementation,
but
for
0.3
I.
Think
if
I
remember
correctly,
maybe
I
missed
something
in
between,
but
I
think
our
current
loader
doesn't
even
have
a
resolution
for
the
bear
specify
a
low.
So
that
seems
to
be
something
it
is
implied
in
that
bullet
point,
and
that
seems
to
be
at
least
to
some
degree.
D
A
G
F
Mean
I
I
do
have
opinions
on
that,
as
in
I.
Don't
believe
that
node
modules
resolution
should
be
built
in
because
I
don't
think
that
that
should
be
an
opinion
that
node
has.
That
should
be,
to
some
degree
left
to
look
to
user
land,
because
otherwise
we
will
get
in
a
situation
where
NPM
or
yarn
trying
to
implement
a
consistent
package.
Caching
we'll
have
to
hack
around
what
node
is
trying
to
do.
H
Yeah
I
mean
I
think
like
yawn,
maybe
you
and
I
can
talk
about
it
offline,
but
I
think
that
the
problem,
if
node,
doesn't
have
an
opinion
there,
then
the
situation
we
get
ourselves
in
it's
NPM
and
yarn
and
17
other
alternatives
are
all
competing
and
userland
gets
fractured.
I
think
it's
absolutely
critical.
That
node
has
an
opinion
about
that
sort
of
thing.
It'd
be
great
if
it's
something
that
can
be
adapted
to
other
approaches,
of
course,
but
I
think
there
has
to
be
a
reasonable
default
there.
Otherwise
it
would
be
catastrophic.
A
This
is
me
putting
up
my
hand
to
chime
in
one
of
the
intents,
as
we
were
talking
about
this
and
I
think
I
think
the
idea
was
that
a
module
system
that
has
a
good
user
experience
is
going
to
require,
bear
imports
and
that's
a
module
system
both
in
the
browser
and
in
node,
and
hopefully
the
two
are
able
to
work
with
one
another.
What
we
were
kind
of
building
off
of
here
and
we
can
decide
how
we
want
to
actually
implement
this-
was
that
we
have,
you
know,
legacy
technology.
A
We
have
existing
technology
today
that
puts
things
into
a
node
modules
directory
the
fact
that
it
goes
into
node
modules
is
kind
of
like
happenstance.
We
could
like,
theoretically
call
it
whatever
it
wants,
but
like
changing
it
to
not
be
called
node
modules
right
now,
it'd
be
like
a
pretty
massive
ecosystem
thrash,
but
that,
like
the
behavior,
the
high-level
behavior
could
be
consistent
and
the
underlying
way
in
which
it's
implemented
becomes
more
of
an
implementation
detail
of
the
embedder
of
the
like
of
the
platform.
That's
implementing
it
so
well.
A
The
browser's
may
be
exploring
package
name
maps
of
the
way
of
implementing
this,
and
those
files
may
or
may
not
be
in
a
node
modules.
Folder
the
code
import
blank
from
blank
will
work
and
that
the
underlying
mechanism,
whether
it
being
a
package
name
map
or
some
sort
of
special
insults
who
will
will
kind
of
hide
that
from
the
user,
so
I
think
relying
on
node
modules,
at
least
as
an
entry
point.
It
needs
to
be
consistent
with
what
would
happen
in
the
browser.
I
wouldn't
see
a
p.m.
A
B
It's
about
node
modules,
then
why
I
totally
agreed
not
to
throw
away
the
node
modules
thing,
but
isn't
that
the
whole
idea
of
loaders
extensible,
loaders
and
in
doing
userland
experimentation
having
different
sets
of
things
that
we
can
try
out?
I
mean
how
is
that
different
from
other
kinds
of
learners
that
we
want
to
experiment
with.
H
C
F
Yeah
just
to
clarify
why
I
don't
believe
that
defaulting
to
node
modules
or
having
that
be
the
thing
that
ships
is
too
valuable,
I
mean
having
it
as
an
opt-in
thing
or
an
officially
maintained
thing
sure,
but
it
feels
like
note.
Moyers
is
a
directory
that
is
primarily
created
by
NPM,
oh
yarn,
and
both
of
these
projects
have
recently
signified
pretty
clearly
that
they
don't
really
care
for
keeping
to
create
node
modules.
They
both
have
shipped
products
that
act.
F
If
you
get
rid
of
node
modules
and
actively
try
to
hack
the
current
loader
tune,
please
do
not
use
node
modules
so
giving
them
like
nobody
outside
of
those
parties
will
create
node
modules,
so
it
feels
like
if
they
are
creating
node
modules,
giving
them
the
control
when
they
are
installing
dependencies
giving
them.
The
control
of
how
the
dependencies
should
be
resolved
seems
like
a
reasonable
solution.
A
D
D
Think
I
think
we
can
agree
that
we
want
to
do
that
as
far
as
like
whether
it
should
be
implemented
with
or
without
node
modules
or
package
name
apps
or
any
that
kind
of
stuff.
I
think
that
that's
just
something
we
need
to
explore
and
can
be
part
of
the
process
of
implementing
it,
and
maybe
we
should
have
calls
specifically
about
you
know.
D
The
effort
to
make
PR
is
to
implement
this
and
I'm
happy
to
organize
those
if
people
want,
but
unless,
unless
we're
opposed
to
supporting
like
users
writing
code-
and
this
like
this
in
general,
regardless
of
implementation,
then
I
would
think
we
can
leave
this
on
here.
I
would
think
I
mean
correctly
come
on.
G
D
How
about
this,
if
I
can
propose
wanna
if
it's
okay
with
people?
Why
don't
we
like
land
this
as
like
we're
gonna
try
to
implement
this
there's
gonna,
be
a
follow-up
where,
like
there's
a
pull,
you
know
whenever
someone
makes
a
pull
request
or
there
might
be
multiple
pull
requests
to
try
to
make
this
work.
That
could
be
where
we
like
have
to
hash
out
like
well,
which
ones
these
do
we
want
to
land?
What
do
we
want
to
have
consensus
and
there
will
be
a
lot
of
effort
going
into
making
those
pull
requests.
D
I
also
think
it's
gonna
be
really
hard
to
try
to
find
consensus
on
like
implementation
of
this
in
a
10
or
20
minute
time
box.
So
you
know
we
should
we
should
spin
off.
You
know
you
know,
I
found
it
really
helpful
to
have
a
call
specifically
about
writing
this
phase
to
document.
So
maybe
that's
a
tool
we
could
use
to.
Try
to
you
know,
have
deeper
dives
into
things
and
have
more
time
to
actually
reach
consensus,
and
here
already
out
on
things
one.
A
Quick
thing
to
add
before
Kevin
guy
is
having
to
drop
from
the
call
earlier
I'm
just
checking
to
see
they're
not
on
the
call
anymore.
So
there
was
a
10
minute
agenda.
Items
specifically
forgot
to
talk
about
the
progress
on
the
dynamic
module
proposal.
That's
getting
punted
to
the
next
call,
so
I'm,
adding
10
minutes
to
the
time
box
for
this.
So
we
still
have
another
14
minutes
to
discuss
this
topic.
Kevin
you're
up.
I
Yeah,
so
this
may
be
a
crazy
idea,
bad
idea,
but
what
about
swapping
phase
2
and
phase
3,
because
if,
if
we
have
the
infrastructure
for
creating
our
own
loaders
and
stuff-
and
you
know
people
can
experiment
with
different
strategies
for
fulfilling
the
requirements
listed
in
phase
2
and
that
way,
maybe
we
can
make
make
progress
without
you
know
getting
getting
into
some
of
the
conflicts
that
you
know
have
have
given
us
trouble
in
the
past.
D
G
Loaders
need
more
design
work.
We
need
more
people
to
talk
about
loaders
people,
just
kind
of
use
them
ephemerally
right
now
we
have
a
loader
implementation.
We
have
a
couple
of
different
ideas
on
how
to
move
forward
with
it.
Yan
put
up
his
stuff
recently
in
the
modules
working
group.
I
have
a
separate
one
and
some
presentations
and
things,
but
we,
if
we're
gonna,
do
loaders
as
a
phase.
G
It's
gonna
be
a
lot
of
talking
about
the
pros
and
cons
of
capabilities
of
the
loaders
in
the
api's
to
satisfy
that
it's
I'm
I
mean
we
have
the
right
hook,
location,
there's
only
one
a
one
hook,
location
the
spec
ever
gives
you,
then
it's
just
how
you
want
to
wrap
it
up.
Well,
we
can
do
it
whenever,
but
it's
gonna
be
just
a
lot
of
design
work,
there's
nothing
to
just
drop
into
the
implementation.
A
So
my
hand
up-
which
was
after
a
slot
and
then
Gil
and
then
Yan
to
your
point,
Kevin
about
like
switching
the
phases.
What
I,
personally
think
would
make
the
most
sense
is
that
anything
that
we
don't
have
consensus
on
for
phase
two
just
comes
out,
but
I
I
feel
that
things
like
at
the
very
least
like
improving
common
jeaious
interoperability
like
create,
require
from
path
I,
think
there.
There
are
things
that
are
not
related
to
loaders
that
are
clear
and
obvious
user
experience
enhancements
that
we
can
make
inside.
At
least
for
myself.
A
The
intent
with
phase
two
was
to
identify
those
things
that
could
be
worked
on
aside
from
loaders,
so
that
we
could
have
some
incremental
enhancements
and
wins
before
I
think.
Similarly,
the
auto
ban
mechanism
for
command-line
disambiguate
in
the
ambiguous
in'
for
like
a
vowel
or
STD
in
I
don't
think
that
those
are
things
that
necessarily
need
to
be
tied
directly
to
loaders.
So
perhaps
phase
two
could
be
better
phrased
as
like
what
are
things
we
can
do
that
are
unrelated
to
loaders
so
that
we
can
still
have
so.
B
E
So
I
think
I
can
take
that
one.
We
have
in
the
experimental
virtual
modules,
sorry
BM
module
or
BM
module
from
source
text.
Basically,
it's
a
module
that
gets
created,
I'm
not
sure
if
it's
in
a
different,
separate
context
or
not,
but
it
does
not
enter
the
module
map
of
the
of
the
experimental
loader
dsm
motor
instance,
but
it
could
actually
I
think
linked
to
modules
that
are
in
it
I'm,
not
sure
but
I
believe
it's
a
one-way
link
and
I
wanted
to
step
away
from
this
idea
and
actually
move.
E
You
know
towards
the
idea
of
how
you
could
dynamically
instantiate
really
crappy,
but
still
they
do
exist,
modules
from
source
text
and
the
browser.
The
cleanest
implementation
is
one
that
you
could
do
with
a
serviceworker
and
browsers.
You
know
are
implementing
that
now,
so
so
the
idea
of
a
virtual
module
from
source
is
a
module
that
does
not
exist
on
this
anywhere,
but
rather
given
source
and
other
modules
in
your
map
can
actually
find
it
as
if
it
was
a
you
know,
a
virtual
source
on
this.
F
Yeah
so
one
argument
for
keeping
the
current
order
where
at
least
the
vm
source
text
module
comes
before
the
loader
is
because
it
gives
us
an
opportunity
to
potentially
define
an
API
that
is
customer
facing
or
consumer
facing
client
facing
for
how
to
interact
with
modules
that
could
then
be
leveraged
in
the
loader
design.
So
the
lorry
design
can
actually
build
on
top
of
so
I'm.
F
G
Bradley
sure
so
this
topic
actually
is
something
that
tc39
has
spent
a
lot
of
time
on
when
they
originally
made
es
modules.
They
had
a
loader
spec.
They
pulled
it
out
because
of
problems.
Those
people
eventually
moved
on
to
start
working
on.
What's
called
the
realms
API,
the
realms
API
is
still
in
progress.
You
can
join
the
calls
they're
open
to
the
public.
G
If
people
are
interested,
that's
something
that's
great
to
go
to
if
we
want
to
actually
enable
this
kind
of
cross
module
map
population.
But
if
you
have
concerns
about
why
it's
bad
to
like
just
let
arbitrary
objects
into
the
module
graph,
please
join
the
realms
api
calls
because
that's
pretty
much
what
they
talked
about
for
four
hours
a
week.
That's
it!
Thank
you.
A
Just
before
you
turn
in
Kevin
I
want
to
let
everyone
know.
We
have
just
over
five
minutes
left
in
this
Kevin.
If
you
don't
mind
I'm,
you
know
I'm
gonna
interrupt
you
about
three
minutes
when
we
have
about
three
minutes
left,
if
you
get
to
there,
so
we
can
see
if
we
have
consensus
on
anything,
Kevin
go
for
it.
I
Cool
yeah,
so
the
strategy
that
you
miles
describes
a
couple
of
minutes
ago,
where
we
go
through
the
base,
two
items
and
trying
to
get
consensus
on
the
more
easy
ones
and
then
for
the
things
we
can't
get
consensus
on.
You
know,
then
we
push
those
back
until
after
we've
had
time
to
experiments,
loaders
that
that
seems
like
a
reasonable
approach
that
could
make
progress.
A
G
D
G
F
F
F
A
So
if
I
frame
it
a
certain
way
and
so
I'll
hand
it
off
to
you
in
a
second,
do
we
have
do?
We
have
consensus
of
kind
of
like
a
stage.
One
kind
of
thing
here
that
were
that
in
phase
two,
we
will
be
exploring
this
problem
space
independent
of
the
implementation,
and
we
will
punt
it
if
the
implementation
seems
to
get
to
a
place
that
we
don't
have
consensus
on.
I
hear
no
I.
G
G
E
It
to
that
language
I
would
object,
actually
it
becoming
B
M
modules
based
on
that.
So
I
don't
know
what
what
password
we
have.
We
don't
agree
on
it
as
a
point
of
you
know,
beginning
to
implement,
and
then
we
can
discuss
the
details
so
I'm
lost.
You
know
like
I,
don't
know,
honestly,
it's
not
gonna
be
worth
it
if
I
need
to
use,
create
dynamic
module
because
from
source
text
to
and
module
to
module
a
loader
just
cannot
do
all
that.
So.
A
E
G
D
F
A
Put
into
the
chat
a
text,
it's
explicitly
explore
design
space
for
virtual
module
from
source.
Does
anyone
object
to
that
specific
title
for
this?
For
this
one
point
cool,
so
I'm
going
to
assume
that
we
have
consensus
there,
the
next
point
improved
common
gif
interoperability.
Do
we
have
any
objections
to
this
being
something
that
we
explore
and
phase
two.
A
A
F
D
Can
I
sorry
I
can't
see
who's
raising,
hands
or
whatnot
miles?
There's
no
one
I
I
have
interest
in
the
specifics
of
the
the
usability
of
this
when
it
gets
implemented.
So
if
maybe
like
people
want
to
say
like
who's
interested
in
working
on
this,
if
we
can
maybe
stay
in
touch
or
have
calls
every
now
and
then
or
something
I
thought
to
have
discussions
with
the
you
know
the
various
people
who
are
going
to
be
working
on
this,
you
know
just
to
just
to
try
to
keep
our
consensus
as
it
gets
built.
D
A
Identifying
champion
this
is
a
great
idea
here,
Jeffrey,
so
if
going
back
reintroduce
it
for
the
virtual
module
stuff,
I
think
we
identified
Brad
and
Yan
as
the
two
champions
Allen,
and
so
is
that
I
would
like
to
be
the
champion
for
improving
commonjs
interoperability.
Does
anyone
have
any
problems
with
that
or
want
to
join
me,
cool
and
and
Daniel
will
join
me
on
that
Thank
You
Daniel
I
tried
to
identify
Yan
the
land
which
you
suggested.
A
A
D
A
C
A
So
I'm,
maybe
the
best
thing
that
we
could
do
is
land
this
space
too,
with
the
text
and
then
have
people
send
like
open
another
pull
request
to
identify
the
champions
just
so
that
people
who
weren't
on
the
call
have
an
opportunity
are
people.
Okay
with
that
yep,
okay,
cool.
So
the
last
one
that
we
have
on
the
list
here
is
an
out-of-band
mechanism
for
command
line.
Disambiguation.
Of
course,
entry
point
our
school.
Does
anyone
object
to
that's
being
part
of
phase
two
yan?
You
have
your
hand
up
yeah,.
D
F
And
at
that
point
we
kind
of
run
into
the
same
all
that
we
have
run
into
consistently,
which
is
as
long
as
the
name
of
the
entry
point
binary
doesn't
change.
We
will
run
into
the
same
issue,
at
least
for
something
that
doesn't
have
a
file
extension.
That
is
yes
and
at
that
point,
if,
if
we
have
a
different
binary
name,
that
question
would
be
answered.
You.
D
A
D
So
the
idea
here
was
like
just
put
a
put
a
flag
in
there
now
and
like
very
likely
when
we
have
something
some
kind
of
more
sophisticated
way
of
defining
the
entry
point
and
or
defining
how
file
extensions
are
treated
or
mime
types
and
so
on.
Then
this
would
get
replaced
with
something
that
parallels
that
more
complicated
configuration,
but
just
so
that
there's
some
way
of
running
ESM
for
these
modes.
A
Know
everyone
has
their
hands
up
really
quickly
for
the
sake
of
time,
because
we
only
have
five
minutes
left
an
alternative
title
for
this:
explore
design
space
for
an
out-of-band
mechanism
for
command-line
disambiguation
of
a
source
entry
point
parse
cool.
Does
anyone
object
to
that
title
just
say.
A
A
We
only
have
four
minutes
left
on
the
call,
and
we
have
consensus
on
first
three,
but
not
on
this
one.
Does
anyone
object
to
us
removing
this
fourth
point
landing
the
first
three
that
we
have
consensus
on
and
opening
a
new
pull
request
like
band
phase
two
and
I
work
on
that
in
the
next
in
the
next
meeting?
Could.
E
G
Yeah
so
I
think
we're
a
little
overly
focused
on
some
existing
designs.
Here
there
are
alternatives
which
we
haven't
really
dug
into
like
data.
You
are
eyes
that
we
could
be
loading
for
evil
or
whatever,
which
do
include
format.
Information
inside
of
them,
apparently
so
I
think,
there's
a
lot
that
we
could
still
look
in
here
that
might
solve
yawns
issues
can.
D
F
And
I
was
about
to
basically
go
into
the
same
direction
as
Jeffrey
just
went,
which
is
if
our
goal
is
to
have
a
temporary
mechanism
to
easily
evolve
some
string
as
a
module
quickly,
mostly
for
people
who
are
investigating
things
about
modules.
Realistically,
if
that
is
the
goal,
couldn't
we
just
have
a
bash
script
that
we
put
up
as
a
gist
that
people
can
install
and
link
in
that
is
ESM
eval
and
implicitly
creates
a
temp
file
from
the
thing
that
you
try
to
evolve.
F
A
I'm
sorry
to
interrupt
you,
but
we're
getting
really
deep
into
implementation.
Details
right
now
and
we
have
two
minutes
left
I-
think
that's
an
interesting
space
to
explore,
but
we
did
have
one
of
it.
We
wanted
to
get
to
before
we're
done
so
really
quickly.
Does
anyone
object
to
landing
the
first
three
points:
changing
the
name
of
the
third
point:
to
define
semantics
for
import
a
package
changing
the
first
point
to
explore
design
space
for
virtual
module
from
spores,
removing
the
out-of-band
mechanism.
A
J
A
The
next
one
really
quickly
ESM
module
Eknath
script
modules,
number
nine.
We
have
a
reef
of
deaths.
Net
Gus
did
a
great
refactor
because
we
now
have
import
meta.
This
is
approved
by
Brad
and
by
guy.
Does
anyone
object
to
landing
this
on
Xmas
script
modules?
Right
now?
Oh
wait!
Gus.
What
do
you
object
to
can't.
A
A
A
Great
I
can
also
just
quickly
edit
it
and
just
put
a
fix
up
commit
on
there
for
the
people
who
are
in
the
meeting,
if
you
don't
mind
putting
your
plus
ones
and
LG
TMS
on
that
issue,
before
it
lands
once
we
updated,
it
just
helps
to
have
it
from
a
documentation.
Standpoint.
Okay,
we're
going
to
end
the
meeting
now.
Thank
you,
everyone
for
being
so
productive.
This
was
really
excellent.
Well,
it
will
come
back
in
two
weeks,
see
y'all
Thanks.