►
From YouTube: Node.js Foundation Modules Team Meeting
Description
A
Okay,
this
is
the
fourth
of
December
modules
team
meeting,
there's
a
bunch
of
people
at
tc39
this
week,
so
we're
gonna
do
the
best
we
can
without
them.
Let's
see,
we've
got
another
member,
oh
there's
Jordan
he's
managed
to
take
some
time
off
from
tc39,
so
we've
got
a
few
items
on
the
agenda
today.
The
first
one
is
azzam.
The
get
package
type
utility
function
is
not
exposed.
Jeffrey.
Did
you
add
this
item
recently?
I.
Don't
think
I
saw
it
on
the
original
agenda.
B
A
Ok,
so,
let's
move
on
to
the
the
next
set
of
issues:
we've
got
conditional
exports
as
Flags
loader,
hoaxes
instrumentation,
unflagging
and
stabilizing
the
resolver.
Maybe
if
you
think
it's
it's
sensible
to
discuss
the
unflagging
considerations,
maybe
we
start
off
with
conditional
exports
as
Flags
then
discuss
the
unflagging
stuff.
Why
worry,
while
we're
discussing
that,
if
that
makes
sense
to
everyone.
A
Jeffrey
does
that
sound
sensible
to
me
okay,
so
this
was
a
issue
raised
by
Tobias
and
I
was
able
to
catch
him
on
Twitter
chat
briefly,
while
he
was
at
this
conference
and
he's
actually
interested
in
implementing
exports
in
wet
pack,
which
is
really
great,
he
likes
it.
We
discussed
variations
of
the
API
and
I
tried
to
get
as
much
feedback
from
him
as
I
could.
A
Support
I
believe
it's
it's
custom,
conditions
and
composition
of
conditions.
So
how
would
they
support
conditions
in
webpack
that
are
webpack
specific
and
how
would
they
allow
those
conditions
to
work
with
the
existing
conditions
we
have
like
what
would
it
mean
for
webpack
to
say,
support
the
required
condition
alongside
other
conditions
that
are
maybe
webpack
specific
like
browser
and
things
like
that,
so
the
clarification
there
was
that
the
current
proposal
for
conditional
exports
does
support,
object
nesting,
so
you
can
nest
conditions
and
group
them
together.
A
C
Oh
yeah,
here
all
right
to
me.
It
felt
like
the
issue
was
actually
resolved
because
I
think
further
on
after
we
kind
of
clarified
the
nesting
stuff,
he
was
like
cool
I'll,
implement
this
and
then
I
didn't
see
any
real
disagreement
or
issues
anymore
and
that's
that's.
The
case
should
be
potentially
even
closed.
The
issue
as
clarified
and
working.
A
One
action
item
that
could
be
associated
with
it
is
if
we
want
to
support
custom
flags
in
nodejs
itself
kind
of
in
line
with
the
issue
title
and
then
Oh
also
further
than
that.
I
just
feel
like
the
uncertainty
that
my
any
uncertainty
that
might
be
left
around
conditional
exports
I
think
it's
very
much
about
ensuring
the
edge
cases
of
the
semantics
work
out
for
all
of
these
use
cases
for
tools
or
for
the
different
edges
of
the
ecosystem,
so
as
much
as
possible
for
us
to
be
having
these
discussions.
A
A
Sure
so
the
use
case
for
setting
custom
conditions
would
be
I.
Think
the
canonical
example,
that's
probably
like
a
development
or
production
environment.
So
say
you
have
an
application
that
can
run
in
two
modes:
developmental
production
or
just
a
production
flag.
That's
going
to
resolve
things
differently,.
A
It
does
crossover
with
functionality.
You
can
achieve
equally
with
top
level
of
weight,
but
it
can
be
nice
to
have
the
resolve
a
way
to
do
it
as
well.
To
avoid
the
sort
of
code
passing
costs
and
things
like
that,
so
you
would,
you
would
have
a
kind
of
environment
flag
where
you
can
set
this
custom
condition
and
then
that
path
would
resolve
in
in
your
exports
resolver.
So.
D
Are
you
envisioning
just
pivoting
on
node,
N
or
generically
any
environment
variables
or
something
different,
because,
like
right,
there's
a
lot
in
the
ecosystem?
A
lot
of
people
use
environment
variables,
many
of
them
like
babel
and
sit
on
top
of
node
ends
and,
like
you
know,
interoperate
with
them
and
then
there's
plenty
that
are
just
or
not
and
underscore
ends
with
productive
production
development.
D
The
pivot
between
things,
like
yeah
I,
mean
I,
have
a
number
of
use
cases
for
environment
variables
and
many
of
my
use
cases
for
environment
variables
are
actually
resolving
different
things
in
tests,
so
that
I
can,
in
my
CI
matrix
I
can
say.
I
want
this
job
to
run
with
deep,
equal
and
I
want
this
other
job
to
run
with
the
native
assert
implementation
and
I
use
an
environment
variable
to
do
that,
and
and
I
just
require
dynamically
a
different
file.
D
But
if
the
resolver
could
do
that
for
me
in
my
own
package,
I
would
use
that.
But
when
I'm
thinking
of
like
defining
different
environment,
variable
things
for
other
people
to
consume,
really
the
only
use
case
I
can
come
up
with
is
like
when
people
do.
What
like
react
does
and
they
make
like
a
roll-up
bundle
for
Devin
for
a
prod
or
something,
and
it's.
A
E
Yes,
so
I
just
wanted
to
mention
the
only
thing
that
concerns
me
about
what
Jordan
just
said
is:
if
I
have
a
package
which
say
uses
no
damn
equals
test,
it
would
be
unexpected
to
me
for
one
of
my
dependencies
to
react
to
that,
because
ultimately
I'm
setting
that
environment,
because
usually
because
I
want
to
select
specific
to
Babel
target,
but.
E
A
C
Yeah
I
think
that
at
least
from
what
I
know
about
the
existing
right
now
I
think
packages
deep
in
the
defense
between
you,
switching
behavior
based
on
no
temper
is
something
that's
already
pretty
widespread,
especially
like
little
chest,
maybe
not
quite
as
much
as
known
in
production
and
even
another
test.
I
would
not
be
surprised
at
this
packages.
C
A
D
So
I
guess
like
to
me.
It
seems
like
the
react
use
case
is
not
a
common
one
and
like
it's,
it's
not
zero
right
in
its
present,
in
particularly
big
projects
like
react
and
I'm
sure
you
know
all
the
other
similar
frameworks
do
it,
but,
like
the
vast
majority
of
node
apps
and
like
packages,
I
think
don't
pivot
resolvers
in
this
way,
and
like
my
testing
use
case,
I'm
fine
continuing
to
do
my
little
hack
because
it's
tests
who
cares
but
like
I,
just
don't
see
this
pattern
commonly
used
for
consumers.
D
I
feel
like
the
like.
Typically
I
would
expect,
bundling
and
minification
and
optimization
to
be
something
you
leave
to
the
fight
the
end
consumer
and
the
fact
that
react.
Does
it
I
know
why
they
do
it,
but
it
also
like
creates
new
problems,
and
it's
just
it's
not,
but
it's
not
like
a
common
pattern.
So
I
guess
it
feels
weird
to
me
to
if
that's
the
only
use
case.
It's
really
solving
feels
weird
to
me
to
give
that
kind
of
a
first
class
position.
A
D
Yeah
so
like
I,
don't
have
any
objection
to
doing
it
under
a
flag
as
long
as
we
don't
have
an
expectation
that
that's
going
to
be
unflagged
without
a
bunch
of
extra
work
and
I'm,
not
necessarily
thinking
design,
work
from
a
technical
standpoint,
but
I
think
there's
a
lot
more.
Like
rationale,
work
that
would
need
to
be
done
and
ideally
like
research
of
like
what
other.
D
What
are
all
the
use
cases
this
can
solve
and
what
are
similar
use
cases
that
this
won't
solve
that
we're
intentionally
not
solving
for,
because
I
think
that
that
that
might
be
enough
to
convince
me
and
hopefully
out
of
people
without
any
technical
changes.
But
you
know
I,
don't
know
yet
did
that
make
sense.
Sure.
A
And-
and
maybe
this
is
something
that
we
should
develop
on
this
more
of
a
driving
need
from
users,
but
it's
only
something
that
could
be
experimental
and
that
we
could
provide
now
so
that
people
could
play
around
with
it
and
get
more
feedback
into
the
process.
Wesley
has
a
comment
saying
that
he's
he
doesn't
like
the
idea
of
composing.
These
conditions
through
JSON
objects
that
it
would
be
better
to
write
code
to
do
this.
Does
anyone
want
to
discuss
that
while
we're
on
this
point.
A
F
A
A
So
it
feels
like
a
very
necessary
feature
to
me
and
specifically
this
issue
that
Tobias
posted.
He
is
specifically
requesting
composition
because
he
needs
it
in
webpack
through
this
interface,
so
that
the
clarification
was
exactly
that
we
are
solving
the
use
case
through
exports.
That
he's
asked
Jeffrey.
B
I
feel
like
before
we
unflagged
that
we
should
probably
get
that
in
front
oughta,
but
I
feel
like
it
hasn't
really
gotten
very
much
exposed
yet.
A
Well
so
there
they're
both
have
been
following
the
proposal.
I
mean
sort
of
both
tobias
of
webpack
and
devon
or
Parcel
have
both
been
following
the
proposal
and
are
interested
in
aligning
with
it
I've
been
trying
to
get
as
much
feedback
from
them
as
possible.
Ideally
I
think
it
would
be
great
if
we
could
get
them
into
these
meetings
and
make
sure
that
their
their
views
are
being
incorporated
into
the
process.
I'll,
try
and
follow
up
with
that
as
well.
I
did
invite
Tobias
to
this
meeting
that
he
couldn't
make
it
Cory.
E
So
I
just
wanted
to
mention
one
concern:
I
have
about
composition
of
the
exports
and
being
able
to
write
code
that
would
generate.
It
is
I,
think
that
might
encourage
situations
where
you
have
modules
that
have
a
lot
of
files
and
they
use
it
to
implement
extension
lists
exports,
and
that
could
become
a
problem.
D
And
then
anyone
who
wants
to
allow
our
extension
Alice
imports-
that's
already
gonna,
be
an
issue.
I
already
have
two
entries
for
package.json
in
all
of
my
three
packages
that
these
exports,
one
with
an
extension
and
one
without
like
the
solution
to
that
is
convincing
export
maps
to
support
a
more
dynamic
format,
not
trying
to
pretend,
like
the
ecosystem,
isn't
going
to
want
that,
but
that
that's
sort
of
a
problem
that
we'd
kick
the
can
down
I.
Think
to
them.
Since
we're
not
people
immense
support
for
it
until
they
do
yeah.
E
E
A
E
A
G
Right
because
they
have
to
execute
JavaScript,
then
you're
correct.
But
my
point
is:
if
you
have
like
I,
don't
think
attempting
to
encode
every
dynamic
behavior
that
you
want
to
support
into
a
static
format
is
the
way
to
go.
I
think
you
just
have
to
admit
at
some
point
that
you
want
the
system
to
be
pluggable
and
you
want
to
execute
JavaScript.
D
G
Export
map
already
provides
I
think
it's
fair
to
say
that
if
you
want
to
compose
multiple
export
Maps
or
the
ability
to
compose
conditions,
I
think
it's
fair
to
say
that.
Well,
maybe
a
we
modify
the
export
map
floaters
to
support
a
dynamic
thing.
Where
be?
You
have
to
include
a
load
of
yourself
that
does
support
that,
but
I
think
the
two
issues
are
deeply
intertwined,
because
this
concept
of
loaders
is
just
a
concept
of
replacing
the
default
loader,
which
we're
saying
already
supports
export
Maps,
which
is
a
form
like
static
configuration.
G
E
D
B
The
the
one
and
I'm
not
trying
to
argue
one
or
the
other
West,
but
the
one
difference,
though,
is
that
this
would
need
to
be
like
a
package
level
loader
like
because,
like
the
exports
map
is
package
level
and
right
now,
all
of
our
load,
all
of
our
loaders
are
global.
You
know
a
part
of
like
initializing
node.
G
I
mean
I
would
think
of
the
dynamic
case
is
less
about
like
a
function
that
generates
a
map
that
could
be
different
every
time
you
call
it
it's
more
like
a
function
that
you
call
once
and
then
you
use
to
get
the
object
like
how
babel
RFC,
zinnias
'luntar
sees
and
every
other
code
is
configuration
file.
Format
works.
It's
called
wants
to
create
the
object
right.
A
But
you
don't
you
want
the
entire
resolution
process
to
be
statically,
analyzable
and
and
even
though
it's
dynamic.
The
whole
point
is
that
we
can
determine
every
possible
branch
and
have
full
analysis
of
every
possible
branch,
which
is
the
important
information
that
any
tool
needs
to
know,
because
otherwise
it's
only
seeing
a
snapshot
of
the
world
that
it
happens
to
have
got
at
the
time
of
that
function.
Execution.
G
A
G
B
I
think
what
he's
saying
is
like
yes,
it'll
change
if
you
like
edit
the
file
edit
your
package
at
Jason
or,
if
you
edit,
the
source
code
of
the
files
in
the
package,
but
yeah,
that's
like,
of
course.
The
point
is
that
it
doesn't
change
within
the
lifetime
of
the
runtime
like
you
would
be
killing
the
node
process
and
starting
it
up
again
and
then
within
each
node
process.
It's
it's
immutable
and
the
it
doesn't
change.
That's
I
think
that's
what
guys
trying
to
say
wise.
C
C
Think
that
just
convinced
me
that
we
shouldn't
have
a
flag
that
allows
adding
custom
conditions,
because
if
a
package
needs
custom
conditions,
it's
a
very
bad
sign
for
the
ecosystem,
because
now
two
different
packages,
which
has
two
different
ideas
of
what
Aflac
means,
potentially
conflicting
definitions
of
a
certain
random
string,
property
value
and
since
it
always
has
to
apply
globally
to
the
entire
loader.
If
it
asks
us
a
flag
to
note,
I
think
it
might
be
a
bad
idea
to
have
such
a
flag,
which
is
kind
of
recycling.
C
The
current
discretion,
no
I
think
the
point
for
me
of
exports,
and
that
is,
after
all,
somewhat
correct.
What
I
just
said
is
that
there
is
a
bunch
of
tools
implemented
in
various
languages
from
other
plugins
over
language,
runtimes
or
compilers
to
run
times
like
node
of
bundler
like
web
pack,
that
all
need
to
somehow
converge
on
the
meaning
of
without
any
additional
information.
What
is
the
resolution
of
this
thing?
C
And
for
me,
the
question
is,
without
anybody
running
additional
code
for
every
single
one
of
those
to
plug
into
them,
to
provide
the
resolution
that
actually
works
for
the
ecosystem.
What
is
the
minimal
set
of
staff
that
exports
needs
to
provide
so
that
we
can
have
an
ecosystem
that
works
with
those
semantics
without
everybody
having
to
run
every
single
tool
with
local,
equal
loader
equals
the
thing
it
actually
works,
and
to
me
composition
of
conditionals
being
able
to
say
something
like
this?
C
A
A
B
I
guess
the
question
is:
can
it
be
something
that
gets
built
later?
Like
say
it's
imagined,
it's
the
end
of
January
and
conditional
exports
is
exactly
as
it
is
now.
If
we
were
to
unflagged
this,
then
could
we
add
this
other
stuff
later
on,
as
an
enhancement
or
would
be,
would
there
be
any
braking
changes.
B
Okay,
so
then
follow-up
question,
then:
are
there
any
things
that
we're
talking
about
or
considering
with
related
to
conditional
exports
that
aren't
backwards
compatible
that
are
like?
Oh,
we
really
should
figure
this
out
before
we
in
flag,
because
you
know
once
we
in
flag
we're
kind
of
locked
in
the
stuff
yeah.
A
A
A
A
B
B
Well
note
in
default
seemed
perfectly
fine
to
me,
but
I
feel
like
if
it
were
me,
I
would
have
put
like
I
would
have
node,
take
a
child
object
and
then
inside
that
it
would
take
like
common
jsm
module
or
something
like
that.
That's
that's
I
mean
I
feel
like
you've,
given
good
reasons
why
that
doesn't
make
sense,
but
I
keep
coming
back
to
it.
B
A
It's
a
really
tough
design,
space
and
and
you'll
find
like
most
people
I'm,
seeing
it
at
first
glance.
Weren't
necessarily
immediately
have
a
full
picture
of
how
the
semantics
are
behaving,
and
maybe
that's
okay,
because
in
most
scenarios
people
are
just
copying
examples
or
standard
usage
examples,
which
is
what
they
should
be
doing,
because
there
are
certain
patterns
that
are
sensible
in
certain
patterns.
That
would
not
be
sensible,
but
yeah
that
that's
the
sort
of
stuff
to
check
I've
gone
through.
So
many
iterations
of
this
as
well
and
feel
like
this
is
probably
the
simplest.
F
Yeah,
so
just
I
have
one
concern
about
know
being
a
condition.
If,
if
we're
saying
note
is
like
specifying
that
node
was
the
legacy
modular
format
being
common
Jas,
but
there's
also
trying
to
explain
to
people
that
if
you
use
yes
m
in
node,
that
is
still
node.
But
it's
not
the
node
condition,
because
if
you're
using
the
loader,
then
it
is
definitely
an
old
condition
as
well.
Iii
would
like
to
that.
A
for
saying
type
module
default
could
as
well
be
module.
F
If
it's
confusing
here,
it's
confusing
there
and
it's
confusing
in
the
type
in
the
browser,
then
you
know
it's
confusing
enough
to
be
the
confusing
thing
everywhere.
So
calling
it
modules,
just
fine
I
mean
we're.
Not
gonna,
be
very
particular
here,
but
default
is
a
little
bit
presumptuous,
that
a
package.json
implies
that
the
default
is
a
JavaScript.
A
can
script.
Module
fact
so
so
default
here
is
a
little
bit
strong
I
think
the
word
module
here
is
as
confusing
as
it
is
everywhere
else.
So
yeah.
C
Yeah
and
just
to
clarify
as
I
think
I
had
something
within
the
lines:
node
does
not
mean
require,
or
common
dress
or
anything
like
node
really
means
it
is
using
node
API
is,
it
doesn't
not
say
anything
about
the
module
format,
so
an
es
module
with
node
specific
code
would
still
be
falling
under
the
node
condition,
at
least
so.
The
current
definitions
are
require
specifically
for
the
require
system.
For
the
common
GS
system.
Note
is
specifically
just
using
node
api's,
as
in
like
the
standard
api
is
global
buffer.
C
All
account
staff
and
default
is
meant
as
it
is
not
using
any
runtime
specific
api's,
or
at
least
supposedly
it's
using
standard
api's
across
runtime,
so
that
grade
default
is
I.
Think
reasonable,
because
well
the
node
API
is
like
a
global
buffer
object.
Are
not
the
default
across
JavaScript
render
one
times,
but
yeah
I
think
rebranding
default
as
module.
I
know
that
I
ranted
against
that
a
lot,
but
I
was
taught
to
die,
but
you
know
it's
nothing.
It's
a
pill.
I
would
buy
on
I
think
using
modulus.
Also,
okay
in
house
president.
F
A
So,
just
just
to
add
to
that
briefly,
if
we
have,
if
anyone
has
suggestions
of
an
alternative
names,
he
use
for
defaults
that
if
that
name
is
not
set
and
we
can
change
it,
anything
that
is
terror,
and
maybe
it
isn't
there
to
users.
Maybe
it's
not
obvious
what
it
means,
like
main,
is
obvious
or
I
could
get
behind,
changing
it
to
module
that
the
concern
with
that
is
just
the
confusion
that
it
might
mean
yes,
module
where,
as
default,
can
quite
happily
point
to
a
comment.
A
Yes,
module
and
it'll
work,
fine,
so
there's
all
those
kind
of
cross
format,
things
and
then
also
it's
worth
remembering
that
the
cross
format
stuff
is
the
problem
we
have
now,
but
it's
not
necessarily
what
things
are
going
to
look
like
in
future.
So
we've
got
to
be
careful
that
we're
not
putting
names
together
that,
like
jeaious
next
end
up
in
a
situation
where
they
look
very
dated.
Looking
back
on
them.
A
Sure,
well,
that's
so:
we've
got
20
minutes
left
I
think
it
sounds
like
on
the
exports
flag
question
we're
happy
to
defer
that
to
a
later
phase
and
then
on
the
export
stuff.
These
have
been
good
discussions
to
have
because
they
are
the
semantics
that
we
need
to
be
absolutely
certain
about
coming
up
to
I'm
flagging,
jewel
Marie.
So
the
next
item
on
the
agenda
is
I'd
like
to
make
it
the
the
stabilizing
the
resolver
point.
A
Which
is
kind
of
building
on
from
this?
This
is
issue
four
or
five
one
or
nodejs
modules,
and
the
the
overall
thinking
is
that
we
we've
got
modules.
Unflagged
and
people
are
gonna,
start
to
ship
all
these
properties
in
their
package.json
x'
and
we're
reaching
the
point
now
where
we
can't
make
where
it's
good
we're
gonna
start
to
be
in
the
situation.
We
can't
make
breaking
changes
to
these
things,
so
it's
going
out
and
it's
becoming
stabilize
very
quickly:
exports
being
used,
type
module
being
used
and
the
semantics
being
used.
A
A
Jordan's
got
to
leave
there
thanks
for
joining
Jordan,
so
we're
looking
to
provide
a
jewel
minute
solution
by
the
end
of
Jan.
The
current
proposal
for
that
is
based
on
conditional
exports.
If
there
are
alternatives,
those
should
be
forward
for
it
now.
If
there
are
adjustments
to
exports,
they
should
be
brought
for
it
now
and
then,
in
terms
of
the
stability
aspects,
there's
this
kind
of
risk
that
I
was
kind
of
thinking
about
which
is
the
the
fact
that
we've
got
no
12
LTS
going
out.
A
It
would
be
I,
don't
know,
maybe
it'll
be
okay,
but
the
concern
was
that
if
people
are
shipping,
jhummer
packages
that
are
gonna
have
a
require
path
and
that
require
path
is
expected
to
trigger.
If
that's
going
to
become
an
issue
where
there
will
be
a
node
12
version
outs
that
doesn't
support
exports
and
then
suddenly
on
an
LTS
release,
it
does
support
exports.
And
now
the
resolution
is
going
to
change
in
no
js',
12,
say
Jan
or
April.
A
So
thinking
about
stabilizing
the
common
jewish
resolver
and
the
conditional
exports
in
the
common
J's
result
of
sorry,
that's
a
terrible
summary
of
it,
but
maybe
if
anyone
else
wants
to
add
to
that
that
could
help
a
young.
Did
you
still
have
your
hand
up
from
before?
Did
you
want
to
discuss
I
briefly
low
up
in
between
so.
C
Just
wanting
you
to
sum
up
the
the
base
concern,
at
least
for
me
if
we
want
to
back
port
the
dual
mode
Inc
like
actually
use
modules,
including
the
dual
mode.
So
it's
not
because
I'm
assume,
if
we
have
do
more
13
and
14,
but
then
back
40s
module
support
an
unflagging
12
without
dual
mode.
Things
will
be
in
utter
chaos.
C
At
least
that
would
be
my
gut
feeling.
So
if
we
want
to
back
part
it
the
longer,
we
wait.
The
bigger
the
impact
will
be
because
the
more
packages
there
will
be
that
have
exports
and
the
more
users
there
are,
that
might
be
broken
by
unexpected
imports
from
exports
using
packages
breaking.
So
if
we
can
get
it
in
in
the
general
release
where
there
is
still
a
relatively
limited
impact,
not
three
moments
where
people
can
be
publishing
packages
that
might
break
consumers
on
release
of
12
with
exports.
A
Do
we
risk
a
situation
where
exports
would
match
the
defaults,
whereas
Juma
it
is
a
required
default
branch
which
means
that
no
12,
if
we
ship
exports
without
conditional
exports
and
it
just
matches
default,
then
the
Jan
to
April
release
of
no
12
would
break
dual-mode.
Just
for
those
versions
of
note,
because
the
common
J's
version
would
try
to
load
the
it's
module
version
because
default
so
thinking
through
these
kinds
of
cases
and
making
sure
that
we're
we're
crystal
clear
on
on
on
our
ideal
compat
and
stability
of
that
resolver,
yeah
Jeffries.
B
So
yeah,
it
seems
to
me,
like
the
what
seems
like
our
status
quo
option
of
like
taking
what's
already
been
on
flagged
backporting,
that
on
January
7th,
whatever
the
deadline
was
and
then
back,
porting
conditional
exports
way
out
in
April
would
cause
problems
because
people
will
start
shipping
packages
with
conditional
exports.
That'll
suddenly
behave
differently
between
you
know,
12
point
whatever
in
January
and
12
points
something
else
in
April,
so
it's
sort
of
like
that
seems
to
be
the
worst
of
three
options
where
the
other
two
options
are.
B
G
G
B
I
mean,
if
that's
the
case,
Wes,
and
this
is
all
moot
and
we
don't
have
to
worry
about
it,
and
then
it
never
gets
back
toward
it
or
it
gets
back
border
but
stays
flagged,
but
I'm
operating
under
the
assumption
that
we
can
back
port
the
unflagging
it's
like
aye
aye.
G
G
B
B
H
So
it's
not
just
that
we
came
back
for
it.
I
want
to
back
port
it
because
it
will
block.
If
we
don't,
it
will
block
other
changes
that
are
unrelated
to
ASM
and
the
more
we
backwards,
the
easier
it
will
be
to
tool
and
other
changes,
and
the
only
thing
that
we
cannot
do
in
LCS
is
major
changes.
Well,
that's
the
same
as
as
current
releases
I.
G
A
With
exports
we're
in
a
situation
where
users
have
not
shipped
they're
only
just
starting
to
ship
exports,
so
by
its
nature
it
is.
It
is
like
a
feature
that
is
in
this
gray
area,
where
you
can't
it
like.
It
doesn't
exist
because
it
hasn't
got
any
usage.
So
even
though,
theoretically
it
would
be
breaking
if
there
is
no
usage,
it's
okay
to
ship,
because
that
is
not
a
that
is
not
a
breaking
change
at
all.
A
The
problem
comes
once
people
start
shipping
packages
and
using
exports,
which
is
what's
happening
now
and
exactly
why
we
need
to
think
about
this
now.
It's
then
it
does
become
breaking.
So
that's
why
I'm
saying
if
we
miss
the
gen7
Altius
release,
then
we
probably
come
back,
but
if
we
make
a
john
7
LTS
release,
then
it's
that
it
would
be
a
major
change,
because
exports
will
have
no
coverage.
Yeah
I.
G
A
Mouse
has
been
quite
clear
throughout
the
process
that
he
still
intended
to
back
port
to
12
and
that
he
was
aiming
aiming
to
do
that.
It's
not
to
say
that
we
definitely
can
and
this
this
might
well
be
a
blocker,
but
this
is
why
we
are
discussing
it
to
try
and
work
this
part
out
because,
as
we
kill
says,
if
we
end
up
in
a
situation
where
we
cannot
back
bats
back
the
entire
12
release
line,
it
also
has
huge
adoption
implications.
G
B
Right
well,
I
also
dropped
a
link
in
the
chat.
The
the
discussion
was
to
back
port
the
whole
thing
we
have
so
far.
The
unflagging
all
features
that
are
currently
shipped
and
then
the
discussion
is
whether
we
should
ship
that
or
wait
until
we
can
unflagging
ditional
exports
to
ship
with
that
and
I.
Think,
that's
the
that's
where
we're
that's
what
this
discussions
about!
It's
like
you
know,
we'd
agreed
to
like
hold
off
until
the
end
of
January
for
get
a
shell
exports,
but
that
would
mean
that
we
missed
the
January
7th
deadline.
B
So
if
we
could,
you
know,
got
our
act
together
and
resolve
any
remaining
issues
with
conditional
exports
by
January
7th.
Then
we
could
get
that
merged
in
unflagged
on
thirteen
before
the
seventh,
then
the
whole
thing,
like
everything,
ESM
related,
that's
on
thirteen
On
January
7
that
gets
back
ported
to
twelve.
C
A
C
A
Then,
in
entirely
on
Flag,
either
in
January
or
April
I
believe
miles
was
looking
to
do
an
apron
flagging
of
modules
entirely
on
twelve,
and
that
might
give
us
a
lot
more
a
little
bit
more
about
to
deal
with
any
any
further
feedback
on
the
implementation
of
modules
in
general
or
we
could.
If
we
could
get
our
act
together,
we
could
get.
It
just
depends
how
it
is
about
that
stupidest.
E
Mainly
because
of
the
problem
where,
with
the
conditional
exports
default
would
refer
to
ESM,
whereas
without
the
conditional
exports,
the
12
LTS
would
ignore
the
require
field,
and
that
would
create
a
breaking
change.
Where,
essentially,
you
couldn't
produce
a
package
that
would
work
on
the
12,
LTS
and
future
versions
as
well.
B
Then
the
question
is
whether
we
think
we
can
get
conditional
exports
done
by
January
7th,
which
I
know
is
not
what
we
agreed
on
a
few
weeks
ago
and
that's
why
I
wanted
to
bring
it
up
like
so
directly
and
that's
why
I
tagged
us
on
that
on
that
thread,
so
we
don't
have
to
discuss
in
the
two
minutes
we
have
left,
but
since
there's
only
whatever
two
meetings
before
January
7th
I
think
we
should
try
to
like
make
a
priority
to
get
this.
This
guy.
A
A
G
A
G
B
G
G
G
I
mean
I
at
least
only
have
time
to
work
on
this,
unlike
the
weekends.
What
I
like
don't
have
anything
scheduled
and
the
reason
that
we
said
the
end
of
January
is
because
well
December
is
like
the
holidays
and
like
I'm
supposed
to
like
come
spend
time
with
family
and
stuff.
But
you
know
the
December
7th
being
the
LTS
deadline.
Just
moves
it
up
by
three
weeks.
I
guess.
B
G
G
A
C
Yeah
I
think
the
point
here
is
just
with
like
just
like
with
type
module.
There
is
a
nonzero
probability
that
we
back
for
it.
We
ship
a
new
release
of
no
12,
something
about
it,
breaks
somebody
and
we
can
do
just
like
with
type
module,
do
a
more
or
less
surgical
adjustment
by
patching
it
that
doesn't
have
to
prevent
us
from
deck
parting
like
we
can
address
this.
The
thing
precisely
that
is
actually
breaking
then.
A
And
specifically
with
exports
when,
when
the
change
to
the
resolver
is
entirely
hinged
on
exports
in
the
package.json
and
we've
looked
through
NPM
and
seen
how
many
packages
have
exports?
Yes,
it
will
break
those
ten
packages
where
exports
do
not
have
the
same
semantics
but
yeah
at
one
point.
One
for.