►
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
Hi
I'm
miles
Lawrence
I'm,
a
product
manager
at
github,
contributor
to
the
nodejs
project,
I
said
on
the
technical
steering
committee
and
have
also
helped
extensively
with
our
modules
team.
I
also
do
standards
work
with
tc39,
where
you
may
know
me
from
such
proposals
as
top
level
of
weight
and
import
attributes,
I'm
joined
today
by
guy
Bedford,
a
guy.
Would
you
like
to
introduce
yourself.
B
A
Thanks
guy,
this
session
was
titled
a
developer,
fanfiction
modules
edition,
which
was
heavily
inspired
by
this
kind
of
tongue-in-cheek
phrase
that
I
use
sometimes
called
developer
fanfiction,
which
is
where,
like
you
know,
either
people
are
opening
issues
or
they're.
There
kind
of
like
reading
speculative
fiction
about
what
the
what
the
future
looks
like
or
what
they
think
things
will
be
I
mean.
A
In
particular,
you
know
different
runtimes
have
different
require
the
browser
and
node
have
different
security
models
and
different
fundamental
infrastructures,
and
even
newer
runtimes,
like
denno,
have
completely
different
requirements
because,
for
example,
they
aren't
bogged
down
by
the
legacy
of
node
and
they're
able
to
do
you
know
something
like
let's
examine
you
are
a
URL
based
loaders
rather
than
you
know,
relying
on
package
managers
guy.
Do
you
have
any
kind
of
insight
into
some
of
the
places
where
you
have
found
recently?
You're
writing
some
developer
fanfiction.
B
As
you
say,
tools
like
Dino
get
to
decide
how
they
want
to
do
things
browsers,
get
to
decide
how
they
want
to
do
things
so
all
around
as
we're
using
the
language.
We're
writing
this
fanfiction
and
I
mean
that
that's
exactly
you
know
we
were
talking
about
earlier
today.
How
tools
like
web
pack
have
have
led
to
this
explosion,
of
where
we
currently
calling
faux
modules
that,
in
itself
is
as
a
form
of
fan
fiction
of
how
tools
have
been
able
to
shape
how
we
use
JavaScript
and
and
create
create
those
working?
A
But
looking
at
the
text
itself
at
the
source
text,
you
know
like
import
thing
embraces
from
module,
looks
very
similar
to
like
constant
basis
thing
equals
require
thing
that
probably
would
work
a
lot
better
if
I
actually
had
some
text
and
perhaps
when
we
edit
this
all
I'll,
add
a
little
writing
on
top.
So
it's
not
just
me
waving
my
hands
but,
like
obviously
there's
advantages
to
code
splitting
and
tree
shaking
that
you
also
get
from
named
imports,
but
realistically,
at
least
in
very
early
versions
of
Babel.
A
A
That
actually
has
made
the
job
in
the
node.js
modules
team,
just
so
much
harder
trying
to
figure
out
how
to
get
these
environments
to
play
nicely,
because
one
of
the
goals
that
we
had
in
node
Quora
was
a
ensuring
that
we
had
spec
compliance
and
then
be
ensuring
that
you
know
we
don't
require
any
sort
of
transport
were
build
step,
and
so,
if
you
were
using
Babel
or
if
you're,
using
webpack
or
if
you're
using
typescript,
you
can
do
something
like
make
a
named
import
from
a
common
J's
module,
because
you
have
that
whole
pass.
A
Where
you're
compiling.
Where
you
can.
You
know
kind
of
sort
all
this
stuff
out.
This
is
why
we
call
them
faux
modules,
which
in
a
way
and
and
honestly
I,
wasn't
thinking
about
it.
When
I
when
I
came
up
with
the
title,
but
you're
totally
right
is
like
a
fun
kind
of
like
developer
fanfiction
from
like
three
years
ago,
when
people
were
trying
to
speculate
like
what
does
it
look
like
to
write
modules
in
three
years?
We
all
know
we
still
haven't
totally
figured
that
out,
but
I
think.
A
Maybe
that's
like
a
really
fun
jump
into
kind
of
like
loaders
and
module
types
right,
because
the
specifier,
when
you
import
a
specifier
and
the
specifier,
is
like
the
string
that
you're
importing
from
there's
so
many
things
that
we're
used
to
doing
but
like
none
of
it,
is
actually
standardized
like
the
idea
of
like
how
you
resolve
a
specifier
into
a
resource.
Yeah.
B
That
was
something
that
we
would
possibly
have
to
live
with
this
huge
difference
between
the
platforms,
but
somehow,
in
this
modules
process
we
managed
to
create
the
same
resolution
behavior
between
the
browser
and
digest
and
for
when
it
comes
to
relative
specifiers,
I.
Think
getting
those
kind
of
details.
B
Rights
was
so
crucial
for
us
to
try
and
set
up
a
piece
for
the
language
where
and
use
their
code
between
these
different
environments
and
not
suddenly
run
into
a
whole
bunch
of
of
bugs
and
issues
when
things
don't
work
between
these
environments
and
yeah
I
thought
that
was
very,
very
cool.
We
could
get
that
out
of
that
process.
I
mean
is:
is
that
something
that
that
you
were
always
thinking
about
in
the
back
of
your
mind
that
these
kind
of
universal
use
cases
yeah.
A
Yes
and
no
Universal
modules-
or
you
know,
as
some
people
like
to
call
it
isomorphic,
but
just
the
idea
that
you
can
share
code
between
environments
has
always
been
like
near
and
dear
to
my
heart
as
someone
who,
like
kind
of
grew
up
in
the
like
paste,
some
JavaScript
in
a
browser,
and
it
works
world.
These
specific,
like
changes
that
we
made
to
the
node
resolution,
algorithms,
specifically
that
in
nodes
eosin
implementation,
if
you
import
a
module,
you
need
to
have
its
full
file
path.
A
A
Where
we're
removing
this
feature,
and
there
were
members
of
the
team
who
very
much
love
that
feature
still
love
that
whew
right
and
think
that
the
shame
that
we
lost
it
and
I
think
you
know
people
come
to
me
and
they're,
like
you
know
miles.
What
do
you
think
of
denno?
You
must
hate
it.
I'm,
like
no
I
love
JavaScript,
like
the
more
places
to
play
the
merrier,
the
more
environments
that
we
have
that
share
similar
kind
of
ethos
to
node.
A
A
We're
like
having
another
runtime
like
denno
and
again,
one
isn't
tied
to
the
same
degree
of
legacy,
actually
allows
us
to
move
forward
faster.
The
fact
that
denno
shipped
this
and
that
people
were
not
like
up
in
arms
was
actually
something
we
could
point
to
as
a
reason
you
do
it
a
node
and
not
just
that.
It's
like
hey
well,
like
the
browser's
not
going
to
do
this
and
denno
is
not
doing
this.
I
really
think
that
we
shouldn't
and
we
were
able
to
get
it
through
one
of
the
other
ones.
A
It
is
just
a
string
and
node
has
a
whole
algorithm
using
package.json
and
the
node
modules
folder
to
German
to
determine
how
you
turn
that
specifier
into
a
path
on
disk
that
you
can
load-
and
you
know
a
future
I
would
love
to
see,
would
be
one
where
you
can
npm
install
something
on
your
system
and
can
you
can
you
hear
those
sirens
right
now?
Yeah
welcome
to
New
York
City
USA
home
of
the
sirens.
It.
A
It's
just
like
not
gonna
work,
you're
gonna
have
to
like
import
the
node
modules
folder,
and
if
that,
if
that
dependency
doesn't
have
any
dependencies,
it
might
work,
but
the
second
you
refers
to
another
dependencies
by
a
bear,
import,
it
breaks,
and
so
there's
this
technology
that
is
in
the
process
of
being
standardized,
called
import
maps
and
guide.
Maybe
you
could
tell
us
a
little
bit
more
about
that.
Yes,.
B
Sir
input
maps
are
I
mean
they
have
come
out
of
like
many
years
of
spec
work
and
discussion
about
how
you
you
resolve
modules
in
the
browser,
because
and
again
it
sort
of
builds
on
top
of
that
base.
Node
used
case
you
just
described
where,
as
as
a
user,
you
just
want
to
import
the
package
of
the
code
that
you're
loading
and
how
do
we
do
the
same
kind
of
thing
in
the
browser?
How
do
how
do
we
enable
the
browser
to
just
load
a
package?
B
Well,
you
don't
have
to
necessarily
copy
and
paste
a
URL
look
up
a
URL
somewhere
and
then
also,
as
you
say,
that
the
dependencies
also
need
to
do
that.
So
this
is
kind
of
iterative
process
that
I
staff
and,
if
you
want
things
to
depend
on
each
other,
so
import
Maps
grew
out
of
what
was
originally
the
idea
that
you
would
have
be
able
to
hook
the
result
function
in
the
browser
and
then
it
kind
of
simplified
down
into.
B
Let's
just
have
a
map
and
the
the
closest
we
had
to
that
in
the
past
was
probably
something
like
the
requirejs
figuration,
which
was
an
old
loader
for
java
scripts.
Well,
you
could
write
this
map
configuration
and
and
point
names
to
different
target
pods,
and
it's
in
many
ways
quite
similar
to
that
in
other
ways.
It's
quite
different
to
that.
B
But
if
import
Maps
have
been
under
development
actually
quite
a
while
and
still
there
still
seems
to
be
a
little
to
work
out,
but
they're
shipping
in
chrome
today,
under
the
experimental,
webform,
peaches,
flank
and
and
I
think,
there's
there's
been
a
lot
of
wider
platform
interest
in
it
as
well
with
projects
like
Dino.
Also,
adopting
import
Maps
is
the
way
that
they
want
to
use
their
specifiers
so
just
to
touch
on
it
briefly.
B
A
A
So
it's
called
package
exports
and
it's
a
new
field
in
the
package.json
called
exports,
where
you
can
define
the
external
interface
for
your
package,
so
you
know
you're,
probably
used
to
putting
in
a
main
or
a
browser
field.
When
you're
writing
a
package,
that's
going
to
be
consumed,
the
algorithm
that
node
has
when
you
like.
You
know
import
lodash
as
it
goes
into
the
node
module
folder.
It
looks
for
a
folder
with
the
name
of
the
specifier.
A
It
looks
for
its
active
JSON
and
then
it
looks
for
me
this
is
something
that's
actually
specified
in
our
communication.
You
could
look
it
up
and
look
at
how
the
resolution
algorithm
works.
You
know
it's
fun
for
me,
maybe
not
for
you.
I,
don't
know
I
like
reading
specs,
sometimes
no
package
exports.
Without
them,
you
can
kind
of
like
deeply
traverse
into
a
module
and
grab
any
file
from
anywhere
in
the
module
with
package
exports
you're
able
to
define
that
interface.
A
So
you
can
say
you
know,
like
slash,
dot,
slash,
deep
module
and
have
a
path
to
it,
and
when
someone
imports
your
module,
slash
deep
module
like
it
will
resolve
into
that.
The
part
of
the
reason
why
this
is
so
powerful
beyond
just
the
fact
that
it's
cool,
till
I
kind
of
have
this
public
private
interface
for
your
package,
which
is
a
great
programming
as
well,
is
that
it
makes
every
single
specifier
within
a
module
assuming
that
you're
writing
it.
This
way
absolutely
static,
and
this
is
something
that
plays
really
nicely
into
import
Maps.
A
So
what
it
means
is
that
anyone
who's
consuming
your
package
and
specifies
something
we
can
like
completely
statically
resolved
the
path
of
all
of
those
specifiers
and
internally
in
your
module
as
well.
All
of
the
specifiers
that
you
write
are
also
statically
resolvable
now
now
this
is
making
the
assumption,
of
course,
that
you
are
writing
a
tree
that
is
all
ESM
were
written
in
a
like
a
sub,
a
sub
set
of
common
j
s.
A
A
A
Has
this
one
called
conditional
exports
where,
for
each
entry
point,
you
can
specify
an
export
for
a
particular
run
times,
so
you
could
at
install
time,
generate
like
a
browser,
import
map
or
a
node
import
map,
and
then
you
could
have
the
exact
same
generic
node
modules
folder
completely
static,
no
translation
and
have
different
code
paths
depending
on
the
import
map
that
you're
using-
and
this
is
something
that
there's
an
awesome
tool
out
there
right
now
called
snow
pack.
It's
part
of
the
picker
project,
that's
done
by
fred
shot.
A
That
is
experimenting
a
lot
with
I
mean
they
are
doing
translation
and
they're,
making
a
new
folder
called
the
browser.
Folder
and
like
they've,
gone
in
a
slightly
different
direction,
but
they
are
playing
with
tools
that
can
generate
import
maps.
They
are
playing
with
import
maps
as
a
way
of
allowing
for
bear.
Specifiers
inside
of
the
browser-
and
it's
really
cool
kind
of
seeing
these
kind
of
tools
in
a
way,
writing
kind
of
their
fanfiction.
Of
what
they'd
like
to
see
the
future
of
web
development
be
yeah.
B
It's
it's
it's
a
very,
very
compelling
use
case
to
be
able
to
see
the
style
of
package
management
for
to
the
browser
and
I
think
it
was.
It
was
amazing
that
so,
as
we
were
working
through
some
of
these
problems
in
the
node.js
modules
group
that
we
were
able
to
look
slightly
wider
than
OGS
again
and
and
look
at
import
Maps
and
see
what
was
going
on
there,
because
I
mean
when
we
were
discussing
this
in
the
original
phase
of
the
modules
meetings,
import
maps
were
still
relatively
new.
B
I
mean
that
they
they're
I
think
they're
much
more
widely
understood
today.
But
we
were
very
much
sort
of
having
to
keep
an
eye
on
on
these
new
technologies
and
and
then
try
and
come
up
with
with
something
that
was
compatible
with
it.
And
what's
very
cool
about
exports
is
if
we
ended
up
designing
it
in
a
way
that
it
works,
quite
naturally
with
import
Maps.
B
Guess
when
you
think
these
things
through
ice,
always
to
imagine
it's
one
one's
own
idea,
but
you
know
we
were
all
discussing
these
things
and
things
get
really
mixed
up.
As
far
as
I'm
aware
it
was
Rob,
Palma
was
was
the
original
producer
of
the
exports
encapsulation
in
really
yeah
and
one
day
they've
been
using
something
similar
at
Bloomberg
and
so
that
they
they
valued,
encapsulation
and
and
valued
in
their
internal
workflows.
B
I
mean
certainly
correct
me
if
I'm
wrong,
but
this
is
as
much
as
I've
been
able
to
glean
from
the
process
and
that
that
encapsulation
is
huge,
because
normally,
when
you
publish
a
package
to
OPM,
you
change
one
internal
module.
Maybe
you
didn't
realize
that
that
a
user
was
importing
that
module
and
relying
on
its
interface.
B
Is
it
actually
automatically
treats
all
of
the
definitions
in
the
exports
field
as
the
entry
points
of
the
package
in
a
rollup
code
splitting
both
as
a
code
splitting
world,
and
then
you
get
the
chunking
and
the
code
sharing
and
the
minimum
number
of
modules.
But
it's
part
of
your
actual
package
management
process,
so
it's
sort
of
a
host
becomes
an
implicit
build
process.
It's
no
longer
something
you
have
to
define
that
the
configuration
for
the
build
yourself.
You
don't
have
to
roll
up
a
web
back
and
say
I'm
building
these
files.
B
You
can
automatically
try
and
optimize
those
individual
packages.
You
rich
I
think
another
step
as
we
try
and
get
these
individual
package
import.
Maps
running
in
the
browser
very
much
like
smart,
bundles,
yeah
and
doing
it
automatically
based
on
the
information,
because
the
exports
is
exactly
the
information
you
need
to
know
to
be
able
to
optimize
the
interface
of
a
package.
So
there's
this
I
mean
there's
lots
of
interesting
tooling.
That
can
build
on
top
of
that
field,
and
this
is
yeah
I.
Think
a
great
success
of
that
process.
B
A
Like
one
of
the
biggest
differences
and
I
think
we're
getting
close
to
time,
sure
you
have
some
closing
thoughts,
but
one
of
the
things
I
think
is
rather
interesting.
Is
that
if
you
look
at
the
way
the
people
have
been
writing
like
kind
of
JavaScript
module
systems
the
last
couple
years,
they
were
all
quite
dynamic
and
one
of
the
like
real
advantages
that
ESM
has,
in
my
personal
opinion
over
like
you
know,
commonjs
is
the
fact
that
it
is
a
static
module
system.
It
has
these
phases.
A
You
can
do
this
kind
of
like
introspection
and
smart
things
with
it
because
of
its
static
nature
and
I
feel
like
these.
Various
technologies
that
we've
been
talking
about
have
been
kind
of,
like
leaning
in
to
the
fact
that
it's
static,
we're
talking
about
all
the
various
like
static,
like
kind
of
like
metadata
to
a
certain
extent,
but
but
you
know
like
unlike
node,
unlike
browserify,
unlike
babble,
which
had
all
these
kind
of
dynamic,
build
steps
which,
if
you,
if
you
need
a
bundler
like
at
the
point,
I
kind
of
I
gave
a
talk.
A
Last
year
and
I
talked
about
like
nihilistic
transformation,
and
it's
kind
of
like
this
idea
that,
like
once,
you
have
to
have
a
transformation
step,
it's
already
dynamic,
so
you
may
as
well
just
like
just
keep
strapping
things
on
to
it.
But
when
we
start
from
this
like
kind
of
static
core
and
add
you
know
kind
of
more
static
insight.
We're
ending
up
with
this,
like
kind
of
really
nice
result.
B
I
think
what
it
comes
down
to
as
well
as
is
making
it
well
at
least
trying
to,
and
in
this
in
this
eventual
goal.
You
know
we're
trying
to
make
it
easier
for
users
to
so
optimize
their
packages
easier
for
users
to
configure
their
built
systems
and
try
and
like
in
lots
of
ways.
The
complexity
around
javascript,
tooling
and
stuff
has
been
the
sort
of
K
Brehon.
A
A
The
thing
about
the
web
and
the
browser
and
JavaScript
in
particular,
which,
like
enabled
and
empowered
me,
was
just
that,
like
it
was
so
intuitive
and
quick
to
get
started
and
I
feel
like
we,
as
an
ecosystem,
have
had
to
layer
on
a
lot
of
complexity
to
like
allow
for
advance
productivity.
But
the
result
is
that
we've
lost
a
lot
of
that
short
term.
Wow
and
I
know
that
we're
talking
here
about
a
lot
of
like
kind
of
you
know,
it's
not
nothing.