►
From YouTube: Node.js Foundation Modules Team Meeting 2018-08-01
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
A
A
A
Thank
you.
First
item
of
business
that
we
have
on
the
agenda
today
is
to
add
sindell
Kumar
Kumar.
As
an
observer
issue,
number
159
is
taken
issue.
It
look
at
159.
We've
got
a
couple
members
of
the
team
who
are
not
on
the
call
and
I
believe
that
between
those
members
who
have
agreed
and
the
number
of
people
that
we
have
on
the
call
we
have
quorum
is
everyone
in
favor
of
this
great,
so
I
will
go
ahead
and
move
forward
on
adding
sandal
as
an
official
observer.
A
A
C
So
last
week
we
were
at
a
point
where
it
was
just
Google
Docs,
so
I
went
ahead
or
actually
last
meeting
and
I
went
ahead
and
tried
different
formats.
The
format
that
were
probably
going
to
go
with
is
markdown
in
the
actual
condition
they
show.
There
are,
you
know,
links
for
the
other
versions
if
anybody's
interested
in
trying
you
know
different
formats
anyways,
but
moving
forward,
I
think
it's
good.
We
have
two
Qwest
we're
sticking
with
markdown
and
I,
see
that
there
has
been
some
interaction
on
the
phone
request.
C
Moving
forward.
I
think
this
is
a
document
that
belongs
to
everyone.
It
really
helps
that
people
who
you
know,
look
at
it
and
say
no
I,
don't
like
that
definition
or
they
say
wait
that
needs
to
be
in
the
terminology
and
they
go
ahead
and
just
contribute
to
the
document,
and
then
we
can
all
go
through.
You
know
a
process
of
it.
You
know
approvals
or
whatever,
based
on
the
norm
that
these
you
know,
processes,
take
I,
guess
so
yeah
from
there
I'll
leave
it
up
to
the
team.
A
Okay,
great,
thank
you
very
much.
We
can
kick
that
back.
Til.
The
pull
requests
to
people
who
are
listening
is
you
could
take
it,
take
the
time
to
review
that,
and
we
can
come
back
next
week
to
dig
in
a
bit
more.
The
next
thing
we
have
on
here
is
developer
survey.
That
was
my
poor
request.
I
believe
I
have
not
had
time
to
dig
into
this
at
all.
Is
there
anyone
who's
on
the
call
right
now
who
would
like
to
take
over
driving
a
developer
survey?
A
I
was
just
gonna
say:
I
can
take
that
silence
as
a
message
to
kick
it
back
to
that
thread,
and
maybe
we
can
just
discuss
it
in
the
thread
itself
agreed.
Actually,
okay,
cool
so
now
onto
the
meat
of
things.
We're
in
to
remain
discussion.
I
believe,
is
it's
Jeff
on
the
call
Jeff
you
were
saying.
The
two
of
these
items
need
to
be
merged
was
at
156.
D
D
So
basically
there
were
some
issues
opened
with
essentially
like
use
cases
where,
like
long
story
short
that
there
needs
to
be
the
ability
to
for
node
to
parse
dot
JSP
with
the
ESM
part
school
and
I,
don't
I,
don't
know
if
it's
really
worth
getting
into
what
those
reasons
are,
but
there's
long
and
long
and
long
and
long
thread
about
like
what
those
use
cases
are
and
how
other
solutions
you
know
don't
work
etc.
But
we
seem
to
have
come
to.
D
We
seem
to
come
to
a
consensus
that
node
needs
to
support
this.
Somehow
that
doesn't
mean
that
we
need
to
change
anything
in
experimental
modules.
It's
like
not
that
this
doesn't
mean
that
we
need
to
like
get
rid
of
MJS,
but
just
that
we
need
an
additional
way
other
than
the
file
extension
to
signal
to
node
that
hey
treat
this
file
as
yes,
and
so
then
that
led
to
the
other
issue
160,
which
was
like
well.
Okay,
the
water
here
are
some
specific
proposals
for
how
to
achieve
this.
What
do
people
think
of
them?
D
E
E
Jordan
yeah
I
think
I
agree
with
Jeffrey's
phrasing
that
like
this
is
something
we
need
to
enable
I
want
to
make
sure
that
we
don't
pigeonhole
this
as
just
being
about
CJ
s
and
ESM,
because
we
also
are
gonna
have
to
handle
binary
modules
and
wasm
and
whatever
future
module
types
come
in.
So
as
long
as
we're
thinking
about
this
is
a
generic
way
to
override
the
default
parse
goal
for
a
file.
Then
I
think
that
sounds
like
a
great
idea.
B
I
really
like
this,
because
it's
a
cooperative
kind
of
effort,
where
we're
trying
to
figure
out
what
use
cases
can
be
served
by
kind
of
different
methods,
different
features,
whatever
you
want
to
call
it.
In
particular,
I
would
like
to
see
more
of
this
in
the
group.
So
I
I
just
really
love
the
idea
of
not
really
fighting
each
other,
because
we
sometimes
fall
into
that
pit.
But
I
just
want
to
be
sure
that
whatever
we
design
we
have
this.
B
Is
it
a
PR
number
160?
Whatever
we
design,
we
need
to
be
very
well
thought
out
and
what
it
means
for
usability,
what
it
means
for
composition
and
ensure
that
if
we
enable
a
feature,
we
aren't
stepping
on
other
features
in
a
way
of
conflict,
so
I
highly
encourage
people
to
kind
of
take
a
look
at
it.
I
think
sometimes
people
get
caught
up
on
things
either
file
extensions
or
the
word
mime
I
would
just
encourage
people
to
look
at
the
use
cases
more
than
the
actual.
B
A
F
I
tried
to
do
it
at
the
same
time,
the
only
thing
I
want
that
is.
Is
there
any
chance
that
some
of
the
existing
use
cases
that
we've
already
put
together
can
form
the
basis?
As
you
know,
Bradley
was
just
mentioning
starting
to
try
to
drive
it
off
use
cases.
Can
we
pull
some
subsets
from
what
we
have
as
a
starting
point.
F
F
What
do
those
you
know,
instead
of
having
to
come
up
with
new
use
cases
or
new
patterns,
do
any
of
those?
Do
we
already
have
what
we
need
in
terms
of
those
use
cases
to
say
these
are
the
cases
we
need
to
validate
are
covered
by?
You
know,
what's
being
what's
being
suggested,
to
be
added
to
the
package
Jason,
whether
it's
mime
or
whatever
else.
D
I
think
I
can
try
to
tackle
that
unless
someone
else
wants
to
so
the
the
specific
like
the
the
way
this
came
up
came
up
in
the
first
place
was
about
build
tools
using
the
experimental
modules,
implementation
and
so
like
kind
of
the.
The
need
is
specific
to
that
implementation
like
like
in
this
in
experimental
modules.
I
can't
do
X
kind
of
as
like
what
the
kind
of
where
this
started,
and
so
it
was
like
well
what
what
would
we
have
to
do?
D
What
would
we
have
to
do
to
experimental
modules
to
enable
this
use
case?
So
in
that
sense,
it's
very
particular
to
that
implementation,
whereas,
like
our
general
use,
cases
that
led
to
the
features
are
kind
of
I
mean
at
least
I
think
are
written
in
a
like
agnostic
way
that,
like
I,
don't
know
what
implementation
is
going
to
satisfy
this
use
case.
This
is
just
something:
I
want
node
to
be
able
to
do
kind
of
kind
of
thing.
D
F
No
I
think
yeah
and
I
I
was
just
hoping
that
if
we've
got
sort
of
like
features
and
use
cases
already
say,
for
example,
the
end,
then
you
know
not
saying
this
is
the
way
to
go.
But
eventually,
if,
if
we
decided
oh
wait,
a
sec,
we'll
just
evolve
the
experimental
modules
implementation
as
a
solution,
we'd
need
to
show
that
it
actually
satisfies
those
use
cases
and
and
if
there
aren't
some
that
already
require
what
we're
talking
about
now.
Maybe
we've
got
a
gap
and
if
there
are
I
should.
D
F
B
I
just
kind
of
want
to
reinforce
that
we
have
a
bunch
of
different
ideas
going
around
about
implementations
and
those
can
vary
wildly.
They
have
different
strengths,
they
have
different
weaknesses,
I,
don't
think
any
implementation
on
its
own
kind
of
is
flawless.
I,
think
everything
has
trade-offs,
and
that's
part
of
why
this
working
group
has
so
much
to
discuss,
but
I
think
has
been
mentioned
in
a
few
places.
It
would
be
nice
to
have
some
base
implementation
that
everybody
could
agree
on.
B
Some
people
dislike
experimental
modules,
and
so
maybe
we
could
base
it
off
something
more
stripped-down
than
that
I
know
miles
had
a
PR
that
also
had
controversy,
so
maybe
making
this
Colonel
this
virtually
unusable
base.
Implementation
would
be
a
good
effort
and
then
we
can
build
the
usability
on
to
it.
So
I'll
give
it
back
to
you.
Michael
I
was.
F
G
A
Yeah
I,
Michael
I
think
it's
very
much
a
subset
of
what
we
have
right
now.
Brad
and
I
talked
a
little
bit
about
what
it
could
be,
and
perhaps
we
should
spin
up
an
issue
particularly
around
that
the
idea
of
making
a
subset
kernel
that
could
work
would
be
removing
any
of
the
capabilities
of
the
current
implementation
that
this
that
stopped
future
implementations
from
working.
A
So
things
that
we
could
remove,
for
example,
would
be
supporting
Jas
at
all,
and
that
doesn't
mean
that
we
will
not
support
jazz
later,
but
it
just
means
with
having
the
know
transparent,
Interop
and
with
removing
the
support
for
Jas
that
is
now
available
to
be
decided
upon
in
a
future
enhancement.
Another
example
of
this
would
be
in
making
a
more
restrictive
loader
I
have
a
PO
request
already
open
for
that
I'm,
not
a
hundred
percent.
A
If
that's
you
know
the
implementation
that
we'd
want
to
use,
but
by
restricting
the
resolute,
an
algorithm
of
the
loader
itself,
we
would
similarly
be
able
to
have
you
know
the
loader
expand
later.
Another
example
of
a
restriction
that
we
could
introduce
would
be
you
know
not
having
any
sort
of
interrupt
right
away,
but
introducing
the
API
that
Gus
was
working
on
for
make
required.
A
So
we
would
have
all
the
kind
of
low-level
capabilities
that
we
would
need
to
build
the
other
api's,
it's
not
by
any
means,
a
version
of
the
module
system
that
people
are
going
to
want
to
use
which
actually
may
stop
people
from
using
them
in
production
with
these
api's
incomplete.
But
it
would
be
a
kernel
that
any
code
that
is
written
against
would
continue
in
theory
to
be
supported
by
whatever
we
do
later,
because
these
would
be
kind
of
the
core,
consistent
API
services.
That
would
not
change.
A
G
I'm
good
I
think
it's
I
think
it's
a
really
really
good
idea.
It's
it's
not
starting
from
scratch.
It's
starting
from
from
es
modules
and
figuring
out
how
to
build
up
to
whatever
generates
a
consensus
and
instead
of
figuring
out
what
is
the
end
goal.
Let's
start
from
small
and
build
consensus.
Slowly
and
you
know
we
can
create
an
issue
and
start
the
conversation
from
there.
It
might
start
to
becoming
really
constructive.
I
think
it's
a
great
idea.
C
Yeah
so
I
think
I
have
two
points
on
this.
First
off
is
I,
always
considered
what
would
happen
if
we
started
off
with
ESM
and
implemented
a
CJ
s
loader
inside
of
esm
I
considered
this
because
I
was
experimenting
and
because
there
wasn't
much
bandwidth
for
Interop
early
on
when
experiment
modules
came
out,
it
is
definitely
not
going
to
be.
C
So
the
second
point
is:
if
we
start
off,
you
know
with
a
minimal
implementation.
I
think
that
if
you
take
away
the
games
that
that
happened
over
the
past
year
from
experimental
modules
like
the
new
editions,
it
was
very
restrictive
early
on.
If,
if
we're
going
to
compare
it
to
about
six
months
ago,
things
were
just
very
difficult,
so
so
I
think
we
have
to
be
careful
which
features
are
actually
just
the
evolution
of
the
language
itself
and
which
features
are
definitely
going
to
create
like
bottlenecks.
C
That
will
make
it
more
useless
to
have
a
minimal
implementation
out
in
the
ecosystem,
because
if
people
get
frustrated
with
a
minimal
implementation
on,
they
are
likely
not
going
to
depend
on
it.
They're
just
going
to
say
that
okay,
it
was
an
expectation
that
then
materialized
on.
So
so
we
have
to
be
careful.
What
we
can
consider
you
know
something
we
can
give
up
on.
A
Thank
you,
so
just
a
quick
question
to
everyone
really
quickly.
I
am
feeling
a
really
really
great
traction,
and
movement
towards
consensus
are
the
likes
which
we
have
not
seen
yet
it
excites
me.
We
have
two
more
things
on
our
agenda.
Right
now,
features
adjustments
in
groupings
and
transparent,
or
not
intra
our
people
to
the
idea
of
tabling
these
for
right
now
and
focusing
the
rest
of
our
session,
specifically
on
discussing
what
a
minimal
implementation
might
look
like.
E
H
E
I
H
H
A
That's
fair,
so
we
have
let's
do
this
if
people
are
open
to
it,
we
have
features
and
adjustments
for
groupings
set
for
10
minutes
right
now
and
transparent
or
not
transparent,
interrupt
for
15.
If
we
move
those
both
to
10
minutes,
we
can
have,
we
can
add
another,
you
know,
let's
call
it
5
minutes
to
go
through
the
remaining
hands
that
are
up
for
this
discussion.
I
I
You,
as
you
start,
adding
more
and
more
and
more
publicly,
then
you
kind
of
may
end
discouraging
other
efforts
to
solve
other
use
cases.
So,
for
example,
you
know
if
you
start
off
with
certain
file
extensions,
you
know
as
the
target
and
then
you
solve
all
the
other
news
cases,
but
then
jeaious
has
never
solved.
Then
you
basically
kind
of
give
him
license
to
say
this
is
the
way
that
code
should
be
written,
but
you
haven't
solved
one
of
the
use
cases
and
you
encourage
the
community
to
kind
of
standardize
around.
I
A
E
In
I
think
in
general,
the
principle
of
let's
build
a
minimal
kernel
and
let
you
know
user
land
and
time
evolved
what
can
be
built
on.
That
is
a
great
philosophy,
but
I
think
that
in
this
case,
this
is
something
that
impacts
the
ecosystem.
I
think
I
feel
very
strongly
that
we
only
get
one
shot
at
this.
E
Whatever
we
first
ship
unflagged,
that
is
going
to
be
the
thing
people
depend
on,
and
people
assume
is
the
way
it's
gonna
work
and
they're
gonna
write
their
code
based
on
that
and
so
I,
don't
think
a
minimal
kernel
is
sufficient
to
to
ship
any
module.
Implementation.
I
see
your
note
that
you
weren't
imagining
it
was
I'm
flag.
That's
great,
but
I
don't
care
what
we
ship
flagged
until
we
agree
on.
What's
going
to
be
unflagged
like
so
the
things
that
we've
shipped
now
that
are
flagged.
E
If
we
all
agree
that
those
don't
matter,
then
cool,
we'll
just
delete
them,
but,
like
the
main
I
think
it's
super
critical
that
we
that
the
first
unflagged
thing
we
have
is
not
minimal
that
it
actually
meets
all
the
use
cases
that
we
want
to
meet.
Initially,
and
also
allows
for
the
use
cases
we
want
to
allow
for
and
I
think
that,
the
longer
we
Bend
until
we've
decided
that
direction
the
greater
risk
we
have
of
of
letting
the
flagged
implementation
gain.
E
A
lot
of
usage
so
like
this
happened
with
generators
in
NoDo
point
11,
like
big
user
land
library,
started
depending
on
them.
You
know
because
they
were
on.
They
were
flagged
for
so
long.
So,
like
I,
think
that,
even
though
I've
cautioned
against
against
rushing
to
a
shipping
implementation,
we
do
need
to
be
careful
that
we
that
we
don't
ship
in
a
flag
implementation
for
too
long.
That
will
end
up
tying
our
hands
with
what
we
can
ship
on
flag
later.
That's
my
piece.
H
Thank
you
very
much.
Jeremiah
yeah
I
agree
with
what
was
it
Wes
and
so
I
think
doing
a
minimal
implementation
from
here
is
a
bad
idea
and
step
backwards.
That's
essentially
what
we
had
originally.
As
someone
else
said,
a
lot
of
things
have
been
added
on
to
it
and
just
a
bit
as
we've
already
seen,
use
cases
where
stuff
doesn't
work
very
well,
and
that
sort
of
thing
also
like
what
I'm
not
really
sure
how
a
minimal
we
can
realistically
get
for
something.
B
Thank
you.
So
this
is
a
different
direction
than
I
thought.
This
was
gonna
go
actually,
so
this
is
kind
of
a
meta
comment
or
discussion.
My
thought
was
at
least
personally
whatever
this
minimal
kernel.
Is
we
never
ship
it
anywhere?
It
is
just
the
basis
for
all
other
proposals.
I,
don't
know
how
other
people
feel
about
that
like
like
we
wouldn't
ship
it
flagged.
We
wouldn't
ship
it
unflagged.
It's
just
all.
Proposals
must
meet
this
baseline
expectation.
A
G
I'll
go
with
Brad.
I
will
go
even
further,
I'm,
not
sure
we
even
need
to
implement
it.
I
think
if
we
start
with
the
minimal
kernel
and
understanding
which
can
be
which
can
be
consensual
and
then
work
from
that
so
work
positively
until
we
reach
consensus
instead
of
thinking.
How
do
we
change
the
current
thing
as
a
basis
for
discussion,
not
so
much
as
a
basis
for
implementation.
H
F
Okay,
great
and
Michael,
this
is
my
last
thought
is
like
I.
Think
the
where
my
question
was
coming
from
is
just
finding
if
there's
anywhere
we
could.
You
know,
get
to
the
point
where
we
have
enough
consensus
on
something
to
then
have
a
place.
You
could
land
code
changes
that
people
would
look
at
and
so
forth.
So
last
thing
I'll
add
in
there
is
I
know
it's
been
discussed
before,
but
I
wonder
again.
F
Like
there
didn't
seem
to
be
enough
consensus
Docs,
you
do
it
in
in
the
core
repo.
So
if
maybe
you
know
like,
we
did
for
NEPA
I
have
a
have
a
fork.
You
can
at
least
have
a
place
where
people
can
experiment,
and
you
know
once
it's
once
it's.
You
know
it's
gotten
far
enough
and
there's
consensus.
You
can
look
at
bringing
it
back
into
the
the
core.
So.
A
D
D
Because
I,
could
you
know
if
it's
gonna
be
out
there
in
the
public,
and
people
are
gonna
use
it
even
though
we're
telling
them
not
to
then
I
want
to
try
to
keep
molding
it
in
the
direction
that,
like
I,
would
want
to
try
to
improve
it
to
you.
If
it's
gonna
be
pulled
out,
then
it
doesn't
matter,
but
so.
A
As
it
is
right
now,
they're
like
the
agreement
that
we
have
as
a
working
group
is
that
summer
patch
things
can
land
on
core.
It's
only
semper
miners
that
need
to
have
working
group
approval,
and
it
wasn't
I
mean
with
the
way
that
it
works.
It
could
land
just
were
you
know,
respecting
the
agreement
and
the
TSE
said
they
would
respect
it.
There's
no
code
freeze
on
modules
patches
can
land
like
small
fixes,
can
land.
The
only
thing
that
requires
discussion
is
cember,
minor
changes,
and
you
know
when
things
come
in
that
are
controversial.
A
A
A
A
A
A
A
Okay,
great,
so
I
had
misunderstood
what
this
one
was:
I'm,
rebasing
I'm
merging
that's
good
to
go
and
we
just
scored
ourselves
10
minutes.
So
now
we
can
talk
about
interrupts
for
a
while.
Then,
if
we
have
some
time
we
can
head
back
to
the
discussion
around
a
kernel,
but
I
think
we
have
consensus
on
that
as
well,
so
I'm
going
to
go
ahead
and
start
a
10-minute
timer
who
wants
to
lead
the
conversation
on
Interop
I.
B
Transparent,
interrupt
not
transparent,
I
think
there
is,
at
least
in
the
issue.
Threads
a
growing
usage
of
import,
interrupts
and
required
in
Tura,
basically
transparent,
Interop
is
somewhat
vague
and
which
it
applies
to,
and
import
interrupts
is
the
ability
to
import
non
es
and
modules
and
require
import
require
interrupts?
Is
the
ability
to
require
ESM
modules.
B
That's
it
let's,
let's
not
use
it
both.
Let's
just
be
a
little
bit
explicit
here.
I
know
some
people
earlier
in
this
discussion.
We're
saying
interrupts
is
mandatory
for
a
minimal
implementation,
not
not
whatever
the
kernel
is.
What's,
let's
talk
about
implementation
requirements,
so,
if
you
think
interrupt
is
required,
can
you
just
kind
of
go
over
your
reasons
and
which
kind?
So
we
can
get
a
little
bit
clearer
picture
if
you're
talking
about
the
both
require
interrupt
and
import
tuner
up.
H
A
K
Great,
so
if
we
were
talking
about
strong
feelings
for
era,
all
right,
I
have
a
lot
of
expectations
for
interrupts.
That
I
am
well
aware.
Many
of
them
probably
won't
come
to
fruition
I'm
going
to
eat
them
anyway,
because
it
would
be
very
nice
if
they
can
interrupt
so.
The
first
one,
that's
important
to
me
is
actually
be
able
to
require
or
import
things
specifically
importing
things
in
ESM,
and
you
can
import
like
a
package
name
like
whatever,
and
whether
that
package
is
ESM
or
CAS.
K
Ts
I
am
aware
that
it's
less
likely
but
I'm
going
to
take
that
anyway,
like
those
two
things
are
very
important
for
people
to
actually
be
able
to
update
their
packages
like
they're
they're
critical
in
that
regard,
moving
forward
without
them
I
do
think
we'll
hamstring
how
fast
the
ecosystem.
That's
just
my
stance.
K
Mean
that
there
needs
to
be
a
way
that
they
can
have
the
same
API
between
some
versions,
where
there
is
overlap
where
you
can
expose
the
same
thing
in
ESM
and
CJ
s
doesn't
necessarily
have
to
be
pre
it'd
be
nicer.
The
like
the
larger
that
overlap
is
the
better
because
then
the
less
effort
model
maintainers
have
to
go
through
to
work
through
this
transition
for
their
package.
Consumers,
but,
like
you,
need
to
be
able
to
say,
RA
Express
Express
now
default
expresses
commonjs.
Stop
module
now
exports
a
member
names
default.
K
Now
it's
always
a
default,
no
matter
how
you
import
it.
Great
cool
people
can
migrate
and
then
Express
migrates
the
underlying
code
TSM
and
everybody's,
like
oh,
it's
the
same
for
all
consumers,
but
we
didn't
need
to
break
our
API
to
migrate
TSM,
who
we
were
able
to
do
those
two
actions:
breaking
the
API
and
migrating
ESM
independently.
Being
able
to
do
those
two
steps
independently
is
very
important.
H
H
B
A
It
doesn't
really
solve
all
use
cases.
Unfortunately,
it
returns
a
promise
which
means
there's
no
real
way
to
export
those
symbols
and
those
promises
become
infectious,
but
unfortunately,
that's
just
what
we
have
unless
we
were
to
have
top
level
of
weight
inside
a
common
jeaious
which
I
really
don't
see
how
we
could
do
without
breaking
the
world.
A
The
flipside
coming
over
to
the
ESM
side,
I
I'm,
personally,
not
a
fan
of
allowing
importing
of
commonjs
as
long
as
it's
done
as
a
default
and
it
hijacks
the
GS
I
think
that
the
ecosystem
fracture
that
it
creates
and
I
know
that
when
we
start
digging
in
around
mind
types,
it's
not
from
an
underlying
architecture
perspective
this
way,
but
for
the
average
person
who's
writing
code.
The
way
that
they'll
see
it
transparently
is
I'm
able
to
import
a
file.
A
That's
j/s,
and
it's
going
to
work
in
the
browser
when
it's
ESM
I
will
never
be
able
to
import
common
common
is
not
a
goal
that
will
be
supported
in
that
ecosystem
and
making
code
work
around
both
is
important.
Now,
when
we
talk
about
a
minimal
kernel,
I
think
one
of
the
things
that
we
can
do
early
on
that
we
can
reach
consensus
around,
is
supporting
MJS
and
I.
A
Think,
having
MJS
supporting
MJS,
having
consensus
around
MJS
for
being
like
the
pointer
to
the
mime
type
for
ESM,
is
an
important
thing
for
say,
especially
to
the
IETF
when
we
want
to
have
this
standardized
and
accepted
I
believe
that
API
such
as
import
meta,
require.
Although
I
know,
we
don't
have
consensus
around
that,
are
the
better
ways
of
having
explicit
ways
of
bringing
in
common
Jas.
A
One
of
the
things
that
I
think
is
really
important
here
is
that
we
can
have
extremely
clear
errors
if
the
main
reason
to
talk
about
not
of
having
transparent
interoperability
specifically
being
able
to
import
common
Jas
is
having
the
ability
for
people
to
not
have
to
know
what's
going
on.
But
if
we're
able
to
trap
errors,
if
we're
able
to
trap
trying
to
import
common
Jas
and
give
someone
a
clear
error
that
says:
hey
the
package,
you're
trying
to
import
is
to
come
and
Jas
error.
A
Please
use
this
other
API
I
think
that
we
have
the
ability
to
to
accomplish
the
goal
from
a
user
experience.
Standpoint
will
not
conflate
in
the
ecosystem
and
overloading
the
loader
itself
I'll
step
back
for
now,
because
there's
lots
of
hands
and
I
think
we
only
really
should
do
another
five
minutes
on
this
for
right
now
that.
B
A
G
Yes,
sorry
I'm,
mostly
with
Miles
I'll,
try
to
point
out
from
from
my
point
of
view,
first
of
all
required
requiring
the
SM
that,
for
me,
that's
not
possible,
ASM
is
asynchronous,
require
a
synchronous
and
returning
and
a
promise
from
requires
you
just
use
away
import
and
we're
done
dynamic.
Import
so
require
ASM
is,
is
a
no
is
a
no
go
for
me.
The
other
way
PSM
to
CJ
is
I,
think,
isn't
very
important,
because
we
have
a
lot
of
wild
code
out
there.
G
That
is
using
ESM
in
a
trance
file
sort
of
way
and
there's
this
assumption
that
you
can
use
yes,
m2
imports,
ejs
modules
now
I
know
destroyed
it,
and
the
current
implementation
enables
us
to
do
that.
Import
CJ's
from
me
SM,
but
it
only
and
correctly
allows
default
exports
a
default
imports
to
be
imported
from
CJ
S,
which
for
me
is,
is
not
a
transparent.
I
can't
take
all
the
code
out
there
that
uses
yes,
modules,
using
translation,
and
just
you
know,
quartet
as
it
is,
because
there's
no
named
exports,
no
named
imports
to
use.
G
G
E
Know,
I'm
jumping
the
queue,
but
last
week
was
tc39
and
I
think
it
was
guys
proposal
to
create
a
new
kind
of
module
record.
And
although
there
was
quibbling
about
that
specific
detail,
the
committee
very
specifically
and
enthusiastically
said
that
TZ
39
will
make
whatever
language
changes
they
can
get
away
with
in
order
to
enable
node
to
allow
importing
of
named
imports
from
CJ
s.
So
I
don't
think
that
that
I
think
that
that
is
now
something
that
we
will
be
able
to
get.
How.
B
E
B
G
C
C
You
can
definitely
import
by
name
I,
try
to
avoid
it
in
longer
term
experiments,
but
it's
it's
stable
from
my
tests,
but
for
tjs
modules,
I
think
static,
import
versus
dynamic
import
is
a
is
something
that
we
have
to
really
be
more
clear
about
when
we're
saying
import,
because
every
time
the
word
import
is
stated,
if
it's
dynamic
import,
it's
it's
a
completely
different
story
for
CJ
s,
static,
import,
having
a
file,
do
all
your
require
and
CJ
s
work
and
then
just
import
that
one
default
import
can
definitely
be
a
very
predictable
way
for
you
to
say
that
I'm
jumping
out
into
the
CJ
s
ecosystem,
I'm,
getting
stuff
done
they're
coming
back
into
ASM,
and
this
is
all
done
before
my
static
imports
are,
you
know
linked
and
my
module
kicks
in
requiring
ESM?
C
Definitely
whether
or
not
gives
a
promise
or
not
I,
don't
think
it's
a
good
idea.
If
people
really
want
to
you
know
move
forward,
then
we
could
encourage
dynamic
import
statements
and
CJ
s
modules
as
a
very,
very
clear
indication
that
the
code
is
is
being
updated.
It's
catching
up
with
newer
trends.
It's
not
to
be
confused
with
code
that
might
have
not
been
updated
and
is
requiring
something,
but
that
thing
completely
changed.
I
guess:
terminology
I'll,
just
feed
there.
B
C
I
think
for
dynamic
import
statements
in
a
require
like
Anna
CJ
s,
module
should
be
encouraged,
as
opposed
to
considering
the
implications
of
loading
CJ
s
as
a
static
import
of
one
of
the
one
of
these
and
modules
being
loaded
in
a
tree
like
in
a
graph.
So
so
I'm
just
saying
that
you
know
when
we're.
When
we're
discussing
things,
we
talked
about
import
and
CJ
s,
just
always
clarify.
C
I
K
I
Also
had
a
hinge
earlier
when
we
can't
have
two
hands
and
one
of
the
things
that
I
was
curious.
It
out
was
just
like
the
idea
of
we
mentioned
that
there's,
like
this
risk
of
community
fracture
and
I,
was
curious
as
to
like
what
we
specifically
meant
by
that
like
there's,
there's
like
another,
a
community
fracture
would
just
how
people
already
consumed.
Yes,
logical,
whatnot,
but
I
understand
that
there's
another
concern.
I
forget
who
specifically
brought
it
up,
but
it
was
something
about
being
able
to
look
on
Jason
amah
in
the
browsers
versus
EndNote.
I
K
A
H
So
Beckham
sort
of
way
I
was
reinforcing
her
in
there
like
in
response
to
two
miles,
I
mean
I.
Personally,
don't
don't
really
have
very
strong
feelings
about?
Well,
maybe
that's
the
wrong
way
is
to
say
I
want
to
say
that
I
don't
want
to
say
that
I
don't
care,
but
I
I
kind
of
don't
I'm
about
aligning
perfectly
with
browsers,
because
no
doesn't
anyways
and
also
I
I
care.