►
From YouTube: Node.js Project Modules Team Meeting 2020-05-06
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
We're
now
live
on
YouTube
May
6th
edition
of
the
noches
modules
team
got
about
eight
of
us
on
the
call.
We've
got
a
decent
agenda,
so,
let's,
let's
kick
it
right
off.
The
first
thing
that
we
have
on
here
is
CLI
dev
flag
for
development
exports
resolution
conditions.
This
is
a
request
by
guy.
Is
there
anyone
else?
Who
knows
it?
Well,
that
would
be
able
to
leave
the
discussion
for
this
I.
A
Okay,
so
we're
gonna
skip
this
topic
for
now
and
come
back
if
we've
got
an
attendee
I,
don't
to
see
Evan.
So,
let's
start
with
the
back
port.
Unflagging
experimental
modules
for
v12
I
can
introduce
this
one
and
then
we
can
talk.
I
I,
don't
know
if
it's
going
to
be
a
huge
discussion.
So
we
have
discussed
this
group
for
a
while
about
unflagging
on
12
in
December
minor.
We
had
talked
about
that
a
bunch
now
that
chevre
minor
got
delayed.
A
Just
consensus
on
a
few
tiny
bits
here,
so
one
thing
that
we
need
to
consensus
on
is
like
a
are:
we
cool
with
back
porting
the
removal
of
the
flag,
and
this
is
something
that
you
know
the
release
team
into
an
extent
the
TSE
needs
to
be
on
the
same
page
of
as
well.
The
other
thing
is:
are
we
okay
with
back
forwarding
the
flag,
with
or
without
the
warning?
A
And
so
I
have
had
a
conversation
with
a
couple
folks
and
I
want
to
make
a
discrete
proposal,
and
then
you
know
we
could
see
if
we
could
reach
consensus
on
it,
and
this
is
based
on
conversations
I've
had
with
people
on
the
TSC
I.
Think
that
is
good
for
us
to
back
port
I.
Think
it's
good
for
us
to
remove
the
flag.
This
is
you
know
a
good
way
to
push
adoption,
but
I.
A
Don't
think
that
we
should
be
removing
the
warning
for
ESM
now,
we've
removed
the
other
warning,
so
we've
removed
the
warning
now
for
self
referential
modules,
as
well
as
first
conditional
exports,
so
that
no
longer
warns,
but
I
do
think
that
we
should
maintain
the
experimental
modules
warning,
at
least
up
until
the
point
that
14
goes
into
LTS.
So
that
would
be
targeting
you
know
around
October
late
October
for
us
to
remove
the
warning
and
part
of
the
reason
for
this
is,
you
know
like
removing
the
warning
on
14:14
is
currently
the
current
branch.
A
D
So
when
I
originally
saw
your
comments
on
the
PR
I
think
it
was
I
always
like
taken
aback,
because
I
misunderstood
I,
think
what
you
were
talking
about.
So
just
after
some
conversations
with
you,
I
wanted
to
clarify,
like
that.
The
the
with
your
proposal
miles
anyone
using
require
will
see
no
warnings,
no
matter
what,
even
if
the
thing
they're
requiring
uses,
exports
or
conditional
exports.
Yes,.
D
Cool
so
the
only
people,
then,
who
would
see
warnings
or
people
using
dynamic,
import
or
ESM
with
static
import
and
like
that
seems
fine
to
me.
I
prefer
not
to
have
the
warning,
but
because
to
me,
unflagged
is
like
I
think.
If
we're
looking
for
adoption,
then
warnings
hinder
adoption
because
package
authors
won't
use
it
but
like,
but
as
long
as
it's
just
in
ESM
I
think
that's
probably
fine.
It.
A
And
for
what
it's
worth
like,
that,
hindering
of
adoption
is
actually
kind
of
a
point
like
we.
We
don't
want
to
give
too
strong
as
a
signal
yet
and
I
think
some
of
the
feedback
that
we've
received
from
people
so
far
related
to
ESM
people
are
still
learning
how
to
use
it.
There
are
rough
edges,
they're,
skinny,
they're
kind
of
like
getting
their
knees,
learning
to
ride
a
bike.
E
C
D
That's
kind
of
what
I
was
concerned
about
in
lighter
terms
3sm
only
but
like
essentially,
if
that,
if
the
whole
point
of
the
warning
is
to
give,
in
my
opinion,
actionable
feedback,
that's
something
somebody's
doing
is
unstable,
meaning
either
accept
the
risks
or
don't
do
that
and
in
top-level
code.
That's
exactly
what
it
does
right,
like
that's
totally
fine
and
in
code
where
the
instant
you
try
to
use
a
package,
you
get
it,
then
you
don't
use
that
package.
D
A
That
I,
guess
to
that
point
like
removing
the
flag,
makes
it
easier
for
people
to
adopt
keeping
the
warning
stops
people
from
adopting
it
on
mass,
which
was
actually
like
the
purpose
of
kind
of
like
creating
these
waterfalls.
Corie
a
question
to
you
just
kind
of
thinking
about
it
out
loud.
You
would
be
able
to
use
in
a
common
j/s
module
like
require
with
the
software
for
rental
name
as
a
way
to
check
for
ESM
support,
but
that
should
not
trigger
the
warning
with
that.
E
Just
to
I
just
double
check
or
the
NYC
code
and
essentially
I,
have
a
separate
low,
DSM
CGS
file
which
performs
dynamic
import
and
that
file
is
only
loaded
if
somebody
tries
to
load
a
dot,
MJS
config
file.
At
this
time
we
don't
support
loading
J's
config
that
has
ESN
a
minute
so
realistically
for
NYC,
no
warning
will
be
produced
unless
they're,
actually
using
ESM
I
guess
my
guide
seems
appropriate.
C
D
E
D
The
other
thing
is
mouse
to
your
question.
Like
so
I
have
a
package
called
has
package
exports
that
basically
tells
you
if
the
exports
field
is
respected
in
your
current
version
of
node,
it
would
be
trivial
for
me
to
make
another
one
for
like
house
self-referential
or
whatever,
but
like
all
that
tells
you
is
whether
you
can
use
that
feature.
It
doesn't
necessarily
tell
you
about
ESM,
depending
on
what
you're
trying
to
do
with
it
right
like
if
you're
trying
to
avoid
the
warning.
A
Yeah,
it
says
so:
I
guess
some.
The
the
reason
I've
been
looking
at
self-referential
is
the
way
to
do
this
is
like
you
can
try
catch
it.
It
will
fail
and
get
caught.
It
doesn't
require
syntax
that
old
versions
of
node
doesn't
support
and
all
versions
of
node
that
support
ESM
without
a
flag
support
self-referential
without
a
flag
and
self-referential
wasn't
in
flag
before
so
I
think
that's
the
right
way
to
sniff
it
myself.
A
Although
people
have
done
hacky
things
to
support
self
referential
modules
before
like
installing
yourself
that
could
make
things
weird,
there
was
another
one
that
Richard
Lao
brought
up.
That
I
think
is
worth
considering,
which
is,
if
anyone
who's
not
currently
opting
into
ESM,
but
maybe
using
dependencies
that
will
change
differently.
A
What's
the
flags
removed
so
like
once
the
flag
is
removed,
any
dependency
that
was
being
required
that
was
previously
using
the
main
entry
point
will
all
of
a
sudden
start
using
the
exports
entry
point,
and
so
I
think
that
there's
like
a
question
about
if
removing
this
flag
is
semver
major
I
still
don't
think
it
is,
but
I'd
love
to
get
folks
to
sense.
On
that.
A
Warning
right:
there's
in
12
16
3.
There
is
no
more
warning
for
self-referential
or
for
conditional
exports.
We
remove
those
warnings,
but
I
don't
believe
I
could
be
wrong,
but
I
believe
that
exports
works,
but
conditional
exports
is
still
in
self.
Referential
are
still
behind
the
flag,
so
they're
not
on
so
people
can
have
an
a
in.
D
A
B
D
But
like
the
presence
of
conditional
are
not
really
isn't
even
what
I
think
kicks
in
I
think
it's
that
in
spirit
someone
should
have
written
it
so
that
their
main
and
their
exports
are
the
same
right
or
have
the
same
API,
but
in
practice
they
may
not
have,
and
so
somebody
may
like,
like
you
could
easily
have
said,
have
written
a
package
that
says
my
main
is
no
12
and
below
my
exports.
Dot
is
node
13
and
up
and
I'm,
using
syntax
in
my
13
and
up
piece
that
won't
work
in
node
12.
D
D
I
have
so
other
than
my
has
package.
Exports
detection
package
right,
like
I,
have
written
a
package
called
es,
get
iterator
which
basically
does
terrible
things
in
old
browsers
in
order
to
to
reliably
get
an
inter
a
tor
interface.
There's
like
stop
iteration
errors
and
all
sorts
of
craziness,
but
I
used
conditional
exports
so
that
because
I'm
because
I
know
which
node
version
like
which
node
versions
are
the
only
ones
that
can
get
that
entry
point.
And
so
that
has
a
simpler
implementation.
D
At
the
moment,
yeah
so
I
didn't,
but
I
could
have
used
like
optional
chaining,
for
example,
and
then,
like
you
know
that
I
don't
know
something
something
that
works
in
node
13,
but
not
12,
probably
not
optional
chaining,
but
I
like
it
would
have
been
really
easy
for
me
to
have
done
that,
because
at
the
time
I
wrote
that
entry
point
I
was
thinking.
Oh,
these
are
the
only
versions
of
node
that
can
ever
run
this.
F
F
This
particular
issue
is
something
that
we
had
a
long
session
with
James
snow
with
at
no
JS
interactive
and
discussing
if,
if
landing
exports
would
be
a
breaking
change
for
common
jazz
or
semi
major
and
he
seemed
to
think
it
was
fine
on
the
LTS
Bronx
I
thought
that's
just
worth
mentioning
as
a
data
point.
Of
course,
there's
risk.
So
the
sooner
we
get
we're
going
to
do
it.
Do
it
soon.
Otherwise
don't
do
it.
You
know
where
people
are
publishing
about
ten
packages
with
exports
every
day.
At
the
moment
it's
going
up.
F
Superfast
is
over
500
packages.
With
the
exports
filled
now
I
mean
we
could
potentially
just
go
through
that
data
set
and
check
that
it's
not
breaking
on
that
data
set
as
well.
I,
don't
know
how
easy
that
is,
but
someone
wants
I've
got
a
guest
with
all
the
packages
with
exports.
One
could
just
literally
run
through
them,
require
them
in
no.12.
With
with
exports
unpacked
and
then
see,
if
we
want
to
be
sad,
careful,
otherwise
just
throw
it
up
and
see
what
happens.
But
it's
it's
probably
good
to
be
careful.
A
A
A
A
So
I
think
there
is
something
to
be
said,
at
least
in
my
own
impression
that
it
is
not
likely
that
these
are
going
to
be
extremely
deep
in
people's
module
graphs
in
ways
that
are
unreachable,
because
it
is
code
that
has
been
written
more
recently
and
that
those
who
are
adopting
it
are
more
than
likely
to
have
like
a
fast
cadence
in
fixing
problems
if
they
arise.
That's
at
least
my
personal
opinion.
A
You
know
we
could
find
out
the
hard
way
but
kind
of
based
on
this
does
any
one
block
the
idea
of
landing
this
in
12
with
the
warning
intact
and
with
with
I
guess
the,
with
the
caveat
that
you
know
we're
aiming
for
an
October
ish
date
of
removing
the
warning
around
when
like
14
goes
into
LTS,
but
if
we
have
large
ecosystem
outcry-
or
you
know
technical
reasons
to
revisit
this
decision
that
we
can
handle
that
pragmatically
and
approach
the
TSE
to
do
it
sooner.
If
we
need
to
is
everyone?
Okay,
with
that.
A
F
Sure
so
I
guess
this
is
in
many
ways
something
that's
incredibly
useful
for
bundlers
and
it
it's.
You
know
that
the
standard
pattern
that
reacts
has
where
it's
got
an
index
file
and
it
checks,
processed
or
environment,
note,
environment,
equal
to
production,
and
then
it
exports
from
a
production
file.
Otherwise
it
exports
from
a
development
build.
So
there
are
two
separate
files
and
the
alternative
to
this
kind
of
approach,
so
that
there's
two
things
that
that
happen
with
these
environment
variables,
one
its
determining
the
graph
itself
and
two.
F
You
also
have
dead
code
elimination
that
can
happen
when
you're
checking
these
these
dev
conditions
and
if
statements
and
one
of
the
benefits
of
doing
it
at
the
graph
level,
is
that
every
time
you
import
a
module,
you
import
all
the
side-effects
of
all
its
dependencies.
So
if
you,
if
you
even
just
have
a
section,
that's
like
within
an
if
statement,
if
you've
got
the
import
at
the
top
for
a
dependency,
that's
used
by
it,
you
still
have
to
include
dependencies
if
they
have
side-effects
and
most
dependencies
aren't
pure
packages
or
pure
modules.
F
So
bundler
skit
would
still
struggle
to
remove
the
dev
code
on
those
branches.
You
can
do
techniques
to
get
around
this.
The
alternative
is
basically
a
weight
dynamic
import.
So
you
have
an
if
statement
on
your
development
condition
dynamically
import,
your
development
dependencies
with
the
top
level
of
weights,
and
it's
one
of
the
nice
things
that's
enabled
by
top
level
weight,
and
then
you
can
use
that
dev
dependency
and
have
your
dev
code
and
especially
in
a
specific
branch.
There's
two
problems,
one.
F
We
don't
have
top-level
await,
yet
it's
taking
its
time
and
two:
it's
something
that
no
bundlers
support
yet
because
they
haven't
had
to
so
there's
also
complexities
on
the
bundler
side
in
terms
of
how
well
they'll
be
able
to
support
that
pattern.
So
by
doing
it
at
the
graft
level,
you
get
all
these
benefits
of
just
immediately.
F
You
don't
have
to
go
through
any
of
the
dependencies
or
do
pure
analysis
on
dependencies,
or
any
of
that
you
can
just
immediately
just
have
two
builds
and
you're
switching
between
those
builds
and
that's
very
much
a
benefit
that
conditional
exports
can
bring
that
you
just
have.
These
two
separate
builds.
It's
the
reason
why
we
don't
do
all
of
the
features
of
conditional
exports
through
if
statements
in
a
single
code
file.
F
So
if
you
want
to
point
to
a
specific
development,
build
it's
a
development
condition,
and
then
the
question
is
well:
we've
got
interest
from
bundler,
so
webpack
are
interested
in
it
and
I
believe
I'm,
not
sure.
Actually,
if
roll-up
are
are
keen,
I
must
discuss
with
and
further,
but
at
least
Tobias
is
interested
to
implement
it
for
now
and
then
the
question
is:
is
this
something
that
we
put
in
node
itself
and
by
putting
it
in
node?
F
So
is
it
something
that
that
should
go
node
and
if
it
does
go,
node
harsh
with
node
turn
it
on,
and
what
else
should
enable?
So
right?
Now
it's
a
it's
a
diversity
flag
after
a
few
iterations
for
consensus,
it's
a
flag
when
you
run
node
and
setting
that
flag
will
always
run
the
development
condition
in
conditional
exports,
which
can
also
nest
because
conditions
can
nest.
So
you
can
nest
it
with
browser
or
Nesta
with
node.
F
And
then
the
only
thing
we're
struggling
with
at
the
moment
is
if
we
should
reflect
this
information
in
a
variable
as
well
it
within
the
execution
environment-
and
this
is
a
tricky
one.
Firstly,
because
it's
very
difficult
to
get
consensus
in
node
on
it,
some
people
one
thing
some
process.
Some
people
wanted
to
be
very
general
for
all
conditions
like
a
lookup.
Some
people
want
it
to
be
a
global,
specifier
and
others
wanted
to
be
an
import
and
I.
F
Think
one
of
the
driving
motivations
behind
this
is
that
it
should
be
a
is
well
at
least
it's
trying
to
be
something
that
can
be
adopted
universally
and
one
of
the
problems
there
is.
We
simply
don't
have
a
patent
for
universal
environment
variables
apart
from
Global's
and
adding
a
new
global,
really
isn't
an
option.
F
So
it's
almost
like
we're
stuck
with
the
platform
issues
there
that
you
know
that
there's
no
way
to
set
an
environment
variable
in
the
browser,
apart
from
just
setting
a
global
and
no
one
is
going
to
let
us
just
set
in
my
retrieve
global
unless
we
make
a
process
or
something
like
that,
so
that
that's
a
tricky
one
and
then
so
for
now,
I've
just
set
it
up
without
the
environment
variable
and
it
would
be
nice
to
merge
in
them
over
time.
We
can
add.
G
So
I'm
gonna
speak
a
little
bit
from
experience
here.
Nodes
conditional
exports
in
the
resolver
is
not
the
first
JavaScript
runtime
to
have
conditional
exports
react
native
resolution
for
each
platform
that
it
runs
on
essentially
already
does
conditional
exports
and
I
will
tell
you
from
experience.
It
is
absolutely
terrible
from
a
tooling
perspective
because
you
have
to
run
individual
builds
for
every
platform
which
creates
an
exponential
explosion.
G
The
amount
of
things
that
can
run
because
of
that
I
can
only
recommend
that
people
actually
never
use
conditions
unless
absolutely
necessary,
because
the
conceptual
complexity,
complexity
of
what
can
actually
execute
explodes
as
such,
while
I
understand,
we
added
conditional
exports
solely
for
compatibility
reasons.
I
would
much
rather
recommend
we
recommend
people
actually
never
use
it
for
anything
else.
B
I
wanted
to
bring
some
additional
context
on
why
this
is
being
talked
about
a
little
bit
more
prevalently
right
now,
so
this
occurred
in
part,
because
people
creating
react,
have
a
variety
of
development
feature
flags.
Essentially,
when
you
enable
the
development
mode,
a
variety
of
side
effects
occur.
It
is
not
purely
about
the.
B
I
think
there
is
something
to
be
said
about
the
difficulty
in
understanding
which
implementation
is
about
to
be
picked
up.
However,
if
we
do
implement
the
feature
Flags,
like
top-level
await,
would
allow.
That
seems
to
also
necessarily
have
your
tooling
take
both
branches
of
the
feature
flag
to
understand.
What's
going
on,
I'm,
not
sure,
at
least
in
the
use
case,
that
I've
heard
this
being
used
for.
D
A
D
D
You
know
you
could
argue
as
well
they're
selecting
between
platforms
right
like
the
node
one.
You
know
it
paves
the
way
to
add
a
browser,
one
or
denno
or
whatever,
but
development
and
production
are
like
a
matrix.
You
apply
to
each
of
those
environments
and
it
seems
like
it's.
It
just
doesn't
seem
right
to
me
to
conflate
them
in
the
same
object.
D
It's
weird
and
unfortunate
that
react
behaves
differently
in
production
than
it
doesn't
development
and
they
do
it
for
performance
not
like,
because
it's
better
so
like
I
would
rather
see
a
world
where
act.
React
can
make
one
build
and
not
a
world
that
makes
it
easier
for
them
to
make
multiples.
You.
D
A
A
G
Right
so
specifically
on
the
subject
of
react,
the
next
version
of
react
to
handle
the
dev
mode
versus
prog
mode,
swap
they
took
over
the
transform4
JSX
and
emit
an
entirely
different
import
and
an
entirely
different
transform
in
dev
mode
versus
prod
mode
at
Build
time
ergo.
They
need
no
runtime.
Switching
that.
F
G
F
F
Some
publishers
want
to
optimize
their
code
for
the
target
environment
and
they
can
make
much
deeper
optimizations
than
the
average
build
tool,
because
maybe
they
have
their
own
build
tools
or
they
have
a
very
particular
configuration
the
common
catch
when
people
build
react,
apps
is
that
they
don't
know
it's
a
set
process,
that
environment
note
environment
and
they
can
end
up
building
two
versions
of
reacts
and
get
double
the
code
size.
So
these
are
real
problems
that
we
have
today.
F
Can
you
trust
the
bundler
on
the
user
side
and
if
you're
a
packaged
author
and
if
you're,
a
packaged
author,
that
cares
a
lot
about
how
your
performance
and
how
users
use
your
package
you're
gonna
want
to
optimize.
I
mean
I'm,
not
saying
this
is
for
everyone.
But
if
you
are,
you
know
a
team
like
react:
optimizing
for
target
environments
with
as
many
optimizations
as
possible
with
Google
closure.
F
All
these
things
is
going
to
get
you
the
best
performance
out
of
your
package
and
for
your
users,
and
in
that
case,
you're
gonna
end
up
with
a
build
per
environment,
so
you're
going
to
want
to
link
those
builds
per
environment
and
the
conditional
exports
basically
is
tailored
to
this
use
case
of
people
optimizing
their
packages
for
the
environments
before
publishing.
It's
not
to
say
that
every
publisher
has
to
do
that.
A
A
A
B
Some
bundlers
do
support
it.
Some
tools
to
support
it,
but
it's
a
bit
of
a
pain
to
parse
it
also,
if
you
use
some
syntaxes
she's,
not
picked
up,
which
we've
had
concerned
with
other
places
in
this
group,
but
even
if
you
use
it,
you
end
up
with
a
similar
problem
that
we've
been
talking
about,
of
not
wanting
two
different
builds
or
two
different
things.
B
These
things
aren't
merely,
for
you
know,
production
builds.
There
are
some
things
you
never
want
to
be
on
your
consumer
facing
site,
for
example,
it's
a
similar
situation.
Here
we
have
things
that
we
want
when
we
the
application
runner.
However,
we
run
other
people's
code
as
well.
We
don't
want
them
to
do
stuff
with
it.
B
B
You
kind
of
have
it
if
you
do
that,
if
else
branching
stuff,
but
it
may
not
work
with
tooling
so
I
I,
don't
think,
there's
a
clear
alternative
path
except
telling
people
they
shouldn't
do
what
they
want
to
do.
If
we
are
saying
that
having
two
different
modes
of
operation
is
problematic,
I
want
those
two
different
modes
of
operation,
but
I
don't
see
a
clear
winner
versus
this
route.
If
somebody
could
explain
like
why
they
think
an
alternative
would
be
better
or
exactly
what
this
feature
causes
that
an
alternative
doesn't
also
suffer
from.
G
So
as
an
immediate
follow-up,
yes,
it
does
feel
like
we're
just
moving
this
stick
around,
because
we
are
in
fact
just
moving
where
the
branch
happens
from
explicitly
encode
today
to
implicitly
in
a
loader
explicitly
encode
today
is
something
handful
of
tools
already
supports
in
a
loader.
Nothing
supports
right
now,
but
we're
assuming
it's
better
because
reasons
now.
Secondly,
there
is
a
problem
that
makes
it
so
this
actually
isn't
particularly
safe
to
do
and
that's
the
exports
only
apply
to
external
references
to
things.
G
So
let's
say
you
do
specify
different
dev
and
prod
on
tree
points
to
your
package
internally
within
your
package,
assuming
you
haven't,
bundled
your
entire
package
to
only
one
file.
None
of
those
conditions
are
going
to
be
applied,
and
so,
unless
you
actually
have
two
completely
independent
trees,
where
you
like
I,
have
medev
package
and
my
prod
package
sitting
in
completely
different
folder
structures
and
never
do
the
two
talk
you're
very
liable
to
in
your
development.
F
Yeah
I
just
wanted
to
say
that
it's,
it
seems
from
from
what
Tobias
has
said
it
seems
like
he
probably
will
implement
this
in
conditional
exports
in
webpack
and
the
fact
that
proposing
it
was
enough
to
see
that
he
was
already
interested
in.
It
shows
me
that
this
is
a
need
in
bundlers
and
if
webpack
supports
it
gets
a
large
amount
of
user
base.
So
I
think
the
question
here
is
really
does
node
want
to
support
it.
A
A
F
A
So
the
TLDR
here
is,
as
of
today,
importing
common
j/s
is
supported,
but
not
with
named
exports.
So
the
rediscovering
the
lead,
the
high-level
bit
I
think
is
worth
discussing,
is
like
just
straight
up
from
a
problem.
Standpoint
like
is
the
problem
of
named
exports
from
common
jeaious
modules,
something
that
we
want
to
solve.
A
I
know
that
folks
have
feelings
about
making
a
behavior
for,
as
we
call
them
faux
modules,
making
a
smaller
Delta
between
our
implementation
and
that,
then
there
are
a
number
of
different
solutions
that
we
could
explore,
one
being
out
of
our
execution
of
CJ
s,
another
being
stack
analysis
of
CJ
s.
Another
being
you
know,
a
double
execution,
but
I
think
is
probably
the
best
use
of
our
time
for
the
next
eight
minutes,
without
getting
too
much
into
the
weeds
to
the
solutions
of
the
problem.
I
think
we
should
reach
consensus
on.
A
If
this
is
a
problem
space,
we
even
want
to
continue
to
dig
into
we
had
had
we
had
at
least
it
seemed
to
be
a
degree
of
consensus
around
this
dynamic
modules,
and
the
spec
was
another
thing
that
we
discussed,
although
like
to
be
honest,
I,
don't
think
that
that
really
has
lakes,
but
just
like
there's
a
number
of
different
solutions,
this
space
that
we've
tried
to
explore
is
this
a
problem
space.
We
want
to
revisit
independent
of
the
solution
that
we
use.
C
The
only
way
to
do
that
is
to
you
know,
give
a
good
faith
effort
to
the
best
possible
solution
we
can
come
up
with,
for
what
named
exports
would
be
and
test
it
and
see
how
good
or
bad
it
would
be
like.
Does
it
catch
99%
of
cases
or
not
or
you
know,
and
then
at
least
we
have
something
we
can
point
to
for.
B
I
think
my
priority
here
is
we're
seeing
a
lot
of
people
having
problems
transitioning
their
modules
I
want
to
make
a
real
value,
a
ssin
of
this
on
how
to
allow
an
easier
transition
for
some
subset
of
people.
I,
honestly,
don't
think
we
can
reach
100%
coverage
for
everything,
but
I
will
state
that
I
am
very
against
the
reordered
solution,
vector
it.
It
has
a
lot
of
weird
effects
and
no
tool
does
it
currently,
at
least
for
static
analysis?
There
are
some
tools
that
exist,
so
we
could
understand
what
they're
doing
and
what's
wrong.
H
Yeah
I
think
I
slightly
disagree
with
the
we
need
to
write
code
at
this
point,
because
I
don't
think
that
I
think
we
understand
how
well
the
different
approaches
would
work
for
the
different
kinds
of
packages,
as
we
know
that,
to
the
extent
that
we
have
documented,
they
do
work
and
the
so
far
the
objections
have
rarely
been,
at
least
from
what
I
have
seen
hey.
This
wouldn't
work
to
the
degree
that
it's
probably
going
to
work,
it's
more
that
people
have
objected
to
the
degree
that
it
could
possibly
work.
H
H
Just
because
that's
not
how
bindings
work
you
can
dynamically
add
a
binding
late
at
one
time
like
that
exists
in
Congress,
especially
ones
in
their
cyclicals.
So
there's
just
a
limit.
There
exists
contrast
modules
that
have
an
indexed
years
that
just
re-exports
like
this
Express
Express
as
an
index
jazz.
That
is
just
modular
exports,
equals
to
require
live
index.
Well,
it
has
only
an
import/export
if
you
just
cross
this
one
file.
H
So
if
Express
already
doesn't
work
with
parsing
directly
I,
don't
think
we
need
to
implement
it
to
tell,
and
yes
we
can
then
say:
hey
Express
just
needs
to
make
a
change
to
work
with
this
parsing
approach.
But
at
that
point,
is
it
really
that
much
more
work
to
edit
a
comment
in
MGS
wrapper
around
the
index?
H
A
Thanks
guy
so
I'm
gonna
add
something
really
quickly.
I'll
just
drop
this
in
the
chat.
It's
a
pull
request
that
I
started
working
on
yesterday.
This
pull
request
hooks
into
the
loading
phase
and
when
a
module
fails
for
importing
a
named
export,
it
checks
to
see
if
the
module
that
you
imported
from
is
a
common
j/s.
Module
gives
a
better
warning,
including
actual
code,
that
you
can
copy
and
paste
to
replace
your
named
imports
that
will
just
work
using
the
exact
named
imports
and
specifier
that
you
used.
A
It
is
suffice
to
say
that
the
regular
expressions
in
here
maybe
need
a
little
bit
of
thinking
and
there's
a
lot
of
testing,
but
we
need
to
do
before
landing
it
but
kind
of
yawns
point,
and
what
we're
going
at
here,
like
I,
do
think
another
approach
here,
at
least
in
the
meantime,
if
we
don't
have
consensus,
is
definitely
improving
the
documentation
and
improving
errors
to
make
sure
that,
like
when
things
break
they
let
people
know
explicitly
what
broke
why
it
broke
and
then
give
them
kind
of
like
the
solution
to
improve.
It.
A
I
think
that
I'm
leaning
personally
towards
where
Yan
is,
although
I
would
be
lying
if
I
said
I
was
in
flip-flopping
I
want
to
improve
the
experience
for
folks
that
are
trying
to
move
towards
modules,
but
at
the
same
time
the
kind
of
clear-cut
you
have
a
default
and
that's
it
for
common
Jas.
Unless
you
write
an
explicit
wrapper
is,
is
to
teach
people.
It
is
easy
to
understand.
A
It
does
not
require
like
if
we
were
doing
the
static
analysis
solution,
an
understanding
of
like
when
modules
are
static
when
they're
dynamic,
when
things
would
work
when
they
wouldn't
work.
It
just
seems
cleaner.
I
realized
that
it's
important
for
us
to
remain
pragmatic
here,
so
I
not
made
a
decision,
but
I
just
want
to
state
that
I
do
feel
like
I'm
leaning
towards
you
know
not
adding
this
feature.
A
A
F
Yeah
I
just
want
to
mention
that
I'm,
probably
leaning
towards
wanting
to
implement
this
I
thought
we
were
gonna,
get
away
with
it
with
just
the
defaults,
but
it's
it's
clear
that
all
bundlers
and
all
tools
and
dev
servers
and
all
these
things
are
going
to
continue
to
support
named
exports
for
common
jazz
modules.
So
it's
going
to
be
very
much
a
continual
friction
where
users
will?
Probably
you
know
if
they're
developing
in
the
browser
and
then
they
move
to
note
or
any
type
of
universal
scenario.
F
They're
always
gonna
keep
hitting
this,
and
especially
seeing
the
amount
of
times
it's
come
up
recently.
I
think
it
can
be
worthwhile
to
just
mitigate
that
pain,
yeah,
I
think
passing
works.
The
the
biggest
concern
to
me
was
doing
it,
for
every
comment
is
module
loaded,
but
it
seems
like
we've
got
agreements.
I
only
do
it
on
the
boundary
with
these
modules,
in
which
case
it,
the
performance
loss
is
contained,
and
it's
likely
only.
A
C
A
What
I
would
suggest
guy
right
now,
at
least
for
myself,
would
be
perhaps
close
the
issue
that
we
have
right
now,
because
that
is
long
and
it's
topic
was
something
else.
I
think
that
we
should
make
a
new
issue.
That
is
explicitly
about
like
the
named
exports,
with
more
or
less
the
equivalent
of
an
RFC
of
what
you
plan
to
implement,
and
we
should
try
to
build
some
consensus
around
that
before
you
start
implementation,
because
I
want
to
be
respectful
of
your
time.
A
I
recognize
that
on
the
node
project,
code
speaks
but
I,
I
I,
don't
think
that
we
have
the
consensus.
Yet
that
can
be
a
strong
signal
that
investing
your
time
right
now
would
not
be
for
nothing.
I,
think
we're
close,
but
I
would
be
just
made.
If
you
put
it
all
this
time
and
then
it's
gonna
work
out.
Okay,.
F
A
That
sounds
great,
I
think
and
we
could
even
like
I.
Don't
think
that
this
is
so
time-sensitive
that
we
need
to
do
something
out-of-band
but
like
if
you
feel
that
we
should
that's
something
we
could
explore
as
well.
But
I
I
think
I.
Think
that,
especially
for
this
one,
because
it's
kind
of
controversial
within
the
group
I
think
it
would
be
good
to
scope
it
and
build
consensus
around
that.
First,
the.
F
A
And
I
actually
think
a
really
good
reason
to
talk
about
timing
here
would
be
if
this
is
something
we
want
in
before
we
unflagged
but
I
feel
like
this
is
something
that
needs
to
live
on
current
a
little
bit
first,
and
it's
also
something
that
arguably,
is,
is
semver
minor,
because
it's
adding
a
feature,
but
let's,
let's
kick
it
off
to
an
issue
we've
run
over
by
seven
minutes.
I
did
not
do
a
good
job
of
scoping
this,
so
thank
you.