►
From YouTube: Node.js Foundation Modules Team Meeting 2018-06-20
Description
A
A
A
A
There's
a
pull
request
to
change
the
way
in
which
new
members
request
membership.
We
were
doing
it
through
pull
requests,
but
that
ends
up
creating
a
lot
of
duplicated
effort
since
we're
now
using
a
tool
to
update
our
membership
list.
So
this
boat
request
just
changes
it
to
open
an
issue
has
a
whole
bunch
of
people
who
have
responded
online.
Does
anybody
who's
on
the
call
right
now
object
to
landing
cool?
We
can
go
ahead
and
land
that
now
the
next
we
have
is
a
pull
request.
A
Open
for
infant
meta
require
encore,
so
so
JD
I
think
you're
going
through
this
I
think
we
removed
another
pull
request
that
you're
gonna
review
and
some
other
stuff,
and
we
need
to
keep
the
links,
but
we
can
come
back
and
get
that
afterwards,
but
so
there's
a
pull
request.
Open
Encore
for
import
meta
require-
and
this
is
just
so.
People
know
that
that
going
on
there
are
some
objections
and
some
different
thoughts
towards
it.
A
Brad
is
not
on
the
call.
So
if
you
take
a
look
at
issue,
1:35
I
think
this
is
another
future
agenda
item
to
just
kind
of
dig
into
loaders
the
high
level
of
the
being
that
a
lot
of
our
use
cases
are
relying
on
us
having
loaders
that
are
reliable,
and
so
we
kind
of
need
to
dig
into
that
implementation
case
a
little
bit
more
and
then
the
last
one
that
we
have
on
here
is
another
pull
request.
Add
features
list
to
read
me
that
is
Jeffries
pull
requests.
Jeff.
B
Sure
this
was
just
in
order
to
close
all
of
those
issues
for
open
features.
We
had
talked
in
one
of
the
issues
about
consolidating
them
into
a
list
that
could
go
into
the
readme
and
then
I
could
close.
All
of
the
other
features
I
see
the
comments
on
there.
Obviously,
it's
subject
to
change.
Obviously
not
every
implementation
or
the
final
implementation
will,
you
know
achieve
all
of
these
features.
B
This
is
much
more
like
I
was
hoping
to
just
have
this
be
like
a
housekeeping
thing
in
order
to
let
us
clean
up
the
repo
and
we
defer
the
discussion
of
like
wait
a
minute.
These
eight
features
you
know
it
shouldn't
be
on
this
list,
follow
block
because
that
could
just
devolve
into
an
endless
discussion.
So
I
was
trying
to
push
that
out.
C
B
B
A
A
A
So
to
read
the
paragraph
that
we
have
in
here,
the
meet
this
meeting
is
to
discuss
transparent,
interrupts
with
the
goal
of
informing
and
coming
to
a
decision
on
if
any
transparent
interrupts
should
be
possible
by
default
or
by
a
loader
or
otherwise.
Please
keep
in
mind
that
transparent
Interop
is
a
large
umbrella.
We
should
clarify
and
make
distinctions
about
what
we
are
discussing,
one
direction
to
direction
etc.
D
D
So
it
would
be
most
useful,
I
think
if,
as
a
group,
we
came
to
a
decision
on
whether
any
or
all
of
those
things
should
be
possible
should
be
made
possible
by
custom
loaders.
And
if
we
can
agree
on
that
which
I
hope
that
we
can
I
expect
that
we
can.
Then
we
can
advance
the
discussion
to
talking
about
defaults.
D
A
D
That
that's
implementation
detail
that
I
think
we
need
to
read
to
resolve,
but
I
think
that
that's
something
that
can
be
decided
separately
from
is
this
behavior.
We
want
to
be
possible
and
it's
totally
fine.
If
we
say
yes,
we
want
it
to
be
possible
and
then
we
end
up
with
an
implementation
that
we
say
now
because
of
this
implementation.
We
no
longer,
you
know
we.
D
D
I
think
that
is
also
a
name,
a
I
think
that
is
also
an
implementation
detail
and
I
think
ironing
that
out
can
also
wait
until
we
have
agreed
like
so.
In
other
words,
the
reason
why
I
separated
out
named
imports
is
because
we
have
I
think
you
think
I
think
we
have
previously
identified
that
there
may
be
implementation
concerns
there,
that
make
it
tenable
or
not,
but
I
think
that's
that.
D
That's
why
it's
separated,
but
I
still
think
that
we
can
make
a
decision
about
whether
that's
something
we
want
to
be
to
be
possible
without
having
to
you
know,
get
into
the
technical
details
and
and
I
fully
acknowledge
that,
if
require,
USM
can
only
return,
a
promise
that
that
will
have
an
impact
and
that
there
will
be
opinions
about
that
and
that
will
trigger
discussion.
But
I
I'm,
hoping
to
prior
to
you
know,
kind
of
in
a
triage
sense
defer
that
discussion
until
we've
agreed
that
require
ESM
would
be
nice.
Essentially,
okay,.
G
G
It
doesn't
really
matter
if
import
or
require
I
think
the
functionality
is
there
I
in
terms
of
require
that
doesn't
require
that
there's
no
returning
promise.
That
sounds
crazy,
because
ESM
is
amazing
loading
mechanism.
Once
we
have
top
level
away,
it
would
not
be
possible
to
do
that.
So
from
my
point
of
view
that
that
direction
from
CJ
s
to
ESM
either
we
don't
need
it
or
we
can't
implement
it.
That's
my
first
comment
on
the
other,
which
is
from
you
is
more
important
from
CJ
s
to
ESM
sorry
from
ESM
to
CJ
s.
G
The
whole
question
of
loaders
seems
to
me
problematic
because
we
need
to
come
out
with
a
really
good
statement
about
how
this
Interop
is
happening
and,
if
we
said
yeah,
you
can
use
this
loader
or
this
loader,
then
we're
basically
splitting
the
ecosystem
into
modules
that
work
with
this
loader
and
modules
that
work
with
the
other,
loader,
etc,
etc,
which
is
fine
for
edge
cases,
but
definitely
not
fine
for
the
mic
from
interrupts
between
CJ
musm,
which
we
will
have
a
lot
of
in
the
coming
years.
The
splitting
on
this
issue
seems
a
bit
problematic.
H
I
actually,
like
Jordans,
deferring
the
loader
discussion,
because
we
have
a
very
vague
notion
of
what
loaders
are
right.
Now
we
haven't
made
well-defined
terms
so
they're
kind
of
magical.
The
question
he
proposed
I
do
like
it's
basically
split
into
two
parts,
like
you
said:
the
ability
to
use
import
to
load
command,
jeaious
and
the
ability
to
use
require
to
load
yes
modules.
I,
don't
want
to
talk
about
specifics
of
the
API.
Is
that
we're
doing
this?
H
H
H
So
with
that
in
mind,
I
think
we're
gonna
have
to
really
think
hard
on
importing
colleges
and
I
want
to
make
the
claim
that,
regardless
of
any
other
things
about
named
imports
about
how
mechanisms
work,
just
the
ordering
issue
makes
a
clear
case
that
we
must
support
it
in
some
fashion.
Whatever
that
fashion
is
somewhat
neutral,
that's
a.
A
You
just
mentioned
a
goal
that
I
think
is
an
important
one
that
isn't
often
talked
about,
which
is
ordering
issues
if
we
want
to
maintain
the
ability
to
specify
order
for
a
common
jeaious
module
inside
of
esm
static
jaya
like
a
static
import
of
common
Jas
is
the
only
way
to
do
it.
I
know
Jordan
when
that
we've
talked
about
in
the
past
and
I
know
a
number
of
people
from
the
note
project
also
believe
in
this
one
is
transition
so
to
make
it
easier
for
people
to
transition
between
ecosystems.
A
So
I
would
like
to
spend
a
little
bit
of
time
with
other
people
if
they
can
raise
their
hands.
If
you
have
other
goals,
aside
from
ordering
issues
and
transition
for
why
we
would
want
transparent,
Interop
I
would
love
to
brainstorm
some
of
those
and
then
follow
up
with
aunty
goals,
which
are
what
are
some
of
the
risks
of
introducing
transparent
Interop.
And
then
we
can
maybe
talk
about
the
trade-off
of
the
two.
So
Wes,
you
have
your
hand
up
so.
C
When
you
are,
when
you
have
a
library
and
that's
written
in
CAS,
you
can
deprecated
things
and
move
things
to
an
API
that
you
can
actually
migrate
to
ESM
and
then
migrate
to
ESM
without
your
consumers
having
to
go
through
a
breaking
change,
making
it
so
that
your
own
ESM
migration
doesn't
force
all
of
your
consumers
to
break
and
change
how
they
import.
You
as
well
I
think
that's
relatively
important
for
making
it
so
that
the
ecosystem
can
actually
adopt
ESM
at
large
mmm-hmm.
A
I
I
E
So
I
would
like
to
mitigate
at
least
as
much
as
possible,
either
month
so
modules
and
maintainer
zuv
modules
of
both
serious
and
innocent
as
being
treated
as
second-class
citizens,
from
either
side
and
I.
Think
if,
if
we
introduce
things
where
one
thing
clearly
does
not
work
and
people
I'm
moving
to
say,
ESM
or
don't
want
to
move
TSM,
there
will
be
significant
contention
among
the
community
about
it.
Okay,.
G
Yeah
I'd
like
to
point
out
that
transparent
interrupts,
where
you
want
to
move
from
CJ's
to
SM
transparently,
will
not
currently,
as
it
is
now
be
transparent
because
we
only
have
default
inputs.
So
if
we're
moving
from
CIS
default
import
to
ESL
named
imports,
that
will
anyway
be
a
breaking
change.
Currently
now,
if
we
go
to
the
named
imports-
and
you
know
a
tweak
the
whole
suggesting
a
bit-
we
lose
the
ordering
that
Brad
was
talking
about.
We
was
they
ordering
because
things
don't
happen
in
the
correct
ESM
or
okay.
F
Yeah
I'm
like
to
be
honest,
I'm
kind
of
wondering
if
we
want
to
clarify
the
like,
which
which
is
our
prior.
It's
going
to
be
down
the
road
to
have
people
continue
authoring,
new
Common
KS
packages
or
allow
people
who
are
authoring
ESM
packages
to
actually
have
them
work,
as
common
j/s
modules
to
like
I
think
the
transition
needs
to
have
clear
stages
where
we
say
okay
now,
the
priority
is:
is
that
anyone
who's
working
on
either
would
feel
that
the
ecosystem
is
supporting
them
down
the
road.
F
The
priority
would
be
to
actually
encourage
ESM
oversee
a
CJ
s
or
maybe
I'm
wrong
about
that.
But
some
clarity
on
those
steps
down
the
road
will
help
us
make
decisions
progressively
towards
a
particular
direction
and
I
think
that
direction
and
the
steps
in
general
leading
to
that
direction
should
be
something
that
we
are
clear
about.
F
Maybe
the
timeframe
would
be
a
little
bit
unpredictable,
but
at
least
we
must
have
a
predictable
path,
moving
towards
what
I
believe
should
be
promoting
ESM
if
there
is
no
need
for
CJ,
yes
and
in
the
far
future
I
guess
that's.
You
know
very,
very
open
to
interpretation,
but
just
some
clarity
and
milestones:
okay,.
H
Your
handout,
oh
I,
have
two
comments.
One
actually
was
to
Gil's
point
about
not
being
able
to
produce
named
imports
easily
from
commonjs
I
I.
Personally,
think
that
that
is
an
anti
goal
and
not
a
reason
we
should
say
transparent,
inter
up
is
impossible
for
importing
comm
jeaious.
If
you
have
a
common
jeaious
module
and
you
have
it
be
a
asynchronous
promise
as
its
module
exports,
it
would
appear
when
you
import
it
like
a
es
module
or
require
it
like,
as
an
es
module
would
appear
the
named
imports
thing.
H
If
you
upgrade
your
asynchronous
module
exports
into
es
module
format,
you
could
still
keep
a
single
default
export
and
you
would
have
the
same
feasible
API
to
your
consumers,
so
we've
maintained
the
transparency
here,
even
though
we've
transitioned
from
command
jeaious
into
ESM
as
an
upgrade
path.
The
ability
to
have
named
exports
I
would
like
to
defer
to
something
else,
because
that
is
a
breaking
change.
If
you
were
to
go
an
upgrade
from
CJ
ste
SM,
and
if
we
are
only
able
to
support
some
subset
of
names
for
exports
from
CGS.
H
Changing
that
list
of
exports
is
a
breaking
change.
You
would
not
have
to
do
that,
though,
so
we
can
plan
around
it
and
we
can
make
it
so
you
can
transition
from
command
j
s
to
e
sm
in
a
way,
that's
not
visible
to
your
consumers,
so
I
think
that's
an
explicit
goal
and
I
do
think
it's
possible,
but
we
need
documentation
added
about
how
to
do
that.
So
that's
it.
J
Yeah
I
just
wanted
to
address.
Firstly,
the
the
comment
you
made.
That
was
because
we
had
a
two
of
the
goals
in
conflict
that
one
of
them
was
determined
to
be
an
anti
goal.
So
when
you
were
sort
of
talking
about
their
miles,
if,
if
named
exports
and
execution
order
are
gonna,
be
you
know
a
trade
off
between
them,
it's
either
one
or
the
other.
That
therefore
named
exports
and
transparent
interrupt
is
impossible
or
it's
an
on
goal.
J
I,
don't
think
that's
valid
I
think
it's
possible
to
have
goals
that
are
necessarily
consistent
with
each
other,
because
we
understand
that
this
is
a
an
area
of
trade-offs
that
we
have
to
weigh
up
like.
We
can't
get
every
single
goal
we
want.
Necessarily
there
will
have
to
be
some
trade-offs
made
in
this
process,
and
and
so
just
because
two
goals
aren't
logically
consistent
with
each
other,
doesn't
mean
that
they
can't
both
be
goals.
The
other
thing
is
named
exports
and
execution.
Even
interleaving
may
well
actually
work
out.
J
I,
don't
know
if
there
were
any
updates
on
the
spec
process
around
that
or
who
might
have
the
best
update
on
that.
Then.
Maybe
someone
could
mention
what
the
process
is
there
and
then,
finally,
on
just
with
respect
to
Bradley's
point
I
think
the
the
upgrade
path
from
common
jeaious
chasm
we
have
to
in
terms
of
the
named
exports
there.
As
long
as
we
can
support
the
majority
cases
of
named
exports
usage
and
yes,
a
default
is
a
valid
path
from
defaults
of
common
shares
to
default.
J
An
ism,
that's
a
valid
upgrade
path,
and
also
just
because
named
named,
exports
are
necessarily
always
going
to
be
valid
because,
for
example,
yes,
module
exports
have
to
be
valid.
Identifier
names,
whether
as
object
properties
can
be
any
valid
object,
property
name,
and
so
you
can
have
all
those
other
different
things
and
in
the
in
the
strings,
I,
don't
you
know
that
that
doesn't
necessarily
affect
the
majority
case
where
named
exports,
safe
identifiers
and
unsafety
is
right.
So
yeah,
just
with
respect
to
the
point
on
specification,
around
execution
and
named
exports.
C
Mean
I
think
Bradley
actually
covered
most
of
what
I
wanted
to
say
where
even
with
just
a
fault.
Technically,
there
is
some
overlap
between
the
api's
that
you
can
provide
between
them.
If
you're
willing
to
look
up
ESM
via
require
like
and
that's
that's
what
I
believe
is
really
important
there
being
some
overlap
between
them,
so
you
can
have
a
non-breaking
transition,
even
if
the
transition
period
is
a
little
awkward
in
terms
of
your
API
shape,
and
it's
just
the
wider
you
make
that
overlap.
I
I
C
And
on
the
note
on
identifier,
names
like
most
of
the
most
popular
NPM
packages
are
actually
represented
by
typescript
declaration
files,
which
are
actually
ESM
syntax.
The
majority
of
libraries
only
export
things
with
valid
identifier
names.
It's
like
most
things,
if
they
add
them,
would
be
able
to
transition
easily.
A
Excellent
anything
else
was
not
okay
and
if
I'm
correct
most
of
the
things
that
you
were
bringing
up,
also
kind
of
fall
under
transition
as
a
goal,
correct,
yeah,
excellent,
so
I
thought
that
you
know
we.
We
have
mostly
the
same
list
for
the
goals,
although
we've
gotten
into
some
specific
goal:
cases
and
transitions,
because
it
gets
a
little
bit
more
specific,
but
I
thought
that
I
could
follow
up
by
listing
some
antique
goals.
That
I
think
are
you
know
reasons
why
I
myself
have
pushed
back
against
transparent
and
trop.
A
One
example
of
an
anti
goal
is
confusing
errors,
so
I,
don't
know
how
many
people
here
have
tried
to
do
named
exports
from
a
common
j/s
module
right
now,
but
the
error
that
you
get
is
not
actually
particularly
useful,
which
leads
into
a
second
anti
goal,
which
is
like
hard
to
teach,
so
this
I
think
pairs
nicely
with
the
transition
goal.
Where
we're
talking
about
making
it
easier
for
people
not
having
to
know
what
they're
loading,
because
as
long
as
we
don't
have
named
exports,
you
do
actually
need
to
know
now.
A
We
could
work
against
the
entacle
of
confusing
errors
and
hard
to
teach
by
making
better
errors,
but
these
are
two
examples
of
kind
of
Antigua's
that
I
feel
our
current
implementation
of
transparent
Interop
creates
another
one
that
I
do
want
to
bring
up
and
then
I'll
concede.
The
floor
is
web.
Interop
breaking
the
web
I
think
introducing
a
goal
that
is
not
supported
by
the
web
by
default
is
a
potential
problem.
It
doesn't
mean
this
is
a
reason
not
to
do
it,
but
I
do
think.
A
A
H
Not
okay,
so
we
can.
Just
you
want
to
just
call
them
pros
vs.
cons.
Is
that
simpler?
No,
because
there's,
like
three
states
being
represented
here?
What's
the
third
state,
a
goal
is
something
we
are
trying
to
achieve.
An
anti
goal
is
something
we
are
not
explicitly
trying
to
achieve
and
there's
a
con
whatever
you
want
to
call
it
of.
This
is
some
sort
of
tech,
debt
or
some
problem.
If
we
attempt
to
go
forward
with
a
feature
mm-hmm.
A
Okay,
so
I
think
maybe
I
was
just
getting
people
confused
design
myself
was
confused
and
we
can
reevaluate
this
I'll
just
keep
taking
the
list
and
we
can
untangle
it
so
lay
yeah,
so
Jeffrey
said
helpful
errors.
We
can
make
a
goal,
but
I
think
I
think
the
the
challenge
there
Jeffery
the
differences,
I
guess
what
I
was
trying
to
point
out
with
antique
rules,
and
maybe
it
wasn't
doing
a
good
job
with
it
would
be
places
where
transparent
interrupts
can
take
us
that
we
don't
want
and
I
think
you
know.
A
D
What
I
wanted
to
sort
of
+1
and
expand
on
what
guy
and
Wes
and
Bradley
all
said?
I
think
that
when
I
say
when
I'm
in
what
I've
been
saying,
transparent,
Interop
I
have
not
been
saying
been
meaning
strict,
transparent
Interop.
In
other
words
to
me,
the
value
is
not
every
detail
matches
everything
else.
There
are
some
things
that
are
impossible
for
node
to
match.
Browsers
browsers,
have
script
tags
nodes
node
does
not.
D
For
example,
there
are
some
things
that
are
to
match
CJ
s,
because
they're
inherently
different
module
systems,
the
I
think
for
me
default,
transparent
Interop
is
in
service
of
transition,
because
I
think
what
would
be
better
for
all
of
us
is,
if
five
years,
ten
years
less
more
from
now,
ESM
is
the
default
module
system
and
anything
that
is
using
a
different
module
format.
It
doesn't
matter
which
means
not
that
it's
neglected
or
that
you
cannot
use
it.
It
means
that
it's
trivial
to
avoid
there,
so
it's
trivial
to
not
have
to
think
about
that.
D
E
Cgs,
which
came
up
to
TSE
meetings
and
stuff
and
as
a
presentation
sort
of
one
those
TSE
means.
I
had
gathered
a
couple
of
people
who
do
teach
javascript
or
have
teach
javascript,
programming,
languages
and
kind
of
gone
over.
Some
of
the
things
that
we
were
discussing
with
them,
and
one
of
the
things
that
stove
the
most
is.
That
is
extremely
likely
that
having
require
sort
of
like
transparently
work
to
load
es
modules,
but
give
you
a
promise.
G
Yeah
two
things:
actually
one
thing,
and-
and
this
is
something
that
isn't
mentioned
a
lot
and
I
might
get
some
flack
for
that
transparent
Interop
is
for
I,
was
a
very
bullish
on
transparent
to
drop
until
I
got
there
I
found
out
that
it's
only
for
default,
because
then
it's
not
it's
not
transparent,
but
the
transition
won't
be
really
really
transparent.
But
the
more
important
thing
is
the
fact
that
transparent
interrupt
for
me
is
the
only
reason
for
the
M
jsj
split,
except
for
the
entry
point
of
a
node.
G
C
G
G
D
G
Love
to
understand
the
reason
why?
Because
I
really
tried
to
figure
it
out
and
good,
but
but
I'll
listen.
But
if
this
is
true,
if
what
I'm
saying
is
true,
then
my
my
thought
about
it
is
that
making
the
transition
from
the
current
and
CGAs
barbel
webpack
world,
which
is
all
j
s
files
to
an
a
fully
MJS,
would
be
much
more
difficult
than
transitioning
from
a
Jas
world
to
another
Jas
world,
from
a
JSC
J's
world
to
a
Jessie
SM
world.
And
for
me
that
transition
is
incredibly
that's.
It.
A
E
Jeremiah,
can
we
come
to
a
shared
understanding
that
when
we
say
transparent
and
drop,
we
accept
that
if
we
are
kind
of
lying
to
ourselves,
because
perfect,
transparent
and
drop
is
like
technically
not
possible,
so
no
matter
what
way
we
cut
it,
it's
not
going
to
be
directly,
as
the
word
would
intend
it
to
be,
and
perhaps
is
maybe
a
little
bit
of
misnomer.
That's
all.
B
I
was
wanted.
A
second
kill
that,
like
I,
also
would
really
like
us
to
prioritize,
seeing
if
we
can
not
solve
this
problem
with
them.
2's
I
know,
Gil
or
not.
Kill
Jordan
feels
very
strongly
that
it's
like
a
done
deal
and
there's
no
other
way
possible,
cetera
et
cetera,
but
I
mean
you
know.
The
NPM
implementation
doesn't
use
MJS
and
it's.
B
It's
working
code
like
clearly
you
know
I'm
sure
there
are
things
that
you
can't
do
if
we
drop
MJS.
So
maybe
that's
like
it's
more
that
like
there
are
assumption
that
you're,
assuming
that,
like
certain
things,
we're
gonna
want
to
include
in
our
implementation,
are
going
to
require
MGS.
And
so
then
it's
a
trade-off
of
like
what
are
those
things
that
we
can't
achieve.
B
If
we
don't
have
this
file
extension
and
that's
worth
having
a
discussion
about,
but
I
really
don't
think
we
should
just
like
take
as
a
baseline
that,
like
this
decision,
has
been
made.
It
was
made
years
ago,
and
we
must
have
MJS
because
there's
obviously
a
lot
of
pushback
from
a
lot
of
quarters
that
a
lot
of
people
hoping
that
that's
not
going
to
be
required
to.
A
A
So,
even
if
we,
you
know,
have
no
transparent,
Interop
chance
can
be
used
for
ESM
the
node
binary
itself
when
it
loads
a
file
is
not
going
to
be
able
to
know
what
that
a
dual
parse,
whether
that
file
is
ESM
or
if
it's
common,
Jas
and
MJS
is
a
way
of
being
explicit
about
it.
You
have
interest
from
the
IETF
and
I
think
that
there
is
value
in
having
a
file.
Extension
is
an
explicit
way
of
stating
that
it's
GSM
independent
of
whether
or
not
it
can
also
be
supported
by
Jas
and.
B
A
H
J
J
Transparent
Interop
has,
in
terms
of
working
out
how
to
load
a
given
module,
as
well
as
solving
it
for
other
scenarios
such
as
I
des
jeux
mode
packages
and
as
mal
says
it's
it's
something
that
the
user
can
use
so
yeah,
it's
a
but
in
terms
of
transparent,
interrupt
and
how
it
determines
a
source
text
interpretation.
This
is
a
huge
topic
of
its
own
and
there
are
really
a
lot
of
ways
of
going
about
doing
that,
and
there
have
been
a
lot
of
proposals.
J
D
So
I
I
agree
with
Brad
I
do
not
want
to
dive
into
the
details.
The
the
thing
that
compelled
me
to
jump
it
jump
the
queue
there
was
I
I
would
prefer
if
we
did
not
try
to
make
decisions
about
transparent
Interop
with
the,
in
my
opinion,
incorrect
belief
that
it
will
have
any
implications
for
the
necessity
or
viability
of
nsj
in
general.
So
if
we
can
defer
that,
then
great
we
can
come
right
back
to
the
original
question
is:
do
we
want
some
percentage
of
transparent,
interrupts
to
be
possible
and
then
separately?
B
B
Think,
though,
that,
like
what
I
would
here's
here's
I'm
throughout
what
I
would
do
if
I
were
the
ruler
of
everything,
I
would
love
to
just
have
like
node,
be
you
know
it?
Ships
ESM
its
to
is
its
default
mode
of
operation,
and
if
you
want
to
do
anything
with
common
j/s
at
least
say
if
the
entry
point
was
coming,
Jass,
however,
that
is
defined
you
have
to
like
npm
install'
come
and
jest
loader
or
whatever,
and
that
or
maybe
multiple
loaders,
and
then
that's
just
like
throws
into
your
app
whatever
loaders.
B
H
Badly,
so
I
really
want
to
push
the
loader
stuff
out
as
far
as
we
can,
because
we
haven't
discussed
even
what
loaders
are
in
this
group,
so
they're
they're
kind
of
magical,
because
we
don't
have
any
description
about
what
they
can
do
or
what
they
are
that
kind
of
stuff.
That
said,
I
want
to
raise
a
concern.
I
have
with
your
idea
that
we
ship
only
ESM
in
node,
and
that
is
our
support
structure
for
older
releases
if
we
were
to
migrate
so
that
node
only
supports
the
sm
in
its
default
loader.
H
That
means
that
no
existing
files
running
commonjs
would
be
able
to
be
run,
and
in
particular
that
means
it's
a
very
large
breaking
change.
Where
we
go
from
one
version
of
node
that
is
defaulted
to
command
s
to
another
version
that
is
defaulted
to
es
modules,
meaning
the
in
one
version
you
didn't
have
to
have
a
flag
in
the
next
version.
You
do
have
to
have
a
flag
and
we
have
to
keep
this
kind
of
dichotomy
of
there
to
different
default
ways.
H
B
Can
I
just
respond
to
that
my
yeah
yeah,
so
Bradley,
if
I
think
I
mentioned
this
but
may
be
used
to
briefly
I
was
I
was
saying
it
only
if
the
entry
point
that
node
loaded
with
CSM
would
like
the
common
GS
loader
stuff
be
required
like
and
I,
don't
know
how
we're
gonna
define
how
node
knows
what
the?
If
you,
you
know
if
your
entry
point
was
common
to
VSM,
there's
like
plenty
of
different.
B
You
know
options
floating
out
there
and
the
implementations
for
how
but,
like
you
know,
if
you
do
node
space
index
touch
and
that's
a
common
today
as
file
that
would
just
behave
the
same
way
it
does
now
and
node
you
have
to
keep
all
of
its
current.
You
know
comedy
s
support
it's
only
if
you
do
you
know
if
you
start
the
thing
node
index
on
MJ,
ass
or
many
of
the
other
way
is
to
start
loading
in
like
in
ESM
mode
from
the
get-go.
B
K
Okay,
if
you
have
your
average
NPM
start
server,
it
does
not
work
very
well
for
something
that
is,
for
example,
C
I.
To
know
that
you
want
to
distribute
where
you
have
an
entry
point
of
the
shebang,
because
if
you
want
to
have
a
portable
shebang,
you
don't
pass
modern
arguments,
and
that
means
that
we
suddenly
are
up
to.
A
A
But
I
guess
that
would
kind
of
break
anyways.
I
won't
take
too
far
into
that,
but
what
I
do
want
to
maybe
say,
though,
and
Brad
to
your
point
about
not
talking
about
loaders
I
want
to
maybe
phrase
it
the
opposite
way.
Is
it
maybe
too
soon
for
us
to
dig
too
far
into
transparent
Interop
until
we've
actually
defined
loaders
better?
Should
we
maybe
be
shifting
focus
and
putting
effort
into
our
loader
implementation
and
then
making
decisions
about
transparent,
interrupt
once
we
know
the
capabilities
of
the
loaders
Brad.
H
I
would
HIGHLY
discourage
that
approach,
because
the
ability
of
loaders
is
very
limited
and
I
think
that's
part
of
why
I
want
to
discuss
this.
Have
a
presentation
on
them
separately.
I
think
we
are
putting
too
much
reliance
on
loaders
right
now.
I
don't
want
to
keep
adding
more
reliance
on
them.
They
are
not
magical,
they
are
limited
and
we
should
approach
them
with
care.
Whatever
we
ship
with
loaders
is
another
thing
that
we
cannot
unship
later.
H
We
can
spend
time
evolving
what
we
understand
to
be
loaders,
but
stating
we
can't
discuss
any
features
until
we
figure
out.
Loaders
is
a
bit
of
a
problematic
thing
for
me
to
go
along
with
when
we're
talking
about,
I
want
to
shoot
multiple
loaders
in
node
you
talking
about.
We
have
multiple
modes
of
evaluation.
H
Just
like
Yan
was
saying
this
is
problematic
for
CL
eyes.
This
is
also
problematic
just
from
a
usability
standpoint.
What
happens
if
you
switch
into?
Let's
say
we
have
two
conflicting
loaders
for
whatever
reason
that
we
decide
to
ship
by
default,
if
I
have
like
loader
CJ
s
main
and
then
loader
es
in
main,
those
are
in
conflict
with
each
other.
If
we
go
even
further,
why
are
we
having
multiple
loaders
to
begin
with
shouldn't
the
default,
be
something
that
is
able
to
be
used,
maybe
not
to
a
full
transparent
sense?
H
But
how
does
this
overlap?
That
Wes
was
talking
about
we're
trying
to
seek
this
transition
period,
and
we
want
to
serve
that
serving
it
by
creating
multiple
modes
of
evaluation
is
something
that
I'm
very
afraid
of,
and
it's
also
something
that's
being
led
into
by
our
reliance
of
putting
all
use
cases
within.
Do
it
in
a
loader
I.
H
L
F
L
L
A
A
We
could
probably
talk
about
this
for
a
whole
other
meeting,
I'd
like
to
suggest
that
perhaps
our
next
meeting
we
spend
the
first
part
of
the
meeting
talking
about
loaders
in
the
second
turret
part
of
the
meeting
talking
about
Interop
in
general,
not
just
transparent,
but
how
we
want
to
have
handle,
interrupts
and
that
can
introduce
things
such
as
make
require
function
and
important
that
it
require.
How
do
people
feel
about
that.
B
A
So
we'll
open
an
issue
with
the
agenda,
anything
can
be
added.
You
just
need
to
request
it
and
then
outside
of
that,
if
you
have
issues
or
pull
requests,
you
could
just
add
the
modules
agenda
label
to
it
and
we'll
get
surfaced
into
the
meeting
and
with
that
I'm
gonna
end
the
YouTube,
oh
I'm,
not
the
Michael
you're.
The
hosts
you're
gonna
have
to
do
that
and
I'm
gonna
drop
right.
Now,
thanks.
Everyone
for
coming
have
a
good
one.