►
From YouTube: Node.js Foundation Modules Team Meeting - 2018-08-15
Description
A
We
are
live.
This
is
the
August
2015
edition
of
the
node.js
modules
team
with
us
right
now
we
have
a
number
of
different
members
from
the
team
for
everyone
who's
on
the
call
right
now,
if
you
could
open
up
the
dock
that
we
have
and
fill
fill
out,
your
name
if
you're
attending.
That
would
be
great.
We
have
a
you
know
pretty
packed
agenda
today
and
we'll
just
get
right
to
it.
A
The
first
thing
that
we
had
was
approving
a
PR,
but
we
don't
currently
have
enough
people
on
the
call
so
without
quorum.
We
can't
move
forward
with
this
right
now.
I'll
come
back
to
this
issue
later,
if
we
end
up
having
enough
people,
so
we
have
two
items
here
for
update
on
process
on
progress.
One
was
create
terminology,
not
markdown,
and
the
other
one
was
a
developer
survey.
I
believe
that
both
of
these
are
being
run
by
SMO
tell
who
I
do
not
see
on
the
meeting
today.
A
So,
let's
punt
on
those
also
for
right
now
and
if
they
join
us
before
the
end
of
the
meeting,
we
can
try
to
find
time
to
get
into
them.
So
just
jumping
right
into
our
discussion.
We
have
four
major
topics
to
talk
about
today:
thinking
about
deadlines,
managing
a
forked
and
a
agreed-upon
minimal
kernel
ESM
in
J's
files
as
well
as
transparent
or
not
Interop.
So
we're
going
to
start
off
by
just
spending
five
minutes
talking
about
deadlines
and
I'm,
just
gonna
say
a
thing
or
two
Oh
Salah
has
just
joined
us.
A
So
after
we
start
finished
talking
about
deadlines,
he
can
give
us
the
updates,
on
those
other
two
issues.
I'm
going
to
set
a
little
context
on
this
I'm
going
to
set
the
clock
for
five
minutes,
and
then
you
know
kind
of
open
it
to
the
floor
for
people
to
talk
so
timer
started.
Deadlines
are
something
that
we
talked
about
before,
and
there
was
definitely
sentiment
within
the
group
that
we
did
not
want
to
have
deadlines
simply
to
have
deadlines
that
you
know
anything
that
was
not.
A
Some
of
that
ecosystem
pain,
that's
being
felt,
and
you
know
bringing
up
once
again.
You
know
I
think
that
we
should
be
having
a
goal
of
shipping,
something
that's
not
behind
a
flag.
Perhaps
before
no
12
goes
into
LTS,
which
gives
us
you
know
about
another
14
months
or
so,
but
the
sooner
we
could
do
it
the
better
chance
we
have
of
having
something
that
can
be
back
ported
to
10
or
something
that
may
even
be
able
to
be
partially,
but
not
totally
back
ported
to
8.
A
So
kind
of
moving
back
to
the
to
the
group
down.
Does
anyone
have
any
thoughts
on
this
or
specific
feelings?
You
know
about
coming
up
with
deadlines,
and
do
we
think
that
perhaps
having
like
I
think
some
of
these
topics,
we
don't
have
consensus
on.
We
could
talk
till
we're
blue
in
the
face,
but
I
think
having
an
explicit
deadline
may
be
a
forcing
function
for
us
to
make
decisions
at
least
even
decisions
in
our
fork,
so
that
people
think
that
there
are
deadlines
that
we
could
be
introducing.
That
would
be
helpful.
A
B
C
Yeah
sorry
I'm
striking
if
I
was
needed
or
not
I
think
deadlines.
You
know
they
can
be
those
things
that
were
singling
deadlines
to
share,
or
we
can
say,
checkpoints
or
you
know
points
where
things
become
concrete.
You
know
we
have
a
working
prototype
within
a
couple
of
months
or
let's
say
you
know
we
have
the
terminology
document,
for
instance
done
by
a
certain
point
and
and
that
would
would
mean
that
we're
able
to
just
say,
okay,
if
something
depends
on
this,
then
it's
roughly
going
to
be
delayed
until
this
happens.
C
D
So
I
definitely
agree
with
a
check
point,
my
son,
whatever
you
want
to
call
it
so
I
also
think
that
Oh
for
me
personally
I,
don't
think
that
the
deadlines,
the
dates-
are,
the
important
things,
it's
more,
that
any
way
of
expressing
progress
would
be
good
like
if
we
know
if
we
know
these
are
the
decisions
that
we
need
to
make.
These
are
the
choices
we
have
to
make.
If
we
have
just
a
list
of
that
list
of
these
are
the
decisions
we
make
you
to
make
in
order
to
have
a
prototype.
This
is
this.
D
A
I
think
that
that's
a
really
good,
a
really
good
point
and
I
think
it
actually
goes
really
nicely
into
the
next
agenda
item
that
we
that
we
have
on
here.
So
perhaps
we
should
dig
into
this
one
first
and
we
can
come
to
the
updates
afterwards,
but
managing
a
forked
in
an
agreed-upon
minimal
kernel
for
individuals
who
are
not
part
of
the
meeting.
A
That
is
entirely
inclusive
of
all
potential
future
implementations
and
then
allowing
us
to
essentially,
you
know,
pull
requests
and
issues
against
that
for
collections
of
features
that
create
an
entire
workflow
and
that
you
know
that
could
make
some
of
the
work
that
we're
doing
more
direct.
So
there
was
an
issue
opened
yesterday
to
discuss
it.
There
were
a
couple
of
different
things
that
needed
to
be
decided
there
first
would
be
like.
Should
this
be
a
branch
on
the
node
repo?
Should
this
be
a
fork?
Should
this
be
something
in
the
node
modules
repo?
A
That
was
one
hanging
question
and
the
other
hanging
question
was
what
would
a
minimal
implementation?
Look
like
what
would
be
part
of
this
Karl?
What
would
not
be
part
of
this
kernel,
and
so
perhaps
something
that
we
could
have
as
milestones
could
be
some
things
around
a
milestone
for
the
fork,
a
milestone
for
the
minimal
kernel
milestones
for
getting
certain
feature
set
collections
put
in
I'm,
just
planning
some
ideas
and
I'll,
just
kind
of
put
it
to
the
room,
I'm
kind
of
like
starting
with
the
first
bit.
A
E
Unmuted
you're
good,
so
I
kind
of
just
want
to
keep
like
keep
it
as
close
as
possible
to
other
core
development,
just
because
there
are
so
many
things
here
that
interleave,
like
even
for
people
who
aren't
members
of
the
node
modules
team
right.
There
are
a
lot
of
concerns
that
come
up
when
developing
other
features
for
notes.
I
want
to
make
sure
that
whatever
we
do
we're
able
to
keep
these,
like
you
know,
big
branching
issues
well,
communicated.
A
So
so
one
thing
that
I
can
speak
to
and
then
we've
got
some
hands
up.
The
working
group,
her
team,
when
it
was
spun
up,
had
worked
in
a
separate
fort
for
this
I
believe
they
just
treated
the
master
branch
of
that
four
core.
You
know
the
base
branch
could
be
called
whatever
as
the
equivalent
as
a
new
branch,
and
that
was
just
to
keep
the
noise
off
of
the
main
tracker
and
it
was
consistently
rebased
against
master
like
on
a
daily
basis.
A
B
B
That's
in
core,
that's
in
master
or
whatever
the
main
branches
move
that
out
into
a
branch
of
its
own,
and
that
may
turn
that
into
a
pull
request
against
master
and
then
the
minimal
core
becomes
just
a
new
pull
request
against
master
and
then,
as
we
gradually
grow,
the
minimal
core
people
submit
pull
requests
like
against
the
minimal
core
branch
kind
of.
If,
if
this
were
like
a
project
that
I
were
running
here
from
a
company,
that's
that's
how
I
would
structure
it.
Yeah.
A
It's
unfortunately,
going
to
be
a
non-starter
and
my
personal
opinion
we
can,
if
we
can
reach
consensus,
that
that's
what
we're
gonna
do,
but
I
do
not
believe
that
removing
anything
from
master
right
now
is
something
that
we
can
consider
doing,
especially
how
I
acted.
A
lot
of
the
different
parts
are
super
interconnected.
We
also
are
shipping
it
already
in
ten
and
eight,
and
even
though
it
is
flagged,
it
would
be
a
huge
disruption
to
the
ecosystem
to
kind
of
pull
that
out
from
under
them
right,
but.
B
That
I
just
don't
understand
them
like
what
is
why
are
we
building
a
new
implementation,
if,
like
the
one
that
we're
shipping
is
like
so
special
that
it
can't
be
taken
out,
can't
be
revised
upon
like?
If
that's
so
like
it's
out
there
in
the
public
and
and
we
need
to
like
honor
it
and
backward
compatibility
at
all
these
things,
then
we
should
be
building
against
that,
and
we
should
be
having
a
pull
request
against
that,
as
if
we're
gonna
be
changing
it
rather
than
saying.
A
Need
to
reach
consensus
as
to
what
the
major
is
going
to
be
before
we
do
a
major
change.
If
we,
if
we
do
an
all
employee
requests
in
core
every
time,
we
make
a
pull
request
every
time
they
make
an
issue,
its
pinging
of
thousands
of
people.
I.
Think
part
of
this
is
about
creating
a
low
noise
place
where
we
can
hash
up
these
ideas
and
then
bring
it
over
to
core
when
it's
ready.
Well,
that's
reasonable,
so
low!
You
have
your
hand
up
yeah,.
C
Then
what
we
are
designing
can
not
only
just
work
in
the
current
version,
but
if
people
want
it,
they
could
also
poured
it
to
other
like
electron,
for
instance,
or
something
like
that,
and
all
of
this
can
happen,
giving
us
the
flexibility
to
stay
close
to
module,
wrap
or
as
far
away
as
we
need
to
I'm
more
inclined
to
be
close
to
module
wrapped
than
far
away.
But
that's
separate,
you
know,
a
native
module
approach
really
means
that
we
are
not
depending
or
changing
the
main
branch
too
much
to
reach
our
goal
whatever.
F
Hi,
okay,
I
think
a
repo
within
the
org
is
fine.
It's
a
place
to
file
separate
issues.
We
can
create
multiple
branches
within
it
and
we
can
scope
discussion
to
that
without
having
to
pay
others
I.
Just
for
me.
It
seems
like
a
nice
place
to
keep
it
in
its
own
area.
That's
what
we
did
with
worker,
we're
doing
it
with
repple.
We've
done
it
with
a
couple
of
other
things:
it's
it's
I'm,
Pro
Eleanor,.
G
D
Absolutely
thank
you
yan
yeah,
so
what
I
wanted
to
say
is
just
to
the
idea
of
make
tourniquet
into
the
libraries
or
something
that
you
can
just
install
with
node
there's
a
huge
advantage
to
that,
which
is
people
can
actually
try
it
out
if
we
do
afford.
We
basically
cannot
tell
anybody
out
there
this
group
to
try
it
out
other
than
us,
regularly,
building
nightly
versions
for
all
kinds
of
platforms
which
is
not
really
practical,
so
there's
certainly
a
huge
advantage
in
making
it
a
library
that
you
can
install
for
NPM.
D
A
D
I
mean
so,
if,
if
we
go
with
a
fork,
it
means
that
people
who
are
not
willing
to
do
a
build
from
source
of
load
itself
manually
on
their
machine
cannot
really
try
it
out.
So
unless
we
find
a
way
to
set
up
nightly,
builds
for
different
platforms,
it'll
be
very
hard
to
try
it
out,
and
even
if
we
have
nightly
builds
with
the
current
situation
of
note
version
managers,
it
would
still
be
kind
of
painful
to
just
try
it
out.
D
D
Yeah,
but
that
gives
us
gets
on
the
level
of
nightly
builds,
which
is
something
that's
possible,
but
also
something
that's
somewhat
painful.
If
you
wanted
to
install
it
like
there's
a
reason
why
few
people
try
out
nightly
builds
at
least
natural
note
users,
because
you
cannot
just
nvm
install
X,
you
can
actually
yeah
yeah,
not
by
default,
at
least
not
without
some
additional
work,
so
I
think
getting
naughty.
Girls
would
at
least
address
some
of
the
pain.
D
E
So
for
the
external
module,
there
are
a
lot
of
things
that
we
have
to
do.
That
cannot
be
explicitly
provided
without
booking
like
from
calling
from
node
core
into
the
implementation
like
context,
lifetime
tracking
and
a
bunch
of
other
random
things
that
we
had
would
have
like.
I
guess
need
like
either
stub
in
decor
to
call
into
the
the
the
module
we
would
ship
or
I,
don't
even
know
what
so
like
like
it
would
be.
It
would
be
really
cool
to
do
I.
A
C
You
yeah
so
I,
guess
I
I
kind
of
view,
the
technical
challenge
that
Gus
pointed
out
as
a
good
opportunity
and
and
the
fact
that
that
there
might
be
upstream
housekeeping
really
those
are
good
opportunities
to
actually
because
when
you
write
isolated
modules,
you
tend
to
uncover.
You
know
tightly
coupled
causes
for
concern
that
that
could
actually
just
be
hidden
under
the
fact
that
it's
all
in
one
repo,
but
with
a
native
module.
Although
there
will
be
a
technical
challenge
to
actually
set
up.
You
know
the
first
implementation
of
that
native
module.
A
A
C
Things
that
might
have
happened
over
several
implementations
or
partial
implementations.
I'm
sure
you
know
the
working
implementation
and
everything
involved
in
it
is
perfect.
But
there
are
certain
things
that
might
be
closed
for
no
big
reason
or
might
have
existed
and
not
gotten
with
me.
So
I'm
really
hoping
that
other
people
buy
into
the
native
module
for
its
vent
methods
or
point.
A
A
Okay,
thank
you
very
much.
We
can
kick
off
an
issue
specifically
about
talking
about
that
and
I
think
one
thing
we
can
definitely
do
once
we
make
the
fork
which
it
sounds
like
we
have.
The
most
support
for
right
now
is
we
can
open
an
issue
or
a
pull
request
that
examines
that
approach.
So
the
other
thing
that
we
talked
about
that
was
part
of
this
topic
was
the
idea
of
a
minimal
kernel.
A
Specifically,
you
know
what
is
the
minimum
curl
that
we
would
want
to
have
in
this
fork
that
we
would
be
making
you
know,
pull
requests
against.
There
is
currently
inside
of
the
issue.
Two
different
proposals
for
what
minimal
kernel
could
be.
The
first
was
from
Gil.
The
idea
of
minimum
is
to
one
have
all
ESM
functionality
included
to
to
avoid
debate
on
all
thorny
issues
being
kind
of
the
guiding
principles
for
this.
A
So
it
includes
the
ability
to
import
any
SM,
either
with
import
from
in
an
ESN
file
or
dynamic
import,
avoiding
the
file
extension
debate.
Import
will
not
guess
the
file
extension
and
will
import
a
file
as
ESM.
If
things
are
being
imported
is
a
folder.
It
will
look
for
a
package,
JSON
main
property
and
will
load
that
as
PSN
again
will
not
guess.
The
file
extension
will
not
look
for
index
jas,
because
that
will
provoke
a
file
extension
of
mate,
and
we
all
want
to
avoid
that.
The
regular
CGAs
folder
searching
algorithm
will
be
used.
A
This
is
like
node
modules
and
all
that,
except
that
it
will
not
look
for
index
dark
gesture
index
MJS
and
avoiding
the
transparent,
interrupt
abate.
Cj
s
will
be
able
to
dynamically
import.
Esm
ESM
will
not
be
able
to
require
CJ
s
gil
quickly.
Before
I
move
on
to
the
next
proposed
kernel,
was
there
anything
about
that
that
I
miss
categorized
or
miss
no.
H
A
Interrupt
import
only
supports
GSM,
so
no
JSON,
no
common,
no
native
modules,
perhaps
an
explicit
ban
on
importing
dot,
J's
files
specifically
right
now,
so
there
isn't
the
expected
behavior
for
that
no
extension
or
folder
searching
like
essentially
what,
if
you
use
the
import
keyword,
you
are
importing
the
full
path
that
you
are
trying
to
find
or,
alternatively,
if
you
are
importing
a
module
that
what
is
within,
that
has
a
bear
specifier
that
would
go
into
the
potentially
that
would
go
into
the
new
modules
folder.
It's
potential
that
we
wouldn't
support.
A
A
Have
my
pull
request
to
172
nine
that
we
can
move
to
the
fork
and
iterate
to
make
sure
that
it
does
what
we
wanted
to
do
and
then
have
dynamic,
Interop
a
dynamic
import
to
allow
for
ESM
in
CJ
s
do
do
people
have
any
thoughts,
concerns
or
opinions
about.
You
know
what
should
be
in
this
minimal
kernel.
D
Yon
you
have
your
handout
I
think
it
would
be
important
to
agree
on
what
we
are
trying
to
prove
out.
So,
for
example,
for
me,
the
minimum
kernel
is:
let's
have
a
very
stable
foundation
that
100%
everyone
can
agree
on
yeah
and
then
start
making
decisions
based
on
it.
So,
for
example,
for
me,
great
require
function
is
technically
not
necessary
because
it
kind
of
involves
some
additional
decisions
on
how
people
will
work
with
it.
A
Think
just
a
clarification
and
then
call
up
so
the
the
idea.
What
I
thought
we
were
trying
to
accomplish
was
what
is
a
kernel
that
supports
every
potential
future
iteration
that
we
would
want
to
do
and
does
not
preclude
any
of
the
workflows
that
we've
talked
about.
So
the
idea
with
create
require
function,
as
being
part
of
that
was
a
create
require
function,
could
be
an
abstraction
that
import
meta
require
itself
would
use,
but
that
that's
a
thing
that
could
be
shared
between
both
command
J
s
and
ESM.
It's
something
that
people
have
talked
about.
C
Yeah
I
think
a
minimum
kernel
should
really
leave
standard
syntax
to
work
the
way
it
works
in
other
modules
that
exists
right
now.
So
if
it's
running
as
a
native
like
native,
yes,
a
module,
mana
native
module,
but
it's
it's
being
handled
natively
by
the
engine
as
a
module,
then
the
standard
syntax
should
behave.
The
way
the
standard
syntax
behaves
in
another
runtimes
that
are
not
experimental,
which
is
read
the
browser's
it's
hard
to
say
that
it
is
I,
think
anything
that
is
no
specific
for
the
minimal
implementation
might
in
most
cases
be
none.
E
A
I
I
guess
I'm,
what
I'm
wondering
is
we
get
I
think
that
seems
like
something
we
can
certainly
build,
because
if
we're
not
planning
on
never
shipping
that,
like
that's
just
clearly
defining
what
we
can
merge
into
master
now
like
and
I,
have
I
don't
have
any
objections
to
any
anything
missing
being
in
there
or
missing
from
there.
It's
more
just
a
question:
if
I'm
not
sure
what
value
that
is
because
to
me
the
the
challenge.
Isn't:
writing
the
code.
I
The
challenge
is
like
deciding
what
we
agree
on
or
like
rather
coming
to
an
agreement
on
something
to
ship
like
we
can
all
it's
not
even
going
to
be
that
hard
to
just
say,
like
here's
all
of
our
opinions,
here's
the
stuff
that
nobody
argues
about.
That's
our
minimal
kernel
like
it's,
it's
tedious,
but
it's
not
hard.
A
The
intent
and
we
could
take
it
either
way
if
we
don't
think
that
this
is
the
right
thing
would
be
if
we
all
want
to
be
sending
pull
requests
into
this
fork,
and
we
want
to
be
able
to
have
like
an
apples
to
apples
comparison
of
the
two.
They
should
be
building
off
of
the
same
branch
whereas
like
if
I
do
something
that
removes
transparent,
interrupts
then
adds
import
matter.
I
I,
that's
fair.
It
makes
perfect
sense.
I
agree
that
that
will
make
that
easier.
It's
just
I,
don't
think
pull
requests
are
necessary
or
even
necessarily
even
automatically
helpful
in
helping
us
agree.
I
think
that
the
agreement
is
entirely
unrelated
to
what
the
code
looks
like
and
the
bike
shedding
about
the
in
the
code
review
about
the
the
implementation
is
something
that
is
just
doesn't
need
to
happen
at
all.
Until,
like
we
agree
about
this
stuff,
so
I
mean
it's
again:
it's
fine.
A
D
It
was,
it
was
vaguely
agreeing
with
it
was
what
has
been
said,
but
also
with
your
very
last
comment
of
maybe
just
making
a
change
will
unblock
something
like
yeah
I
mean
I'm,
not
one
of
her
I
wasn't
sure
what
would
get
everything
flowing
so
I
can't
really
disagree
with
that.
But
I
definitely
also
feel
like
if
we
have
a
minimal
kernel
and
then
two
people
do
a
poor
request.
One
implementing
imports
ojs
gets
a
common
chess
module.
The
other
implements
import
us
implements
gets
a
yes
em
module.
A
That
makes
sense,
I
I
think
that
I
think
that
we
need
to
move
on
to
our
next
topic.
We
can
bring
this
back
to
the
issues.
I'll
take
an
action
item
of
making
that
fork
and
then
perhaps
we
can
just
start.
You
know
having
a
conversation
about.
You
know
what
that
minimal
kernel
can
be
and
maybe
get
some
pull
requests
against
it.
A
One
thing
I
do,
think
that
we
should
maybe
make
sure
we
do
is
have
consensus
around
issues,
and
perhaps
you
know
disabling
the
issue
tracker
on
the
fork
and
keeping
the
issues
in
one
place,
so
we
don't
have
multiple
places
so
I'll
do
that
in
the
fork,
and
you
know
if
people
have
a
problem,
we
can
iterate
on
it.
The
next
one
that
we
have
up
on
here
is
ESM
nsj
files.
We
run
over
on
different
Kings,
so
I'm
going
to
drop
this
to
ten
minutes
in
the
transparent
conversation
at
ten
minutes.
A
A
The
experimental
module
is
what
I
think
that
perhaps
150
got
closed
since
I
started
this,
but
Jeff
I
wanted
to
see
if
you
would
be
willing
to
kind
of
give
everyone
a
quick
update
as
to
what's
going
on
with
the
conversation
in
150
and
160.
What
the
goal
of
the
conversations
are
for
myself
is
just
that.
There's
been
a
lot
of
conversation
in
there
and
I
haven't
had
the
bandwidth
to
catch
up.
So
if
you
can
kind
of
give
us
an
up
register
right
so.
B
B
B
If
you
look
at
this,
someone
already
made
a
pull
request
here
for
just
like
mode.
Yes,
M
just
basically
set
a
Jas
file
within
a
package
boundary
to
be
yes
M,
so
I
was
kind
of,
although
all
the
other
proposals
kind
of
assumed
that
the
logic
in
here
about
how
to
define
a
package
boundary,
whether
that's
a
folder
or
something
else,
would
be.
You
know
what's
in
this
PR
and
then
it
was
the
like,
because
this
is
very
limited
of
just
like
a
boolean
Flags.
So
the
idea
was
well.
B
We
want
a
little
bit
more
configurability
than
that.
So
what
are
the
ways
to
do
that?
You
know
like
the
simplest
one,
which
is
the
like
the
starting
point
of
what
became
the
I
guess.
I,
don't
want
to
use
the
freight
with
the
word
consensus,
but
the
the
merged
final
proposal
is
that
there
becomes
a
new
mimes
filled
in
package
of
Jason,
which
is
just
an
object
that
maps
extensions
to
mime
types
and
then
this.
Basically,
this
follows
the
browser
model
where
this
is
what's
happening
on
a
web
server
for
web
servers.
B
So
the
the
final
proposal
takes
that
as
the
starting
point
like
this
new
mimes
section
with
with
that,
and
what
some
people
who
commented
on
the
thread
wanted
was
a
way
to
to
define
these
through
external
files
as
well.
So
it
can
either
be
an
object,
in
which
case
it's
a
direct
mapping
one-to-one
or
it's
an
array
of
strings
that
are
parses
Jason
files,
and
so
it
can
either
be
like
local
or
in
a
in
a
package.
B
And
the
final
bit
is
that
if
this
starts
with
null
as
the
first
element
in
this
array,
then
that
basically
like
wipes
out
nodes
default
mappings
first
and
then
you
have
to
define
everything
you
plan
to
use.
Otherwise
these
like
build
on
top
of
nodes
default
mapping.
So
like
like
this
example,
for
example,
like
I,
don't
specify
Jason
in
here,
but
like
whatever
nodes
default
mapping
for
Jason
and
is
still
honored.
This
is
just
kind
of
an
override
like
overlaid
on
top
of
like
object
out
the
sign
nodes
default
comma.
B
This
object,
it's
kind
of
how
they're
how
they're
applied.
So
that's
the
gist
of
it
and
that's.
What's
in
here
so
yeah
I
was
kind
of
hoping.
We
could
I
guess
find
consensus
that
this
is
something
we
want
to
move
forward
on
and
hopefully
get
merged
into
experimental
modules,
kind
of
as
a
side
track
to
whatever
we
get
started
with
the
minimal
kernel.
I
So
my
my
gut
preference
would
be
that
this
would
be
a
mapping
of
extensions
to
extensions.
It
would
be
like
load
dot,
J's
files
as
if
they
were
da
plasm
files,
or
vice
versa,
or
something
different.
Because
to
me,
that's
like
I'm.
Basically,
it's
to
me
it's
more
of
a
map
of
like
fake
extensions
like
I,
want
to
pretend
that
this
extension
is
this.
I
Other
extension,
the
mapping
to
mines
achieves
the
same
functionality,
so
I
am
completely
in
complete
agreement,
but
that's
what
we
we
need
that
functionality
and
we
don't
have
to
spend
meeting
time
bike
shedding
that
further.
But
I
wanted
to
voice
that
that
I
think
that
it's
more
ergonomic
and
approachable
to
not
use
mine
types,
but
that
I
do
love
the
idea.
That's
all
Thank.
A
A
B
I
think
it's
so
it
basically
build
on
top
of
nodes.
Parsing
now
like
like
basically
I,
don't
think
this
is
written
written
out,
so
I
mean
yeah.
You
guys
know
the
node
code
base
rather
than
I
do
so
someone
correct
me
but
I'm,
assuming
that,
like
in
the
node
code
base,
like
it's
easy
to
say,
Jason
extension
and
O's,
it
probably
doesn't
say
so
explicitly,
but
basically
treat
that
as
application
slash,
Jason
right,
and
so
it
knows
what
to
do
with
the
Jason
file
and
how
to
behave
with
it.
B
So
there's
somewhere
in
the
node
code,
ways
that,
like
basically,
is
saying
how
to
treat
each
file
extension,
so
this
was
basically
kind
of
be
making
that
more
explicit
so
like
instead
of
that
code
and
the
node
code
based
saying
for
died,
Jason
do
this.
That
would
be
refactored
to
be
like
for
application.
Slash
Jason
do
this
and
then
somewhere
farther
up
in
the
code,
it
would
map
dodged
Jason
to
application,
slash,
Jason,
something
something
along
those
lines.
B
B
A
So
I'd
like
to
see
that
fleshed
out
a
little
bit
more
about
like.
If
there's
another
step
that
you
can
do
for
declaring
new
mimes
and
associating
those
new
minds
with
new
loaders
I'd
love
to
see
how
that
would
work.
Salah
of
your
hand
up-
and
we
have
two
more
minutes
left.
So
if
you
could
keep
it
to
a
minute,
that
would
be
great
I,
really
love.
C
The
declarative
aspect
on
that
I
think
that
declarative
mappings
are
far
better
than
the
imperative
mappings.
That
happens
require,
which
are
very,
very
hard
to
understand.
If
you
are
not
fully
aware
of
what
happened
here,
require
extensions
so
to
this
I
I
also
want
to
say
that
it's
it's
it's
nice
that
note
has
packages
and
package
JSON,
but
the
concept
of
a
folder
is
really
more
universal.
We
have
scopes
for
service
workers
where,
within
a
scope
you
could
actually,
which
is
a
folder
and
anything
underneath
it.
C
You
could
have
a
particular
opinion
on
how
metric
you
know.
Resolutions
or
no
network
resolutions
happen.
Definitely
mine
types
are
in
play
there,
I'm
against
mime
types
outside
of
the
browser,
unless
necessary,
but
I
really
think
we
should
abstract
an
idea
where
we
say
just
like.
If
you
open
a
lot
of
packages
and
their
dist
folder
you're
gonna
find
the
ESM
versus
the
CJ
s
folder,
where
one
is
able
to
declaratively
say
that
this
folder
is
belonging
to
a
particular
mapping
strategy.
C
D
Next
aisle
sorry
I
clicked
the
wrong
button.
I'll
try
to
give
it
like
quick,
so
my
problem
with
the
proposal
is
that
I
see
like
for
me:
it's
either.
Everyone
agrees
with
the
defaults
in
the
ecosystem
at
large,
or
we
just
added
two
lines
of
fragile
boilerplate
every
single
node
package
on
NPM,
because
if
someone
makes
a
typo
instead
of
the
names
thing
they're,
not
body
breaks,
they
look
for
support.
If
somebody
accidentally
added
the
null
and
suddenly
the
adjacent
imports
fail,
they
will
be
desperate
for
help
I.
D
A
Okay,
thank
you
and
I
think.
Perhaps
this
now
leads
nicely
into
the
next
topic,
which
is
transparent.
Interoperability,
which
I
know,
is
a
loaded
term,
but
I
think
you
know,
let's
dive
right
into
it.
I
know
that
Jeremiah
you
were
asking
if
it
was
still
on
the
agenda.
Do
you
want
to
maybe
kick
off
the
discussion.
A
K
So
just
listening
to
Jeff
talk
about
county
scripts
and
you
know
having
experience
with
other
compilers,
like
you
know,
type
scripts
generating
JS
files
from
like
either
TS
or
coffee
files
makes
me
realize
that,
like
that,
that
step
of,
like
generating
new
modules,
that
you
then
import
and
then
like
you,
know,
having
to
rely
on
node
guessing
the
file
extension.
So,
like
you
know,
get
it
right
in
production
just
isn't
necessary.
K
If
we
lean
into
the
suggestion
that
was
made
in
the
context
of
the
the
minimal
carnal
proposals
earlier
that
you
know,
as
happens
in
in
browsers
when
you
import
something
with
an
import
declaration,
it's
just
treated
as
the
SM
right
and
if
that's
not
gonna
work,
because
it's
not
actually.
Yes,
then
then
we're
going
to
need
some
sort
of
loader
hook.
K
Api
to
you,
know,
transpile
files
with
different
file,
extensions
on
the
fly,
something
like
that
but
like
if
we,
if
we
are
okay
with
a
world
where
you
can
just
use
an
import
declaration,
import
any
file
path,
and
maybe
we
require
that
it
has
an
extension.
We
don't
try
to
guess
that
anymore
and
it
just
gets
treated
as
the
SM,
and
we
have
a
way
of
making
sure
that
things
that
aren't
really
yes
and
sort
of
get
wrapped
as
yes
and
modules.
K
K
If
the
default
is
just
that
import
declarations
always
treat
the
module
as
the
SM,
and
you
know
you
have
to
use
import
that
meta
dot
require
to
import
comment
yes
or
will
be
imported
that
meta
de
you
know,
you
know
some
something
to
do
with
wasm
to
import
it.
You
know
exotic
module
formats,
then
there
now
hyatt,
I,
guess
I
I
want
to
believe
that
there's
a
future
where
we
don't
have
to
worry
about
the
mapping
between
file,
extensions
and
mime
types.
K
I
Someone
have
a
clarifying
question
specifically
for
this
yeah
I
did
I
just
wanted
to
kind
of
point
out.
Browsers
are
definitely
going
to
be
like
using
mime
type
to
determine
how
to
parse
the
thing
that
you
import.
It's
just
that
they,
when
you
import
something
in
browsers,
they'll,
never
parse
it
as
a
script.
A
The
flip
side
of
that
is
that
the
server
that
you
use
is
likely
to
use
a
standardized
mime
type
database
to
determine
that.
So
it's
not
something
you're
necessarily
ever
touching,
so
it
is
indirectly
being
determined
by
the
file
extension
correct
file
extension
tells
your
server
just
send
them
late.
And
yes,
you
can
do
this,
but
that's
not
the
normal
case.
Y'all
knew
of
your
hand
up
yeah.
D
Basically,
the
same
thing
that
that
Jordan
just
said,
like
I
I,
think
it's
a
dangerous
sentence
to
say
that
the
server
doesn't
input
everything
as
MJS
like
there
definitely
is
a
strict
white
list
based
on
indirectly
most
likely
file
system,
file,
extension
or
some
explicit
profile
configuration
of
it's
it's
a
CDN,
but
in
the
end,
most
likely
the
serve
for
most
practical
purposes.
The
browser
has
a
strict
white
list
of
file
extension
that
it
allows
to
be
imported,
as
yes,
modules.
J
If
that
was
safe
to
do,
we
would
already
be
doing
that.
Can
you
expand
on
what
you
mean
by
comment
by
by
wrappers
what
Benjamin
referred
to
so
making
it?
So
when
you
import,
my
common
JSU,
actually
import
some
ESN
thing
around
your
common
J's,
which
presumably
also
go
down
the
tree
because
it
would
have
to
if
you
are
importing
actually,
yes,
em
and
not
comment.
Yes,
since.
K
K
I
was
just
thinking
that,
like
coffee
files,
TS
files
again
maybe
dot
HTML
files,
we
could
have
a
loader
hook
system
that,
like
not
only
wraps
those
on
the
fly,
but
also
you
know,
maybe
allows
users
to
configure
what
mine
types
they
get
and
if
that
was
just
a
configurable
thing,
then
well
I.
Guess
it's
a
question
of
how
it
should
be
configured
whether
it
should
be
in
package
JSON
as
in
this
proposal,
or
if
it
should
be
like
a
runtime
api
yeah,
so
I
didn't
raise
my
hand,
so
I
should
I
should
be
quiet.
K
D
That
is
that
if
we
allow
this,
it's
definitely
also
a
future
compatibility
concern
because
then
suddenly
in
the
ecosystem,
there
spreads
one
HTML
loader
that
has
very
weird
semantics
and
then
suddenly,
that
extension
is
blocked
in
the
future,
because
we
cannot
in
core,
maybe
even
web,
compatible
loader
for
certain
file
extension,
because
some
ecosystem
things
spread
already.
That
is
incompatible
and
is
basically
blocking
what
import
with
that
file
extension
means,
or
it
becomes
really
confusing.
We're
half
of
the
ecosystem
is
using
one
thing
in
the
other:
half
is
using
the
other,
so.