►
From YouTube: Node.js Foundation Modules Team Meeting 2019-06-19
Description
A
A
B
B
So
it
was
pretty
much
what
you
see
here.
We
had
another
flag
default
type
that
would
be
appropriate
to
use
in
node
options.
The
initial
suggestion
was
default.
Type
modular
comedy
is
similar
to
input
type
and
it
would
affect
input
type
so
that
like
currently,
if
you
leave
out
input
type,
it
defaults
to
comment.
Yes,
this
would
do
the
reverse,
where
it
defaults
to
module
and
you
have
to
explicitly
say,
input
type
equals
hum.
Yes,
if
you
want
that
likewise,
it
would
affect
the
package
of
Jason
type
field
where
it
currently
at
the
fields
missing.
B
B
B
Those
are
all
options
like
what
we
were
kind
of
thinking
was
put
this
out
there
with
the
minute
most
minimal
version
module
in
common,
yes
and
kind
of
start
from
there
and
see
what
the
reaction
is
and
then,
if
we
want
to,
you
know
broaden
its
applicability.
That
could,
you
know,
come
in
like
later
phases.
I
think
the
thinking,
especially
once
we
see
what
the
feedback
is
from
package
managers
and
users
and
so
on.
D
So
this
this
kind
of
seems
to
me
like
just
another
flavor
of
the
same
flag
that
we
eventually
decided
not
to
ship
with
dash
dash
type
the
we
went
through
our
whole
matrix
of
like
use
cases
and
what
we
like
have
to
support
and
what
we
can
choose
to
support.
You
know
and
things
like
that,
and
we
ended
up
going
with
input
type
and
partially
it
was
to
deal
with
to
you
know
ensure
consensus
within
our
group
and
partially
it
was
to
deal
with
upstream
objections.
D
D
Yes,
so
so
that's
all
that'sthat's,
the
capability
already
exists
merely
by
input
type
being
a
flag,
so
what
I
would
say
is
instead
of
since
you
can
all
the
convention
already
is.
If
you
want
default,
command-line
arguments,
you
set
them
in
your
note
options:
environment,
variable,
I,
think
the
discussion
really
should
be.
Do
we
add
a
flag
that
can
control
the
you
know
that
can
substitute
stand-in
for
a
type
field
in
the
closest
package.json
essentially,
and
that
would
be
the
dash
dash
type
flag
that
we
decided
previously
not
to
do
and
separately.
D
Then
what
it
also
seems
like
this
is
proposing
is
the
functionality
to
change
the
default
for
everything,
which
is
also
something
that
seen
this.
It
feels
like
something
we
explicitly
decided
not
to
do
previously
work.
So
if,
if
let's
say,
we
brought
back
a
dash
dash
type
flag
like
you're
talking
about
that
only
applied
to
within
the
current
package.json
boundary
and
kind
of
pretended
that
the
type
flag
was
set
to
module
there,
other
type
field
was
set
to
module
there.
Then
that
seems
like
that.
That
would
be.
D
That
would
give
you
what
you
want
in
the
sense
that
you
just
default
note:
options
to
input
a
type
module
and
package
type
module
or
whatever,
and
then
you've
achieved
the
defaults
you
want,
but
you
know
and-
and
you
haven't
triggered
all
the
concerns
raised
in
that
thread
about
changing
the
parsing
goal
of
code.
You
didn't
write
so,
like
that's
to
me,
seems
like
a
much
simpler
proposal,
but
then
that
seems
like
the
duplicate
like
the
same
proposal.
D
B
D
I
mean
there's
been
a
couple
of
users
on
the
North,
node,
repo
or
elsewhere.
The
device
for
lots
of
things
I
mean
it's
good
to
consider
those,
but,
like
there's,
been
a
couple
of
people
about,
as
for
default
extension
resolution
to
and
that
the
fact
that
people
asked
for
it,
you
know,
has
it
and
people
have
asked
for
not
it
as
well.
So,
like
I
feel
like
we,
it
should
be
a
minimum
requirement
that
people
have
asked
for
something,
but
like
we
need
to
have
a
higher
weight
of.
Why
do
we
want
to
add
it?
A
B
A
A
B
E
Waite
waste,
if
we
could
come
back
around
on
that
pipe
flag
and
then,
as
he
says,
the
naive
implementation
is
to
do
it
for
everything
and
yes,
that's
breaking,
but
I
was
having
I
guess.
What
we're
doing
is
we're
propagating
this.
This
type
module
filled
out
now
for
everyone
to
add
to
their
package
JSON
files,
and
this
is
something
that
we've
set
into
motion
and
that
we've
created
and
as
this
goes
out
and
people
are
putting
it
into
their
package.
Json
files
we've
created,
like
this
thing
that
we
haven't
worked
out.
E
E
E
Of
bootstrap
this
person
and
say
look
here's
something
that
breaks
here's
a
flag,
but
that's
setting
a
bar
and
in
three
years
time
maybe
package
managers
are
like
yeah.
That
seems
like
a
good
way
to
to
move
in
future,
but
it's
trying
to
start
a
conversation
really
and-
and
what
do
we
think
about
that?
Is
this
something
do
we
care?
Do
we
care
that
we
having
people
just
entering
type
module
and
there's
no
way
to
get
them
to
stop
doing
that?
Or
do
we
not
like
this
approach,
or
do
we
want
it?
E
D
I
questioned
the
premise
that
we
ever
want
to
deprecate
that
field.
I
think
that
the
reason
we
were
having
trouble
right
now
is
because
there
was
the
default,
because
an
assumption
was
made
at
the
inception
of
node
that
this
is
the
only
parcel
that
node
will
ever
need.
That
assumption
has
proven
to
be
wrong.
I
think
that
assumption
in
every
ecosystem
will
always
prove
to
be
wrong
and
I
think
that
if,
in
five
or
ten
years
some
new
super
module
gets
added
to
JavaScript,
we
don't
want
to
have
to
revisit
the
same
exact
thing.
A
We've
already
seen
in
Google
and
some
of
our
infrastructure
for
automating
installs,
that
having
things
that
change,
I'd,
either
publish
or
install
time,
can
cause
the
issues
with
reproducible
builds
or
with,
like
caching,
if
it's
inconsistent
in
any
way,
and
just
in
general
I
am
NOT
a
huge
fan
of
there
being
you
know
major
augments
at
bundle
time
that
are
kind
of
just
happening
behind
the
scenes.
Without
you
knowing
about
it.
This
seems
like
the
kind
of
thing
that
should
be
explicit.
B
B
E
Okay,
yeah
no
agency
was
really
just
that
if
we
did
want
a
deprecation
path,
it's
it
is
a
deprecation
path
that
takes
many
years,
and
so
that
was
the
urgency
to
try
and
allow
that
to
be
created
now.
But
if
it's
not
something
that
we're
concerned
about,
then
yeah
there's
there's
no
rush
to
to
fix
something
that
isn't
broken,
isn't
where
I
mean.
D
I
think
we
could,
regardless
of
this
direction,
we
could
try
and
gently
push
the
ecosystem
to
add
explicit,
tight
common
js2
places.
Obviously
it
wouldn't,
we
probably
won't
be
able
to
get
everywhere,
but,
like
I'm,
we
could
probably
get
NPM
and
yarn
to
add
in
like
a
warning
when
you
publish
a
module
that
doesn't
have
a
type
field.
First,.
E
E
Can
you
repeat
one
more
time
with
the
action
item
you
were
suggesting
was
just
saying
that
maybe
a
note
saying
that
if
packages
want
to
set
type
commonjs,
that's
not
discouraged
because
it
could
be
useful
in
in
allowing
all
packages
to
be
explicitly
defined
as
their
type
which
I
don't
know.
If
we
want
to
be
as
explicit
as
saying
that
would
allow
us
to
search
the
default
in
future,
we
could
say
it
might
allow
us
to
search
the
default
in
future.
E
A
D
I
think
if
we,
especially
if
those
seem
to
be
getting
traction
within
those
two
projects,
I
think
it
would
also
be
useful
to.
We
could
write
some
sort
of
pull
request.
Creation,
bot
that
can
go
and
add
it
to
all
the
existing
packages
like
sort
by
you
know,
download,
counts
or
something
just
try
and
push
it
out
into
the
ecosystem.
B
Was
just
gonna
say:
I
mean
I'm,
just
thinking
more
broadly
I
don't
have
the
answer
for
this
I'm.
Just
thinking
about
what
you
were
saying
is:
should
we
just
recommend
that
people
always
include
a
type
field
period
like?
Is
there
a
reason?
Is
there
an
advantage
to
publishing
a
I
mean
like
you're
saying,
if
you
explicitness
is
always
preferred,
then
shouldn't
we
just
encourage
all
packages
to
have
type
Commodus
or
type
model,
as
the
case
may
be,
or
is
there
some
reason
to
we.
A
Should
encourage
them
to
do
it?
I
mean
like
if
we
wanted
to
go
like
we
could
even
go
to
the
extent
of
like
Docs
deprecation,
runtime
deprecation
than
just
straight-up
deprecation,
but
that
might
be
a
little
bit
too
disruptive,
but
we
could
move
towards
the
like
putting
warnings
in
the
console
if
that
field
is
missing.
If
we
are
like
actually
planning
to
switch
the
default,
because.
D
A
A
Yeah
I
think
we
can
bring
this
offline
and
maybe
someone
can
make
a
PR
updating
the
docs
and
I
think
in
node
core
proper.
We
could.
If
we
wanted
to
create
a
timeline
for
doing
the
switch.
We
could
make
a
combination
of
a
doc
deprecation,
followed
by
like
a
runtime
deprecation
and
there's
also
a
way
to
do
like
non-invasive,
runtime
deprecation,
so
like
warnings
that
will
only
print
if
you
include
a
special
flag.
B
Yeah
I'm
just
thinking
I'm
I'm,
happy
to
spearhead
the
doc
update
but
I'm.
Just
thinking
like
it's
it's
broader
than
adding
just
one
paragraph.
It's
also
like
this
discussion
of
how
you
define
a
module
and
how
you
enable
USM
mode.
You
know
mgs
versus
type,
so
that
should
maybe
be
a
discussion
that
we
have
like
in
an
issue
or
something
as
I'm
sure
people
will
have
opinions.
B
A
A
A
B
A
Just
I
think
I
was
the
one
who
added
it.
I
was
going
through
our
issue
tracker
and
just
trying
to
clean
things
up.
It
seemed
like
there
had
been
some
discussion
on
here,
but
the
discussion
that
kind
of
dried
up
since
April
I
guess
there
isn't
really
anything
to
discuss
with
the
Flex
functionality
options.
I.
B
Mean
I
can
just
ask
like
just
do
we
want
to
change
anything
with
regards
to
flags
like
a
real
crate,
with
input
type
as
our
only
fly
or
does
anyone
still
I
mean
I'm?
Part
of
me
still
wants
to
think
about
input
type
equals
Auto,
but
I
don't
know.
If
that's,
it
seems
like
that's,
never
gonna
get
through
so
I,
don't
know
if
that's
worth
discussing
but
I
think.
A
I'm
less
concerned
about
Auto
and
more
concerned
about
the
flag
being
generally
useful
and
having
a
way
to
do
things
with
a
flag
like,
and
that
really
comes
back
to
the
original
argument
that
we
had
about
type.
That's
independent
of
the
last
conversation
that
we
were
just
having
and
that
just
seems
like
a
general
thoughtfulness.
How
about
the
flags
that
we're
using
and
I
think
it
was
specifically.
You
know
we
got
caught
up
on.
How
should
your
like,
if
the
module
that
you're
running
is
interpreted
as
a
module
but
then
like?
A
How
are
your
dependencies
determined
starts
becoming
like
really
edged
Casey,
so
don't
have
a
good
answer.
Truthfully.
I
was
just
kind
of
okay
with
what
we
had
right
now
and
I.
Don't
think
it's
a
high
priority
for
unflagging.
It's
like
a
thing
that
would
be
good
to
have
a
better
user
experience
on,
but
we
may
find
just
how
many
people
use
it.
A
bunch
may
raise
concerns
or
raise
better
questions
about
what
we
do.
There.
E
B
B
E
A
E
B
All
right,
the
very
high
level,
it's
it's,
not
a
fleshed-out
proposal,
we're
still
like
working
out
the
details,
but
the
very
high
level
is
what
we're
thinking
of
is
basically
two
fields
and
stop
me
and
correct
me:
guy,
if
I'm
speaking,
anything
at
the
moment
we're
thinking
of
two
fields
which
we're
calling
imports
and
exports.
So
I'll
start
with
exports,
because
that's
the
one
that's
more
familiar
to
what's
been
discussed
so
far.
B
Exports
would
be
similar
to
the
to
the
proposal
from
like
six
months
ago
or,
however
long
where
it's
just
an
object
where
on
the
left
is
basically
a
specifier
and
on
the
right
is
a
file
so
like
yeah
like
that
to
use
that
moment
in
example,
say
you're,
say:
you're
the
publisher
of
moment:
you
have
exports
and
then
you
have
a
key.
That's
like
slash
time
zones
and
the
value
would
be
you
know,
period
/data,
/index
times,
yes
or
something
like
that.
So
this
allows
a
consumer
to
do.
B
B
If
you
do,
you
know
I
guess
this
is
this
is
worth
much
more
up
in
the
air
like
import,
Tildy,
slash
time
zone,
then
you
map
that
to
dot
dot,
slash
time
zone,
slash
something-or-other,
we're
still
working
all
this
out,
but
the
idea
is
that
you
get
a
lot
of
the
benefits
of
the
import,
Maps
proposal
of
being
able
to
kind
of
define
almost
like
defining
similans
in
a
way
and
we're
also
talking
about
letting
this
define
dependencies
or
different
dependencies
to
be
some
different
conditions,
and
things
like
that.
Is
that
a
fair
summary?
E
Yeah,
so
imports
then
covers
both,
for
example,
relative
specifiers
in
the
package,
possibly
and
possibly
also
bear
specifier
resolutions
within
the
package
being
able
to
be
remapped
similarly
to
exports.
But
it's
the
difference
between
mappings
within
the
package
and
mappings
coming
into
the
package
as
you
sort
of
enter
the
package
as
a
sub
path.
So
that's.
F
D
Had
my
hand
up
this
kind
of
feels
like
two
features
right,
one
is
currently
impossible
thing
which
is
remapping
like
providing
like
essentially
reef
mapping
and
creating
virtual
deep
imports
for
a
package,
and
then
the
other
feature
is
remapping
bear
fires
for
that
package,
but
the
product
the
thing
is,
is
that
NPM
already?
As
of
six
point,
nine
provides
that
second
feature.
You
can
say
that
an
import
of
moment
actually
installs,
not
version
one
two
three
a
moment,
but
the
version
NPM
:
lo
at
one
two
three
and
then
you've
remapped
it.
B
Odors
definitely
like
will
like
there's
certainly
already
today
in
comment,
yes
and
I'm,
assuming
that
when
loaders
are
built
for
ESM,
they
will
also
support,
like
remapping,
specifiers
I.
Think
the
thing
is
that
that
that
only
have
helps
the
current
project
like
a
visual
packages
like
moment
and
can't
do
that
kind
of
stuff
within
their
own
scope.
You
know
right.
D
So
the
the
the
do
that
stuff
within
your
own
scope,
that's
the
first
half
of
the
feature
which
I
think
it's
currently
impossible
and
is
highly
valuable
boats
for
CJ
s
and
for
ESM.
The
second
piece
of
the
feature
is
something
you
can
already
do
for
yourself
with
NPM
so
and
with
yarn.
So
like
I,
don't
know
why
note
itself
means
to
add
it
directly
and
and
by
by
adding
it
you
introduce
a
complication
about
what
do
the?
How
do
you
differentiate
relative
versus
their
specifiers?
Do
you
require
flash
and
so
on.
H
Yeah,
if
you
want
to
fully
agree
with
what
Jordan
is
just
fair,
I
think
this
is
two
features
and
the
first
part
of
the
exports.
The
second
part
we
could
call
imports
or
aliases,
and
it's
the
first
part
I
think
it's
a
higher
priority
thing
to
Seoul,
and
they
they
just
seem
like
completely
separable
features,
so
I
would
I
would
hope
we
can
just
solve
that.
First
problem
and.
F
F
So
for
me,
exports
is
just
an
extension
of
the
main
field.
So
yes,
John
and
NPM
have
built-in
features
that
you
can
use
to
remap
a
nice
time
specified
inside
of
a
package
scope
that
can
specify
in
gyroscopes.
If
it
doesn't
have
any
specific
path,
extensions
you
can
remap
it
from
underscore
no,
but
that
is
actually
not
even
touching
the
expose
proposal.
F
F
The
only
thing
that
it
actually
changes
what
you
can
do
beyond
what
it
main
already
does
is
that
you
can
have
specific
overrides
for
subpaths
of
the
best
specifier
that
map
to
something
else.
That
is
not
the
exact
path
from
the
best
specifier,
and
that
is
just
sugar
right,
because
you
could
just
have
a
slightly
longer
path
and
it
would
do
the
same
thing.
B
There's
one
other
thing
with
that:
yon
we
forgot
to
mention
is
that
it
would
also
lock
down
anything,
that's
not
defined
like
you
could
you
could
kind
of
give
it
a
wild-card
to
just
open
up
your
whole
package,
but
the
idea
would
be
if
you
didn't
by
default.
Only
the
paths
that
you
specify
and
exports
would
be
the
only
exposed
path
so
that
it's
not
like
your
whole
package.
Any
file
in
your
that
you
can
get
imported
the
way
I
can
now
right.
F
But
that
is
only
something
it
falls
out
from
this
magnetics.
Just
because
that's
how
Bayer
specify
resolution
would
work
and
wouldn't
actually
be
reliable.
It
was
not
a
security
feature.
It
would
be
a
convenience
feature
to
express
an
API,
it's
kind
of
the
underscore
property
of
private
state,
because
you
can
still,
if
you
can
construct
the
URL,
you
can
still
get
to
the
file.
It's
just
that
if
you
used
to
be
a
specified,
wouldn't
automatically
be
resolved.
D
Clarifying
question
here
so
there's
a
lot
of
overlap
with
your
proposal
and
what
the
browser
field
already
does
and
with
that
both
the
keys
of
the
object
and
the
specifier
you're
trying
to
get
to
are
normalized
and
that's
what's
compared,
which
means
that
you,
don't
you
actually
don't
have
a
way
to
get
to
the
original
file.
It's
completely
shot
and
that's
not
something
that's
built
in
your
proposal.
F
F
With
the
browser
key
of
the
original
file,
just
vanishes,
which
is
like
so
nothing
even
inside
of
the
package-
can
get
to
the
original
file
anymore,
which
is
not
really
encapsulation
as
much
as
replacement
right.
So,
if
you
write
the
original
file
completely
on
the
disk,
it
would
have
the
same
effect,
which
is
nice
for
browser
like
for
platform
level
bundling.
But
it's
not
actually
like
a
security
feature,
because
nothing
can
Texas
this.
Just
in
quotation
marks
perfect
security
by
hiding
it
from
everybody,
but
also
you
don't
need
to
use
the
code,
but.
A
It
makes
it
easier
to
like
statically
analyze
and
see
that,
like
all
instance,
if
you
know
that
all
instances
of
imported
modules
within
your
tree
adhere
to
imports
and
then
also
do
not
search
directly
into
the
node
modules
folder.
Yes,
it
may
not
be
like
clearly
a
security
feature,
but
but
it
is
another
stack
valid
nation
that
we
don't
currently
have
yeah.
F
Yeah,
it's
definitely
useful
right.
It's
it's
a
useful
signal,
but
it's
not
really
transformative,
because
you
can
also
have
a
linter
that
that
does
check
that
you
don't
do
any
path.
Imports
into
a
package
like
there
are
ways
of
expressing
this
yeah
really
runtime.
Anyhow,
so
I
think
the
more
transformative
thing
is
actually
the
imports,
because
that
is
where,
especially
like
Jordan
brought
up
the
browser
field.
That's
where
we
actually
get
to
new
interesting
features,
because
having
imports
allows
us
to
express
things
like
hey.
F
This
internal
path
should
now
be
used
instead
of
the
original
one
because
I'm
running
in
a
certain
environment,
and
that
is
something
that
is
actually
changing.
What
you
can
do
using
static
imports,
that's
something
that
you
would
otherwise
need,
either
an
external
tool
with
additional
package,
Jason
fields
that
I
completely
decoupled
from
the
normal
model
resolution
like
the
browser
field,
or
you
would
need
runtime
code
that
does
conditional
await
imports,
which
is
you
know,
not
great
for
static
analyzable.
F
A
Do
we
have
do
we
have
bundlers
that
are
saying
that
they
would
use
this
like?
Would
Babel
use
it?
Would
what
web
pack
use
it
because
realistically-
and
you
can
correct
me
if
I'm
around
like
these-
don't
sound
like
things
that
we
need
to
support
in
the
runtime
necessarily
for
them
to
be
conventions
that
people
are
following,
so
I've
been
talking
with,
like
Jason
Miller,
for
example,
we
were
talking
about
entries
being
the
name.
F
That
works
well
for
things
that
they
have
in
mind,
which
is
compiling
for
different
syntax
formats,
for
example,
where
you
basically
have
a
full
build
in
a
separate
directory
with
everything
in
there.
That
is
for
different
environments.
It
does
not
work
well
when
you
just
want
to
offer
from
some
JavaScript
like,
for
example,
I
have
an
HP
client
library
that
works
for
web
and
for
note
we're
just
a
single
file
in
the
implementation.
F
So
we
would
use
the
same
array
notation
that
is
also
used
for
standard
modules.
Just
having
the
marker
that
says,
hey
this
entry
in
this
array
is
meant
only
for
node
and
if
you
are
and
your
browser
the
tool
would
just
generate
the
input
map,
omitting
the
things
that
are
targeted
for
node
and
you
end
up
with
an
import
map
that,
in
theory,
should
work
one-to-one
in
a
browser.
F
A
D
My
hand
up
I
want
up
to
the
bundlers,
aren't
necessarily
applying
to
any
space
at
all.
Tons
of
node
packages
has
to
are
forced
to
put
their
code
in
a
source
directory
and
then
have
their
output
in
a
build
directory
or
Lib
directory,
or
something
which
means
deep
imports.
We're
forced
to
have
that
extra
tax.
B
Think
it
could
certainly
be
like
submitted
as
two
separate
pull
requests
and
probably
will
be
I
think
what
you
know
what
they
have
in
common.
Is
they
both
describe
using
package
adjacent
to
remap
import
specifiers,
so
in
that
sense
they
need
to
be
designed
together
and
like
mesh
well,
because
you
don't
want
to
have
you
know
if
we're
creating
two
new
fields
that
both
deal
with
remapping
specifiers
like
they
should
have
similar
syntax
and
design
etc.
So
yeah,
like
I,
guess.
A
The
biggest
different,
though,
is
exports
is
about
defining
it
for
the
people
who
are
consuming
your
package,
whereas
imports
is
kind
of
defining
like
metaprogramming.
Your
internal
runtime,
based
on
environment
so
like
to
me,
exports
is
the
one
that
seems
like
the
obvious
thing
that
absolutely
needs
to
happen
as
part
of
like
completing
the
behavior.
We
need
like,
in
my
personal
opinion,
to
unflagged,
whereas
imports
seems
more
on
the
like
nice
to
have
or
extra
metaprogramming
it
like
me.
It
doesn't
seem
like
imports
would
block
unflagging,
whereas
experts
money
anything.
You.
D
A
Also
think
and
I
could
be
wrong-
that
the
exports
proposal
is
pretty
one-to-one
to
patterns
that
people
are
already
doing
today
and
recreating
behavior.
That
already
exists
in
the
ecosystem,
whereas
imports
is
starting
to
think
about
new
power.
I
think
that
we
need
to
bring
in
more
stakeholders
before
making
those
kinds
of
commitments
for
new
things.
Yawn.
F
So
I
think,
if
you're
talking
isolated
note,
then
that's
true.
If
you're
talking
about
people
like,
oh
well,
even
in
those
there
are
things
like
react,
I
think
they
are
doing
things
where
based
on,
if
it's
development
or
not,
they
load
a
development
version
or
production
version
of
the
same
package.
F
F
D
Proposal
doesn't
create
a
way
to
pivot,
on
the
node
end,
for
example
like
this,
you
would
still
need
that
same
exact
solution
now
or
you
have
a
dynamic
check
of
process
data
and
dot
whatever,
and
you
would
still
presumably
need
a
browser
field
if
you
wanted
to
have
a
different
pair
of
node
ends.
Routes
for
the
browser.
F
Hopefully
you
wouldn't
like-
and
the
proposal
is
not
updated
yet
with
that
aspect
which
is
summarized
in
the
past,
and
that
is
that
the
proposal
would
actually
have
a
decrypt
way
of
saying
things
like
only
do
I
reload
this
in
a
certain
certain
environment,
but
so
I
think
the
two
issues
are
a
there's,
a
very
strong
demand
in
the
ecosystem
for
having
a
way
to
have
multiple
versions
of
a
file
or
multiple
versions
of
a
package
and
be
specifying
it
in
a
way
that
is
supporting
those
use.
Cases
consistently
is
very
hard.
F
So
can
we
impose
an
export
separating
the
two
proposals?
Wouldn't
like
guess?
We
can
do
it,
but
it's
like
three
lines
that
would
change
like
it's.
Not
that's,
not
the
big
thing.
The
big
thing
is:
if
we
want
to
support
environment
switching
declaratively,
what
would
be
the
smarter
way
of
doing
it,
and
that
is
the
bigger
part
of
the
proposal
like
if
I
would
split
the
proposal.
I
would
split
into
imports
and
exports,
basically
building
a
resolution
table
and
then
making
the
resolution
table
environment
specific,
because
that
is
the
two
big
pieces.
In
my
opinion,.
D
Again,
pointing
to
the
browser
field,
it's
worth
noting
that
the
browser
field
did
not
lock
out
anything
anything
you
import,
anything
is
imported.
It
doesn't
have
a
key
in
the
browser
field.
It
just
works
so
again,
I
think
the
really
new
feature
here
is
the
ability
to
say
that
if
it's
not
listed,
you
can't
get
to
it.
So
that's
that's
a
feature.
That's
and
one
of
the
pictures
I'm
particularly
interested
that.
F
We
have
two
example
of
reactive
as
a
development,
a
production,
you
really
don't
want
to
run.
The
production
builds
on
your
production
and
you
really
want
to
run
the
development
version
on
your
machine
right
now.
What
they
are
doing
is
they
have
an
implementation
that
requires
like
what
would
they
do
like?
This
is
the
completely
node
specific
example.
A
So,
just
to
interrupt
really
quickly,
we've
only
got
five
minutes
left
on
the
meeting
and
I
think
it
might
be
good
for
us
to
pivot
on
next
steps.
Is
there
run
okay
with
that
would
like
to
suggest,
and
the
people
have
been
working
on
this
proposal
may
disagree
with
me.
I
personally
feel
like
we're
ready
for
act,
the
exports
field
to
get
a
PR
opened
against
core
and
to
iron
out
the
last
little
bit
of
behavior
to
look
at
getting
it
against
both
ESM
and
commonjs
and
figure
out
hey.
A
Can
we
do
this
to
come
and
Jess
in
a
non-breaking
way?
What's
gonna,
be
the
cost
of
this
like?
Let's,
if
I
recall,
I,
think
I
already
has
a
bunch
of
the
implementation
done
it's
it's
not
that
much
code,
let's
just
open
a
PR
against
core
and
start
getting
the
work
towards
getting
this
over
the
finish
line
done
separately.
We
have
the
the
calm.
Calm
has
groups
for
doing
user
outreach.
I
also
know.
There's
a
tooling
working
group.
A
We've
had
good
relationships
with
Babel
and
webpack
I
would
really,
and
then
James
Jason
and
Chris
from
over
at
Google
have
been
doing
some
interesting
stuff
in
this
space
as
well.
I
think
we
should
continue
exploring
the
imports
portion
of
the
proposal
and
bringing
more
stakeholders
and
ensure
that
what
we
would
implement
there
would
be
things
that
multiple
stakeholders
would
use.
B
Jeffrey
yeah
so
that
I
wrote
the
part
of
the
exports
proposal
in
the
and
the
thing
that
yon
posted
the
Google
Docs.
So
I
can
be
a
point
person
on
that
or
help
with
whoever's
implementing
that
Karen
else.
The
other
thing
I
was
gonna
say,
is
if
there's
one
thing
that
people
have
been
commenting
about,
or
at
least
that
I've
noticed
that
people
who
are
commenting
out
on
the
node
repo
about
experimental
models.
Lately,
it's
been
all
the
missing
functionality
we
have
yet
to
implement.
B
Regarding
loaders
and
like
stubs
for
tests
and
all
that
kind
of
stuff
yeah.
How
is
this
gonna
work
with
jest?
How
is
this
gonna
work
with
sign-on,
etc
and
yeah?
We
need
to
be
making
progress
on
that.
So
I
was
just
thinking
if
miles,
if
you're
reaching
out
to
other
stakeholders.
That
could
be
something
else
that,
like
I,
you
know
I
think
we
could
use
some
help
in
that
in
that
area.
Mm-Hmm.
A
Okay,
yeah
I'm
personally,
actually
trying
to
see
if
I
find
funding
to
help
support
some
open-source
development
on
loaders
I
think
that
that
loaders
is
definitely
one
of
the
last
things
we
need
to
figure
out.
These
other
bits
are
really
great
and
interesting
to
dig
into,
but
loaders
are
definitely
one
of
the
biggest
blockers
right
now.
I
feel.
B
Like
I
feel
like
the,
if
we
don't
have
good
answers
to
the
like
how-to
tests
work
in
ESM,
then
it's
like
ESM
is
incomplete,
whereas
like
yeah
exports
would
be
nice
to
have.
But
truly
it's
like
you
know,
that's
it's
an
X,
it's
a
good
feature
to
have,
but
not
truly,
not
like.
Oh
my
god,
there
was
something
in
common.
Just
that
I
can't
do
any
in
stem.
You
know.
E
B
E
A
F
Would
just
quickly
want
to
fold
something?
What's
what
guy
just
asked?
Basically
yeah,
ok,
so
epic
note,
it
is
I
think
we
definitely
do
strictest
control
I.
Don't
think
that
the
resolution
logic
is
where
I
should
live.
It
should
live
outside
up
resolution
logic,
so
that
your
resolver
doesn't
need
to
also
double
make
double
duty
as
a
access
control
mechanism.