►
From YouTube: Node.js Modules Team Out of Band Meeting 2019-10-30
Description
A
We
are
live
on
air
with
the
October
30th
out-of-band
meeting
of
the
node.js
modules
team.
We
have
nine
individuals
on
the
call,
including
eight
voting
members
of
the
modules
team,
meaning
we
have
consensus.
The
high-level
purpose
of
this
meeting
is,
you
know,
hoping
to
reach
consensus
around
what
we
need
to
do
to
move
things
forward
and
get
an
unflagged
version
of
modules
out
of
the
door.
Oh
we've
got
another
attendee
Jordan
again.
A
A
B
A
I,
don't
think
that
it
necessarily
implies
that
although
I
think
that
is
something
that
we
maybe
need
to
reach
consensus
on.
So
maybe
a
good
thing
for
us
to
start
with
right
now
before
we
get
into
the
particular
issues
would
be
to
like
tease
apart
the
things
that
we
want
to
try
to
reach
consensus
on
so
I'm
just
gonna
like
enumerate
a
couple
thoughts
and
then
just
raise
your
hand
or
even
you
know,
feel
free
to
try
knit
or
add
to
the
doc.
A
A
C
C
Don't
know
sorry
I
think
the
divergence
best
the
fire
has
it
is.
Is
that
between
different
environments?
I'm,
not
sure,
that's
something
in
control,
because
someone
can
write
a
custom
resolver
which
supports
any
other
entry
point,
yeah,
I,
sort
of
think
of
it
as
like
environment
conditions
or
I
mean
specific
entry
point,
mappings
was
I'm,
sorry
I
don't
mean
to
be
difficult
on
the
terminology,
but
just
trying
to
be
there.
C
C
A
A
A
Leslie,
you
have
a
comment:
they're
part
of
the
conditional
export
implementation
at
this
point,
I'm
with
supporting
default
path
alongside
path,
but
now
using
it
for
multi
entrance
okay.
So
let's,
let's
dig
into
that
specific
bit
in
the
discussion?
Do
you
think
that
were
a
lesser?
Do
you
think,
there's
something
that's
missing
in
that
list
of
consensus
that
we
should
include,
or
do
you
think
that
that
we've.
D
All
yeah,
like
the
conditional
exports
PR
as
it
is
today,
can
be
separated
out
into
two
separate
features:
one
adding
support
for
using
an
object
with
a
default
field
for
that
point,
set
of
string
or
array
or
whatever
that
can
take
the
place
of
the
string
and
then
two
layered
on
top
of
that
also
supporting
a
module.
Member
of
that
object.
That's
used
as
an
alternative
they're
too
long
for
things
like
the
first
part,
I
can
be
on
board
with,
like
that's
been
explained,
I
can
understand
how
that
can
benefit
the
community
independently.
A
C
D
E
C
F
A
G
D
E
A
Is
there
anything
other
than
the
list
that
we
have
in
reaching
consensus
that
we're
going
to
attempt
to
sort
through
today
or,
alternatively,
you
know
blocks?
Actually,
you
know
what
III
would
I
want
to
add.
One
thing
here,
based
on
the
other
thing,
other
things
that
we
talked
about,
which
would
be
continuing
activity
of
the
group.
A
That
is
an
absolute
deadlock
for
us,
and
so,
if
we
are
unable
to
work
through
that
in
today's
discussion,
I
think
it
would
be
reasonable
for
us
to
save-
maybe
even
the
last
20
or
30
minutes
of
the
meeting
to
go
through
thinking
about
what
we
want
to
do.
If
we
want
to
continue
working
as
a
group
on
this,
if
we
want
to
vote
which
I
would
prefer
not
to
but
just
kind
of
like
how
do
we
find
a
way
forward?
A
B
Not
a
direct
cost
follow-up
for
that,
but
for
the,
what
features
need
to
be
unfledged
first,
I
think
there's
a
should
be
an
a
and
and
open
questions
for
unplugging
those
separate
items
so
background
thought
me
asking
about
this
stuff.
Is
there
still
at
least
one
question
unanswered
for
unflagging
exports,
for
example
like
if
you
would
want
to
underplay
exports
right
now,
there's
one
open
question
that
would
need
to
be
decided
before
we
can
actually
do
that.
So
we've.
A
B
G
B
A
Since
this
seems
like
a
primarily
technical
discussion
and
less
fraught
with
with
violent
disagreement,
although
perhaps
I
will
be
pleasantly
surprised
by
how
angry
we
get
about
this,
maybe
we
should
start
with
this
one
because
it
seems
pretty
well
scoped
yon.
Is
there
anything
else
you
wanted
to
add
about
this
I.
B
Just
linked
the
issue
in
the
reef
egg
exports
item
and
I
can
also
post
it
in
the
chat
which
might
be
easier
yeah.
It's
it's
it's
a
relatively
narrow
thing
and
for
me
it
also
rolls
into
things
like
in
theory.
You
can,
for
example,
on
a
case,
insensitive
file
system.
Again
something
specific.
You
can
circumvent
certain
expert
instructions
because
if
you
specifically
export
it
a
directory,
but
then
unexploited
the
specific
file
which
works.
If
you
then
use
a
case
variant
of
that
file-
and
you
specify
it,
you
can
circumvent
that.
B
But
for
me,
that's
the
kind
of
platform,
specific
behavior
that
I
would
like
to
just
say.
We
ignore
that,
like
if
you
write
not,
if
you
want
preferences,
recode
exports
might
not
catch
certain
attempts
to
get
at
files,
so
kind
of
also
in
the
line
of
export
was
never
meant
to
be
a
100%,
secure
thing.
There's
there
is
ways
of
getting
onto
to
these
files.
Anyhow
of
us
trying
to
lock
it
down
against
all
kind
of
edge
cases
on
different
platforms
and
file
systems
seems
prone
to
fail.
B
E
I
mean
so
I
guess
the
the
question
is:
if,
if
that
you're
in
that
situation,
you
would
have
the
only
way
to
actually
keep
that
file
like
when
you're
trying
to
essentially
negate
a
what
is
it
you're
trying
to
so
you
say
you
export
the
whole
directory,
and
then
you
want
to
NEX
port
a
file
within
it.
The
only
way
to
block
that
would
be
to
have
every
per
casing,
permutation
explicitly
blocked.
Is
that
right.
E
G
E
B
Yeah,
we
are
currently
talking
about
cases
where
people
are
actively
trying
to
get
to
these
files,
ignoring
the
release,
because
the
readme
will
not
contain
a
backslash.
The
readme
will
not
contain
a
different
casing
of
the
file,
so
people
are
pretty
much
already
trying
to
get
around
the
expose
restrictions
and
once
they
are
in
that
situation,
they
can
just
path
resolve
and
require
or
import
the
file
system
URL
like
so.
E
Easier
at
this
point
in
chat
is
really
the
thing
is
that
it.
This
is.
The
concern
is
not
about
people
trying
to
be
malicious
because
yeah,
they
can
always
FS
start
read,
file,
sync
or
whatever,
like
the
this
is
accidents,
so
I
guess
what
I
mean
is
is
if
somebody
accidentally
writes
code
that
well
they
happen
to
be
on
a
case,
insensitive
file
system
that
works
because
of
this,
and
then
they
ship
it
to
a
case
sensitive
file
system.
It
will
suddenly
break
and
not
in
a
way
that
they
can
debug
like
that,
would
be.
E
A
So
I
guess
with
that
the
left
hand
side
of
the
exports
map
right,
like
people
are
going
to
put
a
specific
casing
in
there.
Could
we
just
force
a
direct
match
in
which
I'm,
assuming
is
what
happens
today,
of
like
whatever
they
put
in
to
the
importer?
Require
statement
must
match
with
case
sensitivity,
independent
of
the
system
there
on
how
the
export
is
named,
like
wouldn't
catching
it
kind
of
earlier.
Just
prevent
that
thing
from
happening
and
I
think
tell
me
if
I'm
wrong
it.
That
seems
to
be
what
you
might
be
suggesting.
B
Right
right
now,
we
do
do
exact
matches
on
the
left-hand
side,
which
I
think
is
the
only
thing
we
can
do
anything
else
with
us
having
opinions
on
whether
you
can
have
a
case
sensitive
file
system
over
there.
You
can
use
backslashes.
So
on
the
left-hand
side,
we
just
do
purely
equality
of
the
string
without
any
considerations
around
platform
differences
on
file
systems,
because,
on
the
left
hand,
side
file
systems
do
not
exist.
Titles
do
not
exist,
it's
just
better.
By
matching
the
case.
E
B
Okay,
so
III
think
there
will
always
be
platform
specific
things
that
will,
in
quotation
marks
circumvent
exports,
but
it's
always
cases
where
people
will
realistically
have
no
editor
autocomplete.
They
ignored
the
documentation
and
wrote
something
from
memory,
which
means
that
they
are
not
necessarily
the
absolute
beginners.
So
I
have
a
hard
time
saying.
Yes,
we
should
add
more
complexity
to
our
implementation
and
pretend
like
we
can
actually
address
all
of
these
things
without
a
lot
of
lot
of
code,
and
it's
all
things
that
kind
of
already
exists
in
the
existing
system.
B
It's
not
like
this
is
a
big
regression
where
the
existing
system
wouldn't
have
issues
with
case
sensitive
files
like
I'm,
pretty
sure
that
there
already
is
the
case
that
you
can
have
node
code
that
works
well
on
Mac,
OS
and
fails
and
with
Linux,
because
suddenly
case,
sensitive
file
systems.
I
think.
A
A
I'm
on
a
train:
okay,
classic
train,
okay,
so
I'm
gonna
read
West's
comment.
Then
this
is
caused
by
a
mismatch
between
what
you
want
to
expose
and
what's
being
checked,
you
want
to
expose
specific
cash
entries,
specific
things.
A
specifier
can
resolve
not
a
specific
casing
of
a
path
so
Wesley
and
if
you
respond
in
the
chat,
I'll
read
it
like.
Do
you
have
a
particular
solution
that
you
can
imagine
this
space
that
can
help
with
that.
A
E
The
other
thing
is
that,
on
a
case,
insensitive
system,
if
you
have
a
file
name,
that's
fo,
o
dot.
Jsa,
you
don't
know
you
have
no
information
about
what
the
casing
should
be.
As
my
understanding
like,
we
can't
look
at
it
and
say:
oh
it's
supposed
to
be
capital,
F,
lowercase,
o
lowercase,
o
and
therefore
like.
If
so,
I,
guess
that's
what
I'm
looking
for
confirmation
from
that,
perhaps
from
yon
as
well
like.
If
that's
information
we
can
get,
then
my
hope
would
be
that
we
can
just
say:
okay,
cool!
That's
the
only
casing!
E
B
And
also
that
note
behavior
would
then
be
platform
dependent.
100%,
like
the
same
code
note,
would
do
different
things
for
the
same
code,
depending
on
the
platform,
because
on
Linux
having
foo
or
lowercase
and
foo
or
uppercase
in
the
same
directory
is
completely
valid.
So
if
you
require
uppercase
or
lowercase
or
uppercase,
o
note
cannot
choose
one
or
the
other.
E
Sorry,
what
I
mean
is
is
the
on
a
case,
insensitive
system
like
the
file
names
and
the
requested
file
name.
The
actual
finally
main
request
to
file
name
are
normalized
and
matched
right
to
some
degree,
and
what
I'm
saying
is
that,
on
a
case,
sensitive
file
system?
Yes,
you
can
have
all
caps
foo
in
all
lowercase
foo,
but
what
I'm
I
guess?
What
I
mean
is
both
of
those
like?
E
We
could
take
the
file
system
platform
dependent
part
out
of
it
and
just
say
if
the
actual
files
in
the
folder
are
capitol,
foo
and
lowercase
foo,
then
those
are
the
exact
casing.
Specifiers
you
can
reach
and
if
you
do,
capital
F
lowercase,
o
lowercase,
o
there's
nothing
there.
In
other
words,
that
wouldn't
be
different
across
platform.
That
would
be
the
same
across
platforms.
It
would
just
mean
that
your
some
of
your
case,
insensitivity
expectations,
would
not
apply.
But
that's
fine
is
that.
A
Possible
I'm,
just
I'm
gonna
interrupt
for
for
one
second,
just
with
a
thought,
and
we
can
continue
if
people
want.
We
are
at
1:34
right
now
and
we
have
a
lot
to
get
through.
This
feels
potentially
also
like
it's
an
issue
that
goes
broader
than
our
implementation
and
even
exports,
because
it
explicitly
affects
the
requirejs
loader
as
well.
A
So
I
would
like
to
suggest
that,
potentially
we
treat
this
as
out
of
scope
for
our
implementation,
even
for
exports,
and
if
we
need
to
fix
behavior,
we
need
to
fix
consistent
behavior
in
the
entire
runtime,
not
only
in
exports,
and
this
likely
will
involve
assembler
major
change
against
node
core.
What
one
thing,
for
example,
that
I
think
is
worth
considering
here
is
like
I:
just
did
a
quick
test
locally
on
a
case,
insensitive
file
system
for
Mac,
OS
and
I
created
a
module
foo
with
capital.
A
F
I
required
foo,
with
an
underscore
F
then
required
it
again
with
the
capital
F
and
in
both
console
logged
underscore
underscore
name,
and
both
of
them
have
the
casing
that
I
fed
to
it
so
Wesley.
To
even
like
the
question
that
you
were
asking
there,
even
from
the
cache
entries
I
believe
the
cache
entry
is
going
to
have
the
casing
of
what
you've
required
and
it
will
just
work
when
it
fetches
the
resource
from
the
filesystem.
It
doesn't
actually
get.
The
proper
casing
so
would
be
a
pretty
big
like
I.
A
A
A
Jeff
you've
done
a
lot
of
work
documenting
this
and
then
you've
also
done
work
documenting
the
other
hazard.
Do
you
want
to
give
just
like
a
quick
overview
again
of
the
in
Robert
and
then
the
new
hazard
that
you've
documented
as
well
potentially
you've
been
presenting
the
screen,
so
folks
can
see
stuff
sure.
G
G
We
know
people
are
gonna,
want
to
publish
them
and
they're
gonna
want
the
ESM
side,
which
is
currently
only
usable,
wipe
under
bumblers
to
be
used
by
node
once
node
finally
supports
some
syntax
natively.
So
for
the
current
docs,
we
recommend
using
a
export
or
a
deep
import
path,
such
as
like
slash
module
to
go
to
this
new.
Yes,
module
version
of
it,
and
we
thought
that
that
would
great.
G
Even
with
this
like
slash
module
or
slash
Commodus,
whatever
you
call
it
approach,
because
the
original
dual
package
so
similar
to
the
graph
QL
like
the
decor
graph
QL
package
in
that
example,
say:
there's
like
a
plug-in
for
graph
QL.
It's
like
graph
QL
come
and
J
s
plug-in.
That
does
require
graph
QL
and
then
there's
a
sudden
other
plugin
that's
much
newer
and
that
does
import
graph
QL
slash
module,
then
in
you,
in
the
end-users
app
they
import
graph,
QL
import
graph,
QL
come
Egeus,
plug-in
and
import
graph.
G
If
it
lacks
the
type
field,
it's
implicitly
type
come
to
ask,
then
it's
like
it
has
every
javascript
file
in
there
has
to
be
that
type,
and
then
people
just
won't
be
able
to
publish
quote-unquote
dual
packages
where
they
shipping
common
jsn
dsm
sources
that
just
wouldn't
be
usable
in
node.
But
you
know
I
went
into
some
detail
about
like
what
what
that
would
really
mean
in
practice
and
I.
Think
it's
not
really
feasible,
like
people
would
find
ways
to
work
around
it.
G
You
know
you
can
always
just
require
the
path
like
you
know,
importer
required
dot,
flesch
node
model,
slash
package,
slash
something
so
truly
locking
it
down
and
preventing
the
hazard
may
not
be
possible.
You
know-
or
it's
at
least
on
the
verge
of
being
a
fool's
errand.
So
I'm
sort
of
personally
I
feel
that
like
if
we,
if
we
can't
prevent
it,
that
we
might
as
well
just
allow
it
and
give
people
what
they
want
and
then
adopt
conditional
exports.
So
I'm
gonna
stop
talking
and
then
miles.
If
you
want
to.
B
Their
hand
up
yeah
just
to
amend,
because
somebody
brought
up
creating
a
copy
and
published
by
publishing
on
a
different
package
names
so
low
and
low
yes,
has
exactly
the
same
problem.
Basically
as
long
as
there
are
two
versions
of
the
package
in
the
ecosystem
and
whatever
name
or
specifier,
and
they
share
an
ecosystem
of
consumers.
B
You
have
this
problem,
so
basically,
if
you
actually
want
to
remove
this
issue,
whatever
shared
package
is
in
the
ecosystem
graph
KL,
yes,
then
whatever
would
have
to
publish
a
new
major
version,
completely
drop,
commonjs
support
whatsoever
and
only
ship
ESM.
That
is
the
only
way
to
actually
remove
this
hazard.
B
A
Thinking
about
this
and
a
lot
of
time,
kind
of
coming
coming
to
terms
with
it
and
I
think
like
one
of
the
biggest
things
for
me
with
this
as
well,
is
kind
of
finding
the
balance
here
between
developer
experience
and
foot
guns
and
I
realized
that
someone
who's
champion
top-level
await.
Maybe
you
can't
take
me
too
seriously
on
that,
but
jokes
aside,
when,
when
I
was
under
the
impression
that
splitting
up
like
that
having
two
separate
entry
points,
would
hide
the
hazard
or
at
least
make
it
more
explicit
and
require
more
work.
A
You
know,
I
I,
really
didn't
think
that
the
developer
experience
of
like
a
single
entry
point
was
worth
it
and
I
pushed
extremely
hard,
for
example,
that
changing
a
package
to
ESM
should
be
summer
major
or
there
shouldn't
be
ways
of
moving
this
forward.
But
in
reality
into
yawns
point.
The
problem
is
much
more
subtle
and
it's
in
this
like
similar
to
what
we
have
now
in
the
sense
that
like
even
if
you
are
importing
a
module
that
is
ESM.
A
You
know
the
thing
that
may
have
separate
separate
entry
points.
There
may
be
no
obvious
way
to
those
individuals
to
know
that
the
hazard
is
happening
if
it's
hidden
underneath
them
and
that's
kind
of
independent
of
whether
or
not
like
this
single
specifier
can
mean
multiple
things
and
I.
Think.
The
real
solution
here
overall,
is
educating
people
about
best
practices
around
utilizing
Singleton's
in
node.
This
is
even
for
things
that
are
all
ESM
or
all
commonjs,
not
only
things
that
are
dual
packages.
A
The
kind
of
things
that
we're
having
problems
with
right
now
are
all
around
the
singleton
problem,
and
whether
or
not
the
solution
to
this
is
like
pitching
more
dependency
injection
patterns
or
whether
or
not
the
solution
here
is.
You
know,
pitching
patterns
on
the
like
global
disk
that
allows
people
to,
like
you
know,
share
a
cached
entry.
I
think
that,
no
matter
what
we
choose,
we
need
to
educate
people
on
the
best
practices
of
this
and
the
developer.
A
Experience
difference
between
having
this
feature
and
not
having
this
feature
is
so
massive,
and
since
we
arguably
need
to
do
all
of
this
education
anyways,
it
feels
kind
of
spiteful
or
rather
like
it,
feels
like
throwing
the
baby
out
with
the
bathwater
for
lack
of
a
better
analogy
to
just
Nix
this
hazard
and
again,
you
know
I
say
that
is
taking
a
180
on
my
prior
stance
and
it's
taken
me
a
while
to
get
here
guy.
You
have
your
hand
up.
C
Yeah
just
to
follow
up
on
that
points
of
education
and
I
agree
with
all
those
points,
and
it
was
very
well
put
miles
the
you
know
if
you
think
about,
as
you
say,
that
people
want
to
get
these
this
the
superior
experience
of
modules
and
they
want
to
be
able
to
ship
them.
You
know
what
will
like
you
see
is
the
largest
jeaious
libraries
will
do
the
julno
pattern
in
a
safe
way.
C
They'll
do
wrappers
and
things
like
that,
and
they
will
adopt
it
in
a
way
as
long
as
we
can
clearly
communicate
this
way
of
doing
things
and
make
sure
it's
it's
very
clear
in
the
ducts
and
all
the
the
main
libraries
can
follow
it,
which
they
will,
because
if
they
don't
they'll,
get
bug
reports
and
they'll,
very
quick,
you
switch
to
handling
their
state
in
shared
modules,
so
them
the
main
libraries
will
do
that.
The
issues
will
be
those
libraries
on
the
edges
that
didn't
necessarily
see
the
standard
way
of
doing
things
or
follow.
C
What
the
best
way
of
doing
things
is
so
it's
in
a
sense
getting
on
top
of
it
and
communicating
it
is,
is
a
better
way
to
help
the
ecosystem
towards
good
practice,
as
opposed
to
just
letting
this
organic
bulldozer
of
JavaScript
devs.
Do
all
these
other
things,
and
also
most
devs
will
copy
what
the
what
the
main
libraries
are
doing
or
or
see
those
patterns
happening
anyway.
So,
ideally,
if
there's
an
endorsed
pattern
and
we
can
get
behind
it
and
push
it,
that'll
guide
the
ecosystem
towards
a
better
outcome.
C
A
One
thing
I'd
like
to
add
to
a
guy,
said,
hilariously
an
argument
that
I
had
used
in
the
past
about
why
we
shouldn't
do.
This
was
presenting
all
of
the
open
source
projects
that
had
lots
of
issues
about
this
from
web
pack
to
graph
QL
to
create
react
app.
They
all
got
kind
of
bitten
by
the
specifier
hazard,
had
lots
of
issues
opened
and
I
was
kind
of
holding
that
up
as
an
example
of
like
why
this
is
such
a
problem
when
we
shouldn't
allow
it
and
kind
of
in
retrospect
and
kind
of
I.
A
Think
I
hinted
at
this.
That
actually
could
be
a
feature
in
the
sense
that,
like
yes,
while
these
problems
can
be
very
subtle,
a
lot
of
the
times
they're
experienced
breaking
it.
So
what
I
mean
by
this
is
that
for
the
larger
ecosystem
packages
that
will
run
into
this
I
think
that
if
they
are
publishing
packages
that
have
the
hazard
and
are
biting
people,
people
will
find
out
pretty
quickly
open
issues,
and
this
should
be
fixed.
A
A
This
object
with
that
symbol
to
see,
if
anything
is
on
it
as
like
kind
of
a
lazy
load
that
happens
the
first
time
you
try
to
run
the
function
and
the
common
J's
version
or
the
ESM
version
can
append
the
object
there.
And
if
the
sources
you
know
are
pretty
much
identical
like
you
will
get
to
that's
kind
of
one
instance,
and
it's
a
way
in
which
we
could
mirror
the
cache
another
thing
that
I
guess
we
could
we
could
look
into.
A
E
E
G
A
Like
the
let's
think
about
it,
unidirectionally
from
ESM
to
require
which
is
a
little
different
and
then
we're
at
152,
so
maybe
we
should
time
box
this
particular
conversation,
but
if
we
like
you
can
get,
for
example,
you
can
create
a
require
function.
I,
don't
I
think
that
you
should
be
able
to
access
the
cache
with
that
file.
A
So
in
the
ESM
module,
essentially
right
before
you're
exporting
the
main,
you
should
be
able
to
essentially
take
whatever
you're
about
to
export
and
register
it
into
this
CJ
s
cache
with
the
appropriate
name,
so
that
at
a
later
point,
if
it
is
required,
it
would
be
loaded
from
from
that
object.
So
you
would
only
get
one
instance
you
you.
G
So
if
I
can
just
reply,
I
have
a
PR
up.
That's
like
a
like
a
child
of
the
conditional
exports
PR,
where
I
go
into
fairly
great
length
about
like
recommended
patterns
for
dual
packages,
and
the
first
recommended
one
is
the
the
ESM
wrapper
approach
that
is
like
the
safest
because
then
there's
no,
there
is
only
one
singleton,
that's
shared
between
both,
which
I
think
is
kind
of
the
same
thing
as
what
you're
describing
miles
I
don't
know,
and
then
the
second
one
is
like
lots
of
ways
to
avoid.
G
Having
statefulness
within
a
package
is
like
the
kind
of
second
approach.
We
can
continue,
obviously
to
like
improve
those
Docs
and
make
it
better
and
more.
You
know,
patterns
and
suggested
et
cetera,
but
I
think
I,
don't
think.
There's
any
controversy
there
I
think
it's
more
of,
like
you
know,
can
we
can
we
reach
a
consensus
on
permitting
the
hazard
in
in
general,
obviously
we'll
educate
the
hell
out
of
everybody
if
we
do
permit
it.
B
Yeah,
so
what
I
wanted
to
add
is
that
I
I
personally
believe
that
the
same
thing
hazard
is
important
but
does
not
affect
most
of
the
packages,
which
call
us
my
opinions
and
some
of
this,
which
is
to
say
that
I
believe
for
many
packages.
It
will
in
practice,
be
perfectly
fine
to
just
publish
a
comic
Jess
and
any
SM
built
independently
using
Babel,
and
it
will
actually
be
fine
because
in
most
cases,
that
package
will
be
used
once
or
twice
in
the
app.
B
B
People
will
then
not
use
that
library
if
it
doesn't
tree
shake
as
well,
because
any
transition
in
backpack
from
non
tree
shakin
to
from
non
command
J
as
to
command
J
s
means
that
it's
bailing
out
on
all
kinds
of
optimizations,
so
I
believe
that
for
most
packages,
what
they
will
do
pretty
rightfully
is
that
they
ship,
ecologist
and
use
em
build
using
table.
They
just
come
out
of
utility
functions
or
classes.
B
They
will
be
used
once
in
the
project,
so
that
project
will
use
one,
but
not
the
other,
and
it's
just
a
matter
of
supporting
different
kinds
of
projects.
So
I
think
that
in
practice
for
most
of
that
long
tail
that
we
talked
about
earlier,
they
will
be
fine,
the
dual
specifier
hazard
or
the
dual
instance
hazard
will
not
actually
affect
them.
They
will
not
actually
load
two
different
copies
in
practice.
A
A
G
Okay,
cool
well
I
mean
I.
Guess,
there's
really
two
decisions
to
be
made.
That
one
is
like.
Do
we
want
to
allow
the
hazard
or
not?
The
second
is:
if
we
allow
the
hazard,
do
we
want
to
allow
through
conditional
exports?
So
are
we
assuming
we
have
consensus,
then
that
we
are
okay
with
allow
I
mean
we
already
allow
the
hazard
in
the
status
quo,
so
I
assume
we're
okay
with
that,
and
then
it's
just
a
question
of.
Do
we
want
to
permit
conditional
exports?
I
guess.
Is
that
fair
to
say,
I'd.
G
A
I
think
it'd
be
good
for
us
to
talk
through
these
issues
first
and
then
flip
modes
into
consensus,
seeking
about
like
those
bloc
of
issues
that
we
have.
Okay
thanks.
Unless
anyone
you
know
would
prefer
but
I
think
I
think
we're
having
like
really
productive
discussions,
so
I
don't
want
it
to
to
degrade
so
conditional
exports
proposal
guy.
C
Sure
I
don't
have
any
screen
sharing
to
provide
for
this,
but
the
best
place
to
get
a
good
picture
of
it.
I
think
the
PRI
is
not
a
very
good
description,
unfortunately,
but
yeah.
So
it's
extending
the
export
proposal
so
that
you
can,
instead
of
just
mouthing
to
a
single
string
which
corresponds
to
a
module
within
the
package.
C
C
C
Then
I'm
gonna
pick
the
default
condition
that
the
only
thing
that's
really
enforced
is
that
everything
picks
the
default
condition.
Last
apart
from
that
it's
up
to
the
environment
and
it
could
even
be
customizable
by
a
flag
or
something
like
that,
and
then
it
kind
of
opens
up
a
space
for
different
environments
and
different
tools
to
to
be
able
to
state
their
needs
and
and
what's
nice
about.
C
Is
it's
statically
analyzable
and
build
tools,
you're
able
to
very
easily
optimize
for
just
the
the
environments
that
you're
targeting
and
and
so
it's
it's
kind
of
a
tooling
feature
as
well,
and
what
it's
just
pointed
out,
that
the
module
condition
is
a
different
type
of
condition.
Every
other
condition
is
a
constant
of
the
environment.
If
it's
your
tool,
your
runtime,
your
lint
or
whatever,
you
kind
of
have
this
there's
constant
conditions
and
there's
a
set
order,
and
it's
a
constant
it
doesn't
change.
C
C
If,
if
we
were
to
ship
such
a
thing
and
tools
adopted
it
great,
if
we
were
to
ship
such
a
thing
and
tooling
ignored
it,
because
modules
are
experimental,
we
could
always
effectively
decide
to
deprecate
it
if
people
aren't
using
it
so
III
the
way
I
feel
about
it.
Is
it's
quite
a
big
feature?
It's
incredibly
useful
I've
been
using
variants
of
this
feature
for
many
years,
and
it
would
be
great
to
see
it.
C
Help
simplify,
tooling,
help,
simplify
these
things
and
the
way
I
feel
about
it
is
that
we
should
just
put
it
out
there
and
as
as
an
experimental,
unflagged
implementation,
and
if
we
get
positive
feedback
Wiener
than
a
good
thing.
If
we
don't
get
any
feedback
work,
we
don't
get
usage,
it's
always
something
that
can
be
deprecated,
so
I,
don't
think
we
should
feel
like
it's.
It's
an
all-or-nothing,
I
feel
like
it's
a
it's,
it's
a
it's
a
great
to
have
and
it
could
simplify
things
quite
significantly.
C
A
I
guess
I
got
to
dig
through
this
a
little
bit
more
about
like
so
we're
talking
about
supporting
three
potential
conditions:
a
node
module,
node
and
default
I
will
avoid
with
bike
shedding
over
those
names,
although
at
a
later
point
in
time,
I
look
forward
to
bike
shedding
over
the
names,
but
I
do
I
do
think
like
from
a
semantic
standpoint
like
default
I'm.
Assuming
is
just
like
what
it
goes
to
if
there's
nothing
else
but
kind
of
teasing.
A
C
One
of
the
main
reasons
for
having
the
node
condition
is,
if,
like
I'm
of
the
opinion
and
it's
controversial,
I,
don't
know
if
it's
true
but
I
think
there's
a
good
chance
that,
like
this
node
monoculture
that
we
have
isn't
going
to
last
and
we're
going
to
end
up
in
a
future
where
we
have
lots
of
different
disparate
JavaScript
environments
and
I,
don't
know
if
that
will
happen.
But
if
it
does
we'll
want
a
node
condition
to
still
select
node
when
it
is
no
longer
the
monoculture.
C
While
it
remains
the
monoculture
you
always
want
to
use
default
because
well
we
always
want
to
use
default,
because
if
there
are
any
other
environments
and
they
will
always
work.
So
that's
the
main
reason
and
I
wouldn't
go
so
far
as
removing
the
node
condition,
because
I
think
it's
a
useful
way
to
support
other
environments
in
future.
B
Disagree
somewhat
for
the
exact
reason
that
I
don't
believe
that
we
are
currently
in
a
situation
where
notice
is
monoculture.
What
I
mean
by
that
is
there's
the
browser.
There's
react
native
and
there
is
I
think
electron
in
many
cases
that
have
certain
api's
like,
for
example,
fetch
that
I
would
consider
small
standard
than
requiring
HTTP.
So
for
me,
if
you
write
a
module
that
requires
imports
HTTP,
you
should
mark
that
with
the
node
guard,
because
for
me
default
is
for
portable
code.
B
E
G
E
A
I
do
feel
like
this
needs
a
little
bit
more
work
shopping,
even
if
we
land
on
exactly
what
we
have
today
and
when
we
try
to
reach
consensus
later,
like
part
of
what
I,
what
I
would
to
propose
for
this
is
kind
of
us
reaching
consensus
on
the
behavior
that
we
would
like
conditional
exports
to
have
what
we
want
to
work
towards,
but
still
give
us.
You
know
a
little
bit
of
time
to
to
work
through
this
and
have
some
more
discussions
around
it.
A
Just
because
we
really
haven't
and
I
think
that
if
we
can
hopefully
get
through
a
whole
bunch
of
the
other
consensus
discussions,
we
can
maybe
shift
and
in
focus
on
this
and
other
things
like
JSON
modules
and
like
as
a
group
I,
think
there's
still
a
whole
laundry
list
of
things
that
we
could
be
working
on.
But
anyways
I
think
that
perhaps
for
the
purpose
of
consensus
today,
it
might
make
more
sense
to
feature
to
focus
on
the
capabilities
and
the
higher
level
feature
and
try
to
reach
consensus
on
that.
Yon
your
hand
is
up.
A
B
The
one
thing
I
wanted
to
to
note-
and
that
goes
towards
my
point
earlier-
that
I
think
default
should
be
the
portable
code.
I
believe
quite
strongly
that
we
shouldn't
have
module
guard,
but
we
should
have
a
require
guard
and
I
know
that
guy
made.
That
change
for
very
specific
reasons
like
to
make
sure
that
we
can
have
a
flag
that
potentially
disables
the
divergent
resolution
but
I
think
even
with
a
require
guard,
you
can
have
such
a
flag,
because
you
can
basically
say
that
the
import
resolution
uses
the
require
guard
in
that
mode.
B
C
C
A
A
A
A
Number
one
thing
that
I
think
we
need
to
decide
on
as
a
group
right
now
that
in
turn,
will
kind
of
affect
all
of
the
rest
of
the
decisions
that
we
make
is
the
divergent
specifier
hazard,
so
just
like
really
really,
first
off
and
I
think
that
we
may
I,
don't
let's
see
where
we
get.
Does
anyone
object
to
us
moving
forward
with
the
agreement
that
we're
going
to
allow
the
hazard.
A
So
have
like
allowing
a
single
specifier
to
be
overloaded
to
have
you
know,
potentially
different
different
sources
that
are
served
based
on
the
loader.
So
the
ability,
like
the
the
functionality
that
that
conditional
mapping
and
the
conditional
exports
proposal
will
will
give
so
that
if
you
required
a
specifier
and
imported
a
specifier,
you
will
get
two
different
source
texts
and
two
different.
A
D
If
you
had
asked
me
eight
months
ago
before
we
had
decided
to
table
talking
about
extension
resolution
for
two
reasons,
only
one
of
which
I
found
compelling,
which
was
the
specifier
hazard
I,
would
have
said.
Yes,
this
is
something
we
should
look
into,
because
a
lot
of
people
in
the
community
are
doing
it
this
way,
and
maybe
it
can
work
out
for
us.
D
I,
don't
know
why
y'all
were
willing
to
make
such
a
rapid
about-face
on
it.
Just
because
someone
pointed
out
that
oh
man,
if
you
go
through
an
extra
hoop,
you
can
still
get
a
kind
of
similar
problem
and,
like
that
enough
to
make
you
completely
stay,
oh
well,
then
we
should
encourage
it,
but
I
still
don't
find
that
a
compelling
enough
situation
to
be
a
reversal.
For
me.
D
E
D
E
D
Makes
it
so
insidious
and
that's
what
was
said
in
a
lot
of
the
arguments
that
were
made
over
the
last
eight
months?
Like
yes,
even
within
a
single
package,
you
still
have
to
use
state
to
encounter
the
problem
and
how
likely
is
that?
But
it's
a
really
big
problem,
because
when
you
do
encounter
it,
you
won't
have
encountered
it
before
quite
probably,
and
it
will
be
a
pain
to
debug
and
waste
many
developer
hours.
B
B
B
The
problem
is
that
nobody
wanted
the
alternative,
at
least
what
we
I
now
consider.
The
only
alternative,
which
is
nobody
can
ever
maintain
a
package
where
the
same
major
version
is
available,
both
for
common
J's
consumption
and
ESM
consumption,
which
I
don't
think
is
a
worthwhile
trade-off.
We
thought
we
had
an
alternative
that
gathers
around
the
problem.
The
/sm
hack
right,
we
thought
hey.
This
is
a
way
that
we
can
not
have
this
problem
at
all,
but
people
can
still
maintain
one
major
version
that
supports
existing
comment
rate
as
consumers,
but
also
exposes
ESM.
B
It's
great.
It
works
well,
we've
figured
out,
it
doesn't
actually
work
at
least
not
reliably.
Actually,
we
still
have
the
same
issues,
maybe
even
worse,
because
now
it's
a
lot
harder
to
resolve,
because
you
can
no
longer
fix
that
one
package
you
know
I
have
to
fix
tens
of
packages
if
you
actually
want
to
resolve
the
issue,
because
by
default,
the
issue
is
now
distributed
across
an
ecosystem
instead
of
being
focused
in
one
single
point.
So
what
we
thought
was
a
way
around.
B
The
hazard
actually
turned
out
to
be
an
even
worse
version
of
the
hazard.
So
now
the
alternate
is
not
hey.
We,
the
consumers,
have
to
add
a
slash
years
em
to
the
requires.
The
alternative
now
is
suddenly
well
either
we
have
a
dual
instance
hazard
or
nobody
can
ever
publish
the
packages
available
as
native
PSM,
while
also
supporting
the
common
J's
in
the
same
major
version,
and
that
is,
it
is
no
longer
the
the
trade
off
changes
right.
The
calculation
changes
that
need
for
me
for
me.
Suddenly
it
falls
clearly
on
the
side
of
well.
D
B
Except
that,
then
we
have
the
hazard,
and
so
now
the
question
is:
can
we
make
it
safer,
more
easy
to
use
so
that
people
at
least
have
a
chance
of
finding
out
about
the
feature
or
have
something
that
they
can
google
for
instead
of
just
patterns
that
widely
sprout
out
in
the
ecosystem,
because
every
single
j/s
developer
in
the
world
is
trying
to
figure
out
how
to
do
it?
Okay,.
D
But
hear
me
out
like
this,
doesn't
remove
the
specifier
hazard,
as
we
just
as
you've
described
it
before
in
anyway.
It
still
exists
in
fold,
doesn't
actually
make
anything
better
in
that
regard.
It
just
makes
it
so
that
package
authors
have
another
avenue
in
which
they
can
potentially
do
something
very
wrong,
and.
G
C
C
G
D
What
I'm
saying
is
this?
Isn't
the
way
to
do
it?
So,
first
of
all
to
counter
exactly
one
of
your
points.
The
module
field
works
very
differently
than
this,
because
the
module
field
doesn't
change
its
behavior
based
on
the
package
that
calls
into
that
package.
All
right.
Your
bundler
just
always
uses
the
module
field.
If
it's
present
and
then
falls
back
to
the
common
Jas
field,
that's
a
very,
very
different
behavior.
It
affects
the
resolution
of
the
entire
tree,
all
right
now,
more
importantly,
I
do
get
behind,
enabling
that
use
case.
D
What
I
don't
get
behind
is
doing
it
in
this
fashion.
I
would
be
much
much
happier
if
we
said.
If
you
want
to
ship
ESM
and
support
common
J's
consumers,
then
you
have
to
opt
in
with
this
preload
flag,
and
then
that
gets
you
common
gist
usage
of
your
package,
because
you've
acknowledged
the
fact
that,
yes,
there
are
downsides.
I
know
what
those
downsides
are
and
have
a
talkative
flag
to
say,
load
me
in
CVS
any
way
that
I
consider
to
be
a
much
better
solution.
All
right
like
miles
I.
G
D
D
G
Saying
that
you're
blocking
conditional
exports,
because
there's
some
other
theoretical
solution-
I,
don't
I,
just
don't
buy
it
like
enough
time-
has
gone
by
I'm,
not
really
willing
to
wait
for
a
potential
other
solution
to
someday,
maybe
surface,
and
that
maybe
will
work.
Maybe
we
expect
compliant.
Maybe
that
we'll
find
consensus
like
what.
D
When
we
first
started
this
group
I
sat
down,
and
I
said
I
was
going
to
sit
here
and
I
was
going
to
say
that
I
did
not
want
to
ship
something
that
I
felt
was
incomplete
or
substandard
and
would
not
satisfy
all
of
the
use
cases
that
people
needed
this
I
consider
to
be
substandard.
You
can
disagree
with
me
on
that,
and
we
do
disagree
on
that
right
now
and
that's
fine.
C
I,
just
I
just
don't
think
it's
practical
for
start-up
time
to
allow
packages
to
require
gloving
and
also
require
that
they
execute
code,
that
the
consumer
doesn't
necessarily
have
control
over
a
lot
of
server.
Applications
are
startup
time
critical
and
especially,
do
a
lot
of
lazy
loading
techniques
by
night,
so
that
there's
a
bomb
or
dangerous
feature
for
the
for
the
ways
that
people
want
to
use.
No
J's
I.
D
G
D
C
Yes,
that
was
one
of
the
things
that
we
spoke
about.
A
lot
at
the
beginning
was
that
if
you
require,
if
we
require
gonna
behave
differently
after
you
run
import
against
the
same
module
than
if
you
haven't
already
run,
input
against
the
same
module.
You've
now
introduced
non-determinism
into
your
application
loiters,
and
that
that
that
said,
that's
a
non-starter
and.
D
A
Think
one
of
the
the
bigger
differences
to
here
West,
like
at
least
to
what
I
was
trying
to
suggest
before,
was
identifying
patterns
that
people
may
be
likely
to
use
and
making
better
api's
for
them.
So
I
think
the
example
of
you
know
documenting
the
wet,
like
it's
already
possible
today,
to
put
a
cash
item
from
the
ESM
from
the
packages
running
in
the
ESM
loader
to
append
something
into
the
common
j/s
loader.
If
it
doesn't
exist
already.
A
Yes,
that
may
create
race
conditions
so,
like
a
great
example
is
like
with
the
postorder
traversal.
If
a
deeper
module
used,
you
require
to
get
a
resource
that
you
then
are
later
importing
somewhere
else
in
the
graph
like
this
could
create
really
really
weird
stuff
happening
and
because
of
that
I
think
it's
absolutely
fine
to
document
and
give
api's
that
allow
people
to
manually
do
this,
although
I
do
think
that
doing
this
in
a
way
that
would
be
kind
of
automatic
or
magic
would
not
really
get
through
with
core
another
thing.
A
That
I
think
is
very
much
worth
considering
here
with
a
bunch
of
the
different
ideas
that
we've
that
we've
put
forward
require
ESN
as
well.
As
you
know,
the
auto
load
stuff
I.
Don't
think
that
we
should
underestimate
how
much
node
cares
about
startup
time
and
the
cost
of
startup
time,
and
just
because
we
have
an
idea
of
something
we
think
we
can
do.
A
You
know,
there's
of
extremely
high
likelihood
that
anything
that
hurts
startup
time
and
anything
that
slows
down
the
runtime
in
any
measurable
way
get
significantly
rejected
upstream.
That
was
one
of
the
reasons
why
we
had
to
remove
the
proxies
from
the
built-in
api's
and
introduced
an
api
to
like
manually
sync
them.
I.
Think
that's
another
great
example
of
something
where
it's
like.
We
can
educate
people
and
give
them
the
tools
to
do
it,
but
that's
like
obviously
a
huge
environment,
mismatch
and
foot
gun.
A
If
someone
like
you
know
imports
a
built-in
module,
then
requires
it,
then
the
require
polyfills
or
instruments
it.
And
then,
when
you
access
it
again,
the
ESM
world
like
it
will
not
have
those
updates.
Unless
you
run
that
very
specific
API
I
think
that
our
entire
implementation
ends
up
being
a
big
compromise
between
developer
experience,
usability
and
correctness,
because
we're
absolutely
not
working
in
a
vacuum
and
like
the
massive
reef
actors
that
guy
had
to
do
to
the
bootstrap
because
introducing
promises
like
broke,
async
hooks
and
a
whole
bunch
of
weird
ways.
A
A
Not
even
saying
this
is
100%
the
case,
but
like
I'm,
pretty
sure
the
lookup
in
the
export
map
to
hit
a
particular
key
for
a
common
j/s
module
is
not
going
to
introduce
any
sort
of
major
a
noticeable
slowdown
as
compared
to
main
or
export
maps
as
a
whole
in
the
way
in
which
we
are
talking
about
doing
this.
But
we
don't
even
have
any
guarantee
until
we
go
to
unflagging
upstream
and
core
that,
like
there
won't
be
folks
from
upstream
cool
object
to
that.
A
So
we
can
work
towards
reaching
consensus
here,
but
you
know
like
something
that
we
have
not
spoken
too
much
about
on.
This
call
is
things
being
palpable
to
core
and
mission
of
having
a
fast
run
time,
and
you
know
being
aware
that
that
is
actually
one
of
the
largest
stakes
that
could
stop
us
from
being
successful
with
something
right.
D
And
this
is
like
a
huge
barrier
towards
having
a
fast
run
time
because
it
encourages
patterns
where
you're
going
to
have
multiple
copies
of
your
code
loaded
into
the
tree.
At
the
same
time
and
executed
like
it
might
not
be
immediately
visible
in
startup,
but
the
costs
are
likely
to
be
even
larger
in
a
real
application.
I.
D
G
A
C
So
that's
that,
like
naive
expectation
and
then
when
they
realize
it
doesn't
they
only
need
something
to
replace
that
and
they
will
look
for
a
solution
and
like
ten
surgeries
Geoffrey,
that's
like
we
either
provide
a
solution
or
they
will
find
a
solution.
Unfortunately,
this
is
JavaScript
and
it's
it's
a
while
to
ecosystem.
It's
a.
B
D
A
Well,
I,
guess:
I,
guess:
here's
here's
the
the
thing
that
I'm
gonna
leave
that
into
now.
So
all
of
the
other
things
that
we
kind
of
have
on
here
to
discuss
I
believe
get
derailed,
because
if
we
skip
all
the
way
to
unflagging,
does
dual-mode
modules
block
unflagging
and,
let's
say
independent
of
whether
or
not
we
could
subtly
tweak
timelines
of
things.
A
Just
the
quick
question.
Just
anyone
object
to
us
unflagging,
a
version
of
modules
that
does
not,
at
the
very
least,
have
dual
modules
solved.
Eventually
as
like
something
we
have
consensus
on.
Yes,
I
objective
that
okay,
so
we
have
a
deadlock
here
and
we
have
a
deadlock
that
we
will,
after
all,
the
discussions
that
we've
had
here.
I'm.
Sorry,
just
for
notes
that
was
Jordan
right.
Yes,.
B
E
B
A
That
was
I
was
running
that
explicitly
for
a
reason,
maybe
we'll
get
to
get
to
that
later,
but
that
very
simply
here
and
I
am
not
saying
this
to
any
particular
person
or
saying
any
individual
needs
to
budge,
but
it's
very
clear
that
we're
at
a
deadlock
so
I
think
we
need
to
skip
all
the
way
forward
to
two
different
questions
here.
One
is:
what
is
the
way
in
which
we
can
move
forward
and
the
other
one
is.
How
do
we
continue
working
together?
A
A
Once
we
get
past
initial
things,
loaders
being
another
one,
but
we
do
have
this
impasse
right
now
we
managed
to
boil
it
down
to
one
very
specific
thing,
which
is
allowing
dual
mode
modules,
but
if
we
have
voices
and
I
think
there
potentially
is
even
more
than
one
voice
to
it.
Who
is
objecting
to
this?
We
kind
of
have
a
couple
different
ways
of
moving
forward,
and
perhaps
we
can
focus
on
coming
to
consensus
on
that.
A
A
We
need
to
query
all
members
of
the
group
and
we
need
to
have
enough
votes
that
a
majority
of
the
votes
are
there,
so
I
do
guess
that
with
eight
people
on
the
call
right
now,
we
could
in
theory
have
seven
out
of
14
votes,
and
if
we
get
one
more
even
just
through,
like
you
know,
messaging
some
people,
we
could
get
a
majority
vote
which
could
allow
us
to
move
forward
with
the
thing
I.
Personally,
really
don't
want
us
to
do
that.
Another
option
that
we
have
it's
not
documented
in
our
governance.
A
Although
with
enough
members
on
this
call
right
now,
we
could
decide
the
spirit
of
the
governance
and
to
document
it
later
would
be
to
move
forward
with
the
concept
of
something
like
rough
consensus.
The
idea
here
being
in
general
and
I
will
I
will
kind
of
ask
this
question
generically
if
we
believe
that
we've
really
talked
through
this
concept
like
to
the
end
of
its
completion
that
were
kind
of
where
we're
going
to
be.
A
A
Okay,
with
moving
forward
with
dual-mode
modules
or
without
dual-mode
modules,
without
requiring
a
vote,
because
and
I'm
not
saying
that
this
would
be
the
case
if
we
think
it
would
be
obvious
that
a
vote
would
would
be
able
to
be
pushed
through
as
a
majority
I
think
it
would
be
much
better
for
us
to
reach
some
sort
of
degree
of
consensus
around
this
at
least
a
rough
consensus
around
this,
so
that,
like
I,
don't
want
a
anyone
to
feel
singled
out.
I
don't
want
people
to
feel
railroaded.
A
A
G
D
G
So
how
about
this
with?
What?
If
we
here's
a,
not
here's
one
potential
way
forward,
we
could
agree
to
unplug
what
we
have
now,
potentially
with
say,
conditional
exports
also
merged
in,
but
behind
its
own
flag,
experimental
conditional
exports
say
Wes
if
there's
you're
talking
about
preload,
true
and
other
solutions.
G
D
If
you'd
like
to
ask
whether
you
can
merge
conditional
exports
behind
a
fact
flag
and
then
kick
this
can
down
the
line
until
we
want
to
unplug.
It
actually
merged
this
discussion
with
the
unflagging
discussions
later
on,
and
we
could
have
a
more
complete
discussion,
then
I
suppose.
So
why
not
kick
the
can
down
line
that
works?
D
Fine,
but
like
it's
worth
noting
if
you
are
going
to
do
that
again,
I
am
actually
perfectly
fine
with
like
the
syntax,
like
guy
did
convince
me
that
the
syntax
is
probably
useful
in
the
community
and
so
like
having
that
part
not
be
behind
a
flag
and
just
the
ability
to
like
take
an
object
that
has
like
a
main
member
that
that
seems
fine.
It
is
only
with
the
resolver
behavior
that
I
take
issue
with.
D
What
I'm
saying
is
so
half
of
guys
justification
for
the
feature
is
that
the
the
new
layout,
so
rather
than
it
just
being
a
key
of
string
to
value
of
string
or
array
of
strings
in
the
future,
its
key
of
string
to
object
or
array
of
objects
in
the
future?
And
then
there's
a
known
key
in
that
object
that
we
look
up
things
for
that
does
have
value
you're.
F
G
D
E
Can
I
can
I
reply
to
both
Jeffries
in
yours,
Myles,
real,
quick
I
know
we
have
very
little
time
so
for
Myles
I
think
we
can
establish
rough
consensus
even
if
we
haven't
yet
agreed
that
that's
our
process,
and
that
might
be
something
we
should
do
no
matter
what
is
just
say
like
we
have
decided
that
this
is
what
the
rough
consensus
is.
But
we
are,
you
know,
even
if
we
haven't
yet
decided
to
move
forward
with
it
and
then
for
Jeffrey
I.
G
E
G
D
A
Think
for
a
guy,
you
of
your
hand
up
still
know
how
to
put
it
down.
So
a
quick
thing
to
say
here
is
independent
of
whether
or
not
people
use
it
or
experiment
with
it
or
they
open
issues
on
repos
people
just
say:
I
won't
support.
It
I
think
that
the
contract
that
we
have
is
very
clear.
If
it's
behind
a
flag,
it
is
subject
to
extreme
change.
A
It
will
only
be
on
note
13,
which
is
a
non
LTS,
node
I
think
it
is,
in
my
personal
opinion,
absolutely
reasonable
for
us
to
change
that
at
any
point
in
the
future,
it
is
clear
in
the
contract
and
I.
Don't
think
that
even
if
people
start
shipping
things
that
rely
on
it,
I
have
no
qualms
in
breaking
that.
A
That
is
the
contract
of
the
flag
and
I
think
that,
yes,
if
it's
behind
the
flag,
people
will
use
it
less,
but
if
it's
not
able
to
be
used
at
all,
people
will
not
be
able
to
experiment
it
with
it
with
it
at
all,
I.
Think
having
ESM
not
behind
a
flag,
look
people
playing
with
the
SM
in
ways
we
never
even
imagined,
because
they
will
start
using
it
on
mass.
It
will
start
unlocking
a
whole
bunch
of
stuff
and
we
never
know
what's
gonna
come
up.
C
A
E
C
D
C
A
I
think,
let
me
suggest
something
and
then
let's,
let's
iterate
on
it,
if
people
are
okay
with
that,
so
the
full
thing
that
I
would
suggest
would
be
landing
conditionals
behind
a
flag.
It
can
still
be
modified
behind
that
flag
to
have
multiple
fight
like
we
can
figure
all
of
that
out
separately,
we
unflagged
ESM
with
current
implementation.
A
We
set
a
timeline,
oh
yeah.
We
also
we
do
document
as
well
as
the
hazards
as
well
as
patterns,
for
you
know
best
practices
of
using
them
or
not
using
them.
We
set
a
timeline.
I
would
like
to
suggest
end
of
January,
mostly
because
we're
getting
into
a
slower
time
of
the
year.
I.
Think
three
months
is
a
fair
amount
of
time,
and
we
can
revisit
this
at
any
point
between
now
and
then,
if
we
can
reach
consensus
on
it.
A
D
B
Yes,
okay,
headphones
and
my
concern
about
unflagging
without
a
require
guard
on
in
module
guard
is
that
if
people
in
the
ecosystem
start
publishing
packages
we
will
get
in.
If
we
have
an
unflagging
presentation
of
modules,
they
will
start
publishing
packages
that
work
against
that
unflavoured
of
modules,
extra
meat
or
not.
So
if
they
want
to
publish
two
different
versions,
they
will
pick
up
on
things
that
have
been
published
in
the
past
about
publishing
something
with
/sm
and
I.
Think
that
is
worse
than
them,
not
publishing
anything
at
all.
B
A
Guess
yawn
the
thing
I
would
say
to
that
and
then
I
guess
is
Jeff
and
then
guy
is
that
yes,
if
they
had
the
deep
things
that
wouldn't
be
great,
they
still
need
to
worry
about
this
hazard.
We
still
need
to
educate
them,
and
the
introduction
of
those
entry
points
in
a
couple
months
would
be
an
incremental
improvement
that
could
land
transparently.
A
E
So
yeah
that
I
mean
I
think
what
I
heard
out
of
what
Yan
was
saying,
or
at
least
what
I
selected
out
of
it
was.
If
we
let's
say
we
did
that,
and
we
unflagged
modules
and
wait
until
January
to
flat
to
unflagged
conditional
exports.
I
would
be
I
would
very
much
want
and
would
do
this
on
my
own
anyway,
nodes
Docs
to
strongly
advocate
against
publishing
ESM
packages
until
this
mechanism
was
there
because
that
creates.
You
know
a
ton
of
friction
by
not
not
being
backwards
compatible.
E
Why
we
need
that
long
like
why
not
till
the
end
of
the
year
or
something
you
know
two
months
seems
like
plenty
of
time,
possibly
even
sooner
but
like
the
I
guess,
that's
that's.
What
I'm
concerned
about
is
the
the
intervening
time
where
people
are
gonna
publish
you
know
like,
even
if
we
tell
them
it's
December
major,
that
just
means
that
they're
gonna,
like
probably
they're
gonna,
be
you
know,
working
on
a
v3
of
their
package
and
then
all
the
users
stuck
on
v2
are
not
gonna.
C
C
Kind
of
on
that
point,
the
practice
people
already
putting
MJS
files
in
packages
will
help
you
for
a
long
time,
people
already
putting
type
module
in
packages
they're
doing
a
lot
of
things
and
they're
trying
to
get
on
board
with
best
practices
today
and
without
modules
being
unflagged.
We're
actually
steadily
heading
towards
a
situation
in
which
we're
gonna
have
frictions
anyway,
because
people
are
doing
all
kinds
of
things
where
they
they
want
to
do
something.
C
It's
already
been
kid,
that's
broken
expectations
or
abuses,
and
it's
said
a
kind
of
a
thinking,
but
you
know:
are
we
not
making
progress
as
a
group
and
I
think
it's
absolutely
critical
that
we
do
on
Flag
within
a
month
and
I?
Think
it's
a
very
good
compromise
to
consider
flagging
jewel
mode.
I
would
like
us
to
still
consider
unflagged
as
experimental
I
think
there
is
actually
less
risk
in
in
shipping
an
insane
experiment.
It's
still
experiments
what
its
unflagged,
because
people
will
then
know
that
they
can
get
involved
in
give
feedback.
C
If
you
look
at
how
little
user
feedback
we've
got
it's
because
it's
still
been
behind
this
flag
and
so
it'll
be
great
to
open
up
that
period.
My
ideal
would
be
shipping
conditional
exports,
as
I
say
it
can
still
be
experimental
and
then
it
allows
a
way
to
progressively
enable
doom
would
it'll
be
great
if
we
could
see
ever
consensus
on
I.
A
A
But
again,
I
would
like
to
suggest,
and
if
anyone
has
an
alternative
set
of
things,
please
feel
free
to
add
it
landing
conditionals
behind
a
flag,
unflagging
ESM,
with
the
current
implementation,
with
proper
documentation
of
conditionals
hazards
patterns
to
use,
have
a
timeline
with
the
end
of
January
to
move
forward
with
dual-mode
modules.
If
we
do
not
have
any
alternative
that
seems
to
be,
you
know
looking
like
something
we
would
do:
unflagged
conditionals
without
dual
mode
as
soon
as
possible.
Try
to
reach
consensus
on
that.
A
A
E
A
If
there
are
no
about
this,
I
thought
this
is
the
consensus.
Yes,
so
I
am
asking.
If
there
is
objections
to
this
plan,
if
we
have
no
objections
right
now,
we
can
move
forward
with
landing
conditionals.
We
can
behind
a
flag,
we
can
move
forward
with
documenting
the
hazards
and
patterns
and
we
can
have
a
flag
too
or
we
can
have
a
PR
to
unflagged
modules.
You
know
this
week.
E
E
A
Because
with
Thanksgiving
and
the
Christmas
holidays
and
New
Year's
I
just
want
to
be
fair
to
people
and
give
them
an
opportunity
of
amount
of
time
now
for
what
it's
worth.
This
is
the
consensus
that
we're
reaching
today.
If
we
can
reach
consensus
earlier,
then
we
can
do
it
earlier.
This
is
a
deadline.
Okay,.
E
A
And
we
can
reach
consensus
on
anything
else
between
now
and
then
so.
Can
change,
for
example,
I
think
that
we
maybe
have
consensus
on
conditional
exports,
but
not
on
dual
modules,
so
we
can
land
that
with
a
default
I
just
I
want
to
decouple
those
from
the
unflagging,
because
I
think
that
we
can
explore
those
spaces
separately.
B
A
F
D
D
A
C
G
Amend
I
mean
that
slightly,
if,
if
we
don't
reach
consensus
on
whatever
we
name
these
fields
or
something
like
if
that
breaks
down
somewhere,
then
we
just
shipped
the
whole
thing
behind
the
flag
and
we
at
least
have
consensus
for
that.
But
if
there's
you
know
more
consensus
to
ship
part
of
it
unflagged
sure,
but
if
X
in
census
fails
and
we
least
ship
the
whole
thing
behind
it.
Swag.
A
G
A
You
everyone
for
being
flexible
and
open.
This
has
obviously
been
a
heated
discussion
and
a
long
path
and
I'm
really
glad
that
we
were
able
to
reach
reach
a
path
that
we
could
all
agree
upon.
I'm
really,
that
makes
me
really
happy.
I
also
think
perhaps
I'll
add
an
agenda
item
I,
think
that
if
we
unflagged
we
should
consider
chartering.
But
let's
follow
up
with
that.
Next
Wednesday.