►
From YouTube: Node.js Foundation Modules Team Meeting 2019-10-23
Description
B
With
that
we
are
live
on
YouTube,
with
the
October
23rd
meeting
of
the
node.js
module
stain.
We
are
joined
by
12
individuals
now
because
we've
got
Salah
as
well.
Thank
you
for
joining
us
and
we
have
a
fairly
full
agenda
of
things
to
get
into
I'm
gonna
go
based
on
the
order
in
the
dock,
but
if
anyone
has
things
they'd
like
to
see
in
a
different
order,
please
let
me
know
so.
The
first
thing
that
we've
got
on
here
is
module
resolve
self
reference.
C
C
Can
link
it
in
the
agenda
as
well?
Oh,
basically
for
me,
it
comes
down
to
is:
is
this
in
scope
for
shipping
modules,
because
I
think
we
are
it's
a
very
slim
use
case
where
it
is
in
scope
for
modules
that
is
from
my
current
reading,
which
is
slightly
nicer
unit
testing
for
a
package
that
uses
exports.
C
Everything
else
is
something
is
not
necessarily
related
to
modules
or
the
features
we
are
implementing
with
modules,
so
I
think
what
I'm
looking
for
is
anybody
who
disagrees
with
that
and
otherwise
I
would
declare
it
some
cost
at
this
points,
and
just
say
we
can
put
it
out
of
scope.
We
don't
need
to
do
it
right
now.
B
D
Think
I
agree,
but
I
would
just
want
to
point
out
that
it
had
been
my
hope
that
unflagging
time
all
wrist
resolution
changes
that
the
ecosystem
needs
to
make
would
be
able
to
be
made
like
at
that
time.
So,
for
example,
I'll
have
to
update
resolve
as
part
of
unflagging
to
handle
BSM
stuff
and
to
handle
exports,
and
it
would
be
convenient
and
nice
and
less
prone
to
bugs
if
I,
at
the
same
time,
updated
it
to
handle
whatever
self-referencing
stuff
was
available.
D
A
D
D
That
yeah
I
mean
is
that's
fair,
but
I
mean
what's
the
word
I'm
looking
for
inertia
is
such
that
it
you
know
it's
unlikely.
It
would
be
removed
entirely,
but
and
I
would
prefer
it
to
go
both
at
the
same
time
like
with
both
features
unflagged
but
yeah
you're
right.
That's,
certainly
a
valid
potential
option.
B
B
I
am
thinking
that
this
is
completely
separate
from
unflagging
modules
and
is
specifically
like
this.
Pr
has
been
open
since
July
continues
to
bit
rot
and
landing.
It
would
be
primarily
to
just
kind
of
like
allow
us
to
work
shop
work
on
it,
get
people
to
play
with
it
and
not
have
it
continued
a
bit
rot
Wes.
E
Oh
I
mean
the
pec
package
name
in
general
is
fun
I
just
wanted
to
clarify.
When
we
talk
about
package
name,
we
mean
the
name
found
in
the
enclosing
package.
Json
file
right
yeah,
because
package
managers
do
let
you
install
packages
in
the
location
for
a
different
package,
so
like
they're,
referred
to
externally
by
a
different
name
than
they
would
be
internally.
In
this
case,
and.
D
C
B
B
Okay,
great
so
next
up,
let's
document
the
current
state
of
modules
in
nodejs
I
think
we
can
just
skip
that
one.
To
be
honest,
that
was
I
can
give
the
quickest
of
updates.
But,
like
we
made
this
stock,
we
shared
the
dock
with
the
TSC
they
had
a
couple
days.
We
had
a
meeting
today
discussion
in
the
meeting.
B
B
There
was
discussion
back
and
forth
about
the
existing
hazards
regarding
Singleton's,
the
introduction
of
new
hazards
and
I
would
say
an
equal
amount
of
skepticism
and
positivity
about
which
direction
we
should
go.
The
overall
consensus
from
the
TSC
discussion
was
they
want
us
to
try
to
figure
it
out
and
you
know
move
it
move
it
forward
and
they
were
not
in
a
position
to
really
give
us
any
strong
advice
or
direction.
B
B
So
the
next
one
that
we
have
on
here.
We
have
divergence.
That's
a
fire
hazard,
then
conditional
exports
proposal,
scripted
configuration
files,
loader
hooks
and
proposal,
Support
Package,
my
own
name,
so
I
think
we
can
remove
the
proposal
Support
Package
by
own
name
from
the
agenda.
Does
anyone
have
a
problem
with
that
feels
like
ready,
discussed
it
I
feel
like
divergent
specifier
hazard
and
conditional
exports
proposal
are
kind
of
one?
In
the
same,
does
anyone
disagree
with
that.
G
Just
from
the
perspective
that
they
there
are
somewhat
independent
in
that
the
conditional
exports
proposal
is
a
design
to
it
to
allow
a
middle
ground
for
the
hazard
and
could
exist
separately,
and
so
that
that's
that's.
The
main
thing
were
my
expected,
but
it
is
almost
a
separate
feature
that
happens
to
solve
it.
I
think
that's
a
reason
for
the
separation
yeah.
B
B
Maybe
we
need
a
new
solution
to
how
we
handle
you
know
dual-mode
modules
before
we
think
about
how
to
handle
this
and
to
me
the
the
exports.
The
conditional
exports
proposal
was
the
first
thing
that
came
in
that
genuinely
had
me
thinking
that
perhaps
perhaps
it's
worth
introducing
the
hazard
for
some
of
the
DX
that
conditional
exports
unlocks.
B
With
that
being
said,
I
still
think
that
there's
quite
a
I
think
there's
still
a
non-trivial
amount
of
work
that
I'd
like
to
see
done
on
the
conditional
exports,
specifically
in
kind
of
ecosystem
outreach,
and
you
know
making
sure
the
patterns
that
we're
pushing
our
ones
that
that
folks
and
package
authors
will
adopt
Wes.
You
have
your
hand
up
I,
don't.
E
Get
conditional
exports
because
they
enable
they
enable
the
like
the
the
reason
we
started
talking
about
the
divergent
specifier
hazarded
thingamajigger
was
because
it
was
brought
up
as
a
reason
why
we
couldn't
do
extension
resolution,
one
of
them,
because
if
we
did
that,
then
we
would
have
multiple
packages,
which
referred
to
the
same
thing.
But
you
had
used
the
same
specifier
and
now
we're
reintroducing
exactly
that,
but
rather
than
but
by
extension,
via
a
different
opt-in
mechanism,
it
was
just
to
say
I
filled
in
the
package.json.
It
feels
bad
and
wrong.
B
B
B
So
I
mean
like
a
couple
thoughts
to
what
you
were
saying
less,
like
one
I
think
that
the
file
extension
resolution
well
part
of
it
was
the
specifier
hazard
was
one
of
the
problems,
the
other
problem,
that
it
also
was
a
reason
we
didn't
want.
It
was
incompatibility
with
browser
implementation,
which
I
know
is
also
in
itself.
You
know
not
a
perfect
one,
but
it
was.
B
You
know
the
fact
that
if
we
had
arbitrary
file
extension
resolution
and
then
the
only
way
to
really
solve
that
in
a
browser
context
was
via
import
maps
that
import
maps
would
grow
in
a
kind
of
unbounded
way
per
package
based
on
every
single
entry
that
would
be
required
in
the
map
to
specify
the
extension.
So
it
wasn't,
in
my
personal
opinion,
the
only
reason
and
then
when
we
did
go
through
and
fix
the
file
extension
order
of
resolution,
we
did,
you
know,
remove
the
ability
of
the
overloaded
main
being
used.
B
So
it
still
wasn't,
even
you
know,
like
I,
think
I
think
that
these
are
two
separate
spaces
to
discuss.
That
was
the
main
reason.
I
brought
that
up.
I
prefer
not
to
start
debating
an
extension
resolution
again,
but
with
with
the
hazard,
you
know
like
a
lot
of
it.
Initially
from
my
thought
process
was.
You
know
we
already
have
a
hazard
that
exists
in
our
ecosystem
that
bites
people
a
whole
bunch
based
on
the
node
modules
folder
and
resolving
multiple
versions
of
the
same
package
that
are
not
compatible
and
creating
another.
B
Unless,
like
the
hazard,
still
kind
of
exists,
it
doesn't
exist
in
the
sense
that
it's
not
transparent
from
an
importer
of
graph
QL,
but
it
could
be
transparent
from
someone
who's
using
like
a
large
graph
of
different
things.
I
do
think
that
in
this
case
you
know
it
would
be
on
the
module
authors
to
author
packages
in
such
a
way
that
the
hazard
doesn't
exist.
B
B
You
know
the
single
specifier,
multi
and
multi
entry
points
I
mean
that
it's
more
explicit
that
they
have
to
do
this,
but
either
way
we're
gonna
have
to
educate
folks,
so
that
combined
with,
like
with
the
conditional
exports,
the
other
thing
that's
really
nice
is
we
can
take
a
common
j/s
package
and
essentially
generate
an
ESM
wrapper
for
it
and
now
have
named
exports
from
common
J's
packages.
That
can
be
completely
automated.
B
But,
like
you
know,
I,
don't
need
to
be
super
petty.
At
the
same
time,
I
would
love
to
see
solutions
that
were
better,
but
we've
spent
a
very
long
time
on
this
and
I
don't
and
like
the
thing
that
I
think
is
really
cool
about
where
we
could
get
to
with
the
feature
set
of
package
X
of
conditional
exports
with
that
added
and
properly
scoped
I
think
that
we
can
manage
to
hit
almost
every
single
use
case
that
we
have
mined,
not
all
of
them,
but
the
majority
of
them
I
do
I'm
still
unsure.
C
It
doesn't
be
stole
some
of
my
Thunder
here
so
I
think
for
me,
what
what
the
West
was
bringing
up
is
two
independent
valid
points
to
bring
up.
One
is
hey.
Wait.
A
second
I
thought
we
cared
about
the
hazard.
Why
are
we
suddenly
bringing
back
a
way
to
act
actively,
have
the
same
specify
resolve
to
either
one
of
those
smaller
systems
and
the
second
one
is
hey
if
we
want
to
bring
back
that
possibility,
why
is
conditional
exports
different
from
the
file
specify
a
extension
resolution
solution?
C
The
the
reason
why
it's
different
is
the
extension
resolution
works
exactly
for
you
have
exactly
two.
It
does
not
scale
beyond
that.
So,
for
example,
if
if
you
want
to
use
that
to
say
hey,
this
is
a
node
specific
implementation,
but
there's
also
a
generic
one.
That
would
work
in
a
browser.
Extensions,
don't
help
you.
C
It
can
ignore
the
dual
instance
issue
when
in
fact
they
cannot,
even
if
they
use
this
pattern,
so
I
think
it.
The
the
message
it
communicates
is
very
dangerous
because
it
communicates
this
is
safe.
You
can
ignore
dual
instances.
Nobody
will
ever
use
package
and
package
/sm.
You
can
safely
depend
on
that
and
I.
Don't
think
that
in
an
actual
package
tree,
which
is
what
actually
causes
these
hazard
hazards,
the
others
do
not
appear
in
a
file
right.
Nobody
is
writing
import
and
require
in
one
file
at
least
they
cannot
do
that
in
node.
C
Well,
I:
don't
think
that
anybody
is
in
common
je
s
first
using
require
to
import
the
module
and
then
using
dynamic
import
to
import
the
exactly
same
module.
That
I
don't
think
that
that
is
a
realistic
example.
I
think
in
practice
they
were
not
import,
the
same
specify
using
require
and
import
within
same
file
or.
C
Or
rather
it's
it's
it's
one
of
those
very
interesting
technical
education
that
I
don't
think
it
really
exists
in
an
app.
My
point
was
in
a
realistic
app
in
the
99%
case
of
an
app
the
has,
it
doesn't
appear
in
a
file.
The
hazard
doesn't
appear
even
in
a
project,
because
if
it
appears
in
the
project
there's
a
simple
solution,
you
just
call
the
project
to
ESM
all
the
files
and
you're
done
it's
great.
It
works,
there's
no
hazard
anymore.
C
The
hazard
exists
and
is
actually
dangerous
when
it
appears
in
a
package
tree
where
you
don't
own
all
the
code,
but
you
can't
just
say:
oh,
let
me
just
magically
move
all
my
dependencies
that
only
exists
as
common
gs2
ESM.
So
without
forking
all
your
dependencies.
You
cannot
resolve
that
the
hazard
in
a
package
tree
if
they
are
different,
specifies
being
used
and
if
the
package
authors
assume
that
it's
safe
to
keep
them
incompatible,
so
I
think
the
message.
C
The
the
the
story
being
told
by
having
package
and
package
less
/sm
leads
people
down
a
very
dangerous
path.
It
makes
them
make
wrong
assumptions.
So
I
think
we
should
be
very
clear
that
it's
not
possible
to
ship
two
versions
and
assume
that
the
importer
will
surely
always
require
one
version
or
the
other
I.
C
Don't
think
that
that
is
responsive
and
responsible
message
to
tell
people
so
I
think
we
need
to
be
very
clear
that
if
you
want
a
ship
require
the
ESM
package
within
the
same
distributed,
distributed
artifact,
which
many
people
will
want
to
do,
then
you
are
responsible
for
managing
a
situation
where
people
use
both
version
in
combination.
If
you
cannot
do
that,
then
you
cannot
ship
both
versions,
at
least
not
ship.
Both
words
in
the
you
know
way
that
is
accessible
to
note
and
I.
Think
that
conditional
exports
is
a
good
way
to
tell
that
story.
E
Okay,
so
if
you
started
believing
that
the
hazard
was
a
problem-
and
you
were
convinced
that
well,
it's
still
a
problem.
Even
when
you
have
multiple
distinct
entry
points,
then
you
should
also
be
convinced
that
it's
still
a
problem,
even
when
you
have
a
multiple
distinct
entry
points
and
a
field
in
the
package.json
that
does
like
this
doesn't
remove
the
multiple
distinct
entry
points.
People
are
still
capable
of
doing
that.
E
This
just
makes
it
so
you
can
also
invoke
the
problem
through
a
direct
specifier
call
to
a
package
and
perhaps
more
importantly,
part
of
the
reason
I
like
the
middle
ground.
We're
on
right
now
in
the
module
resolved
algorithm
is
because
it
allows
us
to
completely
eliminate
the
problem
in
the
future
by
figuring
out
how
to
just
load
ESM
in
the
common
Janice
resolver,
because
then
someone
can
just
only
ship
ESM
and
then
there's
no
longer
there's
something
to
be
concerned
about
in
this
field.
Like
that's
what
that's
a
good
thing
to
work
towards.
E
If
we
add
this,
it
precludes
that,
and
that
is
bad
from
my
perspective
and
for
the
record.
I
do
not
support
loading
two
copies
of
something
it's
a
very
bad
idea,
even
beyond
the
singleton
problem.
The
overhead
of
loading,
two
copies
of
all
of
the
code
in
your
program,
one
for
CGS
and
one
for
ESM-
is
non-trivial
like
that,
can't
be
something
that
people
want
to
actively
consider
like
what
to
actively
encourage
happening
in
there
like
tree
of
dependencies
like
people
already
talking
about
how
node
has
these
ridiculous
trees
and
dependencies.
D
So
I
agree
with
Wes's
idealized
goal
right
like
certainly,
if
require
ESM
becomes
possible,
then
we
kind
of
sidestep
the
whole
issue
and
you
know,
and
current
exports
can
handle
like,
like
basically
the
two
dual
mode
things
I,
always
care
about:
our
pre
module,
node
versus
post
module,
node
and
then
post
module,
node
import.
We
require
and
exports
allows
for
the
pre
in
the
old
node
and
new
node
right.
D
So
if
we
had
require
EOS
and
then
certainly,
we
wouldn't
need
conditional
exports
for
import
versus
require,
but
the
if
we
don't
ship
conditional
exports,
the
browser
field,
which
is
a
well
understood,
frozen
spec,
doesn't
handle
ESM
like
and
bundler
still
will
need
to
be
able
to
know,
because
people
are
still
targeting
pre
module
and
post
module
browsers.
So,
like
one
thing,
conditional
exports
does
happen.
D
To
give
us
is
a
dual
mode
solution
for
browser
alternatives
which
bundlers
need
in
order
to
transparently
shim
out
certain
packages
and
functionality
as
needed
for
browser
builds
so
like
I
think,
there's
actually
like
there's
a
number
of
use
cases
that
we've
already
talked
about
and
that
we
probably
aren't
still
aren't
aware
of
the
conditional
exports
actually
provides
for
and
I
agree
that
it
doesn't
remove
the
hazard.
It's
all
that
none
of
these
things
remove
the
hazard
they're,
all
just
moving
it
around.
D
The
hazard
remains
because
people
can
write
dumb
code
and
that
they
will
always
be
able
to
do
that
and
like
it's,
not
nodes
capability
or,
in
my
opinion,
obligation
or
right
to
police
people
from
writing
dumb
code.
Obviously
we
should
make
it
a
little
harder.
We
should
make
it
easy
to
get
out
of
your
mistake
and
like
do
something
better
right,
but
like
I,
think
that
if
we
can
I
think
that
if
we
want
to
wait
for
require
ESM,
then
to
me
unflagging
modules
without
a
dual
mode.
D
B
B
B
B
B
G
Alright
yeah
just
I
think
well,
firstly,
like
all
the
points
that
Wesley
brings
up
or
completely
valid,
except
for
I
think
it's
time
to
really
try
and
be
quite
decisive
about
the
require
as
something
because
I
think
it's
I
I've
never
wanted
to
push
back
on
it,
because
Wesley
was
doing
some
really
good
work
there
and
I
didn't
want
to
discourage
anyone
from
exploring
this
path
further.
G
G
Azzam
promises
are
specified
such
that
they,
the
the
currents
main
thread
execution,
is
suspended
and
the
micro
tasks
are
run
and
if
you
have
promises
and
you're
flattening
that
that
is
not
spec
compatible,
so
we
would
be
deciding
to
be
non
spec
compatible,
and
that
is
something
that
I
would
personally
object
to
quite
strongly.
And
so,
and
not
only
do
we
have
a
problem
of
doing
the
work
on
that.
G
We
also
have
a
problem
of
whether
we
are
willing
to
go
down
spec
incompatible
directions
which
I,
just
don't
think,
is
a
good
idea
with
with
top-level
away.
It's
definitely
very
much
so
observable
spec
incompatibility
so
yeah
that
the
main
thing
then
is
to
just
get
that
up
or
clearly
and
then
in
addition,
that
we
have
to
realize
that,
like
obviously
there's
strong
arguments
on
either
side
of
this
debate,
our
problem
is
not.
It
was
to
find
a
consensus
on
those
arguments
and
to
avoid
stalling
and
we
need.
G
We
only
have
you
know
this
meeting,
maybe
another
meeting
or
so
we
don't
want
to
stall
on
this
issue,
because
it's
a
very
easy
issue
to
stall
on
the
reality
of
the
situation
is
that
package.
Authors
are
ready
today
publishing
packages
in
ways
that
they
want
to
be
shipping
different
versions
to
different
environments,
and
they
are
going
ahead
and
doing
that
there's
nothing.
G
We
can
do
just
that,
that's
happening
in
the
ecosystem
and
so
to
decide
what
we
want
to
do
from
node
that
that's
going
to
facilitate
that
and
avoid
further
fragmentation
and-
and
that's
our
goal
really
is
to
try
and
reduce
fragmentation
in
the
ecosystem
and
to
to
ensure
that
package
authors
are
able
to
achieve
what
what
they're
going
to
achieve
anyway.
In
a
way
that
works
well
with
notice
and.
G
It
is
major
expectation
right
now
that
they
can
ship
it
atmosphere
modules
and
if
we
don't
give
them
that
the
concern
is
that
people
might
start
publishing
two
packages.
So
we
say:
oh
you,
don't
want
twice
the
code.
Well,
we'll
end
up
with
twice
the
code
anyway,
because
not
every
single
packages
is
publishing
a
as
in
version
or
a
legacy
version
or
whatever
other
pattern,
a
that
ends
up
creating
twice
the
code.
B
He's
not
going
to
force
me
I'll,
do
it
so
Gus
says
he
mostly
agrees
with
West
and
Jordan
he's
not
going
to
suggest
requiring
ESM
as
a
solution.
It
also
disagree
with
the
idea
of
generating
rappers
for
packages.
He's
worked
on
tooling.
To
do
this,
and
very
often
you
end
up
with
issues
that
have
to
be
manually
worked
around.
He
would
also
like
to
warn
that
we
don't
get
stuck
in
the
Sun
cost
fallacy
pursuing
something
to
an
end
and
then
deciding
it
that
it
wasn't
worth
it
or
it's
not.
H
H
C
C
They
just
try
to
keep
going
using
that
workflow,
and
so
something
just
happens,
and
actually
some
of
my
comments
about
the
pitfalls
of
how
we
so
far
have
suggested
solving
the
dual
specifier
issue
explicitly
calling
out
some
of
these
patterns
like,
for
example,
using
existing
Babel
transformation
from
you
know,
from
es
modules
to
commonjs,
don't
rewrite
specifiers.
So
now
you
have
the
ESM
version
of
your
package
that
you
might
even
expose
as
/e
SM,
using
the
common
J's
version
of
your
dependency
right.
That's
something
at
a
reasonable
package.
Author
will
cause.
C
If
we
have
to
separate
specify
us-
and
that
is
there
is
an
important
thing-
it
doesn't
come
from
a
user
being
dumb.
It
comes
from
a
user
doing
something
reasonable
from
everything
they
know
not
possibly
reading
every
single
sentence
in
our
dogs
and
then
something
bad
happens
and
I.
Think
that
that
perspective
of
what
can
we
expect
reason
people
to
do
is
different
from
we
are
solving
for
for
everybody,
including
people
that
are
doing
something
super
crazy
and
unexpected
and
for
the
react
issue.
C
I
think
what
is
new
about
this
is
the
tools
to
manage
the
hazard
for
the
yeah.
If
you
have
react,
15
and
react
16
in
the
same
app,
you
know
how
to
manage
that.
You
look
at
the
major
versions
and
you
only
install
packages
that
depend
on
the
same
major
version.
You
can
do
an
NPM
LS,
you
see
immediately.
Hey
I
have
two
copies
of
react
because
dependency
acts
depends
on
react
16,
but
my
atmosphere
using
react.
15
we
have
you.
D
Can
I
just
interject
real,
quick,
sorry
to
interrupt,
but
I
believe
NPM
7
is
planning
on
making
NPM
install
error
when
NPM
LS
errors
specifically
surface
peer
dependency
warnings,
so
your
dependencies
will
be
an
even
more
ergonomic
and
function
to
solve
this
problem,
potentially
in
the
future.
Yeah.
C
The
difference
is
that,
for
this
new
kind
of
hazard,
there
is
no
tooling,
and
especially
if
we
use
some
magical
convention
of
well,
sometimes
you
append
slash
years
M.
Sometimes
you
append
that
comment.
Yes,
sometimes
you
say
slash
module.
Something
sometime,
you
say:
slash
legacy
no
tool
in
the
world.
Big
claim
will
ever
be
able
to
understand.
What's
going
on
and
tell
you
what's
wrong
because
there's
nothing
declarative
about
it,
those
conflicts
will
appear
and
other
than
grepping
through
your
entire
dependency
and
understanding.
C
What
they're
doing
there
is
no
good
way
to
debug
it
having
a
declarative
way
of
saying
hey.
This
is
where
the
switch
happens.
I
can
go
to
that
package
and
figure
out
why
it's
specifically
for
this
package,
these
two
versions
get
loaded
and
or
why
it
breaks
when
both
of
these
versions
appear
the
same
app
I
agree
that
it's
bad
when
every
single
package
Under
the
Sun,
has
two
versions
and
all
of
them
are
always
loaded
into
memory.
C
I,
just
don't
see
like
if,
if
people
want
to
ship
both
versions-
and
they
want
to
support,
come
and
they
cannot
use
her
body
as
em
and
they
get
pushed
or
pushed
themselves
for
people
actually
using
the
ESM
code,
their
ship,
they
are
two
copies
because
from
college
s
they
will
use
the
condensed
version
of
the
package
and
yet
in
consumer
will
use
the
it's
m
copy
of
the
package.
So
there
are
two
copies
as
long
as
that's
true.
C
H
Yes,
I
agree
that
we
don't
have
tooling
for
this,
because
this
is
a
little
bit
of
a
different
scenario,
but
the
description
of
just
having
react
is
not
the
only
way
in
which
we
can
achieve
this
kind
of
duplication
of
code
bases
people
vendor
things.
Sometimes
they
ship
things
in
multiple
bundles.
If
you
look
at
a
lot
of
bundling
systems,
even
using
shared
chunk
plugins,
they
also
are
duplicating
modules.
So
even
the
tooling
we
have
today
is
insufficient
to
actually
prevent
it
just
from
NPM
installs.
H
H
We
could
write
tools,
we
could
do
many
things
or
we
could
educate
one
or
the
other
and
given
the
difficulty
we
have
of
making
a
decision
here,
the
lack
of
being
able
to
remove
the
problem
as
a
whole
I
think.
Maybe
we
should
kind
of
turn
our
attention
elsewhere
rather
than
getting
worked
up
about
this.
C
Yeah
I
I
agree
with
Brad
that
the
issue
already
exists
and
that
there
already
promised,
with
code
duplication
beyond
just
major
version.
Differences
I
was
just
pointing
to
the
major
version
differences
as
an
example
of
where
we
do
have
tools
and
why
it's
not
comparable.
To
that
specific
thing,
I
would
push
back
on
the
fact
that
we
could
equally
create
tooling
in
the
future
to
detect
this
situation,
because
in
once
again
we
have
metadata
that
shows
us
that
both
of
these
versions
have
been
chosen.
C
In
the
other
case,
the
tooling
would
have
to
know
specifically
about
every
single
package
that
has
two
different
variants
and
we're
two
different
specifiers
are
equivalent
to
make
informed
decisions
which
I,
don't
think,
is
realistic.
So
it's
a
it's
a
difference
between
having
metadata
to
write
tools
against
and
not
have
metadata
to
write
tools
against.
B
G
There's
there's
a
big
difference
between
having
duplicate
code
in
the
same
runtime
and
duplicate
code
between
different
runtimes.
Even
if
those
runs
phones
are
like
different
instantiations
of
nodejs.
So
it's
about
what's
running
in
your
current
running,
node.js,
app
and
then
on
on
the
point
of
shipping.
G
You
know
as
I
say
like
it's
really
about
package
authors
here,
and
the
thing
is
that
everyone
is
where
has
been
waiting
for
so
long
to
ship,
yes,
modules
and
the
first
thing
they
want
to
do
is
ship,
yes,
modules
and
if
the
only
way
they
can
should
be
as
modules
this
way
that
breaks
or
their
accommodates
consumers,
then
we
are
that
you
know
that
that's
what
we're
enforcing
and
then
we're
giving
them
a
hard
choice.
So
we
have
to
realize
that
it's
behavior
that
we're
working
on
it's
not
a
technical
program.
G
G
B
B
B
It
would
appear
that
we
are
in
a
deadlock
because
Jordan
is
essentially
blocking
without
the
feature
that
is
being
blocked
explicitly
by
Wes.
We're
done
for
today
we're
out
of
time.
I
will
try
to
talk
independently,
or
maybe
we
can
have
a
spin
up
meeting
to
try
to
see
if
we
can
reach
towards
something.
D
Well,
it
just
just
so.
This
is
not
inaccurately
portrayed
as
lone
objectors
if
it
is,
if
it
isn't,
if
there's
anyone
else,
besides
Wes
or
myself,
who
would
object
to
either
of
those
outcomes?
Could
you
please
speak
up
now,
even
though
you
technically
don't
have
to
because
it
would
really
help
to
know
that
there's
other
people
that
share
the
opinion
and
it
would
really
be
a
bummer
if
Wes
or
I
was
convinced
one
way,
and
then
someone
else
ended
up
objecting
anyway,.
B
Guess
one
quick
question
and
then
we'll
have
to
go
because
we're
actually
done
Jordan
if
we
landed
if
we
were
able
to
get
Wes
or
you
know,
that's
not
fair.
If
we
were
able
to
reach
consensus
on
on
landing
things
behind
a
flag,
if
there
was
some
sort
of
solution,
independent
of
what
solution
to
dual-mode
modules,
but
it
was
behind
a
flag
because
we
wanted
to
do
more
work
on
it.
Would
you
still
object
to
unflagging
on
the
app
on
on
ESM
until
we
had
that
sorted?
D
The
to
be
clear,
the
if
somebody
has
to
run
a
run
node
with
a
flag
in
order
to
use
properly
use
a
dependency.
They
don't
control,
then
that
feature
for
all
intents
and
purposes
doesn't
exist.
So
I'm
happy
to
have
it
land
behind
a
separate
flag
for
experimentation,
but
it
if
it's,
if,
if
having
it
be
still
flagged
while
ESM
is
unflagged,
is
acceptable.
Then
having
any
assignment
like
now
would
be
acceptable.
So
to
me
that
doesn't
change
anything.
D
Yeah
yeah,
sorry,
so
if
SMS
unflagged
now
without
conditional
exports
versus
it
all
versus,
if
ESM
is
unflagged
without
unflagged
conditional
exports
to
me,
those
are
the
same
thing,
because
people
generally
speaking
don't
invoke
node
with
flags,
and
so
whatever
is
by
default,
is
what
node
does
and
if
node
doesn't
have.
Thus,
by
default
a
solution
for
dual
packages,
it's
not
safe
to
publish
a
package
that
uses
that
that
technique,
and
so
it's
it
for
all
intents
and
purposes
it
doesn't
exist.
So
I
would
still.
B
Okay,
so
we're
nowhere
close
to
having
conditional
exports,
unflagged,
anyways
I
still
think,
there's
more
work
to
be
done,
so
it
sounds
like
we
need
to
get
some
more
discussions
going
guy.
If
we
want
to
do
a
vote,
we
we
can
but
I
think
that
that's
a
separate
discussion
for
us
to
have
not
one
more
four
minutes
overtime.
Let's
kick
this
back
to
the
issue
tracker
and
we'll
chat
again
soon.