►
From YouTube: Node.js Foundation Modules Team Meeting - Aug 29 2018
Description
B
This
is
the
29th
of
August,
no
js'
modules
meeting.
We
currently
have
nine
attendees,
which
is
not
quite
quorum.
Unfortunately,
and
we
will
see
how
it
goes
actually
tell
if
we
include
both
where's
and
Daniel,
but
if
we
get
quorum
then
we
can
come
back
to
some
of
these
voting
issues
on
the
agenda.
It
now
be
writable,
so
everyone
should
be
able
to
put
their
names
in
under
present
there.
Sorry
about
that,
so
diving
in
I
think
if
we
can
actually
make
it
the
first
item.
Salah
are
your
arm.
C
Yeah
so.
B
C
Would
it
be
possible
to
just
open
the
issue
that
I
mentioned
in
the
contract?
Oh
I
didn't
miss
that
Lincoln,
oh
yeah
yeah,
so
just
just
it
would
be
easier
with
a
little
bit
of
a
thing.
C
The
hope
is
actually
prepare
questions
that
are
suited
for
a
lot
of
like
people
with
different
mindsets.
My
hope
is
to
have
a
survey
that
would
be
very
beneficial
by
October.
So
in
the
event
it
would
actually
be
rolled
out
either
online
or
at
the
booth
or
something
I'm
not
sure
what
would
be
the
best
way
to
present
it.
C
It's
easy
for
us
to
as
a
group
to
always
eventually
get
very
used
to
the
questions
when
we
rewrite
them
over
and
over
again.
So
unfortunately,
this
will
be
open
eventually,
but
I
think
it's
ideal
that
we
start
off
with
a
very,
very
bare-bones
survey,
which
we
already
have
since
last
week.
It
doesn't
really
have
any
specific
questions
that
anyone
of
us
wants
to
ask
at
this
point
and
I
think
we
can
go.
C
You
know
if
we
could
do
it
more
than
once
a
week,
we'll
just
do
an
iteration
where
we'll
revise
the
survey
based
on
the
input
we
get
from
one
or
two
individuals
who
take
it
the
first
time
like
they
don't
see
the
survey
before
they
take
it,
and
then
their
feedback
is
not.
It
is
going
to
include
kind
of
a
meta
survey,
whether
it's
a
survey
about
the
survey
and
the
survey
questions
we
have
in
this
revision.
C
If
we
do
two
iterations
a
week,
that
would
be
great
if
we
just
do
one
we
can
still
get
far
by
you
know
by
the
time.
This
needs
to
be
rolled
out
so
I'm,
just
not
making
any
decisions
regarding
how
this
should
be
rolled
out
or
what
the
exact
date
it
should
be
ready
on.
I
just
thought.
Maybe
a
systematic
process
could
help
us
get
started
at
this
point.
C
I'm
actually
opening
it
I
hope
everyone
is
willing
to
be
involved
in
one
of
the
iterations,
if
not
actually,
after
taking
the
first
iteration
being
part
of
the
team
that
continues
to
iterate
other
people
in
and
I
hope.
This,
actually,
you
know
really
helps
us
get
as
much
insight
by
next
month
event
or
the
following
month.
Events
basically.
D
Yeah
so
I
think
this
is
a
great
idea
and
a
great
direction
to
explore.
I
was
curious
about
kind
of
mentioned.
It
mentioned
it.
I
think
my
question
is
how
we
get
how
we
figure
out
what
questions
we
want
to
ask
like
yeah
I,
have
some
hypothesis
or
whatever
and
I
want
to
want
a
question
to
like
try
and
figure
out.
If
the
hypothesis
is
correct
or
not-
and
you
mentioned
like
that-
we'd
sort
of
like
get
to
that
through
an
iterative
process.
C
Well,
I
started
off
by
making.
The
survey
includes
open-ended
portions
that
basically
are
very
very
irritating
that
anyone
will
say
no
I
need
a
better
question
than
this,
and
the
idea
of
this
annoying
question
is
that
there's
a
box
right
after
it
that
when
you
take
that
survey
and
you
get
annoyed
you're
in
the
best
position
to
actually
say
this
should
be
asked
in
this
way
or
that
way
the
infant
we're
getting
is
partially
anonymous.
There's
only
two
people
taking
it
at
a
time,
so
we
can
kind
of
know.
C
If
you
know
you
have
some
feedback
who
to
ask,
but
we
don't
necessarily
have
to
still
invalidate
your
ability
to
take
the
survey
as
if
it's
anonymous.
So
the
idea
is
that
I
avoid
asking
the
question
the
way
I
think
is
best
and
in
fact,
I
actually
asked
it
initially
in
a
way
that
is
kind
of
very
irritating
or
extremely
open
that
the
natural
response
for
anyone
who
thought
about
how
this
could
be
better
done
would
be
to
actually
correct
it
in
the
Box
right
afterwards.
C
You
know
we
don't
have
to
go
through
this
process.
Just
you
know
on
its
own
at
some
point
we
will
be.
We
will
have
a
good
enough
draft
initial
draft.
Where
then
we
can
actually
say
okay,
this
actually
does
not
work,
because
we
need
to
know
the
following:
it's
just
an
idea
of
the
process
that
I
think
helps
us
avoid
framing
questions
in
a
way
that
is
familiar
to
us,
because
then
you
will
get
answers.
That
will
surprise
us
all
really.
C
A
C
A
C
C
A
A
C
When
you
ask
questions
in
a
particular
way,
you
get
responses
based
on
the
question
being
read
by
the
person
taking
the
survey
not
based
on
what
you
think.
The
question
will
actually
answer
so
so,
if
we
do
three
four
iterations
in
a
week,
then
I
think
we'll
be
ready
to.
Actually
all
of
us
look
at
a
form
that
it's
actually
full
of
questions
that
are
clear
and
ready
to
be
critiqued.
But
at
this
point
that's
really
like.
C
C
B
B
Cuz,
otherwise
we
can
vote
on
some
of
these
PRS,
or
should
we
wait
until
we've
got
13
I?
Think
it's
something
like
14,
but
it
could
be
there.
It
is
I
just
counted
now
and
there
are
24
members
unlisted
in
the
readme.
So
then
it's
what
we
need
12
or
13
members
to
have
quorum,
yeah,
okay!
Well,
we
can
come
back
if
we
get
an
extra
member
sure.
B
B
B
We
kind
of
going
back
to
this
minimal
folk
and
within
the
group
working
on
on
various
features
and
changes
to
the
modules
integration
there.
That
can
maybe
remove
certain
features.
That's
already
in
the
implementation
of
node
and
break
it
down
to
a
minimal
implementation
and
also
look
at
other
experimental
features
that
we
maybe
wouldn't
want
to
land
in
node
itself,
under
the
experiments
or
modules
flag
and
we've
got
a
few
PRS
there.
I
was
thinking.
B
Maybe
we
could
go
through
these
PRS
individually
and
just
discuss
them
very
briefly,
get
an
idea
where
people
are
thinking
about
them
and
then,
after
that,
we
can
move
on
to
the
discussion.
More
generally
about
this
repo
and
some
of
the
compatibility
questions,
I
hope
that
automates
sense,
but
we
can
dive
into
the
into
the
first
one
in
that
case,
so
the
first
PR
we
have
was
miles
put
together,
PR
to
integrate
import
that
meta
that
require
into
the
Ekman
script
modules.
B
Pork,
the
general
response
to
that
was
there
was
some
negativity
against
it
and
it
also
hinged
on
a
create
require
implementation,
which
is
a
separate
PR
on
node
at
the
moments,
so
yeah
I
guess
miles,
isn't
here
to
explain
it
much
further
than
that.
Gus
has
been
working
on.
The
Creator
requires
implementation.
A
What
features
were
valuing
in
this
minimal
implementation
and
if
we
really
desire
this
minimal
implementation
to
be
something
that
is
non-controversial
or
something
that's
pretty
in
easy
to
use
so
I'm,
very
much
on
the
side
of
create
require
function.
If
you
read
up
my
opinions
on
it,
I
think
it
allows
some
important
features
to
be
preserved.
A
You
could,
for
example,
create
a
shim
for
create,
require
function
which
is
not
easily
doable
without
ahead
of
time
tooling,
for
import
meta
require,
there's
also
some
other
arguments
about
painting
stuff
which
I'm
not
super
swayed
by,
but
other
people
find
very
important
to
them
to
not
put
commonjs
api's
inside
yes,
M.
My
concerns
are
more
about
encouraging
users
to
do
something
that
gives
them
the
most
benefit,
even
if
it
requires
them
to
write
an
extra
line
or
two
of
code.
That's
it.
E
Yeah
I
just
had
a
question.
I
thought
the
idea
behind
this
was
to
kind
of
start
kind
of
start
small,
with
things
least
controversial
and
least
complex,
like
I
thought
we
had
talked
about
like
common
j/s
interoperability
being
something
that
we
just
push
to
be
way
down.
The
line
like,
and
yet
this
is
the
first
PR
like
we
may
be
just
like
cable,
this
PR.
Until
we've
got
more
of
this
built
and
then
revisit
like
hey.
How
do
we
want
to
handle
come
ingest?
It.
B
E
A
E
I
guess,
but
maybe
that's
a
bigger
question
than
is
like
do
we
are
we
gonna
have
like
maybe
milestones
like?
Do
we
want
to
maybe
get
ESM
mode
working
first
before
we
think
about
how
do
we
pull
in
commonjs
or
something
like
that?
You
know
or
a
general
way
forward
or
of
how
we're
gonna
build
this
thing.
E
G
I
mean
I
think
this
is
something
that
we
do
need
to
decide
like
what
I
mean.
This
was
brought
up
when
we
talked
about
a
minimal
plantation
like
we
don't
know
what
minimal
means
the
and
also
what's
the
goal
of
the
minimal
implantation
like
is
the
goal
to
try
and
provide
a
playground
so
that
we
can,
you
know
some
sort
of
a
playground.
So
we
can
like
achieve
consensus
faster.
Is
the
goal
like
so
that
we
can
write
code
because,
like
I,
don't
think
are
the
hard
problem
here?
G
Is
ever
writing
the
code
or
getting
an
implementation?
The
hard
part
is
continues,
OH,
pretty
much
primarily
the
agreeing
on
stuff
so,
like
I
I,
think
it's
useful
to
implement
whatever
we've
agreed
on,
of
course,
and
the
faster
we
do
that
the
better
but
like
what
is
minimal,
mean
like
I,
think
III,
don't
think
it's
a
very
minimal
kernel
if
it
can't
work
with
with
NPM
stuff,
but
like?
G
Is
that
something
we're
okay
with
like
when
we
would
it
be
useful
to
people
to
have
it
something
that
allows
you
to
use
ESM
but
not
to
use?
You
know
90%
of
the
JavaScript
on
the
planet
like
is
that
sufficient?
If
so,
okay,
then
we
can
build
that
I,
don't
know,
it's
just
I
think
it's
it's
it's
hard
to
figure
out
how
to
productively
discuss,
pull
requests
for
things
that
have
like
that.
We
have
no
clear
agreement
on
or
even
a
lot
of
direction
towards
that.
B
H
Yeah
there
have
been
some
reviews
on
that.
There's
been
some
conversation,
I
actually
just
pushed
a
bunch
of
changes
based
on
that
and
it
can
move
forward.
It's
not
a
PR,
it's
not
a
PR
against
our
fork.
It's
a
PR
against
core
because
it
exists
for
other
things
besides
ESM,
so
we
can
move
forward
with
that
separately
from
the
other
stuff.
B
Shirley,
maybe
come
back
around
on
this
one
as
depending
on
how
that
goes.
I'll
move
on
to
the
next
item,
because
there's
four
of
these
PRS,
if
I,
can
even
find
these
nodes.
Okay,
the
next
one-
was
miles
posted
another
PR
up
to
remove
the
file
extension
adding
and
the
directory
lookups
that
we
have
in
the
current
resolver,
and
that
was
poor
quest
number
two
and
I
believe
that
removes
them
pretty
much
universally
support
for
that
stuff.
B
G
E
Sure
I
think
there's
maybe
a
differing
understanding
of
like
the
the
process
here
and
the
goal
here
like
I,
think
what
Miles
was
going
at
with
minimal
implementation
was
not
not
that
the
end
result
would
be
minimal,
but
rather
that
we
would
like
start
with
basically
start
with
nothing.
Like
start
with,
you
know,
you
know
a
fork
of
node
that
didn't
have
any
models
with
NES
and
implementation
in
it
at
all,
and
just
could
gradually
build
up
piece
by
piece
based
on
like
the
parts
that
we
agree
on.
E
I
think
the
idea
is
remove
it
for
now
and
then
you
know
it
could
certainly
come
back
later,
but
we
should
discuss
how
it
comes
back
like
does
it
come
back
as
part
of
package
name
match,
for
example,
or
something
else,
but
I
don't
think
that
this
is
meant
to
be
like.
This
is
a
change,
and
this
is
permanent.
Moving
forward.
I
think
it's
not
just
part
of
the
iterative
process
of
this.
A
A
That
Jeff
was
talking
about,
so
if
it
was
just
about
removing
features
to
create
a
design
space
rather
than
saying
we're
removing
this
in
order
to
match
another
design,
space
I'd
be
more
okay
with
it
as
it
stands,
we
repeatedly
get
into
cases
where
we're
talking
about
package,
name
Maps
or
web
compatibility,
and
it
seems
especially
in
these
PRS
on
this
minimal
implementation
that
we,
we
don't
really
agree
on
if
the
web
matters
for
compatibility,
which
is
an
interesting
change
in
dynamic
from
when
this
group
was
formed.
So
that's
it.
B
Actually
go
to
the
last
one
since
it's
the
same
topic:
I
created
a
PR
in
in
the
same
vein
as
the
one
that
miles
created,
removing
extensions
and
directory
lookups,
but
with
the
difference
that
the
changes
were
done,
the
removals
were
done
only
in
the
case
will
be
of
resolving
from
a
module
in
a
package
to
another
module
in
the
same
package
and
the
idea
with
that
was
to
try
and
retain
some
of
the
use
cases
that
we
have
for
default.
Extensions
around
things
like
MJS,
falling
back
to
jeaious,
acting
as
a
dual
package.
B
My
convention,
things
like
the
fact
that
we
do
need
directory
indexes
in
some
places
and
then
keeping
compatible
it
using
the
package
boundary
to
keep
compatibility
between
the
fact
that
typically
a
node,
you
want
folders
to
behave
like
packages
on
your
local
file
system.
So
you
can,
you
know,
backtrack
from
one
project
folder
into
another
project
and
load
it
as
if
it
were
a
package.
Even
though
it's
it's
a
relative
or
it's
an
absolute
file
system
path.
B
B
A
Kind
of
same
deal
here
this
is
being
done
in
the
name
of
package
name,
app
compatibility,
it
looks
like
they're
in
other
PR
or
import
meta
require.
We
have
people
kind
of
voting
that
oh,
we
can
just
use
ahead
of
time
tools
if
we're
talking
about
using
ahead
of
time
tools,
I'm,
not
sure
what
value
to
users
have
know
this
pyaare
gives
if
it
was
rephrased
as
well
to
be
like.
A
Oh
we're,
trying
to
reserve
some
sort
of
design
space
and
we're
stripping
out
behavior
in
order
to
get
that,
so
it
can
be
redesigned
I'll
be
fine
as
it
stands
right
now.
The
framing
makes
me
very
uncomfortable
to
be
relying
on
a
very
alpha
spec
and
also
having
non
consensus
on
if
we
need
to
support
browsers,
natively
or
only
using
ahead
of
time
tools.
That's.
B
Right
so
to
be
clear,
the
design
space
that's
being
reserved
with
this
type
of
PR
is.
It
is
packaged
Maps,
and
it's
saying
that
with
browser
packaged,
Maps
you'll
be
able
to
resolve
any
bare
specifier.
But
if
you
have
a
relative
in
imports,
currently
packaged
Maps
don't
have
a
mechanism
by
which
those
can
be
resolved.
A
B
I'm
sure
the
current
teams
would
think
differently
about
that
sure
and
then
the
last
PR
we
have
we're
actually
doing
fine
for
time
is
removing
the
JSON
supports.
So
you
can,
if
you
try
and
import
it,
add
a
JSON
file.
It
weren't
supported
by
default
in
the
Azzam
implementation,
but
from
Commodus
it
would
still
be
supported.
Jeffrey.
E
I
think
when
we
talked
about
this
with
Miles
I
thought
we
would.
We
had
said
like
that.
He
was
gonna,
create
a
fork
and
then
basically
strip
out
all
this
stuff,
and
we
would
basically
add
it
back
in
so
like
we
would
add
in
support
for
Jason,
add
in
support
for
node,
etc.
I,
remember
suggesting
like
just
looking
at
whatever
was
common
between
experimental
models
and
the
NPM
implementation,
for
example,
and
be
like
well
whatever's
common
between
those
two
is
probably
like.
E
Pretty
core
and
gonna
be
in
is
probably
like
the
non-controversial
core
of
this,
and
it
wouldn't
be
a
functional
implementation,
but
at
least
that
would
give
us
a
starting
point.
Do
we
maybe
need,
rather
than
like
all
these
PRS
to
remove
things?
Do
we
maybe
need
to
like
rethink
what
our
starting
point
is
in
terms
of
either
something
common
between
those
two
or
maybe
like
over
a
fork
of
node
that
doesn't
have
any
SM
implementation
whatsoever.
C
That
will
allow
them
to
do
things
that
they
were
not
able
to
do
and
in
the
new
implementation
that
they
were
able
to
do
in
experimental,
so
a
replacement
to
import
a
JSON
file
dynamically
instead
of
actually
doing
import
dynamically
and
getting
that
to
import
the
JSON.
That
would
actually
be
just
a
plate.
You
know
a
replacement
function
exposed
from
that
module.
B
Okay,
does
anyone
have
that
anyone
else
anything
else
to
add
on
this
topic
on
the
piazza?
Otherwise
we
can
move
on
to
the
discussion.
The
that.
The
first
item
is
the
one
that
Bradley
has
brought
up,
which
is
brought
up
on
a
number
of
these
topics,
which
is
browser
and
bundler
compatibility,
which
is
issue
170,
and
how
much
we
should
be
tailoring
the
implementation
to
deal
with
the
needs
of
browsers
and
to
deal
with
the
needs
of
bundlers
bradley's.
Do
you
want
to
maybe
share
someone?
That's
sure.
A
So
we
we've
kind
of
seen
a
miniature
version
of
this
in
these
talks.
In
this
meeting
we
have
some
people's
prioritizing
web
compatibility
and
we
have
some
people
prioritizing
existing
tools.
Others
prioritizing
ease
of
the
final
implementation
being
used,
and
that
gives
us
a
wide
range
of
what
we're
trying
to
discuss
here
when
we're
talking
about
something
like
Jeff's
idea
of
stripping
everything
out
to
reserve
design
space.
A
We
need
to
come
to
an
agreement
on
what
level
of
support
we
care
about
for
the
web
and
it
could
be
zero.
Do
we
care
about
these
ahead
of
time
tools?
Do
we
care
about
people
who
are
trying
to
create
ES
modules
purely
for
the
web
and
having
a
compatibility
so
that
they
could
do
that
in
a
way
that
they
could
also
write
suffer
note?
And,
lastly,
do
we
care
about
the
usability
of
nodes
api's
such
that
we
are
willing
to
remove
compatibility
with
the
web?
A
One
of
those
three
things
as
a
baseline
and
there
will
be
exceptions
but
as
a
baseline
like
are
we
trying
to
ship
something
that
could
reasonably
work
on
the
web
as
it
is,
could
we
reasonably
ship
something
that
ahead
of
time
tools
can
generate
for
the
web
and
have
it
work
pretty
much
out
of
the
box,
or
do
we
want
to
ship
an
implementation
that
is
reasonably
easy
to
use
for
node
users,
even
if
it
doesn't
allow
it
to
be
easily
replicated
on
the
web
so
yeah?
That's
it.
E
I
just
I
just
raised
it,
so
we
did
kind
of
already
come
to
an
agreement
on
this.
When
we
did
the
features
list
and
the
remember
they
were
like
there's
two
like
extremely
high
priority
features
that
got
like
pushed
at
the
top
of
the
list.
One
was
like
spec
compatibility
or
respect
compliance
and
the
other
one
was
browser
compatibility,
so
that
was
kind
of
already
voted
on
and
agreed
to
and
like.
There
was
nearly
Universal
that,
like
that
was
something
we
wanted
now.
E
Maybe
it
hasn't
been
defined
clearly
enough
that,
like
you,
know,
they're
people
that
are
like
something
like
the
automatic
file
extension
resolution
is
like
not
something
browsers
support
or
you
know
more
or
less
support
or
likely
to
ever
support
her,
and
so
people
who
are
said
like
yes,
we
need
to
be
compatible
with
browsers,
maybe
think
it's
somehow
okay
for
node
to
do
that
and
that's
not
presenting
a
browser,
compatibility
problem,
I,
don't
know,
that's,
maybe
something
we
should
talk
about
if
I
could
venture
a
definition
for
myself.
It's
you
know.
E
Npm
now
has
all
these
modules
that
run
on
that
are
meant
to
be
used
in
browse
I
would
want
us
to
make
an
es
models,
implementation
that
encourages,
if
not,
forces
like
new
NPM
models
that
are
using
ESM
to
work
in
browsers
whenever
possible,
like
yeah,
they
import
the
FS
model.
Of
course
they're
not
going
to
work
in
browsers,
but,
like
aside
from
you,
know,
limited
unavoidable
exceptions,
we
really
should
be
able.
We
really
should
be
pushing
users
to
create
models
that
work
in
both
environments.
B
C
You
know
rank
something
like
that
and
then,
when
we
have
that
data
next
meeting,
it
will
be
easy
to
rationalize
but
also
have
a
snapshot
of
where
we
stand.
In
the
you
know,
a
real
vote
really
I
think
it's
it's
hard,
sometimes
to
count
a
vote
when
people
are
trying
to
elaborate
things
and
get
distracted.
You
know
from
the
actual
point
into
other
questions.
So
so
maybe
that
would
be
a
good
effort.
If
anybody
supports
that.
D
If
you
take
all
the
programs
that
are
going
to
be
written
in
ESM
modules,
for
now
there's
going
to
be,
you
know
an
intersection
area
there
of
modules
that
will
work
on
the
web
and
then
there's
going
to
be.
You
know
a
set
of
programs
that
aren't
you
know,
programs
that
read
files
and
and
whatnot
and
and
there
will
be
a
lot
of
developers
who
are
writing
those
kinds
of
programs
that
read
files
and
things
like
that
that
don't
even
really
care
about
compatibility
with
a
browser
and
I
think
I.
D
Think
that
in
our
approach
we
should
treat
both
both
of
those
both
of
those
sets.
But
the
intersection-
and
you
know
the
exclusion
as
like,
first
class,
so
you
know
use
cases
should
be
ergonomic
for
both
of
those
like.
If
I'm
writing
a
program,
that's
only
for
now,
then
you
know
I
shouldn't
have
to
bend
over
backwards.
In
order
to
you
know,
in
order
to
get
a
denote
specific
things,
and
also
you
know,
if
I'm
writing
for
that
intersection,
there,
then
I
should
be
able
to
code
it
in
a
way.
D
A
A
Is
this
compatible
with
other
environments
and
so
you're
starting
to
talk
about
ergonomics
over
you
know
easier
design,
questions
I'm,
not
saying
that
choosing
one
will
lead
us
to
have
all
three
scenarios
be
ideal,
but
I
think
choosing
one
of
these
paradigms
and
stating
this
is
the
number
one
paradigm
we
could
even
go.
This
is
the
number
two
paradigm.
This
is
the
number
three
paradigm.
These
are
our
priorities.
Would
let
us
at
least
better
evaluate
the
value
of
different
API
decisions,
because
we
have
a
very
large
design
space
for
working
with.
A
So,
if
we're
going
for
things
like
web
compatibility,
that
would
change
my
opinions
on
the
minimal
kernel
implementation
drastically
versus
this
intersection
idea
and
so
I
think
it's
a
way
of
getting
us
all
to
agree
on
a
direction
we're
going
to
go
in
rather
than
us
all
spreading
to
the
winds
and
taking
all
these
different
directions.
So
that's
if.
B
I
can
just
mention
as
well.
I
yeah
I
also
worry
about
focusing
on.
You
know
forgetting
about
the
browser
too
much.
If
you
think
back
to
what
the
how
the
current
wear
clothes
we
have
today
are
working
all
bundlers
follow
the
same
original
conventions
that
were
set
by
browserify
and
when
browser
five
first
came
around,
we
were
writing
node
modules
that
didn't
run
in
the
browser
and
browser.
If
I
said
hey,
we
can
make
all
these
node
things
work
in
the
browser
we
can
make.
We
can
do
the
resolution
that
node
does.
B
We
can
do
the
JSON
imports,
we
can
shim
the
FS
module,
we
can
shim
all
the
built-in
modules
and
they
shim
all
the
built-in
modules
and,
if
you
use
the
buffer,
global
or
the
process,
global
will
automatically
replace
a
few
all
of
those
conventions
stuck
and
have
stuck
until
today.
So
the
conventions
by
which
we
bound
our
apps
and
we
write
our
apps
and
they
sit
on
NPM
and
run
in
browsers,
were
set
by
browserify
when
it
came
out
and
browser
if
I
was
simply
following
what
no
did
so.
B
What
we
are
doing
here
is
we
have
the
ability
to
sent
those
conventions
that
the
bundlers
of
tomorrow
follow,
and
we
can
see
a
step
ahead
because
we
can
see
that
this
happened
was
browser.
Fine.
We
can
see
what
batter
it
was
and
realized
that
were
in
a
position
to
change
things
for
the
better
here
and
that's
my
point.
Okay,
thanks
sulla.
C
Yeah
I
think
like
what
Bradley
you
know,
I
brought
up
the
idea
that
there
will
be
rewrite
to
get
your
code
that
exists
today
to
work
as
ESM
and
that's
no
question
and
I
think
it's,
the
idea
that
you
know.
There's
convention
like
browserify
derive
implementation
and
butlers
is
also
a
very,
very
good
thing
to
keep.
C
So
the
minimalistic
changes
that
you
could
do
in
import
statements,
things
that
are
statically
overwritten
by
service
workers
or
whatever
those
are
good
decisions
to
to
support
the
browser.
But
things
that
can
you
know
require
code,
ast
analysis
and
stuff
like
that.
That
makes
it
very
very
tricky
if
you
don't
have
control
over
the
module
that
was
intended
for
node
being
maybe
unpackage
being
accessed
in
the
browser
that
will
require
you
to
do
a
lot
of
work
in
a
browser
thread
to
actually
get
it
to
work.
C
I
Like
the
thing
like
that
this,
this
is
like
the
core
of
the
thing
that
gets
me
about,
like
the
module
design
for
note
like
coming
at
it,
and
then
saying
we
don't
like
what
people
have
done
with
modules
and
come
and
yes
and
we
want
to
start
fresh
and
do
things
differently
coming
at
it.
From
that
perspective,
is
the
part
that
feels
very
wrong
to
me.
It's
the
part
that
makes
me
come
down
and
say:
well
then,
what
was
all
the
other
code
that
I
wrote
like?
I
Why
are
you
not
trying
to
support
me
continuing
doing
what
I'm
doing
and
just
making
it
incrementally
better
I,
don't
want
to
start
fresh
I,
don't
want
to
start
new
I
want
to
leverage
the
knowledge
I
already
have
with
little
new
parts
tacked
onto
it.
I
think
that's
the
point
of
advancing
forward
and
not
starting
with
some
new
runtime
somewhere
else
like
if
I
can't
continue
to
do
what
I'm
already
doing
with
just
small
additions
that
make
it
better.
Why
am
I
doing
it?
But.
A
I
Like
1.8
is
like,
if
the
module
like
a
DES
module
ecosystem
or
build
process,
is
so
divorced
from
the
common
json',
how
different
is
it
from
another
runtime?
Aren't
you
just
shipping
to
runtimes
that
have
a
loose
coupling
to
one
another
at
that
point
like
if
you
want
to
take
the
opportunity
of
esm
to
strip
all
the
Global's
out
change
all
of
the
api's
and
make
everything
different?
Why
are
you
starting
with
the
initial
runtime
in
the
first
place?
I
Why
aren't
you
doing
that
and
the
reason
is,
is
because
you're
trying
to
capture
those
initial
old
users
and
you're
trying
to
bring
them
forward.
So
why
aren't
you
trying
to
help
those
people
all
the
way?
Why
aren't
you
making
it
so
they
can
adopt
as
much
as
they
can.
Why
is
this
cool
things
so
new
and
cool
it's
worth
giving
up
everything
that
already
exists.
I
B
I
Right
so
I've
had
I've
had
two
stances
during
this
and,
like
the
issue
I
take
is
with
the
middle
ground.
Going
for
this
intersection
is
the
worst
thing
you
can
possibly
do
for
note.
You
won't
want
to
go
full
all
the
way
to
browse
incompatible,
ileum,
do
nothing
different
than
the
browser
and
maybe
provide
like
one
out
to
get
back
into
common
js4
like
some
back
combat
and
like
you,
want
to
completely
match
the
browsers
and
do
nothing
different
I
can
see
the
value
in
that
I
can
see
saying.
I
Okay,
we
want
to
be
exactly
like
the
other
runtimes,
rather
than
like
our
past
runtime.
That
has
value.
I
can
also
see
saying
we
want
to
be
as
much
like
the
people
who
have
already
been
using
es
modules
and
load
in
a
transparent
fashion.
We
want
to
do
everything
we
can
for
them
to
make
the
transition
as
soon
as
possible.
We
want
to
do
everything
we
could
like
we
did
in
the
past.
We
want
to
keep
all
overall
DPI's
around,
but
make
everything
available
like
it
was
before.
I
We
want
to
iterate
slowly
and
move
forward
and
if
all
things
incrementally,
rather
than
an
Indian
fashion,
but
this
intersection
in
the
middle,
where
we
say
all
right,
we
want
to
be
kinda
a
little
bit
more
like
the
browser
in
these
ways,
but
also
remove
these
api's
from
CJ
s
and
then
just
take
these
little
parts
out
from
each
place.
That's
where
I
take
issue
that
part
in
the
middle
makes
things
worse
for
people
going
either
direction.
If
you're
moving
from
CJ
ste
SM,
you
have
a
hard
time
of
it.
I
I
A
I
A
Champion
I
think
we
can
do
a
lot
of
stuff.
We
can't
get
a
hundred
percent
compatibility
I
think
we
can
get
maybe
eighty
percent.
What
else
was
there?
I
I,
don't
see
it.
So
importantly,
if
almost
every
design
we've
been
talking
about,
doesn't
let
you
do
this
import
from
dot,
J's
files
and
it
statically
parse
and
try
to
guess
what
mode
the
source
text
is
in
like
we
have.
We
have
things
besides
named
imports
that
are
gonna,
be
requiring
you
to
alter
your
configuration,
your
source
code,
whatever.
F
That
the
initial
question
I
mean
the
initial
approach
we
are
taking
in
general
is
not
like
what,
if
we
can't
but
try
to
explore
the
design
space,
do
what
we
can
and
then
based
on
what
we
are
managed
to
achieve.
The
constraints
will
you
know,
put
us
in
a
certain
direction
so
that
that
was
kind
of
the
goal
of
this
working
group?
Is
my
understanding
so
like
the
hypothetical?
F
What
if
I
I,
don't
necessarily
know
if
they're
super
useful
right
now,
like
I,
think
there's
a
meta
issue
that
we're
trying
to
come
up
with,
which
is
like
what
is
the
general
direction?
And
you
know
they're,
even
even
before
you
mentioned
like.
If
we
want
to
prioritize
things
and
then
you
know
come
up
with
exceptions,
that's
fine,
if
that's
the
case,
but
like
I.
F
Don't
think
that
there's
an
MIT
Wesley
I
didn't
want
to
like
answer
for
you,
but,
like
my,
my
I
hope
is
that
we
can
just
try
to
come
up
with
a
design
that
does
recapture
existing
users
who
have
been
like
creating
this
cow
path
for
modules
and
note,
and
then
try
to
ensure
that
there
is
the
easiest.
You
know
situation
for
everybody
right.
If
there
are
constraints,
then
we'll
find
them
naturally
in
the
process
right.
F
A
Where
I'm
like
take
six
yes
better,
this
working
group
there's
been
four
years
I've
been
trying
to
do
this.
Before
that,
there's
been
the
EP
process,
we
talked
to
the
technical
steering
committee.
We've
been
talking
for
years
on
this.
What
what
do
you
want
at
this
point
like
what
direction?
What
actionable
thing
do
you
want
when
we
state?
We
cannot
do
something.
B
Okay,
if
you
don't
mind
if
I
just
terrify
something
again
on
where's,
this
point
it
does
concern
me
was
when
you
say
that
you'd
like
to
see
like
no
parrot
eyes
and
and
the
concepts
of
there
being
an
intersection
with
the
browser
being
you're
worried,
because
you
know
in
any
language
environment.
You
know
you
have
the
concepts
of
portable
code
and,
in
general,
like
the
easier
it
is
to
write
portable
code,
the
more
successful
that
you
know
it's
it's
like
it's
it's
a
key
thing
for
any
type
of
environment.
It's
the
more
portable.
I
I
It's
just
a
matter
of
how
much
do
you?
How
close
do
you
want
that,
like
ability
to
write
code
that
will
work
on
both
platforms,
beef,
the
most
blessed
way
to
do
something
or
the
only
way
to
do
something,
and
if
doing
that
involves
like
bucking
the
conventions
of
the
colleges
community
for
the
last
four
years
or
five
years?
It's
just
like.
What's
the
point
like,
why
not
just
go
all
the
way
and
just
do
things
exactly
like
the
browser,
if
you're
going
to
do
things
differently
anyway,.
B
J
I
I
Entire
graph
is
capable
also
being
resolved
synchronously.
It's
only
once
you
push
in
the
stuff
for
like
top
level,
oh
wait
that
the
asynchronicity
becomes
actually
required
and
like
there
are
things
like
je
DS
loader
that
do
things
like
take
ES
and
do
nonsense
to
try
and
make
it
live.
Synchronously,
like
those
are
all
those
things,
yeah
technically
again
spec,
but
we
have
people
who
say
like
well,
we
can
try
and
change
the
spec
to
make
more
things
work
out.
J
B
B
C
Yeah
just
one
thing
about
compatibility
with
transpiled
module,
let's
modules
like
babel
and
typescript,
they
can
actually
just
me
transplant
they
transpiled
to
begin
with,
so
we
should
think
of
those
who
don't
actually
transplant
their
modules
and
build
a
lot
of
those
as
being
at
a
disadvantage
with
our
decision-making.
I
Just
read
transpiler
modules
or
recompile.
Your
modules
rather
like
the
issue
for
us,
has
nothing
to
do
with
the
output
format.
It's
the
fact
that
the
same
input
format
coming
for
different
things
like
right
now.
It
can
mean
two
different
things
and
that's
already
a
problem
if
notice
something
different
than
the
browser
or
different
than
what
both
loads
already
do.
We
can
mean
three
different
things:
that's
an
even
bigger
problem.
That's
the
problem
right,
that's
our
problem!
We.
C
I
fully
understand
that
part
like
I'm,
not
weighing
in
on
whether
or
not
that
will
change
I'm,
just
saying
that,
if
it's,
if
it's
just
about
how
the
compatibility
of
the
object
with
weird
yes,
you
know
fields
on
it
is
being
constructed.
If
that
is
going
to
be
changing
for
any
reason
which
is
you
know
probable
at
this
point,
then
it
affects
people
who
transpire
modules.
C
It
doesn't
necessarily
affect
people
who
right
yes,
modules
intended
for
the
browser,
whether
or
not
we
do
support
them,
as
is
a
node
or
sapote
support
modules
that
are
written
for
node
exactly,
as
is
in
the
browser.
Just
you
know,
if
it
was
transposed
recently,
it
most
likely
can
be
read
transposed
it's
a
good
bet
compared
to
someone
who
writes
code
by
hand
having
to
go
through
all
their
modules.
You
can
search
and
replace
and
whatever,
but
it's
still
a
manual
task
compared
to
one
that
is
already
automated.