►
From YouTube: Node.js Foundation Modules Team Meeting 2019-09-25
Description
A
We
are
now
live
on
YouTube
with
the
September
25th
edition,
the
node.js
modules
team.
We've
got
seven
people
on
the
call,
we're
all
excited
to
talk
about
modules.
What
works,
what
doesn't
work?
What's
working,
what
isn't
working
speaking
about
things
that
aren't
working?
Let's
hop
right
into
our
first
agenda
item
global
should
be
wrapped
to
stay
in
sync
with
ESM
I.
A
A
A
So
I
started
playing
with
removing
the
flag
and
there
was
kind
of
like
a
bit
of
an
unexpected
issue
with
this
and
Brad's
on
his
way,
so
he
can
get
into
the
specific
once
he
joins.
But
essentially
one
of
the
challenges
that
we
were
ran
into,
which
we
were
not
expecting
was
that,
with
the
way
that
the
flag
worked,
the
flag
actually
changes
the
bootstrap
of
node
itself
and
in
changing
the
bootstrap
of
node.
A
A
So
when
I
did
the
experiment
of
just
like
removing
the
flag
and
running
the
test,
suite
a
bunch
of
tests
from
node
course
started
failing
in
Sobrato
this
PR
to
try
to
fix
that
specifically
making
sure
that
the
Global's
were
wrapped
to
stay
in
sync
with
ESM
and
that
resulted
in
a
-1
from
Matteo
upstream
specifically
for
performance
concerns.
So
there
are
some
like
high-level
questions
about
how
we
want
to
handle
built-ins
named
exports
for
built-ins
and
keeping
things
in
sync
and
how
we
want
to
do
that
in
a
way.
C
Sure,
there's
also
an
added
thing
here
that
was
uncovered
one
of
the
tests
had
a
getter
fired
that
through
an
error
on
a
built
in,
and
so
these
proxies
have
to
eat
girl
e
inspect
all
the
built-ins.
So
if
you
were
to
create
a
getter
or
use
a
getter
on
any
built-in
that
would
throw
by
accessing
it,
who
knows
why
deprecation
or
something
I
think
in
solid
from
node
source
I
actually
had
a
mode
where
you
could
disable
certain
built-in
api's
with
that
effect?
C
So
we
need
to
do
a
couple
things
here.
We
discuss
how
to
get
away
from
the
negative
one,
so
performance
wise,
it
seems
like
the
main
concern
from
Matteo
is
process
dot.
Next,
stick
is
a
very,
very
hot
API
and
having
get
access
to
it,
slow
down
is
prohibitively
bad
such
that
he
would.
Rather,
we
not
land
the
proxy.
C
So
we
can
take
a
few
different
approaches
to
this.
We
could
disable
importing
the
process
module.
There
is
a
global
called
process.
You
could
access
for
that.
We
could
allow
the
process
global
to
go
out
of
sync
with
the
es
module
named
exports.
I,
don't
know
of
anybody
who's
vying
for
that
currently
or
we
could
remove
named
exports
from
the
process
built-in.
C
C
D
C
B
C
B
E
Get
out
of
sync
I,
don't
see
a
very
clear,
reliable
path
around
that
and
with
that
in
mind,
and
also
just
from
an
API
design
point
of
view
for
me,
processing
buffer
were
always
built
in
modules
were
exporting
objects
or
constructors,
so
they
only
had
a
default
export.
So
I
think
it
doesn't
feel
like
a
big
loss
to
lose
named
export
support
for
process
or
for
buffer.
It
feels
like
something
where
I
would
expect
that
I
only
have
to
default.
Anyhow,
it's
not
like
FS,
where
every
file
is
a
function.
E
E
A
I
guess
and
that's
something
that
we
had
discussed
that
you
know.
Perhaps
the
alternative
was
simply
banning
import
of
those
two
built-ins
and
and
essentially
having
people
use
the
global,
because
I
think
and
Brad
can
chime
in
on
this
and
then
Salah
has
their
hand
up,
but
Brad
did
some
ecosystem
searching
and
there's
at
least
four
process
very
few
instances
of
people
using
require
process.
Most
people
are
just
using
the
global
object,
correct.
B
F
Yeah,
so
in
terms
of
importing
process,
if
we're
going
to
do
any
kind
of
security,
you
know
selective
exports
from
process
at
some
point,
it
might
be
a
better
practice
to
actually
have
people
import,
particular
things
from
process.
What
I'm
trying
to
get
at
is
that
maybe
since
process
is
really
kind
of
like
an
instance
of
the
class,
you
don't
want
to
be
having
that
as
the
exports
namespace
of
a
module
per
se.
F
So
the
fact
that
it
is
like
that
in
the
required
system
or
in
the
comm
J
assistant,
that's
fine,
but
you
probably
want
to
just
selectively
export
particular
things
from
process
I'm,
not
sure
about
butter.
I,
don't
use
that
so,
but
at
least
for
process
you
want
to
selectively
export
so
like
a
wrapper
module
around
it.
B
B
Api
is
because
about
these
long
lasting
guarantees
that
you'll
be
able
to
import
something,
because
if
it's
not
there,
it's
it's
not
just
a
catchable
error
unless
you're
using
dynamic
import,
but
I
would
very
much
be
for
keeping
the
ability
to
import
process
and
buffer
and
and
mainly
for
the
reason
that
I
think
like
if
you've
got
it
environments
that
want
to
be
able
to
not
assume
Global's,
then
it's
it's
nice
to
have
to
rely
on
that.
It's
not
something
I,
you
know
hold
any
strong
opinion
on,
but
it's
it's
just
at
the
preference
way.
B
C
F
So
so
I'm
thinking
more
less
of
the
the
primitive
type
properties
of
processed.
But
there
are
object
types.
Then,
then,
you
know
somebody's
importing
the
particular
kind
of
sub
API
from
the
process
object.
But
if
it's,
if
it's
a
primitive
value
that
needs
to
be
synced,
that
that
definitely
complicates
the
intent
of
wrapping
it
here
can.
G
G
G
C
D
G
C
G
Okay,
I
had
one
of
the
questions
this
is
and
and
stop
me
if
this
is
like
too
far
off
topic,
it
seems
like
we
don't
have
any
better
solution
than
the
status
quo
for
the
whole
named
exports
from
comedy
s
issue
that
we've
been
kind
of
batting
around
for
like
a
year
or
more
now,
I
think
the
only
like,
essentially
only
had
three
possible
solutions,
one
of
them,
the
two
of
them
like
kind
of
depending
on
the
tc39
and
I.
As
far
as
I
know,
neither
one
really
ever
got
advanced.
G
So
the
third
was
that
kind
of
crappy
solution
that
I
proposed,
which
was
like
just
let
people
define
it
in
package
of
Jason,
and
then
we
read
in
the
named
exports
from
that
I.
Don't
know
if
that's
something
we
want
to
reconsider,
if
that's
or
people
think
that
status
quo
was
even
is
still
better
than
that.
But
is
there
something
like
if
we
did
say,
reconsider
that
and
then
handle
named
exports
in
some
kind
of
lower
level
way
for
comma
J
ass
modules?
G
D
A
So,
that's
it's
not
that
we're
missing
information,
it's
specifically
about
keeping
the
two
caches
in
sync,
so
I
think
like
a
radical
solution
and
I'm,
not
suggesting
that
we
do
this,
but
an
example
of
a
radical
solution.
I
think
would
be
like
trying
to
keep
a
single
cash,
for
everything
would
be
an
example
of
one
that
would
like,
maybe
not
require
the
proxies,
but
would
require
massive
rewrite
of
everything
it
may
not
even
be
like
actually
feasible
based
on
our
architecture.
So
I
said
that
more
is
like
an
example
not
like
what
we've.
Although.
G
I
mean
many
people
have
talked
about
how
we
do
need
to
do
that,
like
Wes
and
in
particular,
and
if
we
do
have
this
thing,
where
like
each
URL,
could
it
could
mean
exactly
one
thing,
even
across
module
systems
where
you
can't
have
the
same
thing,
be
something
in
common
guess
and
something
else
in
you
stem,
then
we
could
have
one
cache.
So
even
if
you
automatic
it
might
be
worth
it
for.
B
Sort
of
on
this
track,
another
thing
that
we
can
do
is
basically
stop
sinking
this.
We
there's
am
named
exports
and
the
commonest
so
that
when
you
mutate
a
common
Darius
module,
it
doesn't
get
reflected
on
the
named
exports
of
there
as
a
module
or
they
aren't.
There
aren't
like
exact
identity
of
the
module
object
between
them.
B
G
A
D
Okay,
so
back
when
I
was
adding
this
proxy.
Originally
it
just
copied
the
properties
like
I
said,
and
people
were
unhappy
with
that,
but
if
we
can
find
another
way
around
that,
that
would
like
also
be
an
acceptable
solution.
The
other
thing
is
that
well,
I
was
adding.
This
I
also
asked
as
a
policy
that
we
don't
add
any
more
deprecations
that
fire
on
access
and
I
forgot.
My
last
point:
you
can
come
back
to
me.
A
E
So
I'm
not
sure
if
it's
worth
it
to
just
see.
If
we
can
get
agreement
like,
for
example,
it
might
be
easiest
in
the
the
spirit
of
minimal
core
to
say
just
making
it
impossible
to
input
them
right
now
until
we
find
a
good
solution,
if
we
ever
find
a
good
solution
might
be
the
least
friction
I'm,
not
sure.
A
So,
for
me,
one
of
the
things
I
would
very
much
like
us
to
try
to
see
if
we
could
accomplish
in
this
meeting.
But
perhaps
you
know
the
meeting
is
not
the
great
it's
time
and
if
anyone
has
things
from
the
agenda
that
they'd
like
to
make
sure
that
we
get
to
on
top
of
this,
we
definitely
can.
But
basically,
this
specific
thing
is
absolutely
blocking
our
ability
to
unflagged
and
any
really
big
changes
that
we
want
to
make
if
they
affect
core
if
they
affect
how
things
work
outside
of
the
SM.
A
So
we
are
not
in
a
great
position
right
now,
so
I
do
know
that
we
have
a
lot
of.
We
have
a
handful
of
other
things
that
we've
been
debating
and
some
other
things
on
the
agenda,
but
I
think
that
kind
of
coming
up
with
a
at
the
very
least
proposal
to
how
to
solve
this
and
bring
it
upstream
to
see
if
people
are
open
to
it
or
amenable
is
something
that
we
need
to
do
kind
of
ASAP,
and
if
we
want
to
try
to
land
this
on
LT
s
before
it
goes
to
LTS.
A
A
C
C
If
we
are
looking
for
doing
a
variety
of
things
such
as
Polly
Polly,
filling
new
api's
as
they
get
added
to
node,
that's
going
to
get
into
interesting
scenarios
already,
since
you
can't
add
module
exports
after
the
built-ins
are
created,
so
I
think
having
them
go
out
of
sync,
maybe
somewhat
natural
as
people
polyfill
older
nodes
and
are
unable
to
add
those
named
exports
through
the
proxy
I.
Don't
think
it's
the
best
thing
in
the
world.
I
think
this
really
moves
up
the
need
to
solve
some
stuff
for
certain
use.
C
C
F
F
C
F
A
D
A
C
B
A
If
we
do
this
in
12,
with
the
experiments
like
where
it's
still
experimental
but
without
a
flag-
and
we
start
to
run
into
like
really
big
ecosystem
issues
around
it,
we
always
could
you
know
change
that
in
13
and
change
that
in
a
semi
major
414
and
handle
it
in
an
appropriate
way
and
future
versions
could
be
more
consistent.
If
we
can
find
a
way
if
we
can
find
a
good
way
to
do
it,
there's
a
long
ways
saying
I,
think
I'm,
plus
one
on
just
removing
the
proxies
across
the
board
for
now
yon.
C
I
would
agree
with
your
statement.
We
could
add
something
that
does
it
that
just
doesn't
do
it
on
a
proxy
or
object
model
trap,
so
a
function
where
you
give
it
a
module.
Namespace,
that's
well
known,
like
FS,
and
you
give
it
another
object
to
sync
against
would
be
possible
still,
and
you
could
do
that
with
a
pre-loaded
module
like
require
I
presume
could
do
that
or
an
APM
technically
could
do
that
at
runtime
as
long
as
we
actually
go
and
design
an
API
that
allows
such
I.
E
E
F
Yeah,
just
one
last
point
about
updating:
there
are
no
built-ins
where
the
exported
names
will
actually
change
in
such
an
update.
Does
anybody
know
of
anything
that
currently
does
that
adding
new
properties
to
built-ins
only
polyfills
that
I
know
of
so
so?
Is
there
a
way
he
thought
about
how
ESM
namespace
objects
can
get
new
members
on
Dhin
with
such
a
cannot
yeah
that.
C
D
A
D
C
A
And
guy
I
know
that
you
were
just
throwing
that
that
API
out
there,
but
it
is
now
canonical
and
in
removing
it
would
be
some
four
major
sorry,
okay,
cool
Jeff
you've
been
doing
a
really
good
job
of
keeping
the
Lehner
dock
up-to-date.
Would
you
maybe
be
open
to
taking
an
action
item
of
documenting
this
discussion
in
the
stay
in
the
phase
three
dock.
A
G
A
A
Okay,
very
cool,
so
we've
got
20
minutes
left.
We've
got
a
couple
more
things
to
get
into.
I.
Think
that
you
know
with
with
the
with
the
road
ahead
of
us
and
the
things
that
are
going
on
for
LTS
I
do
think
that
it
would
be
really
good
for
us
to
maybe
start
thinking
more
explicitly
about,
like
a
really
really
clear
checklist
of
this
is
what
we
need
to
move
forward
and
building
consensus
around
that,
and
perhaps
we
can
make
that
you
know
an
issue
for
next
week.
A
G
A
A
B
A
So,
let's
just
go
through
this
and
then
like
really
quickly
for
these.
If
there
isn't
a
ton
of
discussion,
that's
more
just
an
update
or
explicitly
like
if
these
things
are
blocking
removing
the
flag.
Let's
try
to
get
really
quickly
to
the
heart
of
that,
and
thanks
for
being
patient
through
that
last
one,
because
that
was
intense,
so
Jeff.
You
want
to
quickly
update
us
on
the
specifier
hazzard,
what
our
next
steps
and
what
you
think
we
need
to
do
towards
unflagging.
A
Great
and
then
I
guess
that
PR
can
just
close
this
issue
and
we
can
remove
it
from
the
agenda
for
now.
Sound
good
people,
okay,
great
anyone
else-
have
anything
else
to
add
to
the
divergence
with
fire
hazard
discussion
nope
great
next
one
up.
We
have
loader
hooks
351
yawn.
Do
you
want
to
take
that
Brad?
Who
would
be
the
best
person
to
drive
this
discussion.
E
H
I'm
not
sure
exactly
what
I
can
go.
Look
back
to
some
other
group
and
then
also
talks
around
changing
the
current
experimental
loader
hook
to
be
more
in
line
with
design
doc.
That
Bradley
is
written
mm-hmm,
so
I
was
thinking.
I
would
be
happy
to
go
and
work
on
a
PR
to
bring
the
current
experimental
hook
more
in
line
that
maybe
get
me
functionality
from
a
loader
developer
and
loader
user
perspective
in
light
of
the
design
doc.
Maybe
not
necessarily
the
security
advantages.
H
A
A
G
A
E
A
I'm
hearing
no
objections,
let's
see
what
we
can
get
away
with
and
we'll
play
it
by
ear,
so
I
think,
let's,
let's
move
on
to
the
next
thing,
Alex!
Thank
you
for
all
the
hard
work
that
you're
doing
on
loaders
here
and
I
think
that
we
have
a
clear
action
item
of
like
the
one
thing
that
we
need
to
that.
We
need
to
get
in
place,
I'm
selectively.
A
Changing
the
flag,
yeah,
either
an
additional
flag
or
changing
what
the
flag
itself
is
to
just
make
it
clear
that
it's
experimental,
because
once
we
remove
the
flag
for
DSM,
then
it
will
just
be
on,
and
if
the
flag
just
seems
like
it's
a
normal
flag,
then
you
know
that
could
give
people
the
wrong
impression.
Yeah,
the
next
one
that
we
have
is
support
loading
by
own
name.
E
Sure
so
the
current
status
on
that
that
there
is
a
pull
request
for
using
the
@
sign
for
self
reference,
so
the
ED
sign
referring
to
the
module
that
the
importer
is
part
of
what
the
package
scope
that
the
importer
is
part
of
it
is
implemented
for
both
come
to
us
and
ESM.
The
big
controversy
right
now
is
where
exactly
it
should
fall
on
the
president's
order.
E
So
right
now
it's
implemented
as
a
last
resort,
which
means
that
if
you
have
node
modules,
/ad
anywhere,
it
will
take
precedent
and
will
not
ever
use
the
self
reference
thing
we're
just
done
so
that
it
definitely
does
not
break
backwards-compatibility.
In
any
case,
the
disadvantage
is
obviously
that
if
your
application
has
normally
slash
at
and
any
of
your
dependencies
tries
to
use
at
for
different
purpose,
it
will
not
work
within
that
library
because
it
will
find
your
node
modules
slash
ad
in
the
tree.
E
Using
that
pattern
is
creating
a
node
module,
slash
ad
actually
is
currently
actively
broken
in
NPM
and
yarn
because
it
can
potentially
delete
the
whole
source
directory
that
at
points
to
so
I.
Don't
think
many
people
are
using,
don't
worry,
/
@,
so
the
discussion
is
both
very
theoretical,
but
also
it
might
have
an
impact
on
how
we
can
evolve
the
feature
in
the
future.
E
So
the
two
options
right
now
I
basically
keep
the
current
implementation,
counting
on
the
fact
that
nobody
has
a
node
module,
/,
add
or
choose
an
implementation
that
is
technically
not
backwards
compatible
but
might
be
backwards
compatible
in
practice,
and
that
puts
at
as
the
first
thing
in
the
president
order.
So
it
would
just
always
pretty
much
be
a
self
reference.
It
would
know,
look
up
a
node
modules
if
the
specifier
happens
to
be
add
or
add
slash
something.
A
So
you're
on
sounds
like
there's.
Good
progress
being
made
sounds
like
this
does
not
necessarily
block
any
of
the
upstream
work
that
we're
trying
I
mean
any
other
work
regarding
unflagging,
and
this
is
something
that
once
we
reach
consensus
on,
if
it
lands
in
a
way,
that's
not
considered
summer,
major
could
be
back
ported
to
twelve
at
some
point
right.
E
A
B
Think
it's
worth
thinking
it
through
from
a
compatibility
point
of
view,
because,
if
uses
one
to
ship
exports,
they
it's
it's
similar
to
the
problem
that
we
have
with
a
gradual
adoption
of
features
it
to
do
with
modules
and
browsers
where
you
have
to
be
very
careful
about
what
features
you
use
depending
on
the
support
and
if
exports
do
become
a
node.
Thirteen
feature,
then
we're
in
a
situation
where
we
now
have
different
names
between
notches
azzam
and
common
guess,
but
different
mains
between
node
versions,
because
exports
is
a
main
as
well.
A
B
You
understand
that
you
mean
backward
from
13
to
12,
potentially,
yes,
yeah
I,
don't
think
the
backporting
will
be
a
assembler
minor
it'll
be
simple
major.
Actually
it's
difficult
to
know,
because
at
that
point,
if
people
relying
on
the
way
the
things
result
in
what
with
modules
and
then
exchanges,
which
is
what
exports
does
mm-hmm
divergent
behavior
on
top
of
the
current
modules,
so.
B
E
It's
not
enough,
because
exports
can
also
override
the
main
export,
so
it's
no
longer
at
14
imports,
also
PO
kind
of
going
against
what
guy
said
earlier.
I,
don't
think
that
there's
a
fundamental
difference
between
lending
exports
independently
in
lending
exports,
together
with
the
ESM
implementation,
because
exports
is
no
longer
just
in
ESM
thing.
It's
also
affecting
commerce
result
of
a
solution.
B
The
risk
is,
if
someone
publishes
the
packages
Azzam
so
I'm
excited
about,
as
am
I
published
my
as
in
package
and
now
I
realize
that
users
are
loading,
a
file
with
the
dirtiest
extension
inside
my
package,
so
I
add
an
exports
field
to
the
package
or
the
new
exports
feature.
That
will
then
break
the
previous
version
which
didn't
use
exports.
E
Like
if
it's
already
written
in
yes
M,
then
I
don't
have
to
worry
about
explaining
it
to
economists,
users,
so
it
basically
comes
down
to
and
my
readme
and
if
you
do
I
need
to
explain
hey
if
you're
on
note
version
bigger
than
this,
you
can
use
this
shorter
specify.
Otherwise
you
please
use
the
longer
one
and.
E
E
E
A
E
B
I
guess
it's:
it's
probably
something
we
need
to
have
a
few
more
discussions
about.
There
might
be
a
middle
ground
like
just
having
exports
as
a
main
initially,
but
then
there's
also
the
cases
about
how
that
changes
between
environments
but
I
guess
it
gets
back
to
this
kind
of
not
jewel
jewel
jewel.
What
we
call
a
jewel
mood
hazard,
but
it's
a
suitable
environment,
Avenue,
hesitant
man,
we've
got
two
environments,
we've
got
node
with
modules
and
node
without
modules
and
I
guess.
B
The
concern
is
that
we
now
have
three
environments:
node
with
modules
node
with
modules
and
node,
with
exports
and
modules
and
if
you're,
defining
a
package-
and
you
expect
it
to
work
a
certain
way.
You're
gonna
get
some
unreliable
differences
between
oh,
twelve
and
thirteen.
Otherwise
and
depending
on
our
time
line,
it
could
hit
some
some
difficult
cases.
So
we
just
need
to
make
sure
we're
thinking
that
through
maybe
we
need
to
arrange
a
separate
discussion
to
to
actually
just
brush
this
one
off.
A
B
The
moment
the
exports
implementation
provides
support
for
fullbacks
and
to
just
summarize
it
briefly,
it's
that
you
can
either
provide
a
exact
string,
mapping
for
your
exports
main
or
your
individual
sub
parts,
or
you
can
provide
an
array
of
mappings
and
and
what
this
does
is.
It
opens
up
that
ability
space
where
we
can
support
import
maps
for
backs,
as
well
as
potentially
other
extensions,
the
resolver
in
future,
and
it
turns
out
that
import
maps
have
now
deprecated
for
now
the
full-backs
and
built-in
support.
D
E
Yeah
yeah
just
for
additional
context,
for
why
the
browser
went
back
on
the
array
support
so
don't
like
did
a
revised
spec
for
input
maps
where
he
moved
a
bunch
of
stuff
that
was
previously
part
of
input
maps
to
future
work.
So
the
arrays
aren't
gone
from
the
proposal.
They're
just
gone
from
the
thing
that
they
want
to
ship
first,
and
they
are
now
in
a
section
about
things
they
may
do
in
the
future,
which
generally
means
that
they're
no
longer
a
thing
that
will
happen
for
certain.
But
it's
not
a
thing.
E
It
was
entirely
removed
from
the
discussion
and
as
far
as
I
understand
it,
the
reason
for
removing
it
was
a
they
removed
the
concept
of
standard
URLs
or
built-in
URLs.
So
it's
no
longer
part
of
the
import
map
story,
which
means
that
for
for
the
browser
use
case,
they
no
longer
have
a
real
use
for
fallbacks
and
also
the
way
that
the
browser
did
fallbacks
was
that
the
browser
depended
on
network
requests
for
doing
fallbacks.
So
it
was
literally
trying
one
URL
at
the
time
it
failed
to
fetch.
E
E
Do
we
believe
it's
a
considerable
risk
shipping,
something
that
my
it
might
in
the
end,
be
not
consistent
with
how
browser
input
Maps
work,
I,
wouldn't
call
it
incompatible,
because
I
think
we
can
always
like,
given
the
way
that
Banda's
work.
I,
think
that
the
thing
that
is
in
package
Jason
as
an
input
as
an
input
to
a
bundler
would
always
be
compatible.
The
way
that
we
designed
it
with
what
is
currently
in
the
browser,
supported
version,
so
I
think
it's
so
compatible.
It's
just.
E
It
might
just
be
come
in
consistent
depending
on
how
the
browser
moves.
So
that's
the
one
thing
and
the
other
thing
is:
do
we
believe
that
our
current
design
is
still
something
as
valuable
to
note
where
I
believe?
The
answer
is
yes
for
me,
because
I
still
believe
that
in
node
we
definitely
have
use
cases
that
are
currently
served
by
the
common
jazz
ecosystem.
E
That
would
be
regressions
to
not
address
at
least
eventually
in
ESM
like,
for
example,
development,
production
bills
and
I
believe
that
we
have
vetted
the
array
approach
sufficiently
to
make
sure
that
the
way
that
array
support
is
currently
implemented
allows
us
to
add
these
features
in
the
future.
If
we
so
choose,
and
if
we
don't
have
array
support,
we
will
not
have
that
API
option,
because
older
versions
would
not
understand
how
to
do
fall.
Backs.
F
So
so,
practically
speaking,
import
maps
is
really
very
targeted.
It's
you
know,
you're
in
a
browser,
and
the
fact
that
they
don't
support
arrays
is
is
for
a
very,
very
different
and
is
not
necessarily
you
know
related
to
whether
or
not
exports
should
have
it.
I
definitely
do
agree
that,
for
known
to
the
array,
syntax
does,
you
know,
have
use
cases
and,
if
you're
creating
import
Maps
from
there,
it
could
be
that
the
import
map
take
the
string
from
that
array.
F
F
E
Okay,
yarn
yeah
to
me,
the
brows
are
never
getting
array.
Syntax
and
just
sticking
with
strings
is
one
of
the
best
outcomes
that
we
can
actually
hope
for,
because
that
way
it
will
never
conflict
with
whatever
we
are
doing
instead
of
our
race
and
then
it
would
just
be
the
job
of
a
bundler
to
take
all
the
exports
resolve
the
arrays
to
the
thing
that
actually
should
be
resolving
for
this
target
browser
and
write
out
simple
strings.
So
that
would
be
everything's,
perfect.
G
A
So
a
farmers
a
possible
future
feature
I,
don't
think
that
we
can
necessarily
like
rely
on
that
in
our
design
space,
for
what
it's
worth,
but
I.
Think
that
like
either
way
the
decision
of
what
we
wanted
to,
what
we
want
to
support
I
think
it
could
be
wrong
needs
to
be
able
to
support.
You
know
the
tooling
use
cases
that
in
turn,
would
then
create
an
import
map.
E
Yeah
and
that
approach
of
tools
taking
this
and
turning
it
into
an
input
map,
realistically
that
that's
that
has
to
happen
that
step
anyhow
I
guess
you
know,
browser
will
actually
combine
package
JSON
files,
so
I
think
that
we
need
to
keep
that
use
case
in
mind,
but
I
think
our
crimin
design
was
driven
by
that
it
was
driven
by
allowing
tools
and
node
both
to
understand
it.
Note
immediately
interpreted
and
for
tools
to
convert
it
into
something
at
a
browser
might
understand.
B
A
G
I've
been
weir,
the
road
map
I
just
opened
a
PR,
invite
you
guys
all
to
look
at
it
on
the
modules
repo
I've
been
basically
just
adjusting
it.
Based
on
what
the
discussion
in
this
meeting,
it
sounds
like
from
what
I've
heard.
If
you
know
we're
gonna
continue
development
on
loaders
after
unflagging,
it
sounds
like,
and
that
goes
under
its
own
flag,
continue
development
on
exports.
You
know
now
and
after
unflagging,
it's
not
really
related.
That's
not.
G
It
doesn't
seem
like
that
holds
up
on
flagging
and
I
assume
that
the
@
symbol
stuff
falls
under
that
category
of
like
it'll
ship
when
it's
ready
to
ship
and
it's
not
necessarily
a
whole
blocking
unflagging
or
related
on
flagging.
So
correct
me.
If
I'm
wrong
in
any
of
that,
so
it
seems
to
me
that
the
only
thing
potentially
blocking
unflagging
was
that
topic
we
discussed
for
the
first
half
hour,
which
was
the
the
proxy
issue.
Is
that
it
or
is
there
anyone?
Does
anyone
have
any
other
items
that
are
like?
A
My
impression,
based
on
Jordans
comment
inside
of
your
roadmap
update,
is
that
he
does
not
agree
yet
I'm
pinging
him
independently
and
trying
to
tease
out
of
him
exactly
what
he
would
object
to.
I
think
it
can
be
fair
for
us
to
stay,
though,
that
you
know
you
know
we
want
to
unflagging.
We
want
to
unflagged,
maybe
even
by
like
the
next
meeting
so
well,.
G
G
Based
on
Jordan's
last
meeting
his
issue
was
the
ESM
comedy
oz
packages,
thing
that
the
what
led
to
the
divergent
specifier
and
led
to
the
docs
update,
and
he
just
wanted
us
to
find
a
better
solution
than
telling
people
to
write
a
readme
I
mean
that's
what
he
said.
The
last
meeting
I,
don't
remember
there
being
any
other
issues
that
were
blockers
in
his
mind.
So
you
know.
A
Maybe
we
should
let's,
let's
open
an
issue
to
discuss
unflagging
and
highlight
all
of
the
known
issues
and
try
to
collect
all
the
unknown
issues
in
there
and
then
at
least
reach
consensus
on
that
list.
I
know
it's
kind
of
arguably
what
we
have
inside
of
the
roadmap
already,
but
I
think
centralizing
that
in
the
discussion
will
you.