►
From YouTube: Node.js Foundation Modules Team Meeting 2019-11-06
Description
A
We're
now
live
on
YouTube,
with
the
November
6th
edition
of
the
node.js
modules
team
joined
by
six
people,
including
myself.
We
have
a
fairly
full
agenda,
so,
let's
just
kick
it
off
to
those
on
the
call.
If
anyone
could
help
with
with
notes,
that'd
be
greatly
appreciated.
So
does
anyone
have
a
preference
for
the
order
that
we
go
through
these
things?
I
think
that
it
would
probably
make
sense
for
us
to
probably
start
with
conditional
exports
then
go
to
the
index
proposal.
Maybe
then
have
discussion
about
loader
hooks
and
leave
chartering
to
the
end.
A
A
B
B
B
We've
also
removed
the
previous
condition
that
we
had,
which
was
the
what
was
the
other
condition,
the
node
condition.
For
now.
The
idea
with
the
node
condition
was:
if
we
wanted
to
select
between
different
environments
like
other
non
Noches,
JavaScript
environments
or
server
environments
we
could
have.
We
could
specify
different
names
to
them
instead
of
relying
on
the
defaults
and
there's
some
fine-grained
behaviors
around
that,
because
it's
all
about
conventions.
B
So
if
people
are
shipping
default
as
the
main
entry,
when
they
have
you
kind
of
have
these
specific
branches
and
then
the
default
fallback,
if
we
ship
node
as
a
condition
there,
there
is
some
risk
that
people
will
do
browser
a
node
and
then
any
other
environment
that
comes
up
that
doesn't
match
either
of
those
conditions,
because
there
exists
no
J's
environments
that
aren't
the
browser
or
node.js
I
start
janus
environments
that
aren't
the
browser
or
node.js.
So
then,
what
does
it
do
in
that
case?
B
Is
it
just
supposed
to
fail,
or
will
it
still
use
the
node
condition?
So
that
gets
a
little
bit
difficult?
So
for
now,
we've
just
disabled
the
nerd
condition,
and
we
can
rethink
that
in
future
it
can
be
a
follow
up,
PR
after
unflagging
or
whatever,
and
then
I
think.
That's
everything
on
conditional
exports.
For
now.
The
other
concerns
kind
of
move
into
the
index
field,
concerns
about
the
questions
on
the
bids
or
anything
that
needs
clarifying
happy
to
go
through.
C
B
B
Because
we
have
these
new
semantics
for
exports
tools
are
potentially
going
to
want
to
also
be
able
to
support
exports
in
environments
that
aren't
know
Jess,
so
that
there's
a
kind
of
a
tooling
argument
there
and
then
the
way
this
worked
out
in
in
why
it's
useful
for
nodejs
is
because
it's
it's
a
way
for
us
to
support
dual-mode,
because
we're
not
because
exports
apply
both
for
common
Jess
and
es
modules.
There.
B
Otherwise,
it
is
difficult
to
justify
that
no
jess
to
try
and
solve
a
tooling
problem,
but
I
I
think
it
does
provide
a
lot
of
simplification,
because
without
structuring
specifications
for
the
package.json
like
the
package.json
is
the
most
like.
There
is
no
spec
for
package.json
at
all.
Everyone
does
these
organic
things,
and
no
one
really
thinks
about
how
they're
gonna
scale
into
all
the
possible
ways
they
might
interact
with
each
other,
and
so
you
get
these.
You
hit
these
kind
of
bottlenecks
where
it
works.
Fine,
initially,
the
the
browser
field
will
work.
B
Fine,
the
module
field
worked
fine
for
a
while
and
then
eventually
it
kind
of
breaks
down
where
it
hits
all
these
edge
cases,
and
and
now
schools
are
having
to
implement
things
like
module.
:
browser
because
does
the
module
field
mean
it's
for
the
browser
or
node
or
by
convention?
A
lot
of
people
are
using
it
for
browser
code,
but
how
do
you
split
on
that?
And
so
that
it's
keeps
getting
more
and
more
complicated
if
you
just
follow
the
shortest
part?
B
So
at
some
point
you
say:
there's
all
these
cow
parts
being
paved,
let's
just
sort
of
generalize
what's
already
being
done,
and
this
is
a
kind
of
a
simple
proposal
that
grew
out
of
discussions
with
various
teams
about
it
and
as
I
say
that
the
main
benefit
for
node
is
is
the
dual
mode,
but
littles
it's
being
able
to
define
these
conditions
like
the
browser,
particularly,
but
then
also
things
like
development
or
production,
some-some
tool.
The
react
native
package
air
as
well
right.
So
there
are
other
environments
that
might
want
their
own
resolution.
B
I've
included
electron
as
an
example
as
well.
I
know
it
like.
Tron
has
two
environments:
is
the
renderer
and
the
sort
of
node
side
in
the
browser,
so,
if
might
want
to
decide
what
it
wants
to
do,
but
it
opens
up
a
space
that
can
potentially
scale
better
than
the
scaling
issues
that
we've
been
hitting
and
a
lot
of
people
have
been
having
issues
with
in
tooling
whether
it
is
as
fine-grained
as
like
JavaScript
environment,
with
support
for
optional
chaining
as
a
string
that
then
detects
that
I
don't
think
that's
a
good
idea.
B
I,
don't
think
we
want
to
see
that,
but
I,
don't
think
tools
will
support
that.
Of
course,
when
you
open
up
these
things,
tools
can
do
a
lot
of
crazy
stuff
with
it.
They
can
come
up
with
all
these
these
crazy
idea,
but
in
general
I
think
that's
a
good
thing
for
JavaScript.
It's
it's
a
you
know
it
has
this
kind
of
Darwinian
nature,
its
environments,
where
you
know
the
best
patterns
will
hopefully
emerge
and-
and
hopefully
yes,
all
the
things
that
you
can
imagine
will
be
done
by
someone
somewhere.
A
E
No,
it
will
read
so
they
kind
of
have
to
put
the
node
version
in
there
and
then
default.
Isn't
really
its
intent
like
if
default
is
meant
to
be
like
this
is
the
kind
of
universal
JavaScript
one
that
can
work
in
browsers
and
a
node
and
and
wherever
else,
people
kind
of
don't
have
a
way
of
of
saying,
like
here's,
the
here's,
the
one
that
relies
on
node
stuff
like
process
or
whatever,
and
then
here's
the
one
that's
universal
JavaScript,
so
I
would
I
mean
I'm,
not
gonna
like
block
on
this
or
anything.
E
A
I
can
speak
to
that
for
a
second
Jeff,
because
I
may
be
partially
responsible
for
that
getting
removed.
I
I
still
need
to
spend
more
time.
Thinking
about
like
the
naming
that
we're
doing
I
understand,
I'm,
just
painting
the
bike
shed
here,
but
I'm
not
like
super
thrilled,
specifically
with
like
the
use
of
require,
as
the
name
there,
and
if
we're
gonna
include
node
like
what
the
semantics
of
node
is.
A
What's
the
order
of
operation
and
what's
like,
like
just
the
user,
experience,
feels
a
little
odd
to
me,
where
we
have
both
require
and
node
and
which
one
trumps
which
and
what
the
order
is
and
how
we
best
educate
people
on
that.
So
you
know,
I
I
had
brought
up
the
request
of
having
those
other
Flags
put
behind
the
experimental
dual
resolution
flag
and
keeping
that
flag
specific
to
the
feature
rather
than
the
name
of
you
know
those
particular
fields.
I
am
more
than
happy
to
have
both
require
and
node
behind
that
flag.
A
B
B
A
A
A
That's
the
exact
naming
stuff
that
I
think
we
need
to
talk
to
you
because
I
think
it's
confusing
and
I
think
that,
like
the
semantics,
we
may
want
to
tweak
that
a
bit.
But
then
it
becomes
weird
because
we
make
it
import.
Then
that's
not
node
right
like
so.
Maybe
we
want
to
have
a
node
flag
and
then
have
a
sub
flag
for
import
and,
like
I,
just
I
think
we
need
to
talk
about
it
a
little
bit
more,
but
I.
E
D
E
Said
you
might
not
necessarily
have
like,
like
one
another
environment,
that's
also
using
the
like
quote:
unquote:
universal
JavaScript
version
like
that
you
had
browser,
know
to
default
like
Brad,
the
browser
might
get
a
browser,
specific
thing,
node
might
get
or
nodes
specific
thing,
and
then
there
isn't
some
other
key.
That's
getting
the
like
universal
version.
You
know
what
I
mean
I
see.
D
E
B
A
I
would
like
to
suggest
if
people
are
open
to
it,
I
think
that
in
me,
if
I'm
wrong,
we'll
always
need
a
default
case
here
and
I
think
like
that
was
feedback
that
Brad
gave.
That
was
feedback
that
Yan
had
you
know
the
way
in
which
were
setting
up
these
fields
for
conditionals
are
kind
of,
but
not
exactly
like
a
case
like
a
like
a
switch
statement,
so
I
think
that
we
can
all
get
on
the
same
page
that
we
will
likely
always
have
a
default
field.
A
What
what
and
if
we
want
to
say
we
want
to
support
alternative
fields
other
than
default.
Is
you
know
the
discussion
that
I
think
we
need
to
have
moving
forward?
I
think
that
it
sounds
like
Jeffrey
and
Yan
are
of
the
opinion
that
for
the
flagged
implementation,
it
is
much
more
a
v'
of
a
full,
proper
implementation
of
a
complete
feature
if
it
includes
the
node
field,
since
those
are
both
behind
an
additional
flag,
and
we
have
the
explicit
warning
that
it
can
change.
A
A
B
E
B
Thank
you.
The
important
thing
for
me
with
that
is
that
we
can
still
support
the
object
with
the
default
just
to
give
it's
probably
a
good
time
to
go
through
the
example.
Now,
if
someone
writes
a
package
like
this
and
they're
running
a
node
that
doesn't
support
conditional
exports,
that
package
isn't
going
to
be
able
to
load.
So
if
we
flag
the
require
condition,
what
that
means
is
that
you'll
always
be
like
without
the
the
flag
for
the
required
condition.
The
package
will
always
load
the
the
module
case
effectively,
not
working
from
require,
but.
A
Guy
and
like
you
know,
I
I'm
good,
not
by
shedding
on
this
too
much
I,
don't
think
that
the
proposal
as
its
landing
right
now
with
just
the
default,
is
even
conditional
exports,
because
there
are
no
conditions,
there's
just
a
default.
It's
just
like
a
verbose,
some
syntax
right,
so
I
like
I,
think
experimental
conditional
exports
is
a
reasonable
name
to
use,
but
I
think
experimental
conditions
is
also
reasonable.
D
B
A
B
A
I'm
personally
happy
with
just
like
you
and
yon,
and
everyone
spent
a
lot
of
time,
thinking
about
what
is
in
there
right
now
and
I
honestly
have
just
not
had
the
bandwidth
to
really
think
through
it
I.
We
do
have
you
know,
and
you
know,
for
anyone
who's
on
the
call
right
now
or
listening
we're
doing
a
really
small
user
design
like
research
session
next
Monday
in
San
Francisco.
A
So
if
you're
going
to
be
in
the
city
and
interested
feel
free
to
reach
out
to
me,
my
DMS
are
open
and
I
was
planning
on
getting
a
build
of
node
that
essentially
had
like
modules
working
with
all
these
flags
removed
and
with
all
of
these
features,
enabled
and
just
kind
of
playing
with
it
and
I.
Think
I'll
be
in
a
better
position
to
like
really
make
a
concrete
proposal
after
like
actually
making
some
dual-mode
modules.
A
E
If
we
did
like
move
the
fields
around
like
like
the
like
I
kind
of
like
the
idea
of
putting
require
and
import
under
the
node
field,
for
example,
I
mean
if
that,
if
we
change
the
PR
a
lot,
something
along
those
lines
is
and
as
everyone
still
okay
with
like.
However,
the
fields
move
around
and
the
discussion
I
get
hub
or
does
anyone
have
any
concerns.
D
E
E
A
I
think
and
then
someone
can
interrupt
me
if
they
disagree
with
this-
that
it's
absolutely
fine
for
us
to
play
with
what's
behind
that
flag
and
then
you
know
continue
to
give
the
team
updates
and
potentially
even
discuss
in
a
team
meeting.
If
we
want
to
have
more
of
a
discussion,
but
then
you
know,
obviously
we
need
to
take
it
to
the
team
before
unflagging.
So
I
think
there's.
A
A
So
I
think
I
think
with
like
that
said,
we
don't
have
quorum
right
now,
but
I
think
we're
just
reestablishing
consensus
that
we
had
in
the
last
meeting,
so
I
think
it's
fine
to
just
do
it
this
way,
but
is
everyone?
Okay,
with
landing
this
proposal,
you
know
with
adding
back
node
putting
node
and
require
behind
a
single
flag.
A
B
B
Up
until
now
been
absolutely
fine
with
having
that
sugar
for
exports,
where
you
can
treat
it
as
a
string
that
points
to
the
main
you
can
think
of
exports
as
the
new
main,
but
have
conditional
resolution.
We
can't
do
this.
We
just
simple
good
example
here
and-
and
this
question
Oh
Reuter
it's
entirely
about
typing
and
aesthetics.
There
is
nothing
here
to
do
with
semantics
or
how
things
behave.
B
It's
all
just
about
typing
and
the
reason
why
you're
typing
matters
is
because
this
is
something
that
is
done
like
it
is
one
of
the
most
common
things.
When
you're
creating
a
project,
you
write
a
package.json
and
set
the
main
and
install
some
dependencies
and
I
did
a
like
a
basic
analysis
on
about
fourteen
hundred
dependency
packages
and
how
they
get
loaded
of
all
the
ways
that
they
were
loaded.
B
Only
a
hundred
and
nine
of
those
packages
were
loaded
in
a
way
at
all
that
used
any
subpath
require
so
I
think
it's.
It
agrees
with
intuition
I
think
it's
pretty
clear
that
the
majority
of
packages
only
ever
need
single
main
entry
point.
X
Pope's
is
an
excellent
feature.
It
it
allows
those
packages
to
be
encapsulated
and
that
it
allows
a
whole
lot
of
neat
features.
D
D
Well,
of
course,
I
mean
the
Iribe
not
saying
that
there
was
more
sampling
you
could
have
done.
You
certainly
been
most.
You
could
have
done
there,
but
but
I
think
also
specifically,
this
isn't
something
that's
likely
to
be
typed
very
often
like
you
can.
We
could
easily
add
this
2
n
pm
in
it
to
where
you
type
a
file
path,
and
then
it
automatically
puts
the
correct
format
in
the
package.json.
D
I
think
that
the
number
of
people
that
manually
edit
package.json
is
actually
very
small
and
that
it
would
be
also
totally
fine
for
us
to
create
a
tool
that
can
make
it
easy
to
interact
with
these
things.
In
other
words,
I,
don't
think
we
should
just
like
with
code
I,
don't
think
we
should
be
optimizing
for
writing
and
typing.
We
should
be
optimizing
for
reading
and
like
maintainability
the
ability
for
tools
to
work
with
it
and
for
humans
to
read
it
and
understand
it
and
syntax.
D
You
know
syntax
sugar,
shortcuts,
tighten
in
the
design
space
restricted
and
also
potentially
raise
questions
about
what
it
means
for
longer
forums.
Do
not
I'll.
Also
note
I
was
playing
with
the
new
NPM
fund
funding
field
that
they
amount
where
they
released
like
yesterday,
and
the
string
field
doesn't
even
seem
to
work,
preferably
so
like
there's
a
there's,
even
confusion
around
the
people.
D
Building
the
tooling
around
these
fields
when
they
deal
with
the
shortcuts,
so
I
would
personally
be
very
happy
if
we
just
removed
that
string,
shortcut
and
kind
of
made
people
go
over
the
hump
of
in
the
beginning
of
putting
the
larger
object
form
which
tooling
can
do
and
then
break
that.
That
also
reduces
the
diff
turn
when
they
add
throws.
B
B
B
They
need
to
do
export
to
refer
to
the
main
and
then
we're
telling
them.
This
is
your
new
main
now,
if
I'm,
a
existing
will
begin
a
Noches
user-
and
you
tell
me
to
do
the
top
one
when
I've
been
doing
the
bottom
one
I'm
just
not
going
to
listen
to
that.
There
is
no
way
I'm
going
to
write
this.
When
I
can
write
this,
it's
just
not
going
to
happen.
I'm
going
to
write
the
splitter
and
you're.
B
Okay,
we're
gonna
Miri
share.
D
B
B
If
we
remove
the
sugar,
which
I
think
is
like
the
base
point-
that
we
all
agree
on
we're
now
telling
users
here's
what
you
must
type
every
time
you
wanted
to
find
a
main
entry
for
your
package,
and
this
is
the
good
and
right
best
practice
new
thing
to
do,
and
but
you
can
still
do
this
and
it
will
work
I.
Think
it's
a.
D
B
B
B
Right
but
I
don't
really
care
that
much
about
encapsulation
I
just
want
to
get
my
main
entry
point
working
and
that's
all
I
care
about
it.
I
don't
really
care.
If
tooling
knows
whether
or
not
there
exists
some
parts
that
can
be
required
in
my
package.
That
does
not
concern
me.
What
I
care
about
is
just
getting
my
code
running
well,
I,
there's.
E
D
You
guy
what
you're
saying
is
you're,
saying
you
only
care
about
getting
your
code
running,
that's
fair
and
if
you
have
to
manually
type
that
out,
do
you
have
a
common
argument
but,
as
I
said,
I
am
in
it
because
most
of
this
stuff
and
a
tool
like
an
additional
tool
could
easily
do
it.
Like
people
don't
tend
to
handwrite
package.json
anymore
so
like
it
would
just
be
a
question
of
how
organ
ama
CLE
want
their
tooling
to
be,
which
could
just
be
what's
your
main
file?
B
The
you
know,
a
lot
of
people
are
copying
what
they
see
elsewhere.
If
I'm
looking
at
packages
and
I
see
one
package
that
does
this
and
I
see
one
package
that
does
the
exports
dot
and
I
haven't
otherwise
read
any
documentation
or
know
anything
else.
I've
just
looked
at
as
what
other
people
are
doing.
I'm
gonna
copy,
the
simple
one
that
makes
sense
to
me
because
I'm
like
okay,
this
is
a
main
I
know
what
that
is.
I'm
gonna
copy
that
pattern,
because
it
makes
sense
to
my
brain.
B
B
Just
saying,
if
I,
if
I,
never
if
you've
never
told
me
anything,
I,
don't
see
a
package,
yes
I
would
need
it.
He
have
like
it's
through
reaction
against
the
dot.
Syntax
like
this
is
like
it
just
looks
bad
aesthetically
so
ready
my
brain
doesn't
like
it
and
couldn't
leave
I,
don't
understand
what
it's
I
don't
understand.
What
exports
means
I,
don't
understand.
Why
there's
a
dock
there
and
I,
don't
understand
why
you
know,
and
you.
B
D
Wouldn't
understand
what
Maine
means
either
and
you
wouldn't
and
like
you
wouldn't
understand,
just
that's
like
it's
I,
think
anybody
building
a
package
has
to
have
some
context
and
no
amount
of
package.json
sugar
is
gonna
fix
that
problem
and
if
you
assume
that
people
have
some
sort
of
minimum
context
when
they
come
in
which
obviously
not
everyone
will
but
like.
If
you
assume
that
people
do
have
that,
then
I
don't
think
the
visceral
reaction.
B
A
B
We
haven't,
but
that's
what
we're
discussing
here
and
I
can
go
through
a
quick
argument
about
the
upgrade
path
or
otherwise.
You
can
read
the
description,
but
the
justification
is
is
kind
of
around
how
you
the
kind
of
idea
of
progressively
right,
defining
your
application
and,
if
you're,
starting
from
from
this
case
and
wanting
to
add
a
dual
mode,
that
it's
it's
it's
not
as
simple
as
just
doing
exports,
where
you
can
then
say
require,
goes
to
Maine
dot,
C
J's,
otherwise
fall
back
to
Maine
dot
MJS.
A
The
require
and
light
I
think
that
that's
fine
honestly,
and
the
reason
why
I
would
say
is
the
second
that
someone's
thinking
about
making
a
dual
package
there's
an
advanced
thought
there
as
a
like
package
author.
That
requires
knowing
so
many
different
things
that
you're
like
we're
already
saying.
We
need
to
educate
everyone,
who's
doing
dual
packages,
I'm,
like
the
dual
specifier,
has
written
the
Middletons
I.
Don't
think
that
that
extra
step
of
adding
a
dot
is
a
bit
of
Education
for
dual
mode
for
dual
packages
that
that's.
D
D
B
F
D
Yes,
but
there's
not
it's
not
objective
that
that
the
currently
highlighted
syntax
is
unreadable
or
that
sorry
that
the
dot
section
is
unreadable
well,
it
certainly
has
more
cognitive
overhead
has
more
stuff
in
it
sure,
but
that
doesn't
mean
it's
necessarily
that
much
less
readable
or
significantly
less
readable
that
it's
a
problem.
I
was.
E
Just
that
we
dropped
the
exports
shorthand
until
the
conditional
syntax
was
finalized,
and
then
we
can
bring
it
back
and
then,
when
we
bring
it
back,
we'll
decide
like
okay.
This
is
confusing,
with
wit
like,
like
guys,
currently
highlighted
an
example.
Our
people
likely
to
get
confused
with
you
know
the
shorthand
versus
the
conditional.
E
That
was
all
that
was
my
only
concern
I'm
not
like
opposed
to
it
in
general,
but
since
the
rest
of
this
syntax
is
kind
of
in
flux,
I
didn't
I
felt
like
we
don't
need
it
for
now,
so,
let's
kind
of
like
land
it
along
with
landing
the
final
version
of
the
syntax
for
conditionals.
What
I
was
proposing
and.
D
And
for
the
record,
I
would
agree
with
what
Geoffrey's
saying
as
well
like
I'm.
A
big
part
of
my
argument
here
is
keeping
the
design
space
open,
which
necessity
means
we
can
add
it
back
later.
But
if
we
add
it
now,
we
can
never
change
what
it
means
theoretically
so
like
I
would
also
be
in
favor
of
bringing
it
back
later,
along
with
conditional
exports
with
once
we've
decided
and
convinced
ourselves
that
the
shorthand
semantics
are
actually
intuitive.
F
Does
what's
your
opinion,
like
my
opinion,
is
just
that
like
I,
like
the
UX
of
just
the
simple
you,
you
know
you
find
and
replace
main
with
exports?
That's
something
we
didn't
think
you
can
tell
people
who
are
currently
writing
packages
today
to
do
that,
and
that's
a
super,
easy
thing
to
tell
them
to
do
once
you
tell
them
to
expand
it
more.
Naturally,
you
have
to
start
explaining
why
certain
things
are
required
like
when
you
say
you
change
me
into
exports
and
you
get
encapsulation.
They
cannot
along
and
be
like.
F
That
is
a
good
thing
when
you
say
well,
you
change
me
into
exports
and
then
you
add
a
dot
to
specify
that
it's
the
main
entry
point.
They
go
well,
okay,
what
if
I
was
like
I?
Guess,
that's
okay
and
they're
like
okay
and
then
you
need
to
also
make
it
an
object
that
specifically
says
default
because
you
might
have
multiple
platforms
like
hold
on
I'm.
Just
writing
a
script!
For
you
know
my
server
in
the
backend
can
I,
just
not
have
a
package.json
like
do
I
do
I
need
all
this
anymore.
F
B
But
the
reason
this
matters
so
much
is
because
it
is
it's.
This
is
the
beginner
and
nerdiest
experience
in
a
lot
of
ways.
It's
the
beginner
package
publishing
experience,
and
it
really
does
it's
the
experience
that
defines
a
lot
of
people's
first.
Like
experience
with
the
part,
these
processes
and
I
think
it's
really
important.
We
think
a
lot
about
it
and
make
sure
it
feels
good
because
make
feel
good.
It
means
people
will
do
it
more.
It
directly
leads
to
success
of
the
existed.
I
don't
mean
to
over
blur
it,
but
I
don't
understand
and.
F
Also,
we
we
would
very
much
like
to
be
able
to
completely
stop
referring
to
main
in
its
entirety.
It
should
never
be
like
something
we
have
people
or
tell
people
about
or
ask
them
to
fall
back
to
we'd.
So
we'd
like
to
say,
like
encapsulation,
is
not
only
the
default
like
we
don't
talk
about
main
anymore.
It
is
not
something
you
would
like
people
to
use.
It's
quietly,
deprecated.
A
So
I
guess
a
quick
question
here,
and
this
would
be
to
both
guy
and
Yan
from
the
exports
proposal
perspective
like
we're
talking
about
not
allowing
you
know
the
string
syntax
here,
but
it
seems,
like
you
know,
like
one
of
the
bigger
challenges
here
would
inject
to
your
point.
We
do
have
corn
now,
but
it
seems
like
the
bigger
question,
would
actually
be
the
dot
syntax,
because
if
we
think
the
dot
is
confusing
like
we
could
use
a
different
signal
there,
but
is
this?
A
F
E
Well,
not
if
it's
just
like
starts
with
name
rather
than
dot,
slash
name
but
yeah.
The
the
other
is
an
argument
for
like
having
people
to
make
the
effort
to
use
the
dot
and
that's
like
it
kind
of
subtly
pushes
them
in
the
direction
of
hey.
You
could
have
multiple
exports
here.
You
don't
have
to
just
export
one
thing,
which
will
hopefully
start
encouraging
people
to
provide
multiple
exports
for
packages
that
could
potentially
do
that,
which
is
which
is
something
we
want
to
encourage
and.
D
Along
with
that
is,
it
sets
up
a
better
mental
model
for
them
like
I
like
it's,
the
the.
If
anybody
who
is
essentially
forced
to
use
the
the
object
syntax
for
exports
will
be
thinking
about
how
exports
and
entry
points
work
in
a
more
correct
way
in
a
way
that
will
lead
them
to
probably
offer
a
better
package,
as
opposed
to
you
know
the
like
I
guess,
unless
you're
trying
to
claim
that
the
there's
an
every
package
on
NPM
is
authored.
D
E
How
about
this
it
could
be.
Do
we
potentially
have
core
or
agreement
on
like?
Could
we,
along
with
what
we've
already
stuck
on
the
conditional
exports
flag
of
like
the
node
field
and
or
the
require
field?
Could
we
stick
the
shorthand
of
exports
behind
that
flag
as
well,
and
then
we
can
continue
to
like
figure
out
how
these
you
know
are
supposed
to
interact
with
each
other,
and
then
we
could
kind
of
unflagging
all
together
and
once
we've
got
a
good
solution
for
that.
I.
D
Mean
the
problem
is
that
the
stuff
that's
currently
behind
the
flag,
if
we
just
delete
that
from
node
nobodies
package
breaks,
they
just
have
functionality
that
doesn't
kick
in.
If
we
delete
the
string
syntax,
then
packages
would
break
potentially
or
or
we
they
would
have
a
bunch
of
fluffs.
That
would
be
well.
A
B
Okay,
sorry,
you
cut
out
there
I
wasn't
sure
if
he
said
my
name,
yeah
I
just
wanted
to
flip
the
argument.
Slightly
I've
I
mean
there
have
been
lots
of
good
arguments
for
various
points
here.
Bama
actually
heard
any
arguments
against
index
so
I
wanted
to
know.
Does
anyone
specifically
dislike
indexed
will
have
reasons
for
not
wanting
to
do
go
in
this
kind
of
a
direction?
Yes,.
A
One
more
thing
that
we
need
to
teach
people
and
I
know
that
dot
is
something
that
we
definitely
need
to
teach
people
but
like
having
more
and
more
fields
in
the
package.json
I
I,
like
the
idea
that
all
of
this
is
under
a
single
flag
and
I.
Don't
think
that
the
dot
export
is
an
incorrect
mental
model
of
how
you
think
about
this
or
a.
A
B
Was
one
way
that
we
were
looking
at
supporting
and
exports
without
a
dark
property
for
the
singular
case,
so
I
get
kind
of
a
sugar
for
the
singular
case,
and
that's
another
thing
that
we
haven't
really
discussed
fully
yet
the
way
this
detection
can
work
is,
if
you
have
keys
and
say,
route
could
be
either
all
of
the
keys
must
start
with
a
dot
which
I'm
making
up
an
era
that
very
carefully
throws.
If
it's
mixed,
you
try
to
do
something
like
this.
It
would
throw
and
say,
there's
a
path
export.
It
doesn't
know.
B
B
D
B
Looking
at
it,
what
I'm
saying
is
I
see
this
is
the
this
will
be
them
that,
like
90
percent
of
packages
will
be
doing
this
in
future
right,
they
will
likely
be
supporting
different
environments,
and
so
they
will
likely
have
different
cases
being
handled,
and
so
this
this
is
our
ninety
nine
ninety
percent
package
case.
This
is
the
major
case
of
how
people
are
going
to
define
packages
and,
if
we're
always
mandating
this
dot,
the
concern
is
like
a
kind
of
a
just.
A
D
A
D
A
E
F
E
E
A
On
it
for
sure,
potentially,
there
is
sugar
for
four
things
at
the
top
level
of
the
export
object
that
do
not
have
a
dot
at
the
beginning
of
them,
but
then,
similarly,
if
you
want
to
support
the
syntax
of
the
second
example,
that
guy
has
there
require
browser
default,
are
you
going
to
support
that,
while
also
supporting
named
exports?
If
you
do
that,
then
are
you?
How
do
you
decide
if
you
have
a
dot
or
you
have
those
like?
Is
it
this
introduces
so
many
like
different
branching
code
paths,
I'm
personally
kind
of.
E
A
Verbose
syntax
with
the
dot,
makes
no
sense
at
all.
If
we're
gonna
do
any
of
these
other
things,
we
should
have
one
or
the
other,
and
so,
if
we're
at
the
point
where
we
want
to
discuss
like
they
like
one
or
the
other,
then
I
think
all
of
exports
should
probably
go
behind
a
flag.
So
we
can
work
that
out.
Otherwise,
it
seems
like
we
maybe
should
just
make
a
have
a
conversation
today
and
just
make
a
decision
to
move
forward
with
thought.
A
Otherwise,
if
we
do
not
have
consensus
to
move
forward
with
that,
I
think
we
should
put
all
of
exports
back
behind
a
flag.
It
could
be
unflagged
in
short
order,
but
I
don't
think
that
we
should
ship
support
for
dot
if
we're
talking
about
having
any
of
these
other
sugars,
because
I
personally
do
not
like
the
idea
of
having
multiple
ways
of
writing.
This
I
think
we
should
pick.
You
know
one
idiomatic
way
of
doing
this
and
that'd
be
the
way
that
you
do
it.
E
D
Field,
so
if
we,
if
we
have,
if
there
is
no
like
chance
of
consensus
or
rough
consensus
for
the
index
field,
then
it
sounds
like
we're
back
to
the
dot
and
then
the
only
open
question
is:
what
do
we
do
with
the
string
sugar
and
that's
something
that
we
can
either
remove
or
put
behind
the
flag
or
leave?
And
that's
what
that's
the
only
decision
left
to
us
and
the
rest
of
exports
doesn't
need
to
change
that
right.
I
think.
A
D
A
It
basically
what
I'm,
saying
and
and
something
that
we
should
consider
is
exports
is
unflagged
right
now,
the
second
that
exports
is
unflagged
and
released.
If
we
do
it
in
modules,
where
we
have
exports
unflagged
and
the
dot
is
there,
people
are
using
that
and
push
it
out
in
the
ecosystem
and
Wes
you're,
saying
support
supporting
both
seems
like
it
could
be
reasonable
and
I
agree
with
you
that
it
could
be
reasonable,
but
I
don't
think
it's
a
decision.
We
should
be
making
in
the
last
five
minutes
of
a
meeting.
A
A
E
A
So
then,
so
then,
an
alternative
here
would
be
we're
all
saying
that
we
will
absolutely
always
support
the
dot
syntax.
If
we
want
to
add
additional
sugar
that
additional
sugar
would
need
to
be
able
to
work
with
the
dot
syntax
in
us
having
consensus
around
that.
Does
that
seem
like
where
we're
at
that
it
sound.
D
B
So
what
I
was
saying
is
we
would
have
some
kind
of
special
error
that
would
validate
exports
objects
and
if
you
have
any
field
that
starts
of
the
dots
alongside
either
every
every
key
must
start
with
the
dot
or
every
must
not
start.
At
least
you
have
a
mixed
error,
export
that
don't
you
must
do
one
or
the
other
to
indicate
and
then
point
to
a
documentation
page
or
something
just
work
out
how
to
clearly
verify
that
to
have
already
put
gun.
Okay,.
A
D
A
E
Mean
I
just
really
want
to
be
on
flags
this
month.
So
is
there
that's
my
only
concern.
Is
there
any
risk
that
we
wouldn't
have
everything
done
and
the
flag
dropped
like
in
two
ears
that
mean
the
rest
of
the
end
of
the
month
has
basically
lost
or
Thanksgiving
for
many
of
us,
so
I
think
we'll
have
to
make
some
of
these
decisions
in
the
foot
before
the
next
meeting.
Yep.
A
That's
why
I'm
saying
we
should
work
in
the
in
the
in
the
tracker
and
then,
if
we
need
to
meet
in
person,
we
can
I
have
that
user
research
thing
that
I'm
doing
on
Monday
and
I
could
talk
to
some
people
as
well.
Let's
kick
this
back
to
a
sink
and
try
to
get
it
wrapped
up
and
then
basically
do
what
we
did
today
and
hopefully,
by
the
end
of
the
meeting
in
two
weeks,
we
can,
at
the
very
least,
have
consensus
around.
You
know
the
shape
of
exports
to
be
okay
with
unflagging.
A
Perhaps
we
can
just
quickly
reach
consensus
that
if
guy
can
get
that
proposal
in
a
place
where
we
have
sign-off
and
no
objection
in
the
proposal,
you
know,
then
maybe
we
can
just
move
forward
anyways
and
if
anyone
has
a
problem
with
where
the
proposal
is,
please
bring
it
up
and
the
proposal
independent
of
whether
or
not
you
have
a
commitment
encore
will
respect
those
objections,
because
if
we
can
reach
consensus
at
a
band
on
this
I,
don't
think
we
necessarily
even
need
to
wait.
Til
the
next
meeting,
our
people.
Okay,
with
that
sure.