►
From YouTube: OpenJS Foundation AMA: Node.js Modules
Description
The OpenJS Foundation is a member-supported non-profit organization that provides a neutral home for some of the most important project in the JavaScript ecosystem.
Learn more and join us at https://openjsf.org
A
B
Sure
so
I'm
Bradley
Phidias
work
at
GoDaddy
and
I.
Think
I
was
the
first
person
to
try
to
propose
landing
modules,
so
I've
been
around
a
while,
but
it's
no
longer
just
me.
We
have
a
huge
working
group
and
I've
actually
started
doing
less
than
most
the
other
working
group
these
days.
That's.
C
C
E
Hi
I'm
young
I'm,
also
working
at
Google,
like
at
Mars
and
I,
originally
started
working
on
modules.
A
node
kind
of
from
the
web
compatibility
compatibility
perspective
trying
to
make
it
work,
so
you
have
the
same
code
work
in
both
and
well
not
having
modules
and
no,
it
was
kind
of
a
blocker.
For
that.
A
Awesome,
thank
you
very
much
and
lastly,
I'm
Woodrow
I'm
the
moderator
for
the
evening.
I,
don't
know
it's
evening
for
me:
bril
dead
zone,
yeah
and
I
work
as
a
composite
attacker
at
agalya,
working
on
v8
stuff
and
PC
39
and
I've
been
working
on
nodejs
working
a
little
on
the
common
GS
side
of
things
and
the
embedding
side
of
things
when
it
comes
to
actually
running
code
in
v8.
So
it'll
be
really
interesting
thanks.
D
So
for
a
road
map,
stuff
I
guess
we
could
talk
a
little
bit
about
like
what
has
landed
and
what
could
be
expected
and
then
maybe
for
historic.
Brad
Brad
can
maybe
kick
that
off,
but
the
the
most
straightforward
stuff
right
now
that's
good
to
know
is
that
es
modules
has
been
unflagged
in
nodejs
as-as-as
of
13.2
there's
two
two
major
features
that
are
still
flagged
that
are
being
worked
on.
Although-
and
maybe
you
know
Jeffrey
or
Dion
knows
a
bit
better.
D
E
D
The
current
timeline
that
we
have
those
hoping
to
have
those
features
unflagged
this
month,
we're
hoping
to
back
port
as
much
of
if
not
the
entire
implementation.
Aside
from
the
unflagging
to
new
GS
12
and
the
next
cember
minor
release
with
the
intention
of
unflagging
everything
in
nodejs
12
by
April
for
the
next
cember
minor
release,
so
you
know
we're
kind
of
living
in
the
future.
A
B
The
JavaScript
language
standards
body
landed
es
modules
in
2015,
but
without
a
plan
to
actually
ship
them
and
browsers
or
a
node,
things
got
really
hairy
for
a
while,
meaning
that
both
browsers
and
node
had
to
kind
of
take
the
spec
and
figure
out
how
they
were
going
to
actually
ship
it.
So
for
the
next
few
years,
node
at
least
was
trying
to
figure
out
how
they
were
gonna.
Do
that
and
there's
an
older
process
that
we'd
no
longer
use
called
the
EP
process
for
enhancement
proposals
and
so
for
a
while.
B
B
But
after
this
EP
process
kind
of
started
to
wind
down,
we
enter
kind
of
this
next
life
cycle,
there's
a
period
of
time
where
we
just
kind
of
landed,
a
implementation
in
node.
That
is
one
that
we'd
no
longer
use
and
things
got
quiet
for
around
a
year
and
finally,
miles
started
up.
The
modules
working
group,
as
some
contention
came
up
on
social
media,
about
the
implementation
that
we
did
land
and
we
spun
up
the
modules
working
group.
B
This
is
around
the
time
that
MPM
made
a
counterproposal
to
the
node
implementation
of
the
time
and
there
were
other
proposals
starting
to
show
up
as
kind
of
these
counter
proposals
after
we
landed
something
in
node
and
so
from
these
counter
proposals.
For
around
2
years
ago.
Until
now,
we've
had
this
working
group
going
and
trying
to
agree
on
what
we
are
going
to
ship
instead
and
so,
like
Miles
said
in
13.2,
we
unflagged
a
new
implementation.
B
It
uses
a
decent
amount
of
that
older
implementation,
but
it
has
a
different
user
experience
and
so
that's
how
we
got
where
we
are
today
and
now
with
the
working
group.
We
have
meetings
quite
often
and
we
are
landing
pr's
they're
open
on
node
right
now.
We
try
to
keep
them
somewhat
contained
and
small,
so
yeah.
If
you
want
to
participate
it's
much
easier
than
it
was
in
the
past
and.
C
Just
to
add
something
that
the
implementation
that
was
in
flag
and
13.2
first
landed
in
1200,
some
of
the
like
latest
parts
of
like
very
newest
additions
to
it.
I
think
are
probably
only
in
the
13
line.
But
if
you
use
node
12
and
up
with
the
experimental
modules
flag,
that's
essentially
the
same
implementation
as
what
eventually
got
flat
unflagged
in
the
current
nodes.
C
A
So
there
is.
This
is
crc
number
75
on
npm,
which,
which
is
an
RC
for
a
feature
that
should
come,
the
user
for
a
module
type
been
initiating
initializing,
sorry,
an
NPM
module.
So
what
what
do
you
people
think
about
what
the
what
the
expected
workflow
is
here?
Is
there
any
interesting
work
going
on
in
the
two
men
side
of
things
to
make
things
easier
as
adoption
growth.
B
I
can
kind
of
speak
to
this
a
little
bit.
So
one
of
the
key
things
that
you
mentioned
here
is
it's
about
tooling
support,
so
node
historically
hasn't
made
any
recommendations,
while
we've
had
these
flagged
features,
but
now
that
we
have
unflagged
a
that
type
field
in
package.json
in
the
13
line,
we're
going
to
see
a
situation
where
different
tools
may
have
different
opinions
on
what
they
want
to
do.
I
I
feel
personally
that
in
the
future,
all
tools
should
set
the
field
to
some
value
type.
B
The
type
field
I
feel
the
type
field
should
pretty
much
always
be
populated
in
the
future,
by
tools
but
I
don't
have
a
strong
preference
on
what
the
fields
value
should
be.
I
think
that's
up
to
an
individual
tool
and
if
we
ever
add
more
values
to
that
field,
it
may
change
over
time
what
we
recommend.
That's
it
and.
C
And
something
that's
probably
worth
pointing
out
I
feel
like
the
one
of
the
things
that
people
are
confused
about
this
so
or
why
they're
asking
is
because
they're
like
well.
Why
should
I
set
a
type
field
if
I'm
gonna
have
multiple
types
in
my
package,
like
I'm
gonna
ship
in
ESM
version
and
I'm
gonna
ship,
a
comedy
version,
a
package
can
contain
multiple
package
that
JSON
files-
that's
always
been
the
case.
So
if
you
are
shipping
multiple
artifacts,
you
could
have
like.
C
You
know
a
top-level
package
of
Jason
that
with
a
type
field
that
controls
whatever
you
want
at
the
top
level.
You
know
that
the
root
folder
of
your
package
and
then,
if
you
have
a
subfolder
like
comment,
yes,
another
subfolder
called
yes
model.
Each
of
those
folders
can
have
a
type
of
package,
a
jason
with
the
type
field
itself.
So
you
can
be
more
specific
in
like
describing
the
the
things
within
your
package.
A
That's
great,
thank
you,
so
much
I
believe
we're
gonna,
see
more
and
more
people
fiddling
with
doing
in
this
area
as
we
get
more
and
more
usage.
Actually
talking
about
usage.
Now
that
modules
and
exports
is
unflagged,
we
should
be
able
to
see
the
first
relative,
first-time
relative
usage
of
type
module
that
we're
just
talking
about
versus
the
infamous
dot
MJS
extension.
So
the
question
person
who
submitted
the
questionnaire
asked
do
we
have
any
relevant
statistics
here
and,
if
not,
will
someone
be
collecting
this
information
to
inform
future
modules
development?
A
E
Yeah
I
can
take
a
stab
at
this
one
right,
so
it
is
kind
of
real-time
from
the
outside.
Looking
in
to
see
that
note
basically
has
two
different
solutions
to
how
do
I
tell
note,
but
this
file
isn't
years
module
right.
So
this
you
can
use
type
module
in
penetration,
and
then
you
have
your
adoption
s.
Files
that
belong
to
that
package,
chasten
be
treated
as
an
es
module
or
you
can
call
your
individual
files,
dot,
mgs
and
no
matter
what
happens
outside
of
those
files.
They
will
always
be
treated
as
use
modules.
E
The
reason
why
we
have
those
two
solutions
is
because
right
now
nobody
knows
which
of
those
two
will
actually
work
out,
and
it
is
very
likely
that,
depending
on
what
kinds
of
tools
somebody
is
using
or
what
kind
of
existing
code
they
have,
one
of
the
solutions
will
work
and
the
other
will
not,
or
vice
versa,
so
I
think
the
short
answer
is
a
yes.
We
are
definitely
monitoring
usage
and
try
to
keep
a
tab
on
what
people
are
actually
doing
and
what
different
tools
support.
E
So
what
will
likely
happen
is
that
tools
will
add
support
for
both
and
people
will
use
what
works
for
their
projects
and
right
now,
even
though
there
is
a
handful
of
packages
that
might
have
tried
it
out,
we
are
definitely
far
away
from
any
kind
of
significant
numbers
that
we
could
look
at
it
like
if
point
zero,
zero
one
percent
of
the
NPM
registry
downloads
using
one
or
the
other
and
one
is
double
the
other.
It
doesn't
really
mean
anything
right.
It's
not
statistically
significant
that
there
is
a
big
difference.
E
B
B
So
what
we've
been
doing
is
using
some
source
code
tooling.
Historically,
we've
only
really
had
MJS
as
something
that
we've
seen
on
the
registry,
so
we're
starting
to
see
type
module
stuff
show
up
on
the
registry
these
days,
but
there
are
other
things
to
consider
as
well.
I,
don't
think
many
people
are
going
to
be
transitioning
from
the
current
bundler
tool
chains
or
compiling
of
typescript
to
JavaScript
transpiling
via
babel.
B
All
this,
and
it's
really
going
to
be
interesting
as
people
migrate,
not
just
if
they're
going
to
be
using
MJS
or
type
module,
but
if
they
are
going
to
move
off
their
compiler
tool
chains
as
well,
so
with
compiler
tool
chains.
You
get
to
an
interesting
scenario
where
what
you
publish
may
be
something
that's
in
a
different
format.
B
Then
what
is
actually
run
by
node
and
what
I
mean
is
you
may
push
some
language
up
to
the
registry
and
it
may
be
typescript,
but
typescript
could
be
compiled
theoretically
to
either
of
these
directions,
and
so
you
get
into
a
situation
where
we
have
to
monitor,
not
just
which
of
these
solutions
is
used,
but
kind
of
what
the
ecosystems
that
generate
them
is.
So
there's
going
to
be
kind
of
an
ecosystem
thing
where
we
have
to
monitor
not
just
what's
out
there,
but
what
people
are
using
in
their
tool
chains
as
well.
D
How
do
you
refer
to
common
j
s
and
that's
where
CJ
s
comes
in?
You
know
personally,
I
think
that
there's
always
value
in
in
being
explicit
here,
so
you
know,
I,
don't
see
kind
of
either
going
anywhere.
An
ecosystem
support
for
MJS
is
getting
better.
There's
work
that
we've
been
ongoing,
work
that
we've
been
doing
with
the
IETF
to
standardize
it.
The
extension
is
now
supported
in
the
Python
mime
type
database.
D
You
know
the
friction
that
people
would
have
had
when
starting
to
use
it
a
couple
years
ago.
No
longer
is
as
much
of
an
issue
now
I
understand
that
people
have
aesthetic
concerns
or
personal
concerns
with
it,
and
we
tried
as
much
as
possible
in
the
new
implementation
to
make
it
so
that
folks
can
make
decisions
based
on
what
they
want
to
have
for
myself.
C
Yeah
and
I
would
just
add
to
that:
it's
not
either/or,
like
you
know,
that's
kind
of
why
we're
all
we're
encouraging
all
users
to
add
the
type
fields,
regardless
of
what
their
extension
they
use,
because
you
can
have
type
module
and
use
MJS
extension
in
your
files,
so
that
just
provides
two
signals
to
tooling
about
what
your
intentions
are
and
that
you
know
can
only
be
a
good
thing.
I
think
like
in
node,
will
probably
support
both
indefinitely
and
in
terms
of
what
becomes
more
prevalent.
I.
C
So
likewise,
though,
like
there
are
going
to
be
tools
that
have
trouble
using
the
type
field,
because
they're
not
set
up
around
looking
for
metadata
in
a
separate
file
outside
the
file
itself.
So
these
are
the
issues
that
we
have
I.
Think
it's
going
to
depend
on,
like
whatever
your
tooling
situation
is
whatever
tools
you're
trying
to
use
with
your
project.
They
might
have
different
needs
in
terms
of
what
they're
looking
for
and
what
they
support
and
so
from
nodes
perspective.
Nodes
will
will
want
to
provide.
C
A
Perfect,
thank
do
so
much
everyone
for
sharing
your
thoughts
and
experiences
on
this
I,
just
like
to
remind
our
YouTube
audience
that
please
feel
free
to
submit
any
questions
this.
It's
not
usual
for
this
group
to
take
questions
like
this.
So
it's
really
interesting
to
hear
all
these
things
and
and
give
the
concerns
of
the
community
now,
especially
now,
as
you
mentioned,
that
ESM
isn't
flat
when
you're
using
it
everywhere.
So
yeah
we'd
love
to
hear
your
questions
to
move
on
with
the
conversation.
Actually,
this
is
super
interesting.
A
This
is
something
that
just
occurred
to
me
so
I
just
and
aesthetically
direct
the
specially
directing
this
two
miles.
Of
course,
each
of
you
can
chime
in
mazi
if
I'm
not
incorrect,
you're
working
on
this,
you
tc39
proposal
called
module
attributes
which
adds
modular
tickets
to
to
deafness,
trip
right,
and
it
allows
people
to
import
essentially
JSON
modules
and
HTML
modules
and
stuff,
like
that.
So
I've
I've
been
wondering
what
how
can
it
correlate
if
it,
if
at
all,
with
no
GSM,
and
does
it
have
any
interesting
thing
in
store
for
how
we
approach?
D
Yeah
so
bit
of
history
here
so
last
year,
I
opened
an
issue
over
on
the
HTML
spec
about
JSON
modules.
So,
as
mentioned
earlier
on,
in
this
conversation,
one
of
the
one
of
the
kind
of
driving
goals
of
the
ESM
implementation
and
node
with
the
current
team
is
whether
interoperability
and
so
node
historically
has
the
ability
of
bringing
in
a
whole
bunch
of
different.
D
Module
types,
so
you
can
require
not
only
you
know,
a
common
chance
module,
but
you
can
require
JSON.
You
can
require
doc
node,
which
are
no
native
modules.
Json
is
one
in
particular.
That
is
a
really
really
great
user
experience
and
one
of
the
amazing
things
that
we've
been
seeing
happen
in
the
last
little
bit
with
the
modules
team
is
user
experience
from
node
affecting
web
standards.
This
is
what
we're
seeing
with
import
Maps,
which
is
something
that
we
can
talk
about
later.
That
allows
bear
imports
in
the
browser.
D
So
that's
the
ability
like
import,
low,
excuse
me
and
the
environment
then
knows
to
find
that
a
node
modules
folder
this
is
kind
of
an
invaluable
user
experience
and
and
requiring
JSON
is
one
of
those
in
the
browser.
Today.
If
you
want
to
take
some
JSON
and
get
it
into
a
module,
you
need
to
use
the
fetch
API.
You
need
to
then
fetch
the
resource.
You
need
to
then
wait
to
get
the
response.
D
Then,
with
the
response,
you
need
to
call
dot
JSON
and
then
you
get
it
and
you've
gone
through
two
different
promises
and
you
only
have
the
value
asynchronously
and
you
know
that
is
less
than
desirable.
There
is,
if
you're
fetching
something
that's
based
on
like
the
route,
then
you
also
need
to
use
import
meta
to
get
the
URL
a
there's,
a
lot
of
steps
that
you
need
to
go
through
as
compared
to
import
thing
JSON.
So
the
feature
was
requested
in
the
HTML
spec.
D
Another
thing
with
JSON
modules,
in
the
reason
it
was
pushed
for,
is
because
there's
a
number
of
other
module
types
that
we'd
love
to
see
be
able
to
be
imported,
including
CSS
modules,
HTML
modules,
web
assembly
modules
and
JSON
modules
were
identified
as
a
module
type
where
the
behavior
was
not
very
controversial.
So
you
know
we
could
focus
more
on
implementation
details
to
figure
out
what
like
blockers
would
be
for
all
these
various
module
sites.
D
This
security
concern
being
one
of
them,
so
the
module
attributes
proposal,
which
is
currently
stage
one
at
TC
39,
is
one
attempt
to
solve
this.
It
is
a
stage
one
proposal,
which
means
that
the
committee
has
agreed
to
exploring
the
problem
space
but
has
not
agreed
on
the
shape
of
the
solution,
nor
has
agreed
that
this
necessarily
will
land
in
the
specs.
So
this
is
still
very
much.
You
know
up
in
the
air.
The
module
attributes
proposal
will
allow
you,
when
importing
a
module,
to
give
additional
metadata
to
what
the
module
is
so
exact.
D
What
that
metadata
exactly
is
and
how
it
syntactically
works
has
not
been
agreed
upon.
One
type,
syntax
it'd
be
like
import.
Think
JSON
as
JSON
would
be
one
potential
syntax.
So
an
extra.
Actually,
you
have
the
end
to
let
the
environment
know
what
type
of
module
it
is.
This
would
be
considered
in
banned
metadata
to
support.
You
know
some
sort
of
enhanced
validation.
D
And
then
you
know
inventors
that
would
be
node
or
chrome
or
environments
that
embed
the
JavaScript
language
would
be
able
to
pick
any
number
of
potential
attributes
that
they
may
want
to
see
verified
or
extra
data
that
the
module.
This
is
still
one
of
the
things
that's
being
debated
by
the
group
now
how
this
affects
nodes.
Esm
implementation
is
with
our
hope,
to
have
with
interoperability.
D
We
do
not
support
by
default
importing
JSON.
You
need
to
actually
give
a
flag
for
experimental
JSON
modules
and
the
implementation
that
we
have
under
experimental
JSON
modules
is
based
on
the
now
reverted
HTML
spec
that
had
those
security
concerns.
Now
where
this
becomes
interesting
for
node
and
I'm
sure
Brad,
who
has
their
hand
up
could
add
to.
This
would
be
that
you
know
the
concerns
that
we
have
right
now.
D
Security
wise
for
the
web
platform
doesn't
necessarily
apply
to
node,
and
this
is
one
of
the
ongoing
challenges
that
we
have
in
our
module
system,
which
is
like
what
user
experience,
concerns
or
limitations.
Should
we
have
on
the
implementation
in
note
that
our
browser
specific
concerns
to
better
support
interoperability
between
the
environments?
On
the
flip
side?
You
know
what
concerns
and
changes
should
the
browser
side
make?
You
know
because
of
server
side
concerns
and
we're
always
kind
of
blocking
that
line
of
interoperability
and
user
experience
and
trying
to
find
a
balance,
at
least
for
myself.
D
Selfishly
I
would
love
to
see
the
two
environments
as
much
as
possible.
Be
interoperable
and
I
am
personally
willing
for
to
see
a
little
bit
of
developer
experience
concessions
in
the
name
of
interoperability,
but
I
know
that
we
do
not
have
complete
consensus
within
the
modules
team
around
this
Brad.
Is
there
anything
you'd
like
to
add
to
that
yeah.
B
But
there's
just
a
few
key
things
here.
One
is
when
we're
talking
about
these
security
concerns.
We're
not
specifically
talking
about
loading
JavaScript.
Being
the
only
concern
we're
talking
about
executing
code
being
a
concern
here,
so
the
way
that
es
modules
were
specified.
They
were
never
meant
to
only
load
JavaScript,
which
is
interesting
way
back
in
2015
when
it
landed.
Every
kind
of
es
module
actually
inherits
from
an
abstract
module
record.
B
B
B
One
thing
to
note
here
is:
although
we've
been
talking
about
the
potential
for
checking
the
type
of
a
dependency,
that's
not
the
only
thing
that
the
module
attributes
proposal
is
really
able
to
do
so.
There's
a
variety
of
other
constraints
that
exist.
Things
like
in
the
service
worker
world
for
the
browser
they're,
considering
preventing
people
from
using
top
level
of
weight
when
you
first
load
a
Service
Worker,
because
it's
a
problem
for
the
browser
there
as
well,
so
you
could
see
more
attributes
show
up.
B
B
Excuse
me:
basically,
what
we've
got
here
is
a
very
generic
proposal
that
isn't
purely
about
any
sort
of
conflict
between
the
browser
node,
but
about
how
we
can
use
all
this
metadata
in
different
ways.
We've
been
talking
about
the
module
attributes
proposal
in
tc39
as
an
end
band
way
of
doing
all
this.
There
has
also
been
some
discussion
of
doing
it
out
of
band,
so
their
ups
and
downs
of
doing
it
either
way.
B
E
Also
thinks
yeah
what
I
was
quickly
gonna
say
is
when
I'm
always
a
little
bit
uncomfortable
with
is
phrasing
it
as
a
conflict
between
browser
and
node.
In
some
cases,
this,
in
some
cases
it
generally
is
something
it
only
applies
to
the
browser
and
something
at
only
applies
to
node
and
that
he
needs
to
be
sub
made
some
kind
of
trade-off.
E
So
it's
not
necessarily
a
browser
concern
it's
more
a
any
kind
of
engine
that
fetches
from
a
potentially
untrusted
third
party
concern,
and
so
and
at
the
same
time
concerns
around
polyfill
ability,
like
the
ability
to
support
browsers
that
don't
support
what
have
not
support
added
yet
for
new
module
types
is
something
it
applies
through.
The
browser
and
get
also
to
some
degree
then
applies
to
note
that
quotes
are
bought.
E
If
you
have
an
attribute
as
CSS,
you
load
that
module
in
a
browser
doesn't
have
support
for
CSS
modules,
yet
the
server
cannot
provide
a
polyfill
as
a
JavaScript
module
because
it
would
be
rejected
by
another
browser,
potentially
or
rather
because
most
likely,
the
browser's
are
not
supporting
s
CSS,
which
is
completely
reject.
The
whole
thing,
so
I
think
that
some
of
these
concerns
are
more
about
capabilities
of
the
engines
and
not
necessarily
the
engines
themselves
being
fundamentally
at
odds
in
what
their
goals
are.
D
D
So
a
great
example
of
this
is
like
sub
resource
integrity,
so
sub
resource
integrity.
From
for
a
module
you
can
supply
like
an
md5
or
a
shot
to
five
of
six
of
the
source
that
you're
importing
and
on
the
surface.
This
would
seem
like
a
really
great
thing
to
be
able
to
provide
in
line
if
you're
importing,
especially
you
know
like
if
you're
on
brow
and
a
browser
and
importing
a
resource
over
the
network.
D
Now
one
of
the
challenges,
though
there
would
be
this-
isn't
super
scalable
if
you
have
a
large
graph
and
you're,
including
resource
integrity,
for
every
single
module
inside
of
your
graph,
and
then
you
have
a
single
cycle,
you
can't
really
resolve
including
inline
subbers
resource
integrity
with
cycles
and
graphs.
You
just
it's
not
possible,
then
further,
like
the
second,
that
one
thing
in
your
graph
changes
that
propagates
through
the
whole
graph.
D
So
you
know,
including
sub
resource
integrity,
is
something
that
had
been
discussed
at
the
committee
and
you
know,
chrome
was
not
very
in
favor
of
it.
Now
we
could
see
a
world
where
one
JavaScript
runtime-
and
this
doesn't
even
mean
a
browser.
This
could
be
denno.
This
could
be
node.
This
could
be
a
new
runtime
decides
to
introduce
a
new
attribute
for
sub
resource
integrity.
D
Now,
what
do
other
environments
do?
Do
they
throw
on
sub
resource
integrity
existing?
If
it's
not
an
attribute
that
they
support?
Do
they
even
need
to
know
that
it
exists?
If
people
start
publishing
code
that
has
sub
resource
integrity
in
line
there?
You
would
expect
that
it's
validated
to
some
extent
you
don't
want
the
code
just
running
and
ignoring
it,
and
so
this
creates,
like
a
just
one
example
of
a
really
weird
mismatch
that
could
exist
between
different
environments.
So
to
myself
this.
D
This
is
a
concern
that
I
have
with
the
attributes
proposal,
specifically
that
things
could
become
inconsistent
between
environments
and
being
consistent
in
a
way
that
can
either
be
wrong
or,
at
worst
problematic.
Don't
have
an
answer
to
that.
Don't
know
if
this
is
even
a
concern.
That's
large
enough
to
stop
that
from
happening,
but
it
is
something
that
I
think
various
and
better
is
such
as
you
know,
Chrome
or
WebKit
or
node
need
to
actively
be
thinking
about
how
coordination
around
these
attributes
would
work.
B
So
this
is
like
step
back
yawns
point
a
little
bit,
so
we
have
actually
discussed
in
case
people
are
wondering
what
it
would
take
to
load
HTTPS
in
node
I.
Think
that
leads
into
a
another
question,
but
I
just
want
to
like
try
to
table
all
the
security
discussion
about
doing
so.
There
are
a
few
documents
if
people
want
to
dig
them
up
about
security
models
for
remote
code,
loading
for
node,
but
maybe
that's
better
on
a
different
call,
because
that'll
eat
up
a
lot
of
our
time.
So
yeah
thank.
C
Just
a
few
days
ago,
we
landed
a
PR
for
support
for
the
loaders
in
yes,
module
which
are
still
very
much
a
work
in
progress
and
experimental
and
will
changed
significantly
between
where
they
are
now
and
when
they
eventually
get
unflagging.
But
one
of
the
examples
that
we
were
playing
with
and
that
we
put
in
the
docs
is
a
loader
that
just
enables
this
of
loading
a
module
from
an
HCP
URL,
and
you
know
I
wrote
the
docs
for
this
and
one
of
the
things
I
wrote
it
was
like.
A
Yeah,
thank
you
very
much
and
thanks
everybody
else.
Also
for
this
amazing
discussion.
The
only
unfortunate
problem
is
that
you
all
used
all
the
wrong
words
on
tape,
and
you
talked
about
Dino
insecurities
and
integrity
and
everything
so
moving
on.
Are
there
any
plans
for
loading
a
module
from
a
fully
qualified
URL,
as
dean
orders
or
as
ESM
does,
for
example,
and
adding
on
to
that
my
own?
A
E
Sorry
yeah
I
mean
the
the
the
quick
cop-out
answer
to
the
question
as
phrased
is
you
can
load
from
a
fully
qualified
URL
today?
It
just
happens
to
be
a
file
here
well
file
protocol
URL,
so
we
definitely
set
up
the
whole
module
system
in
a
way
that
it
is
based
on
your
Al's
and
for
people
who
are
we're.
Conscious
is
definitely
not
based
on
your
else.
Conscious
is
based
on
five
pounds
and
platform-specific
file
paths
and
file
names
that
can
contain
characters
that
make
it
look
like
URL,
even
though
it
is
a
5s.
E
E
So
if
you
need
a
flag
or
not,
but
you
can
generally
import
from
a
data
URL,
you
can
use
data
URL
import
that
and
it
works
so
regretting
it
just
confirms
no
flag
needed
for
the
data
URLs
anymore,
so
we
generally
want
it
to
enable
other
kinds
of
protocols,
for
example
HTTP
in
the
future.
So
the
reason
that
it's
not
done
yet
is
that
as
Brad,
he
kind
of
hinted
at
the
exact
details
of
what
it
would
do.
E
Definitely
uncertain
just
because
nobody
really
knows
what
it
could
mean
for
node,
two
out
of
the
box,
allowing
you
to
load
code
from
random,
HTTP
URLs
and
immediately
execute
it,
especially
things
like
the
Namek
import,
make
it
interesting
what
happens
in
those
cases,
because
it's
no
never
used
to
do,
and
so
people
are
rightfully
curious
what
it
would
mean
for
node
and
but
yeah.
Generally
speaking,
it's
not
ruled
out
that
it
might
become
a
built-in
capability
at
the
future
as
far
as
I
know,
at
least
and
as
Jeff
drop
really
kind
of
hinted
at
it's.
B
Yeah
I
just
wanted
to
kind
of
second
that
so
like
beyond
was
saying.
The
new
ESM
based
system
for
loading
modules
actually
is
fairly
different
under
the
hood
and
how
its
storing
modules
it
is
not
reusing.
Some
of
the
features
that
people
have
historically
seen
like
using
required
cache.
It
actually
has
an
entirely
different
store
based
upon
the
URL
that
a
module
is
located
at.
B
So
there
is
in
some
way
the
ability
for
you
to
kind
of
fudge
things
with
require
doc
cache
right
now
in
ways
you
can't
for
modules.
So
what
we're
working
on
really
recently
is
making
new
pr's
adding
features
to
these
experimental
loaders
in
order
to
get
their
usability
and
feature
set
up
to
the
point
where
we
are
comfortable
moving
forward
with
them.
I
think
that's
gonna,
be
probably
our
priority
over
trying
to
make
a
massive
push
to
get
all
the
security
aspects
considered
for
loading
HTTPS.
B
So
we've
had
some
discussions
in
the
past
about
loading,
different
HTTP
or
HTTPS
modules
off
the
network.
There's
been
a
few
things
in
the
security
working
group.
A
few
documents
about
this,
but
really
the
sense
I've
gotten
from
every
discussion
there
is
they
would
need
to
use
some
sort
of
policy
feature
in
order
to
lock
them
down
for
you
to
use
them
by
default.
B
People
are
very
concerned
with
loading
things
off
the
network
if
you
cannot
verify
what
you're
going
to
be
od.
This
is
kind
of
in
the
same
vein
is
what
we
were
talking
about
with
module
attributes
where,
if
you
load
something
off
the
network-
and
it
does
something
different
from
what
you
expect
that
can
be
problematic.
In
particular,
this
is
really
a
concern
for
node.
Node
has
a
different
architecture
than
Dino,
so
node
actually
runs
in
a
single
process.
Dino
does
not
so.
Isolation
is
a
big
concern
for
node.
B
B
D
Yeah
one
small
thing,
I'd
love
to
add
to
this
and
I
think
it's.
You
know
a
great
example
of
why
interoperability
can
help
us
in
ways
that
are
unexpected.
You
know
moving
forward
with
the
module
attributes
proposal
and,
if
node
adopts
it
independent
of
whether
or
not
no
today,
you
know
me
needs
all
the
benefits
that
come
from
it.
D
Json
modules
means
that
if
you
know
node
follows
suit
and
this
gets
standardized
that
if
we
do
eventually
introduce
HTTP
or
the
ability
to
fetch
resources
over
the
network,
we've
kind
of
built
in
some
of
that
security
model
by
it
by
adopting
these
features,
I
think
this
is
just
a
good
thing
to
keep
in
mind
when
we're
thinking
about
like
hey,
you
know:
does
this
or
does
this
not
benefit
node?
It
can
you
know
future
proof
for
some
design
space.
D
B
Just
to
clarify
we're
not
talking
about
node
and
web
browsers,
sharing
the
same
security
model
because
we
pretty
much
know
we
can't
do
that.
We're
talking
about
reusing
the
same
infrastructure,
potentially
the
same
kind
of
feature
set
to
give
that
configuration
the
node
may
want,
or
the
browser's
may
want
in
different
scenarios,
so
yeah
I
totally
agree.
We
could
come
up
with
something
that
said:
module
attributes
a
stage
one,
let's
not
hop
on
any
bandwagon
until
we
get
a
little
bit
more
design
discussion
on
that
one,
but
yeah
definitely
feel
like.
A
Thank
You
Bradley
and
miles
for
the
amazing
insights.
Actually
now
the
beer
nearing
the
end
of
the
EMA
I'd
actually
like
to
highlight.
It's
really
actually
interesting
and
I
actually
take
a
lot
of
pride
in
this
that
we
talked
a
lot
about
tc39
stuff
today
and
also
given
the
fact
that
out
of
five
people
in
the
panel
today,
I'm
not
sure
about
Joffrey
and
yen,
but
at
least
the
three
of
us
have
been
more
heavily
involved
in
DC
39,
at
least
as
a
flake.
A
So
I'd
like
to
point
out
how
you
know
things
have
consistently
improved
when
it
comes
to
the
representation
of
no
js'
depot
inside
of
tc39,
and
the
amount
of
you
know
consideration
that
has
been
given.
You
know,
Jess
at
one
time
in
DC,
39
and
actually
I'd
like
to
hear
everybody's
thoughts
on
that
and
also
discuss
some
of
the
issues
that
we
have
had
in
the
past
when
dealing
with
especially
the
modules
I.
B
Just
like
to
say,
I
think
tc39
is
much
better
about
getting
feedback
from
its
the
ecosystem.
These
days,
I
know
I
joined
tc39
and
GoDaddy
paid
for
it,
since
its
cost
membership
based
upon
modules,
I
think
the
ecosystem
feedback
is
so
credible
nowadays
that
we
probably
wouldn't
encounter
the
same
sort
of
scenario
anymore,
especially
with
the
stage
system
in
place.
F
A
Yeah,
indeed,
thank
you
all
for
your
time
and
a
special
thank
you
to
all
our
listeners
for
the
amazing
questions
and
also
for
being
involved
in
the
community,
I'd
like
to
come
to
everybody
to
everybody,
who's
interested,
especially
in
node.js
and
at
my
shop
modules,
to
help
out
in
the
modules
working
group,
the
mock
modules
working
group
has
been
accepting
new
people
as
observers
and
eventually,
as
members
of
the
working
group.
So
that's
a
great
thing
to
work
on
and
and
I'd.