►
From YouTube: Node.js Foundation Modules Team Meeting 08-26-2020
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
Okay,
we
are
now
live
on
youtube
with
the
august
26th
edition
of
the
node.js
modules
team.
We
have
six
people
on
the
call
today
and
a
pretty
full
agenda,
so
let's
just
get
right
to
it.
The
first
thing
that
we
have
on
here,
which
we're
putting
in
the
announcements
section,
is
christopher
hill
who's.
Hillary
has
joined
us
today
with
some
questions
regarding
a
twitter
thread
last
week.
Chris,
would
you
like
to
kick
it
off.
B
Sure
so
I
just
wanted
to
bring
up
something
that
that's
been
been
tossed
around
before
and
it's
still
kind
of
an
issue,
and
that
is
doing
module
level
mocking
in
in
tests
using
esm
and,
of
course,
with
the
common
js
and
requires,
and
the
cache,
and
all
that
you
can
do
this
sort
of
thing
pretty
dynamically.
B
There
are
modules
out
there
like
proxy
choir
or
rewiremock,
or
even
maybe
back
in
the
day
re.
I
think
rewire,
and
they
do
this.
This
sort
of
thing
they
work
with
with
com.js
it's
nice
to
be
able
to
just
kind
of
swap
out
a
module
and
and
just
just
kind
of
mock
it
and
for
you
know,
isolation
purposes,
and
you
know
esm
kind
of
makes
this
difficult.
B
Now
there
are
I've,
seen
a
couple
loader
implementations
out
there
that
allow
you
to
do
this
sort
of
thing
I
haven't
had
time
to
to
play
around
with
them,
so
I'm
not
sure
exactly
how
sufficient
they
are.
B
But
I
know
that
there's
at
least
one
challenge
where
it's
it's
the
requirement
of
of
how
to
of
using
the
loader
flag
at
all,
because
we
don't
necessarily
know
if
we're
going
to
start
mocking
things
or
when
we're
going
to
mock
things,
and
we
don't,
and
you
know
a
as
it's
implemented
now
you
can
only
have
one
loader
right,
and
so,
if
you
want
to
use
two
loaders,
maybe
you
want
to
use
something
that
I
don't
know.
B
I
don't
know
what
people
use
loaders
for
typescript
or
something
right,
and
you
want
to
have
that
loader
and
then
you
want
to
have
this
other
loader.
That
does
the
mocking
for
you.
Well
you're
not
going
to
be
able
to
do
that,
because
there's
only
one
single
loader
now
I
understand
there's
something
in
the
works
or
being
considered
about
like
chaining
loaders,
which
would
help
still
that
kind
of
puts
a
lot
of.
B
It
may
need
to
start
spawning
a
sub
process
every
every
for
all
tests,
even
if
you
don't
specifically
want
to
use
the
this
loader,
because
the
only
way
to
get
it
at
all
I
mean
it's
like
mocha
would
have
to
like
install
it
by
default
or
you
would
have
to
use
node
and
then
a
loader
and
then
mocha
and
it
just
it
becomes
not
very
ergonomic
or
ergonomic,
but
it
would
be
cool.
B
Just
like
pie
in
the
sky
is
if
there
was
a
way
to
use
a
loader
and
and
just
like,
do
it
from
code
and
say:
okay,
hey!
I
want
to
load
this
this
year
module,
but
I
want
you
to
use
this
particular
loader.
I
don't
want
to
have
to
go
in
and
add
a
loader
flag.
Every
time
that
can
be
difficult,
I
don't
know,
might
be
able
to
work
around
it.
B
As
I
said,
you
could
spawn
sub
processes
and
make
that
happen
and
mocha
does
things
like
this,
but
it
doesn't
want
to
necessarily
if
it
doesn't
need
to.
So
it's
just.
It's
just
kind
of
awkward,
and
I
saw
that
and
I
wonder
if
there's
a
gist
url,
that
guy
pasted
in
the
chat
can
get
into
the
the
minutes,
but
I
haven't,
I
haven't,
had
a
chance
to
look
through
this
thread
with
mateo
and
guy
here,
but
it
sounds
like
he
was.
B
B
Are
there
things
going
forward
that
or
you
know,
coming
down
the
pipe
that
may
make
this
left
less
difficult
for
for
people
to
do,
or
would
you
know
something
like
a
programmatic
api
to
enable
a
loader
just
be
like
completely
not
feasible,
or
would
it
be
a
security
risk
or
or
what
have
you,
and
so
I
just
kind
of
want
to
understand
what
what
the
modules
team's
feeling
is
about
this.
B
This
sort
of
thing-
and
you
know
if
they
foresee
you
know
a
solution
to
make
it
more
like
what
we
had
with
with
common
js,
because
I
mean
there's
really
no
other
way.
To
put
it.
It's
just
that
it's
the
the
experience
is,
is
kind
of
downgraded
and
I
realize
that's
because
of
the
spec
right.
The
spec
is
is
not
wanting
you
to
to
do
all
sorts
of
loosey-goosey
things,
but
it's
something
that
you
know.
B
A
Anyone
have
anything
to
add
here.
B
So,
okay,
let
me
just
ask
a
question,
so
is
it
possible
at
some
point
to
do
something
like
enable?
I
don't
know
what
the
loader
flag
does
under
the
hood,
but
I
want
to
specify
let's
use
this
loader
and
I
want
to
do
that
in
the
script
instead
of
on
the
command
line.
Is
that
possible
to
add
some
sort
of
api
in
node
to
do
this
and
if
it's
possible,
but
it's
undesirable?
Why
is
it
undesirable.
C
I
feel
like
bradley
has
the
answer
to
that
question.
There's
definitely
some
security
concerns,
although
I
I
feel
like
those
would
be
addressed
through
policies
rather
than
forcing
people
to
use
flags.
B
C
Oh,
I
remember
the
last
time
we
talked
about
this
and
someone
I
feel
like
I'm
not
saying
this
very
well.
So
if
someone
else
is
on
the
call
or
remember
is
better
than
me,
please
tell
me
tell
me
to
shut
up
and
explain
this
better,
but
the
the
reason
I
remember
being
brought
up
was
at.
As
of
now
we
don't
have
like
package
scoped
loaders.
C
So,
like
you
know,
how,
like
the
type
field
is,
follows
our
package
scope
like
it
applies
to
that
package
and
any
subfolders
under
that
until
you
find
the
next
package,
if
we
allowed,
you
know
loaders
through
configuration
files,
say
the
obvious
place
to
put
that
configuration
would
be
in
package.json.
We
don't
really
have
any
other.
I
mean
there's
policies.json,
I
guess,
but
there's
there,
I'm
not
aware
of
any
other,
like
node
config
files
that
we
have
at
the
moment.
C
So
if
it
were
to
be
in
package.json,
then
the
question
would
be
like
well
now.
Is
it
on
a
per
package
level
like
a
particular
child
package,
could
load
say
the
typescript
loader,
but
that
would
only
apply
to
that
package
and
then
how
do
we
enforce
that
it
gets
messy
if
it's
not
package
scoped,
then
it's
sort
of
like
we
have
to
introduce
the
concept
of
there
being
like
the
root
package.json,
which
is
like
you
know,
where's
the
main
entry
point
for
the
node
process.
C
What's
the
controlling
package.json
for
that
main
entry
point,
what
does
it
have
defined
as
what
loaders
should
be
loaded
and
then
those
get
loaded
to
the
application?
But
the
problem
there
is
that
well,
if
you're
already
doing
all
that
then,
like
you
could
put
in
your
npm
start
command
for
running
your
node
program.
Whatever
flags
you
want,
so
it's
really
like
what
you're
asking
for
is
like
a
per
package
based
loaders
and
I
think
that's
had
resistance
in
the
past.
B
It
wouldn't
be
per
package,
it
would
be
like
per
module.
A
So
so
just
I
I
want
to
interrupt
for
a
second
just
from
a
timing
perspective.
This
was
not
something
that
was
put
on
the
agenda
before
and
we
do
have
quite
a
few
other
items
on
the
agenda
and
we're
already
at
almost
20
minutes
past
the
hour.
Guy
has
their
hand
up
and
wes
also
pointed
out
something
for
debugger
dot
set
script
source
that
potentially
could
work
for
modules.
So
I
just
want
to
quickly
check
and
just
let
folks
know,
I
think
we
should
close
this
at
20
minutes
and
then
christopher.
A
If
you'd
like
to
have
further
discussions
about
this
either
a
maybe
add
the
agenda
label
or
or
we
can
add,
the
agenda
label
to
the
hot
reload
modules
issue
that
wes
pointed
out,
or
you
should
open
a
new
as
you
issue
to
discuss.
So
we
can
have
it
on
the
agenda
and
have
it
kind
of
like
fairly
stack
drink
with
the
other
content
that
we
have
to
discuss.
B
Yeah
yeah,
that's
fine!
That's
fine!
I
I
realize
I'm
coming
in
here
and
you
know
taking
taking
your
time,
but
I
want
to
thank
everybody
for
letting
me
do
so,
but
yeah
jeffrey,
but
what
I
mean
by
by
module
is
yeah.
D
I
just
wanted
to
reiterate
the
point
of
order
there,
because
we
do
have
a
standard
process
for
creating
your
gender
items
and
and
managing
these
discussions,
and
there
are
items
on
the
agenda
this
week
that
we're
on
last
week
that
we
had
to
skip
over
because
we
ran
out
of
time
and
now
we've
used
20
20
minutes
of
today's
meeting.
Discuss
topic.
A
Okay,
so
moving
to
the
agenda,
we
do
have
one
item.
I
lowering.
D
I
can
just
add
a
couple
more
things
to
sorry.
I
don't
mean
to
be
rude,
but
it's
just
when,
when
it's
brought
up
to
already
a
third
of
the
meeting
and
then
we're
continuing
to
discuss,
that
was
my
main
sort
of
point
of
order
to
point
to
two
other
things
briefly
on
the
topic.
One
is,
I
believe
marker
does
start
new
processes
already
when
you
run
it
and
the
other
one
is.
D
A
Okay,
thank
you
guy.
The
first
item
I
wanted
to
get
to
really
quickly
is
aderon,
sir,
as
observer.
This
is
an
issue
that
has
been
open
for
18
days,
which
is,
in
my
personal
opinion,
not
very
fair.
A
We
have
got
on
here
five
members
of
the
team
and
plus.
E
John
jeff,
I'm
gonna.
A
Mute
you
no
offense.
We've
got
five
members
of
the
team
who
are
on
this
call
right
now:
jeffrey
guy,
jordan,
west
and
myself
and
with
yon
having
approved
this
pr.
That
makes
six
which
is
cornish.
A
Does
anyone
object
to
us
just
landing
this
and
moving
it
forward,
because
I
we
just
have
not
had
quorum
the
last
couple
meetings,
which
might
be
something
independently
that
we
need
to
follow
up
on
as
a
group,
so
I'd
like
to
just
land
drawns.
So
anyone
have
any
objections.
A
A
Yeah,
jordan,
I'm
gonna
go
through
and
do
something
like
that.
Anyways
and
I
may
also
modify
the
governance
to
set
like
a
two-week
time
box
for
nominations,
so
we
can
come
back
to
that.
So
guy
you
did
mention
that
we
have
things
on
the
agenda
that
we
didn't
get
to
last
week.
I
am
or
two
weeks
ago
I'm
spacing
about
which
specific
ones
they
were
because
they
get
sorted
not
based
on
that
order,
which
item.
D
A
Okay,
so
I
think
with
that
in
mind,
the
modify
esm
experimental
loader
hooks
is
that
one
that
we
can
maybe
skip
for
right
now.
Does
anyone
have
a
problem
with
that
to
just
move
on
to
these
other
agenda
items.
D
A
Skip
the
special
treatment
for
package.json
resolution
and
exports.
We've
talked
about
that
extensively
on
the
last
couple
meetings.
So
how
about
we
table
that
one
for
right
now
and
come
back
to
it?
If
we
have.
A
A
C
I'd
like
to
talk
about
I'll
talk
about
that
one.
I
don't
know
if
anyone.
C
D
Sure,
and
and
thanks
for
joining
jeffrey,
I
was
concerned
if
you
weren't
gonna,
make
it
today
but
yeah
the
maybe
last
week
we
discussed
this
without
you
present
and
we're
running
off
of
the
numbers
that
you've
provided
and
then
also
putting
them
into
context
so
far
as
what
the
criteria
are
considered
for
the
success
of
of
this
kind
of
thing,
and
we
kind
of
came
to
a
sort
of
a
rough
sort
of
point
that
the
the
definition
like
it
seems
like.
D
C
Sure,
okay,
so
the
more
I
look
into
this,
the
more
I
feel
like
you
can
you
can
you
can
basically
define
your
way
into
success
or
failure
essentially
like
if
you
want
this
tiara
to
succeed,
you
can,
as
I've
done,
you
know,
define
success
criteria
that
make
it
work
or
you
can
do
the
or
you
could
do
otherwise.
C
It's
really
like
an
open
question.
You
know
what,
like
whether
users
consider
this
feature
to
be
broken
or
not,
essentially,
is
something
we
aren't.
We
don't
have
a
clear
sense
of
you
know
and
I
like,
if
you
I
would
judge
whether
we're
successful
on
this
is
whether
or
not
like
users
open
tickets
to
the
node.
C
You
know
github
repo
saying
like
oh,
this
is
broken
for
such
and
such
right,
and
so
the
question
is
like:
are
they
going
to
do
that
they're
already
doing
it
for
the
current
default,
only
approach,
so
I
view
the
the
idea
that
we
should
just
do
nothing
to
me
feels
like
a
very
low
like
like
we
could.
We
can
do
better
than
that.
C
Pr
does
do
better
than
that,
so
I
don't
feel
like
we
should
stop
there,
then
the
question
so
what's
the
question
to
me
is
like
they're,
the
fewest
number
of
tickets
are
going
to
get
open,
is
basically
the
most
packages
that
we
can
successfully
detect
these
exports
from,
and
I
I
don't
think
that
there's
much
value
in
like
a
very
bright
line,
clear
definition
of
like
it
works
in
these
cases
and
not
in
these
cases.
Therefore,
your
tickets
are
invalid.
C
I
think
we
should
just
try
to
make
it
work
in
as
many
for
as
many
packages
as
we
can
as
many
cases
as
we
can
and
the
explanation
to
users
is
like
we
make
a
best
effort
attempt
at
static
analysis
for
the
ones
we
can
statically
analyze
and
find
the
names
we
support
it.
Otherwise
we
don't
you
know,
that's
the
best
we
offer
to
you.
If
you
want
it
to
be
sorted,
don't
supported.
The
named
exports
for
a
particular
package
should
be
supported.
C
Don't
complain
to
node
go
complain
to
the
package
author
and
get
them
to
add
an
esm
wrapper
for
your
package
and
that's
kind
of
how
I
would
treat
this
like.
I
feel
like
that's
what
users
would
most
want.
They
wanted
to
work
as
much
of
the
time
as
possible,
so
the
most
we
can
provide
for
them.
We
should
it's
kind
of
how
I
feel
about
it.
Does
that
answer
your
question.
D
Yeah,
I
think
I
mean
it
seems
like
like
you
and
gus,
need
to
have
a
discussion
here.
Further,
possibly
I
mean
have
you
have
you
spoken
with
him
at
all.
C
I
no
I
haven't
had
the
time
and
he
hasn't
reached
out.
I
can
try
to
reach
out
to
him.
I'm
not
going
to
block
this
pr
under
any
version
of
it.
Like
I
don't
think
I've
put
a
blocker
on
it.
I
mean
if
you
can
get
it
to
work
for
es
module
in
a
way
that
satisfies
gus,
then
let's
merge
it
in,
but
I
would
want
it
another
pr
that
goes
further.
C
So
you
know
if
you
can
get
something
that
passes
gus's
test
in
order
to
get
this
pr
merged
in
then
fine
go
for
it,
and
then
you
know
we
can
kind
of
reopen
this
with
the
earlier
code,
and
I
can
haggle
with
him
about
that.
But
I
mean
does
anyone
else
on
the
call
have
have
strong
opinions
either
way
about
this.
I
mean.
C
A
But
I
can
also
see
where
folks
are
coming
from
on
not
being
thrilled
about
like
magic
that
doesn't
work
all
the
time
and
in
fact,
like
that,
potentially
being
worse
for
people
who
don't
know
as
much
like.
So
if
we
step
back
here-
and
it's
like
like,
if
we
think
about
the
specific
developers
that
we
would
be
designing,
this
feature
for-
and
please
correct
me
if
I'm
wrong
or
summarizing
incorrectly.
A
But
I
really
think
that,
like
this
type
of
feature
that
we're
talking
about
creating
is
one
likely
for
developers
who
have
less
familiarity
with
the
module
system
and
less
of
a
extensive
understanding
of
all
kind
of
the
edge
cases
and
aren't
necessarily
like
digging
through
the
docks
of
everything
so
that
they
can
just
kind
of
install
things
and
use
them
and
they
and
they
just
work
as
well
as
folks
who
are
trying
to,
like
you
know,
convert
existing
packages
that
were
being
transpiled
to
using
native
esm.
A
Well,
I
think
creating
a
system
that
allows
named
exports
from
common
js
does
help
these
folks
having
one
that
is
not
consistent
and
then
requires
them
to
understand
even
more
rules
about
what
it
will
work
and
when
it
won't
work
actually
to
me
could
potentially
be
worse
as
far
as
the
support
story
is
concerned,
because
now
it's
not
just
like
a
single
rule
that
they
need
to
learn
which
is
like
common
js
just
doesn't
have
exports.
We
can
give
a
clear
error.
A
C
That's
kind
of
why
I
would
say,
like
you
think,
about:
what's
the
user
experience
right
now,
it's
like
they
try
to
do
a
named
export.
It
fails.
It
gives
an
error
saying
like
name.
Exports
from
cjs
aren't
supported,
use
this
code
instead,
and
it
gives
them
a
two-line
snippet
of
importing
the
default
destructuring
off
of
it
right
all.
Like
say
we
say
we
merged
in
the
most
ambitious
version
of
guys
pr
that
like
gets
named
exports.
Most
of
the
you
know
for
as
much
as
possible.
C
All
that
would
really
change
from
a
ux
perspective
is
well.
Some
some
named
exports
would
work,
but
then
for
the
ones
that
didn't
that
error
message
would
just
say.
Instead
of
saying,
like
only
default,
exports
would
work
work
from
cgs,
it
would
just
say
named
exports
from
for
common
js
packages
work
only
when
node
can
successfully
determine
them
via
static
analysis.
This
package
appears
to
not
be
you
know,
one
that
node
can
understand
through
static
analysis.
C
You
can
import
its
exports
through
by
using
the
default
and
then
the
same
two
line
thing
so
like
we're,
adding
a
sentence
to
the
error
message
essentially,
but
that's
it
like.
I
don't
think
we
would
write
any
documentation
for
package
authors
to
let
them
game
the
system
to
get
this
detection
system
to
work
for
them
like
for.
If
package
authors
want
named
exports,
we
tell
them
write
an
esm
wrapper
and
that's
it.
You
know.
So
nobody
needs
to
know.
Like
users,
don't
need
users
both
consuming
users
and
package.
C
Authors
don't
need
to
know
the
details
of
what's
going
on
under
the
hood
in
terms
of
guys
magic.
I
think
I
mean
how
do
you
feel
about
that
miles?.
A
Well,
we've
got
three
people
with
their
hands
up,
so
let's
let
them
talk
and
let's,
unless
anyone
objects,
I'd
like
to
give
another.
You
know
like
let's
say
five
minutes
for
this
agenda
item,
or
do
you
think
we
need
more
well,
let's
see
where
we're
at
in
five
minutes,
wes.
G
Also
at
the
time
that
we
make
the
error
message
like
because
we
know
that
we're
already
in
a
module
graph
with
an
error,
we
could
easily
like
just
require
the
module
in
question
to
get
like
the
full
list
of
things
and
say
like
we
couldn't
detect
this
thing
that
you
referenced,
but
it
does
exist.
So
you
do
have
to
say
it
in
this
way
like
with
the
default.
And
what
have
you
like
specialize
the
error
message,
even
fur.
A
A
What's
going
on
right
now
to
improve
it,
jordan.
E
So
I
I
guess
I'm
kind
of
of
two
minds
around
this.
I
think
that
in
one
case
I
would
like
to
improve
the
ergonomics
around
this
and
for
packages
that
are
intended
to
be
used
as
if
they
had
named
exports.
It
seems
you
know
where
the
author
can't
write
an
esm
wrapper.
It
seems
like
it
would
be
a
really
nice
thing
to
just
kind
of
make
that
work,
especially
if
the
error
message
can
be
made
more
clear,
but
on
the
flip
side
decisions.
E
E
D
So
sort
of
in
line
with
that
one
of
the
things
that's
also
worth
discussing
is
it's
a
kind
of
a
raising
to
add
the
named
exports
and
then
there's
like
one
edge
case.
That
does
need
to
be
considered
quite
carefully
and
that's
whether
a
default
export
should
be
overwritten.
D
Don't
necessarily
know
when
whether
that
breaks
that
sort
of
invariant
of
thinking
of
common
js
is
always
the
default,
and
it's
worth
remembering
that
default
exports
were
invented
for
common
js.
For
this
reason-
and
I
mean-
and
you
get
this
parity
mismatch
between
the
systems-
so
that's
it's
it's
a
tricky
one.
I
I
tend
to
like
the
guarantee
of
default,
always
being
modular
exports
and
then
the
other
names
are
kind
of
the
lifted
extras.
D
But
we
do
also
need
to
move
on
it
soon.
If
we
want
to,
I
could
get
the
export
star
cases
finished
up
for
the
es
module
case
for
the
es
module
lifting
to
get
it
to
kind
of
over
gus's
concerns.
It
would
be
quite
a
bit
of
work.
D
Well,
not
not
a
huge
amount,
but
it
would
be
some
work
so
having
some
agreement
or
understanding
between
us
on
whether
we
want
to
do
that
or
not,
and
how
and
and
if
we
can
get
agreement
on
it
would
be
useful
not
to
waste
effort
there,
because
it's
it's
not
something
that
like
is
particularly
fun.
But
personally
I
I
would
prefer
to
keep
the
default
semantic
wesley.
G
I
think
it's
worth
noting
that
to
a
packaged
consumer,
whether
the
package
is
esm
or
cjs
or
even
is
completely
transparent,
and
so
that
saying
you
import
cjs
with
a
default.
While
that's
useful.
If
you're
like
working
inside
the
package
and
you're
mixing
formats
yourself,
when
you're
consuming
a
package,
you
actually
have
no
idea
except
for
any
documentation.
The
package
author
may
have
left
you
that
you've
read,
and
so
in
that
respect,
that
guidance
isn't
actually
particularly
helpful
for
people
consuming
packages.
A
A
The
fact
that
one
supports
the
other
is
meant,
as
you
know
like,
like
a
bridge
between
them,
but
I
I
think
like
well,
I
can
say,
like
a
modules
interface,
you
shouldn't
have
to
know
about
it,
like
people
do
publish
raw
typescript
as
modules,
and
you
do
need
to
know
that,
because
if
you
try
to
import
it
or
require
it,
it
just
won't
work.
C
Yeah,
I
I
I
agree
with
a
guy
on
this
one
that,
like
I
feel
like
we're
gonna
like
we
had
that
all
that
stuff
about
the
the
hazard
the
dual
package
hazard
that
ties
directly
into
this.
If,
like
module
exports,
is
a
different
object,
then
you
know
import.
That's
the
same
type
of
thing
like
I
feel
like
we're.
Definitely
gonna
get
bugs.
If,
like
we
suddenly
make
yes,
module
versions
of
module,
exports
behave
differently.
C
D
So
should
we
continue
to
pursue
this
or
not?
I
guess
is
the
question
I
still
like
the
idea
of
supporting
it
for
the
es
module
cases.
I
do
also
support
extending
like,
if
you
think
of
it
as
a
kind
of
a
lifting
and
it's
not
guaranteed.
D
I
don't
see
a
problem
with
that
because
it's
like
it's
kind
of
like
you
know
you
know
you've
got
your
default
is
always
going
to
work,
but
if
you're
lucky
you
might
get
some
named
exports,
and
that
seems
better
than
nothing
so
like
I
kind
of
agree
with
jeffrey
like
that,
but
gus
won't
allow
it.
So
I'm
all
for
the
es
module
restriction
to
get
something,
because
there
are
a
lot
of
transpiled
modules
and
there's
only
going
to
be
more
and
more
transpiled
modules.
D
So
at
least
that
gives
us
something
and
it
gives
us
typescript
and
babble,
and
so
many
packages
have
yes
module
on
them
these
days,
it's
like
it's
gonna,
be
more.
How.
E
Many,
how
many
transparent
modules
are
there
that
are
not
going
to
be
updated,
because
that's
really
the
problem
set
right,
the
ones
that
are
going
to
be
updated.
We
can
just
update.
We
can
come
up
with
solutions
to
actually
produce
an
es
module
wrapper
in
the
transpiler
and
then
just
solve
that
for
all
future
transparent
modules.
Right
sorry,
can
you
just
clarify
that
again?
E
Yes,
what
I
mean
is
of
all
of
the
transpiled
modules
out
there,
some
percentage,
let's
say:
80
percent-
are
going
to
continue
to
be
transpiled
and
updated
moving
forward,
which
means
that
if
we
investigate
and
locate
a
solution
in
typescript
and
babel
and
so
forth,
then
that
80
aren't
gonna
need
any
special
handling
from
node.
They
can
just
have
a
generated
esm
wrapper
that
provides
the
named
exports.
E
It's
that
other
20
that
is
never
going
to
be
updated
and
so
recognizing
the
historical
es
module
marker
is
the
only
way
to
provide
named
exports
to
those.
So
I
guess
my
question
is:
I
said,
80
20.
What
do
we
think
the
actual
percentage
is
there
like?
How
many,
because
it
seems
like
this
feature
really
is-
is
only
providing
the
only
way
out
for
that
20
percent.
A
Sort
of
like
asking
how
many
packages
sorry
to
interrupt
quick
point
of
order,
two
things:
duran
has
their
hand
up
hey
we're
over
the
extended
time
box
that
we
talked
about,
and
so
after
duran
adds
something.
I
think
it's
good
for
us
to
gut,
check
and
see
if
we
want
to
move
on
from
this
topic
or
not
duron,.
A
Them
I
think
that
that
could
potentially
work
for
some
cases,
but
where
we
see
things
get
really
weird
is
when,
like
you
have
packages
that
are
deep
in
dependency
trees,
I
guess
it's
not
going
to
really
matter
from
an
import
perspective,
though,
because
usually
you're
really
only
importing
something
that
you're
directly
depending
on.
C
Ana
has
written
a
utility
that
automatically
generates
an
esm
wrapper
for
packages.
There's
certainly
nothing
stopping
someone
from
integrating
that
into
a
package
manager
like
npm,
and
then
it's
like
on.
You
know:
npm
install
even
all
the
way
down
the
tree,
it
generates
wrappers
and
then
you
know
you
can
import
anything
and
it'll
just
work,
but.
C
I
mean
it
also
doesn't
help
for
all
the
people
who
have
packages
that
are
already
on
their
machines.
You
know
that's
true,
that's
true!
So
quick
time
check
can
I
just
ask
if
you
know
say
I
was
able
to
convince
gus
to
come
around
to
what
I'm
proposing.
Does
anyone
else
hear
oppose
it
like?
Would
anyone
else
object
to
that.
C
A
I
I
honestly
would
need
to
see
more
numbers
and
the
full
user
experience
before
being
able
to
commit
to
whether
or
not
I
would
object
to
something.
A
In
principle
I
mean
I
I'm
gonna
be
honest.
I
think
that
guy
has
invested
a
ton
of
engineering
hours
into
this
and
we've
continued
to
discuss
it
and
not
had
a
ton
of
progress
and
in
respect
to
guys
time.
I
don't
know
if
continuing
to
explore
implementation
is
necessarily
you
know
the
best
use
or
respectful
of
that
time.
If
we
do
like,
because
at
least
to
myself,
it
doesn't
feel
like
at
the
end
of
this
discussion,
we're
any
closer
than
we
were
at
the
beginning.
A
C
A
Okay,
so
import
maps
and
node.js
guy.
Would
you
like
to
take
this
one.
D
Yeah,
it's
a
shame,
bradley
isn't
here
this
week,
so
this
is
quite
a
big
topic,
but
I
I
guess
so:
firstly,
doran
brought
up
import
maps,
I
believe,
and
then
so
you
know
it's
a
question
that
generally
comes
up
is:
should
node.js
support,
import
maps,
dina
supports
import
maps
and
chrome
supports
it.
Behind
the
experimental
web
platform
features
flag
and
generally,
the
feeling
is
no.
We've
got
our
own
modular
resolution
system.
If
you
have
a
bare
package
specifier,
it's
looked
up
in
modules.
D
We
have
our
own
mechanisms
here,
and
that
seems
fine.
I
mean
one
example.
Is
I
mean
import
maps
would
offer
a
kind
of
a
mocking
system
like
christopher
was
asking
about
at
the
beginning
of
this
meeting.
D
D
Firstly,
if
you
look
at
the
node.js
policies
implementation,
it
does
import
mappings,
so
node.js
policies,
map
modules
in
the
res
in
in
the
node.js
call
resolver
they're
a
mapping
system,
and
that
was
necessary
for
the
security
properties
of
policies,
bradley
just
merged
a
pr
to
add
scopes
to
policies.
So
policies
have
both
imports
and
scopes.
They
have
scoped
mappings
as
well,
which
are
both
features
of
import
maps.
D
The
other
thing
is
that
policies
do
integrity
which
import
maps
don't
do,
but
in
system.js
we
needed
integrity
for
lazily
loaded
modules,
which
wasn't
possible
any
other
way,
and
we
ended
up
adding
an
integrity
field
to
the
import
map
as
the
easiest
route
to
provide
this
information
and
get
guarantees
for
code
execution,
and
so
that
that
was
quite
interesting,
that
from
the
system.js
side
we
support
input
maps
and
then
we
added
integrity
and
from
the
node.js
policy
side
it's
got
integrity,
which
was
then
turned
into
import
maps,
and
so
this
made
me
think,
maybe
if
we,
if
we
consider
input
maps
as
a
kind
of
a
virtualization
of
the
environment
that
can
provide
like
the
mocking
features
that
christopher
was
interested
in
and
things
like
that
and
also
possibly
even
like,
if
it
might
have
security
properties
or
things
like
that.
D
If
you
know
around
these
use
cases,
it's
something
node.js
might
want
to
consider.
And,
furthermore,
right
now,
import
maps
aren't
being
actively
driven
because
the
environments
that
most
need
them
are
the
runtimes
like
dino
and
projects
like
systemdas
and
stuff,
like
that
and
and
the
use
cases
around
browsers.
D
Aren't
that
fleshed
out,
whereas
it
might
be
the
new
javascript
runtimes
that
are
able
to
more
utilize
import
maps
so
shouldn't
they
be
steered
by
the
runtimes
that
need
them
so
kind
of
a
combination
of
security
thinking,
a
combination
of
the
use
cases
around
mocking
and
stuff
like
that
and
and
defining
modules,
and
whether
node.js
might
be
able
to
say
you
know
what.
As
a
project,
we
have
an
interest
in
the
future
of
the
specification
and
as
a
project.
D
E
Yeah,
so
I
have
my
hand
up
it's
worth
noting
that,
in
order
for
built-in
modules,
the
language
proposal
to
be
unblocked,
some
sort
of
import-like
mechanism
needs
to
be
part
of
the
specification
of
262.
and
the
intention,
or
the
hope
would
be
that
browser
import
maps
would
build.
Then,
on
top
of
that,
you
know
or
would
refactor
to
live
on
top
of
that.
E
Similarly,
any
mapping
mechanism
node
had
would
hopefully
also
live
on
sit
on
top
of
that
it
seems,
regardless
of
what
node
decides
to
do
now,
it
seems
like
that
is
something
that
that
you
in
particular
may
be
interested
in
being
involved
in.
I
don't
know
the
timeline.
It's
not
likely
to
be
soon
as
my
guest,
but.
D
Yeah,
I
I
guess
it's
kind
of
it
is
trying
to
work
out
what
the
contextualization
is
here
and-
and
you
know
it
is
closely
linked
to
built-in
modules
and
and
the
guarantees
around
the
the
module
system
and
and
and
maybe
it
is
an
overreach
to
to
bring
up
the
security
concept.
Sorry
I'll
I'll
I'll,
let
the
question
I'll.
Let
it
go
back
to
the
questions
go
for
it.
C
Was
just
gonna
ask
like,
could
we
not
implement
import
maps
as
a
loader,
and
I
don't
know
where
whatever
happened
to
that
effort
to
have
like
official
node
packages?
But
I
mean
I
guess
we
could
always
implement
it
under
a
flag
which
would
be
about
the
same
thing
as
implementing
it
as
a
loader.
But
or
are
you
talking
about
like
on
a
much
earlier
stage
than
that,
like
you
want
to
know,
if
node
is
interested
in
like
having
a
representative
in
these
discussions.
D
Right,
it's
so
it's
it's
more
about
like
long-term
investment
in
the
platform
and
and
no
traditionally
not
having
a
voice
in
in
web
web
standards,
and
things
like
that
and
as
modules
being
something
relatively
fundamental
import
maps
and
security
concepts
and
things
around.
That
is
something
where
it
would.
No
just
representation
might
make
sense.
So
I
think
this.
A
Is
a
good
place
for
me
to
interject
and
then
we've
got
duran
and
then
we've
got
wes.
I
was
one
of
the
people
in
the
original
meeting
that
came
up
with
the
original
import
map
proposal,
partially
representing
node
and
partially
representing
thinking
about
how
do
we
have
bear
imports
as
a
js
ecosystem
thing?
So
you
know
node
has,
to
an
extent
been
represented
at
import
maps
from
the
initial
discussions
of
the
proposal.
A
Just
to
give
that
context,
an
update
on
where
it's
at
right
now
there's
an
implementation
in
chrome,
that's
behind
a
flag.
It
is
right
now
part
of
the
wicg
web
incubator,
community
group
and
waiting
to
graduate
if
it
graduated
it
would
most
likely
move
into
the
wwe.
No,
the
what
working
group
html
spec
the
thing
that's
blocking
it
from
moving
right
now
is
another
implementer
expressing
public
interest
in
implementation.
A
There
are
no
other
browsers
right
now
that
have
expressed
public
interest
in
implementation.
Although
I've
I've
been
pinging
folks
at
different
browsers
to
try
to
see
if
we
can
get
them
to
do
so,
they're
currently
is
no
work
being
done
for
integrity
as
part
of
the
import
map.
I
have
a
separate
proposal
that
I've
opened
up
at
at
the
wicg
about
the
idea
of
a
sub
sub-resource
integrity
map.
A
I
personally
am
not
a
huge
fan
of
trying
to
shove
additional
logic
into
this
into
import
maps
at
this
time,
as
they
are
not
like.
We
don't
even
have
any
guarantee
that
long
term.
This
will
be
a
single,
manifest
format.
It's
possible
that
the
two
could
get
merged,
but,
like
things,
need
to
happen
one
at
a
time
and
my
understanding
is
like
the
limited
scope
is
looking
to
have
browsers,
commit
to
the
limited
scope
before
trying
to
extend
it.
A
I
think
there
is
use
in
node
for
import
maps
as
they
exist
today,
especially
as
a
way
of
like
kind
of
like
pre-generating
the
entire
resolution
map
for
all
of
the
specifiers,
so
that
you
do
not
have
to
do
the
specifier
resolution
algorithm
live.
This
is
like
kind
of
a
production-like,
build
step
that
one
could
do,
for
example,
so
I
think
even
just
the
off-the-shelf
map
that
we
have
can
be
useful,
jordan
and
jeff.
I
believe
that
you
had
had
your
hands
up
before.
Were
they
still
up
to
discuss
again
or
are
they
I'm.
A
Okay,
so
duron
and
then
wes.
H
What
I
was
trying
to
ask
guy
on
a
private
channel
is
basically
what's
the
use
case
for
input
maps
in
node,
because
the
way
I
see
it
and
how
you
know
you
participated
in
the
creation
mines
input
map.
Is
this
highly
dynamic
thing
and
it
makes
a
lot
of
sense
in
the
browser
context
and
then
do
you
know
it
makes
sense
because
they
load
models
from
the
web.
H
H
As
for
other
reasons,
I
can
see
stuff
like
a
b
testing,
perhaps
been
done
through
that
I
can
see
stuff
like
replacing
lock
files
and
like
being
done
in
the
integrity
suggestions.
But
it's
really
important
to
understand.
If
it
has
like
I'm
excited
about
it,
and
I
just
don't
know
if
node
needs
it.
A
So
the
baseline
proposal,
to
the
best
of
my
understanding,
is
not
dynamic.
There's
a
static
mapping
of
a
bear
specifier
in
the
left
to
a
resource
on
the
right,
and
at
least
for
myself
whether
or
not
that
resource
is
like
a
file.
Url
or
a
https
url
doesn't
seem
like
a
major
deal.
You
know,
and
as
far
as
node
is
concerned,
I
still
see
value
in
in
having
that
static
mapping
pre-computed
before
load
time.
G
So
like
import
maps
as
they
currently
exist,
like
don't
compose
right,
you
just
have
one
import
map
for
your
final
application.
Yes
yeah,
so
that
means
import
maps
if
we
supported
them
in
some
way
in
node,
wouldn't
be
able
to
be
shipped
with
packages
you
just
have
to
like
provide
one
on
the
command
line
to
like
override
resolutions.
G
A
G
Using
it
like
that,
and
that's
like
a
standardized
version
of
like
a
yarn,
lock
file
or
like
a
package
lock
file
like
both
of
those
are
things
that
the
package
managers
have
much
stronger
opinions
on
that.
A
lot
of
us
here
do.
We
should
probably
be
asking
them,
because
that's
definitely
a
feature
pretty
much
for
them,
because
we
wouldn't
be
generating
it.
They
would.
D
For
what
it's
worth,
I've
been
working
on
an
import
map
package
manager
generator
for
seven
years.
Personally,
the
other
side
of
it
is
that
policy
does
do
these
mappings
and
policy
does
do
these
integrity
locks.
Similarly
to
a
lock
file
and
the
generation
of
policy
is
a
current
active
problem
and
they're
the
story
around
that,
and
I
I
I
don't
want
to
over
conflate
them.
D
I
I'm
not
saying
that
we
should
unify
them
right
now,
but
I
do
think
that
there
are
a
lot
of
cross
concerns
between
these
systems
and
yeah.
But
but
more
generally,
as
I
say
it's
it's
about
like.
A
So
right
now
the
way
in
which
we
do
things
we
rely
on
the
resolver
to
in
real
time
at
runtime
resolve
all
these
things,
including
package
exports.
So
this
is
happening
like
you
know,
during
the
load
phase
and
even
during
execution
when
we're
dealing
with
dynamic
imports.
A
So
the
benefit
that
I
see
to
node
is
like
essentially
having
a
path,
a
pass
where
you
can
go
and
resolve
this
once
for
your
whole
tree,
especially
when
we're
talking
about
like
things
being
deployed
in
a
serverless
environment.
I
genuinely-
and
I
could
be
wrong
here-
I
don't
have
numbers
to
back
it
up,
but
I
do
think
that
we
can
see
performance
improvements
by
essentially
making
every
single
resolve
call
be
in
order
when
operation.
D
Have
that
shipped
right
now,
problems
for
that
with
native
modules
and
native
caching
and
stuff
like
that
as
well.
Possibly
I
don't
remember
the
details
again.
Probably
bradley
would
be
the
right
person
to
be
around
for
that
conversation
and
then
one
other
thing
just
to
mention
briefly.
We've
hit
sort
of
time,
but
I
mean
wesley,
you
mentioned
loading,
multiple
import
maps.
I
guess
the
frustrations
from
me.
D
Working
on
system.js
and
jspm
come
out
of
things
that,
like
I
need
multiple
input
maps
and
things
like
that
are
useful
and
they're
not
being
defined
by
browsers.
I've
ended
up
putting
together
a
whole
bunch
of
extensions
to
import
maps
and
extension
proposals
like
the
ability
to
lazily
load
them
and
to
extend
them
in
in
a
well-defined
way
and
the
fact
that
it's
only
platforms
that
are
adopt
actively
adopting
these
kinds
of
workflows
that
are
able
to
really
work
through
those
issues
and
that
maybe
the
browser
isn't
the
best
place
to
drive
that.
A
So
with
that,
we
are
at
time,
so
I
think
that
we
need
to
call
it
a
day
for
now
and
revisit
this
in
two
weeks.
Everyone
thank
you
for
joining
and
those
who
dialed
in
thanks
for
calling
I'm
gonna
go
ahead
and
stop
this.