►
From YouTube: Node.js Foundation Modules Team Meeting 2019-08-28
Description
A
A
A
C
So
this
was
so
when
I
was
working
on
the
attempt
to
try
to
get
dual
packages
and
to
be
clear
what
I
mean
by
that
is
like
the
same
package
that
contains
both
ESM
and
common
data
sources
being
able
to
do
require
package
as
well
as
import
package
and
the
you
know
if
it
works
in
both
cases.
We're
and
how
it
works
is
up
for
debate
and
there's
many
approaches
for
that.
C
But,
as
in
the
user,
wouldn't
have
to
write
like
our
current
solution,
that's
in
the
Docs
is
the
user
has
to
write,
say,
require
package
and
then
import
package,
slash
module
item
to
s
or
import
package
and
then
require
modules,
left
common
tasks
or
something
like
that
or
much
less
common
yeah.
So
the
idea
was
to
not
have
to
have
this
like
divergent,
like
these
two
specifiers.
So
miles
pointed
out
in
the
discussion
about
that
that,
if
we
have
one
specifier
mean
two
different
things
in
the
to
model
systems.
C
This
can
cause
chaos
and
it
actually
has
already
come
up
once
with
the
graph
QL
project
when
they
started
to
try
to
adopt
MJS
under
the
previous
node
7.
Through
11
version
of
experimental
models,
so
I
wanted
to
I,
didn't
fully
understand
the
issue,
so
I
dug
into
it
a
bit
and
tried
to
like
come
up
with
like
a
minimal
repro
of
what
the
issue
was,
that
I
can
kind
of
get
a
grasp
on
it,
and
my
sense
was
that
this
isn't
just
a
dual
package
thing.
C
It
would
also
apply
to
extension,
searching
if
you
had
filed
a
time
jeaious
and
filed
a
j/s,
and
you
just
did,
like
you
know,
dot
flash
file
or
import
that
file
required.
A
flash
file
resolve
the
two
separate
things
into
separate
model
systems,
basically
the
same
issue
so
as
I
tried
to
break
it
down
in
that
issue,
we
basically
have
three
options.
C
One
status
quo
like
what's
there
now
is
what
we
should
where
we
ship
with
when
we
on
Flag,
and
we
would
probably
get
rid
of
the
the
flag
that
lets
you
opt
into
the
automatic
extension
resolution
option
to
be
like
there's
a
hazard
but
I
don't
care.
We
write
about
it
in
the
Docs
that
advise
you
to
how
to
avoid
it.
C
But
then
it's
just
on
the
user's
to
not
have
this
problem
or
option
3
come
up
with
some
clever
technical
solution
to
avoid
the
problem
and
the
only
one
that
anyone
at
least
on
the
thread
thought
of
was
having
require
I'll,
be
able
to
import
ESM.
So,
if
I
published
this
package
that
has
both
Commodus
and
ESM
sources
in
node
12
import
package
require
package
would
both
times
pull
dsm
sources.
C
D
So
basically,
the
hazard
you're
describing
is
one
that
has
always
existed
in
NPM,
not
just
because
of
extension
sourcing,
but
also
because
of
package
duplication,
which
is
a
normal
and
necessary
thing
and
mature
package
manager.
So
the
solution
to
this,
the
long
well
widely
known,
but
perhaps
long
misunderstood,
solution
to
this
is
your
dependencies
and
anything.
That's
stateful
or
a
singleton
needs
to
be
a
peer
dependency
so
that
you
only
have
one
copy
in
the
tree.
This
is
not
something
that
can
be
fixed
by
leaving
things
as
they
are.
D
This
is
not
something
that
can
be
avoided
and
other
than
the
solution
I
mentioned,
and
if
you
use
that
solution,
then
extension
searching
and
dual
packages
offer
no
additional
hazards.
So
for
me,
I
have
not
yet
seen
any
explanation
or
any,
like
example
of
a
case
that
differs
from
that.
So
to
me
there,
this
hazard
is
not
a
new,
it's
not
a
hazard
that
this
introduces,
and
so
it
should
not
be
relevant
to
discussing
dual
packages
or
extension
searching
it.
D
Just
is
the
it
remains,
the
the
universal
truth
that
if
you
have
a
stateful
thing,
you'd
have
to
ensure
there's
only
one
copy
of
it,
and
my
understanding
of
the
graph
QL
issue
you
mentioned
was
that
they
had
two
copies
of
it,
one
in
CGS
and
one
atsm,
and
that's
the
same
thing
that
would
happen
with
duplicate
packages.
We.
A
Have
yarn
and
then
Wes
and
then
I
would
like
to
say
something
and
then
to
stop
for
a
second
I,
do
believe
that
we
now
have
quorum
on
the
call
we're
up
to
twelve
people,
ten
of
whom
are
active
members.
So
after
this
agenda
item
I'd
like
to
go
through
the
pull
request
and
just
quickly
review
and
approve
the
new
people
who
wanted
to
be
added
as
observers
yawn,
you
had
something
to
add.
Yeah.
E
I
think
it's
it's
skipping
over
some
final
details
to
say
that
this
is
nothing
new.
It's
definitely
knew
that
like
Peter
Pan
sees,
cannot
save
you
from
this,
assuming
that
people
are
publishing
packages
that
have
both,
which
is
the
only
scenario
where
this
is
actually
a
thing
right.
It's
now
knew
that,
even
if
you
have
only
a
single
copy
of
a
package
because
dynamic
extension
resolution
applies,
you
might
now
find
two
different
copies
of
the
same
implementation
within
that
same
package.
E
So
there
are
ways
to
address
it
by
explicitly
having
specific
files
not
be
duplicated
within
that
package,
but
it's
definitely
new
like
the
fact
that
you
have
to
design
your
package
specifically,
so
that
your
transpile
sources
are
not
100%
copies
of
each
other,
but
that
you
only
compare
inspired.
Parts
of
the
package
and
parts
of
the
package
need
to
be
manually
maintained
is
something
that
the
ecosystem
is
definitely
not
used
to.
B
Yeah
I
want
to
go
backwards
in
time
with
the
things
I
want
to
respond
to
here.
It
specifically
like
I
do
agree
with
Jordan
that,
like
that
has
it
does
already
exist,
but
I
also
agree
with
the
fact
that,
like
the
real
problem,
isn't
the
fact
that
the
hazard
already
exists
yes
has
already
existed.
People
know
how
to
work
around
it
by
having
separate
packages
that
you
only
include
one
copy
up
by
their
demands.
B
It's
correct,
however,
the
current
modern,
tooling
and
recommended
practices
for
working
with
ESM
and
transpiled
copies
of
the
s/m
order,
ship
them
side-by-side
in
the
same
package,
which
is
where
we
run
into
the
problem
like
and
changing
everybody's
views
on.
That
is
a
monumental
task
so
like
that
shouldn't
necessarily
be
taken
lightly.
It's
simply
that
current
patterns
for
that
invite
problems
going
back
even
further
to
what
Geoffrey
was
saying
like
the
third
interesting
technical
solution,
isn't
actually
that
interesting
like
we
don't
actually
need
full
require
of
esm,
that
is
in
Hansen.
B
All
you
need
to
be
able
to
say
is
that
the
CJ
has
all
you
need
to
be
able
to
say
is
that
the
ESM
resolver
is
a
strict
subset
of
the
CJ
s
resolver,
so
it's
all
salty
it
all.
That
means
is
the
CGS
resolver
will
do
everything
like
the
ESM
resolver
would
do
I,
look
up
exact
files
and
all
that
jazz
lie
and
we'll
load
files
with
the
same
priority
in
at
the
ESM
resolver
does
using
the
same
flags
the
ESM
resolver.
Does
that
way?
B
If
the
result
turns
out
to
be
something
that
should
be
loaded
as
an
e
sm
file,
the
CGS
resolver
can
simply
say
no
and
throw
because
it
knows
that
you
should
not
do
that.
That's
all
you
don't
actually
need
to
actually
be
able
to
resolve
it
to
an
object
or
do
anything
with
it.
You
just
need
to
be
able
to
know
that
you
should
not
leave
the
thing
like
actually
loading.
It
would
be
a
nice
enhancement
on
top
of
that,
but
it's
not
actually
the
part
that
fixes
the
problem.
E
I
just
want
to
clarify
what
what
West
was
just
saying
so
I'm,
assuming
that
this
implies
that,
for
example,
yes,
M
would
either
never
apply
dot
MJS
or,
if
it
would,
it
would
do
it
with
a
lower
priority
than
all
the
existing
things,
including
everything
as
in
required
extensions,
because
otherwise
it
could
never
actually
do
it
without
stopping
to
be
a
subset
of
the
GJ
CJ
s.
Resolution.
B
So
like
the
idea,
there
is
the
ESM
resolver
today
in
fact
sees
MJ
s
as,
like.
You
have
to
include
the
exact
extensions.
There
is
no
priority
system
right
now
at
all,
and
then
the
follow-up
to
that
is
yes.
If
there
is
extension,
searching
the
priority
and
ESM
needs
to
be
the
same
as
in
CJ.
Yes,
however,
that
priority
is
free
to
be
modified
in
both
at
the
same
time,
by
something
like
the
type
module
field
which
can
easily
be
recognized
by
both.
A
So
so,
I
guess
kind
of
like
stepping
back
for
a
second
and
thinking
about
what
kind
of
like
what
we're
talking
about
here.
What
we
want
to
accomplish
and
why
we're
bringing
this
up
is
I,
believe
that
the
reason
why
I
Jeff
brought
this
up
was
to
try
to
bring
you
know
more
evidence
towards
why
we
don't
want
to
turn
extension
resolution
on
by
default.
We
have
other
reasons
as
well,
but
like
not
having
it
on
does
by
default,
does
protect
against
this
hazard.
I
think
that
you
know
to
Jordan's
point.
A
Yes,
this
hazard
to
a
certain
extent
already
exists
in
the
ecosystem.
It's
part
of
the
reason
why
NPM
started
flattening
dependencies
in
a
future
in,
like
you
know,
newer
versions
of
NBM
for
front-end
applications,
specifically
to
minimize
wear
this
wear.
This
hazard
would
hit-
and
in
my
own
personal
experience
when
this
hazard
does
hit,
it
hits
in
ways
that
are
not
very
intuitive.
It
hits
in
ways
that
break
in
very
mysterious
ways
and
in
order
to
understand
exactly
what
is
happening,
requires
somewhat
sophisticated
understanding
of
the
module
loading
algorithm
so
well.
A
I
recognized
that
this
hazard
exists
and
that
things
like
peer
dependencies
and
I
know
NPM
seven
is
looking
at
introducing
new
ways
of
handling
peer
dependencies.
Ok,
help
solve
it.
I.
Don't
find
that
personally,
a
compelling
reason
for
us
not
to
try
to
minimize
the
hazard
in
our
own
runtime
I.
Think
that
you
know
we've
pointed
at
this
hazard
as
one
of
the
reasons
for
not
having
file
extension
resolution
compatibility
with
import
name
Maps
being
another,
but
you
know
I
I
am
personally,
you
know
not
left
I,
guess
stepping
back
the
intention
of
open
opening.
A
This
issue
I
think
was
to
maybe
closed
the
session
around
whether
or
not
we
were
going
to
turn
extension
resolution
on
by
default.
That
is
the
reason
why
we're
discussing
it.
If
we
want
to
discuss
other
like
major
changes
to
how
we
do
things,
then
that
should
maybe
be
its
own
discussion,
but
maybe
could
I
just
amend
that
slightly.
A
A
Okay,
so
so
pseudo
more
accurately
than
say,
HF
and
let
me
know
if
I'm
wrong,
you
would
like
to
remove
dual
packages,
has
what
or
a
release
like
I.
Guess
we
transparent
dual
packages
where
someone
can
import
the
same
specifier
and
it
can
be
both
tjs
or
ESM.
You
would
like
to
remove
that
as
one
of
the
the
cases
that
we're
trying
to
solve
for
with
with
our
implementation,
is
that
accurate.
C
Yeah
well
right
now
it's
under
phase
3,
it
would
get
moved
down
under
the
like
tabled
area
of
phase.
3
is,
and
we're
not
going
to
pursue
this
any
further
I
think
on
the
only
at
the
moment.
It
seems
to
me
the
only
way
to
avoid
that
happening
would
be
the
require
of
esm
solution,
but
there's
no
PR
for
that.
It
doesn't
seem
to
be
making
progress.
So
I
guess
we
could
table
it
and
then,
if
that
PR
comes
up
in
a
month
two
months,
even
after
we
on
flag,
it
could
be
revived,
but
yeah.
B
Right
so,
first
of
all
extension
resolution,
while
I
didn't
well,
it
increases
the
surface
area
of
this
hazard
is
not
the
only
way.
This
hazard
surfaces,
like
extension
resolution,
means
that,
yes,
with
relative
imports,
you
can
have
two
different
things:
that
if
the
two
resolvers
behave
differently
return
different
things
but
anywhere
the
resolvers
do
things
differently,
ie
in
the
interpretation
to
package.json
Flags,
the
problem
occurs.
The
two
resolvers
should
not
be
to
resolvers.
B
They
need
to
be
one
resolver
that
just
does
different
things
with
the
resolution
result
like
the
fact
that
they're
different
is
the
of
the
problem
and,
as
I
keep
saying,
we
don't
actually
need
to
be
able
to
execute
ESM
to
fix
the
problem
like
we
just
need
to
be
able
to
guarantee
that
the
one
resolver
always
behaves
as
a
subset
of
the
other.
That's
all
I.
We've
made
this
harder
on
ourselves
by
implementing
the
ESM
resolver
in
c++
thinking.
B
That
would
actually
entirely
solve
this
problem
because
then
we'd
be
able
to
say
well,
both
resolvers
know
about
the
type
module
field,
both
resolvers
know
how
extension
priority
resolution
works,
and
one
resolver
simply
says,
since
this
was
founded
by
extension,
searching
I'm
not
going
to
use
any
of
these
results,
simple,
throw
and
whereas
the
other
resolver
says
it
seems
good,
it's
the
CJ
s
file.
It's
fine
like
there's
nothing
to
do
with
actually
loading
any
code.
That's
why
this
entirely
resolver
behavior.
A
D
I'll
be
as
grievance
again,
and
so,
although
I
have
many
feelings
about
dual
packages
and
extension
searching
and
I've
made
them
clear,
I
think
in
the
past.
That's
not
those
are
implementations
that
I
think
solve
problems.
The
thing
that
I
think
is
really
critical.
That
I
don't
think
we
can
or
should
table
before.
Unflagging
is
solving
the
problem
of
how
I
publish
a
module.
They
can
work
across,
at
least
across
no
inversions
meaning
the
across
the
barrier
here
between
support,
CSM
unflagged
and
does
not
I
think
that
is
far
too
critical
to
table.
D
People
do
not
enough
people,
not
enough
people
read
documentation,
not
enough
people
speak
English
like
it.
That's
it's
fine,
if,
like
there's,
no
other
option
than
putting
a
caveat
and
the
docks
is,
of
course
the
only
option,
but
anything
that
requires
need
to
write
prose
to
explain
it.
It's
just
a
massive
failure,
in
my
opinion,
in
providing
like
compatibility
and
interoperability.
A
E
Maybe
I
should
also
unmute,
so
one
thing
that
confused
me
about
the
con
by
Wes
is
saying
that
the
ESM
resolver
could
be
a
subset
resolver
which,
as
far
as
I,
can
tell
that
is
the
case.
Right
now,
like
at
least
that's
the
design
goal,
if
it
isn't
that
I
would
consider
at
the
back
yeah
and
that's
what
I'm
saying
as
well
like.
It
is
a
bug
right
now
that
it
is
not
no
I'm
saying
if
there
is
anything
about
it.
That
is
currently
not
a
subset.
E
E
Shared
implementation
might
potentially
help
guaranteeing
that
I'm,
but
given
my
attempts
of
even
sharing
parts
of
the
implementation
and
getting
the
if
conditions
and
the
flow
right,
I'm
not
sure
the
resulting
code
would
be
something
that
is
maintainable
because
implementing
a
subset
of
the
common
J's
resolver
inside
of
the
highly
optimized
code
of
the
conscious
resolver
is
hard
and
it
will
make
future
maintenance
a
lot
harder.
So
I
would
be
in
favor
of
having
a
strong
acceptance
test.
E
E
B
Well,
I
mean
like
that.
My
then
follow
to
that
is
like
once.
We
have
that
in
place
that
we've
agreed
that
that's
the
premise,
like
extension
searching,
can
be
added
to
ESM
with
no
problem,
because
that's
still
a
subset
of
c
j
s
and
the
C
J's
Neos
and
resolve
are
going
to
resolve
to
the
same
extension
in
the
end
anyway,
right.
E
B
I
think,
like
the
the
reason
that
I
continue
to
walk
down,
that
path
is
because,
like
you
can
do
incremental
in
that
direction
because
like
if
we
set
state,
if
we
start
today,
we
was
saying
the
one
resolver
is
a
subset
of
the
other.
That
way,
we
don't
have
the
diverged,
specify
our
hazard.
We
can
say
tomorrow
we
had
extension
resolution,
then
we
can
say
the
day
after
that
we
can
now
load
ESM
in
CAS,
because
that's
as
I've
been
saying
likely
very
possible
like
that.
F
B
E
A
So
I
guess
what
you're
saying
and
then
this
would
be.
The
bug
would
be
the
order
at
which
we
do
extension
searching
for
ESM
and
commonjs
is
a
different
order.
It
should
be
the
same
order
and
the
order
should
only
switch
when
you
do
type
dot
module
now,
if
in
both
commonjs
and
in
ESM,
if
you
you
wouldn't
be
able
to
do
the
trick
that
people
do
where
they
drop
the
extension
and
then
all
of
a
sudden.
A
E
B
The
the
yes
a
resolver
doesn't
need
to
worry
about
that
because
it's
not
going
to
resolve
any
tensions
right
now
when
it
does
start
resolving
extensions
I.
Imagine
you
would
want
to
read
the
required
on
extensions
keys,
because
people
have
put
those
in
there
and
want
them
work,
but
in
just
the
list
of
string
keys,
I,
don't
think
is
that
bad
I
mean
if
you're
gonna
do
the
extension
searching.
You
should
probably
search
for
all
the
extensions
people
asked
for.
E
B
A
C
Jeffery
yeah
I
would
just
say
like
I.
What
I
find
frustrating
is
that
like
I
feel,
like
you
know,
Wes
require
VSM
is
a
potential
technical
solution
to
this,
but
it
seems
like
you're
only
interested
in
an
interest
in
pursuing
it
in
the,
in
the
sake
of
making
automatic
extensions
work
in
the
s/m,
and
there
are.
There
are
plenty
of
other
reasons
why
many
people
here
wouldn't
want
to
enable
that
so
it's
like
we
could
solve
the
problem
for
dual
packages
and
get
to
a
packages
to
work
Jeffrey.
This.
B
A
I
think
what
wes
is
saying
is
that
the
solution
of
this
problem
would
just
be
an
update
to
our
current
flag
for
a
file
extension
resolution
and
changing
the
order
for
it,
and
it's
a
separate
thing
all
together
from
require.
Yes,
M,
is
that
our
act
absolutely
accurate?
Yes,
and
if
we
learn
that
one
change,
then
it
like
there's
other
reasons
why
we
may
not
want
extension
resolution,
but
it
removes
the
hazard
that
extension
resolution
would
create
with
the
dual
mains.
G
F
D
A
That
would
be
like
the
eventual
thing
like,
because
what
we
did
and
what
wes
is
pointing
out
and
saying
is
above
is
that
we
look
for
MJ
s
first
before
we
look
for
J
s
in
the
file
resolution
searching
inside
of
our
implementation
in
any
SM,
and
if
we
just
change
that,
so
the
order
was
the
same.
Even
if
we
didn't
support
required
out
extensions.
A
It
would
still
like
solve
for
that
case,
unless
people
did
some
like
really
weird
funky
stuff,
but
it
just
like
independent
of
that
I
guess
what
what's
the
saying
and
maybe
less
we
should
go
through
and
just
tweak
that
anyways
for
the
implementation,
that's
behind
the
flag,
but
it
just
makes
it
a
non-issue
in
the
discussion.
It
also
means
that
file
extension
resolution
should
no
longer
be
thought
of.
As
like,
like
a
reason
for
file
extension
resolution,
dual
packages
isn't
like
they're,
two
separate
things
now
altogether:
yeah.
B
A
The
solution
that
the
expert
mass
proposal
is
talked
about
would
made
me
do
this
whereby,
like
you,
can
have
a
main,
and
you
can
have
a
main
in
your
exports
map.
If
you're
in
a
version
of
node
that
understands
export
Maps,
then
it
always
uses
the
main
and
the
exports
map.
But
if
you're
on
a
version
of
node
that
doesn't
understand
it,
it
uses
the
other
main,
like
that's
an
example
of
a
dual
mode
module
that
has
backwards
support.
But
it's
not
one
that
could
like
resolve
to
two
different
specifiers
in
the
same
runtime
and.
E
B
B
Yeah
and
like
that
great
process
is,
is
so
bad
right
now
because
of
the
fact
like
you,
you
have
to
then
use
dynamic.
Import
introduced,
awaits
everywhere
and
do
a
bunch
of
other
garbage
like
the
upgrade
path,
completely
garbage
right.
Now,
that's
one
of
the
reasons
why
I
think
you
really
need,
like
a
synchronous,
require
of
esm,
but
I.
Consider
that
separate
yeah
I
also.
A
Think
West
for
what
it's
worth
and
it
would
be
something
we're
sitting
down.
I
think
that
a
synchronous
requires
something
that
we
can
maybe
target
for
node,
14
and
I
think
that
maybe
that
is
something
that
we
should
sit
down
and
maybe
try
to
create
like
a
separate
roadmap
to
as
as
a
incremental
enhancement,
because
I
just
still
don't
know
how
we
do
that
in
12,
without
breaking
changes,
especially
as
we
get
close
to
LTS,
like
even
small
behavior
changes,
start
becoming
an
issue.
I.
B
Think
it's
like
the
by
the
same
way
that
we
have
to
go
and
patch
the
resolver
to
like
we
already
patched
it
to
throw
for
not
MJS
and
like
we
have
to
patch
it
to
do
the
correct
thing
for
the
type
module
field.
All
of
those
cases
are
just
making
things
that
into
things
that
throw
right
now
the
idea
being
like.
If
we
had
the
synchronous
require,
we
would
just
make
those
not
throw
so.
G
E
A
D
A
You
have
do
you
have
like,
especially
since
we
just
came
up
with
the
fact
that
we
want
to
make
the
two
resolvers
have
in
the
same
order,
which
means
you,
if
we
do,
that
you,
you
will
no
longer,
even
with
extension,
searching
turned
on
be
able
to
use
the
main
for
a
dual
package.
Do
you
have
an
alternative
proposal
for
dual
packages,
so.
D
Off
the
top
of
my
head
right
now,
no
I,
certainly
don't,
but
what
I
would
like
to
see
from
myself
or
someone
else
in
order
to
untried
an
explanation
of
how
you
know
whether
it
requires
changes
or
not,
of
how
I
can
write
a
package?
If
we
assuming
let's
say
we
unflagging,
know
12
LTS
right
a
package
that
works,
you
know
in
12,
9,
LTS,
8
and
12
LTS
you
know
like,
and
if
that,
if
that
exists,
then
so
be
it.
You
know,
even
if
that,
like
I
would
say,
there's
two
tiers
there.
D
You
know
and
or
like
rewrite
your
ab,
if
someone
can
you
know
and
I'll
certainly
try
and
think
about
it
and
put
you
know
putting
the
time
as
I
have
it,
but
if
someone
can
come
up
with
a
path
to
doing
that,
then,
like
that's
great
I,
like
ice
tried
to
imply
earlier,
like
I'm,
not
actually
attached
to
do
them
own
packages
or
extension.
Searching
it's
just
that
in
my
head.
Those
were
the
only
ways
to
achieve
it
to
cheat
the
actual
important
goal.
Well,.
D
E
Agree
with
Jordan
that
we
need
to
have
a
migration
story,
because
we
also
know
already
that
the
compilation
story
doesn't
work
for
intermediate
packages,
because
if
you
write
code
once
you're
trying
to
compile
it
to
modern
syntax
or
well
legacy
syntax-
and
you
publish
the
both
versions,
your
specifiers
will
not
be
modified,
at
least
not
good
tooling.
So,
if
your
dependency
is
as
two
implementations,
you
need
to
modify
the
specifiers
while
compiling
it's
something.
It's
just
not
soft.
E
Yet
so
I
agree
that
we
need
some
sort
of
guidance
on
how
to
write
a
package,
especially
it
immediate
package
that
has
both
versions
and
depends
on
something.
That
also
has
the
two
versions
and
the
guidance
can
be
well.
You
can
never
use
the
ESM
version
of
your
dependency
as
an
intermediate
package,
but
we
need
to
actually
write
that
out.
D
A
I
think
that
we
need
to
move
on
to
the
next
thing.
We've
run
over
by
quite
a
bit
the
one
bit
that
I
do
want
to
say,
though,
in
general,
about,
like
the
concept
of
blocking
I,
think
that
in
general,
if
we're
talking
about
like
blocking
stuff
I,
don't
think
that
it's
reasonable
to
block
unflagging
with
like
without
proposed
implementation
or
a
proposed
solution.
Otherwise
we're
just
in
a
holding
pattern.
Well,.
D
A
But
those
came
with
specific,
specific
pr's
that
landed
in
the
state
that
would
allow
it
to
move
forward.
Not
an
unknown
state
of
what
solution
could
be
I,
see
those
as
different
things
quickly
before
we
go
I
want
to.
We
have
a
couple
people
that
want
it
to
be
added
as
observers,
and
we
have
the
people
on
the
call
for
this
there's
an
open
issue,
a
pull
request
from
Brian
Clark
from
Alex
a
bhishan
and
from
Bob
Evans.
Does
anyone
object
to
adding
any
of
these
individuals
as
observers.
A
Okay,
so
I
will
move
forward
and
add
all
of
them
to
the
repo
Thank
You
Jordan.
Maybe
we
can
spin
up
I
think
that
I'm
hearing
like
two
separate
kind
of
out-of-band
conversations
that
we
can
have
one
around
potential
top-level,
the
weight
in
CJ
s
and
a
move
forward
for
either
require
ESM
or
a
weight
dynamic
import
in
CJ
s.
The
second
one
that
I'm
hearing
is
some
sort
of
work
around
documentation
for
how
we
move
modules
full
forward
act,
two
that
we
have
here.
A
E
Originally
so
originally
in
the
expose
proposal,
there
was
a
way
to
also
specify
main
using
duck
name
so
in
exports
you
could
have
a
Property
Act
dot
and
you
put
in
a
specifier
just
like
you
would
in
the
main
field,
and
it
was
a
way
to
basically
drop
using
nein
and
just
use
one
field
for
both
in
the
very
first
version.
There
was
even
a
shorthand
that
if
you
said
exports
to
a
string,
it
would
explicitly
said
the
main
field
and
exports
to
falls
so
you're
only
exporting
that
one
thing
that
is
in
the
string.
E
We
dropped
that
a
because
of
the
dual
package
thing,
because
at
that
point
exports
was
slated
just
for
ESM
and
we
also
dropped
it
because
dot
main
happened
to
be
somewhat
contentious
as
a
syntax,
because
people
objected
to
having
an
object
key
that
is
just
a
dot,
but
now
that
we
have
additional
syntax
and
exports
like,
for
example,
the
array
fallback
syntax.
With
some
of
these
no
thoughts
about
what
kind
of
features
it
might
support,
we
basically
come
to
a
choice
between
two
semi
bad
options:
option,
one
being
we
bring
it
back.
E
We
say
exports
can
override
main
completely
both
for
common
j
s
and
years
m.
If
you
have
a
dot
field
in
your
exports,
it
overrides
the
main
field
or
the
alternative
is
we
could
support
that
same
array
syntax
in
main,
but
that
would
mean
that
if
you
want
to
use
fall
backs
for
your
main
export,
you
would
need
to
drop
support
for
all
versions
and
bundlers
before
export
was
introduced.
E
A
E
It
is
already
implemented
in
note.
It
is
supported
right
now
we
are
just
basically
the
four
Bex
notice
take
the
first
thing:
if
we
understand
that
is
a
string,
that
is
a
URL,
so
the
current
implementation
already
supports
it,
and
if
you
want
to
add
fallback
support
at
any
time
in
the
future,
we
kind
of
have
to
support
it
right
now,
because
otherwise
we
kind
of
well
we
it
would
go
against
the
whole
purpose
of
having
a
fallback
syntax,
which
is
that
older
versions
will
fall
back
to
some
kind.
B
A
E
E
E
So
so
those
are
and
also
write,
polyfills
for
built-ins.
That's
how
the
browser
is
using
it.
So
it's
kind
of
modeled
after
the
import
map
array,
syntax,
which
is
doing
the
same
thing
so
in
import
Maps.
If
you
want
to
polyfill
standard
key
value
storage,
you
put
the
standard
specifier
first
in
the
array,
so
an
environment
that
would
support
this
and
specify
I
would
use
it.
And
then
you
put
the
polyfill
as
a
second
item.
E
A
E
A
F
A
Perfect
that
actually
answers
the
question
that
I
cared
about,
which
was
that
whether
or
not
main
here
could
be
used
for
dual
modules.
But
it
sounds
like
the
answer
is
no,
which
is
good
because
you
wouldn't
be
able
to
like
have
one
that
like
have
a
ESM
module,
denis
CJ
s,
module
and
have
it
fail.
It
will
just
fail
in
the
require
loader,
because
it
will
get
that
proper
URL
and
then
try
to
load
it.
Yeah.
A
And
I
like
the
idea
of
this,
especially
where,
like
essentially,
we
would
be
not
deprecating
but
like
it
shadows
it.
So
if
you
have
a
main
in
the
exports
and
you're
in
a
version
of
node
that
supports
exports,
then
that's
what's
used
and
then
that
allows
main
itself
to
be
like
a
backwards
compatible.
A
A
Which
also
means
that,
like
West
to
kind
of
what
you
were
asking
about
in
to
what
Jordan
was
asking
about
like
this
could
be
the
solution
that
we
talked
about
like
if
you're
an
es
module,
and
you
have
a
package
in
you
and
you
want
to
have
support
for
older
versions
of
node
that
didn't
support
ESM.
You
very
well
could
transpile
like
an
e
s3
or
any
s5
source
text
from
your
module,
put
it
that
in
the
main
and
then
and
then
any
older
version
of
node
will
be
able
to
use
it.
E
Then
you
upgrade
to
a
version
of
node
that
supports
modules
and
now
suddenly,
your
application
breaks
because
you're
using
require
to
get
to
that
module,
but
you're
on
a
version
of
node
that
suddenly
supports
exports,
and
that
is
it's
like
like
that
is
where
it
becomes
actually
dangerous
to
have
these
two
fields,
because
you
might
be
preventing
successful,
node
version
upgrades
because
dependencies
use
this
pattern.
I.
A
F
F
A
C
Iii
think
I
think
it
would
be
a
great
feature
to
support
I
do
share
Yuans
concerned
about
how
do
we
make
the
upgrade
process
seamless,
but
it
just
opens
up
so
many
doors
in
terms
of
like
being
able
to
have
this
the
main
point,
two
different
things
in
different
environments
and
so
on.
That's
a
huge
win
that
we
know.
Users
have
been
wanting
for
years
and
years
with
the
browser
field
and
the
electron
field,
and
so
on
and
so
on
and
so
forth.
So
I'd
love
to
try
to
make
it
work.
A
Doesn't
sound
like
it
and
I
mean
thinking
about
the
pitfalls
that
you
were
mentioning
yon.
It
seems
to
me,
like
the
kind
of
thing
that
can
be
solved
through
best
practices.
You
know
like
if
you're
gonna
have
both
a
main
and
an
export
dot.
Maybe
you
have
the
main
console.log
of
warning
or
have
some
sort
of
warning
of
like
hey
you're,
using
a
legacy
interface.
So
that
seems
like
the
kind
of
thing
that
can
be
solved
through,
like
best
practices
in
education.
C
Yeah
I
mean
the
solution,
for
that
user
would
always
would
just
be
to
downgrade
their
version
to
the
version
before
you
added
the
exports
fields.
You
know
like
if
this
is
only
really
if
someone
has
upgraded
their
dependency
to
a
version
after
you've
added
that
but
they're
still
using
an
old,
no
debt,
cetera
yeah.
A
A
Yeah
because,
like
if
they're
in
a
position
where
they
need
to
opt
out,
it's
probably
a
whole
opt
out
not
just
on
a
per
module
basis.
Right
like
they
need
it
to
run,
to
run
as
if
exports
doesn't
exist.
So,
like
I,
think
that
if
we
have
an
opt-out,
that
should
actually
be
sufficient
to
support
to
solve
this
problem.
I.
B
F
F
E
Yeah
I
think
there's
a
valuable
bike
sure
to
be
had
about
the
key
and
or
where
to
put
it,
I
think
it's
functionally
the
same,
to
put
it
into
Xbox
or
dots
or
put
it
into
a
table
new
top-level
fields,
I
think
I
am
kind
of
liking.
The
idea
of
supporting
the
string
syntax
for
exports.
Again,
we
can
set
export
itself
to
a
string
on
array,
in
which
case
the
second
top-level
field
might
be
awkward
I.
A
A
I
would
like
to
also
propose
that
perhaps
we
find
time
for
an
out-of-band
meeting
next
week,
I
will
be
out
the
following
week
because
of
TPAC,
but
also
just
we
got
through
like
half
the
agenda,
so
I
think
it
would
be
good,
maybe
to
follow
up
on
stuff
and
not
have
two
weeks
in
between
so
I'll
do
that
offline?
Does
anyone
else
have
any
thoughts,
concerns
grievances,
announcements,
cool
stopping
the
stream
thanks
for
tuning
in.