►
From YouTube: Node.js Foundation Modules Team Meeting 2020-09-09
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
we're
now
live
on
youtube
with
the
september
9th
edition
of
the
new
js
modules
team,
we're
going
to
go
ahead
and
kick
it
off
and
I'm
going
to
hand
it
off
to
guy
bedford
who's
going
to
lead
the
meeting
today.
Guy.
B
Thanks
miles,
yes,
so
we're
gonna,
hopefully
be
able
to
get
through
most
of
the
agenda
this
week.
The
last
couple
of
meetings
we've
had
a
few
more
items
we've
been
able
to
get
through.
B
B
The
first
item
on
the
agenda
is
three
four,
seven
one,
eight
on
a
pull
request
on
the
node.js
repo-
and
this
is
a
pr
that
I
put
together
to
implement
a
simple
kind
of
pattern
replacement
in
the
exports
field
and
to
to
reiterate
the
problem
that
this
is
solving,
that
we've
discussed
the
last
few
times
is
that
it
is
quite
common
or
it's
becoming
more
common
for
packages
to
have
many
many
exports,
potentially
hundreds
of
exports.
B
As
a
result,
path
exports
become
absolutely
indispensable
in
in
these
scenarios
to
be
able
to
simply
export
an
entire
folder,
but
there
are.
There
are
two
problems
with
doing
this.
The
first
is
when
you
export
an
entire
folder
you're
exporting
every
single
module
in
that
folder,
when
maybe
not
every
single
module
in
that
folder
is,
is
a
public
module.
B
B
B
You
need
file
extensions
for
all
of
those
those
modules
in
the
package
and
we
can
solve
both
of
those
problems
if,
if
we
just
treat
a
folder
export
as
effectively
saying
when
you,
when
you're
using
a
folder
export
you're
allowing
any
subpart
of
the
package
to
map
into
the
subpart
of
the
of
the
folder
mapping,
sorry,
I
know
it's
difficult
to
understand
without
context
of
path
exports
in
the
exports
field,
but
I
believe
most
of
us
have
that
context
here
and
and
with
with
the
with
the
wild
card
match
you,
you
can
basically
specify
that
the
the
last
portion
of
that
of
that
path
can
then
be
substituted
into
a
pattern
instead.
B
So
it's
just
extending
the
existing
functionality
where
path
exports
act
like
a
wild
card
already
and
and
allowing
a
little
bit
more
functionality
in
the
pattern.
So
it's
not
actually
I
I
would
argue
that
it's
not
actually
a
new
feature
so
far
as
it's
the
capability
is
there
today.
The
way
the
path
exports
behave
is
a
replacement.
B
The
issue
is
that
not
enough
package
authors
have
hit
this
problem
because
the
package
authors
adopting
exports
today
maybe
have
packages
with
five
or
six
exports
at.
C
B
And
these
are
problems
we
only
had
far
down
the
line
and
it's
it's
a
problem
that
came
up
specifically
when
I
was
working
on
jspm
and
suddenly
saw
these
packages
with
thousands
of
exports
and
wanted
to
pr
the
exports
field
for
them
and
then
realized.
There
was
no
realistic
way.
I
could
create
a
exports
pr
for
them
that
would
support
their
use
cases.
B
I
do
think
it's
important
functionality,
so
yeah
I'd
be
good
to
hear
people
are
currently
thinking
jordan.
I
believe
you
had
your
hand
up
first
yeah,
so.
D
Part
of
the
reason
I
mean,
I
think,
you're
right
that
not
a
lot
of
folks
have
run
into
it
yet
partially
because
having
exports
is
a
breaking
change
partially
because
it's
new
and
so
on,
but
I
mean
the
I.
I
kind
of
I've
expressed
this
a
few
times
before,
but
I
feel
like
I'm
over
two
minds
here.
Right
one
is
that
if
we
think
that
things
package
authors
want
to
make
it
easier
for
them
to
write
smaller
exports
maps,
if
we
think
that's
important,
then
there's
a
lot
of
features.
D
We've
already
decided
not
to
do.
That
would
help
with
that
that
are
already
hit
way
more
often
than
the
use
case
you're
describing,
which
is
still
valid
so
in
in,
if
we're
going
to
decide
to
change
our
direction
and
tackle
those
problems.
This
is
a
clear
path
in
that
direction,
and
we
should
do
that.
If
we're
not
going
to
change
our
direction,
then
that's.
D
D
So
the
we
currently
have
the
directory
exports,
like
the
things
that
the
left-hand
side
ends
with
slash,
is
that
right
or
the
right
hand
side?
I
always
forget
how
to
talk
about
these
things.
D
Okay,
so
the
directory
exports,
like
that's
an
escape
hatch
right,
meaning
that
was
not
intended
to
be
commonly
used
and
all
those
invariants
that
people
wanted
of.
Having,
like
you,
know,
a
one-to-one
mapping
between
exports
and
import
maps
and
like
being
able
to
not
have
to
look
at
the
file
system
to
be
able
to
generate
an
import
map
and
so
on.
D
We
kind
of
like
just
accepted
that
the
directory
exports
as
the
escape
hatch,
were
this
thing
in
the
corner
that
that
messed
with
that,
but
that,
hopefully
people
wouldn't
use
and-
and
I
think
that
this
feature
kind
of
expands
on
that
thing.
We
hope
people
wouldn't
use
and
turns
it
into
a
thing.
We
expect
people
to
use,
which
means
that
those
concerns
one-to-one
with
import
maps
and
being
able
to
not
have
to
look
at
the
file
system
seem
like
they
kind
of
go
away.
D
And
if
that's
the
case-
and
we
agree
on
that-
that
that's
what
what
the
case
is
then
cool
like
there's,
then
there's
other
previously
disclosed
discussions
that
we
may
want
to
reopen.
But
but
I
I
feel
like
at
the
moment
the
pr
is
inconsistent
with
our
previous
decisions
and
then
and
then
the
quick
little
data
point
is.
I
have
a
package
that
has
1712
export
specifiers
without
an
exports
field,
and
I,
when
I
add
an
exports
field,
I
am
intend
to
manually
write
those
all
out.
D
I
will
probably
write
some
tooling
to
to
help
me
there,
but
like
so,
but
I
having
your
feature
would
actually
help
me.
So
I
have
a
personal
like
use
case
that
I,
where
I
would
use
this
pr.
I
just
think
it's
that
what's
more
important,
is
that,
like
the
overall
module
system
and
us
as
a
group
are
on
the
same
page
about
priorities
and
directions,
and
things
like
that
bradley.
E
Sure,
in
the
pr
I
mentioned,
there's
an
ordering
thing
which
I'm
concerned
about
where
the
top
level
left
hand
side
is
ordered
by
length
and
the
right
hand,
side
leafs
are
ordered
in
object,
iteration
order.
E
I
just
prefer.
If
the
top
level
left
hand
side
was
object,
iteration
order,
I
don't.
I
don't
think
that
needs
to
be
discussed
here.
So
much
per
other
things.
I
highly
suggest
you
don't
put
1700
exports
entries
in
a
package
json
at
16,
000,
total
entries
for
a
policy
file.
That's
a
good
three
to
four
hundred
millisecond
punishment
for
doing
it.
That
way,
that
can't
be
avoided
because
it
has
to
be
done
eagerly.
E
So
for
policies
and
things
like
that,
we
also
have
essentially
done
roughly
a
similar
thing
of
scoping,
and
that
gets
you
actually
performance
back.
It
also
still
remains
completely
static,
so
I'm
I'm
not
sure.
I
understand
the
claim
that
we
never
want
to
inspect
the
file
system,
because
we
always
eventually
have
to
inspect
the
file
system
at
runtime
so
having
to
inspect
the
file
system
at
whatever
build
time
or
creation
of
package.json
seems
reasonable
to
me.
E
E
A
All
yeah
so
a
couple
different
thoughts
here
I
as
I've
been
saying
in
the
issues.
I'm
kind
of
leaning
minus
zero
on
this
not
like
objecting
but
feeling
uncomfortable,
and
I
think
that
I'm
starting
to
understand
more
specifically.
Why-
and
I
think
it's
more
of
like
a
syntax
and
like
paint
on
the
shed,
rather
than
the
actual,
like
problem
that
you're
trying
to
solve
here
and
I'd
like
to
suggest
two
potential
alternatives.
A
And
you
know,
obviously
we
could
decide
not
to
go
in
that
direction,
but
you
know
import
maps
and
export
maps.
The
imports
field
in
the
exports
field
that
we
have
right
now
are
already
doing
a
lot,
but
it's
kind
of
like
a
one-to-one
thing
and
adding
kind
of
the
stars
here
start
to
feel
like
globs
to
me
and
in
my
personal
opinion,
kind
of
like
complicate.
A
What's
going
on
with
that
in
mind,
I
think
that
there's
two
potential
approaches
that
we
could
take
to
this,
one
of
which
was
suggested
by
jordan
before
which
would
be
an
extension
map
which
would
be
a
single
field
where
you
could
state
the
extension
and
the
goal
that
it
would
resolve
to
and
like
we'd
have
to
figure
out
what
shorthand
you
would
want
to
do
for
no
extension,
which
could
be
like
empty
string
or
something
like
that
which
is
like
not
lovely,
but
I
feel
like
that.
A
Might
that
might
scale
a
little
bit
better.
The
other
thing,
the
other
potential
solution
here
as
well,
would
be
making
a
separate
extension
map
where
you
give
the
folder
and
then
the
extension
that
you
want
resolved
when
no
extension
is
given.
This
would
be
slightly
more
verbose,
but,
as
far
as
I
can
tell
would
mostly
accomplish
the
same
basic
things
that
this
proposal
is
trying
to
prese
to
to
present.
It
would
still
be
static
in
the
sense
in
in
in
this.
A
In
the
case
that,
like
you
know,
there
would
be
a
single
resolution
for
every
single
specifier,
it
would
enable
the
patterns
that
you're
talking
about,
but
by
kind
of
teasing.
This
apart,
I
feel
like
it
would
be
clearer
to
instruct
people
on
and
and
clear
to
like
reason
about
looking
at
a.
D
I
put
it
back
up
after
miles
just
to
suggest.
D
D
It
feels
like
that.
Might
since
we
already
have
to
look
at
subfolder
package
jsons
anyway,
for
type
module.
Is
it
out
of
the
question
to
add
export
support
there,
because
that
then,
like
the
already
existing
directory
nesting,
that
packages
have
like,
including
my
package
that
has
1700
things
like
that's
actually
much
smaller?
D
If
you
look
at
it
per
directory
like
I
feel
like
the
problem
and
potential
performance
issue,
but
also
like
boilerplate
stuff,
becomes
a
lot
easier,
and
this
is
whether
guy's
pr
lands
or
not
and
similarly
like
if
an
extension
map
landed,
and
that
was
also
in
any
package
json,
then
it
would
be
kind
of
a
similar
thing.
In
my
mind,
is
that
out
of
the
question
like
to
make
it
be
any
folder
and
not
just
package
level,.
E
I've
previously
objected
to
this,
and
I
can
be
a
bit
more
concrete
as
to
reasons
why
right
now,
exports
applies
to
bear
specifiers.
It
isn't
really
that
it
applies
to
any
specific
folder.
It's
only
to
these
specific
specifiers
that
we
use
it
in.
If
we
apply
it
to
all
specifiers,
it
becomes
immensely
complex
in
a
very
old
rfc
on.
I
think
it
was
in
the
node
eps
repository.
We
tried
to
discuss
a
consumer
and
author
negotiation
system.
E
It's
a
two-phase
commit
if
we
do
that,
and
that's
slow
and
figuring
out
how
to
make
it
not
slow
or
complex
is
hard
because
it
would
suddenly
apply
to
any
relative
specifier
and
if
you
resolve
something
it
could
resolve
to
a
location
that
resolves
outside
of
another
thing.
So.
E
C
I
think
we've
discussed
this
before
and
there
are
we
are
like.
There
are
technical
reasons
why
it
just
doesn't
work.
C
D
C
So
I
had
just
two
thoughts:
one
was:
if
oh
am
I
my
up.
Sorry,
I
had
two
thoughts.
One
was
I
I'm.
I
kind
of
feel
like
miles,
I'm
like
maybe
minus,
like
minus
zero
on
this.
Just
because,
like
the
more
complex
exports
gets,
I
feel
like
the
harder.
It
is
then
for
bundlers
and
other
tools
to
like
mimic
how
it
works,
as
I'm
sure
jordan
could
talk
about.
C
So
I'm
a
little
concerned
about
that,
but
not
so
much
so
that
like
if
this
really
you
know,
improves
a
lot
of
people,
then
sure
we
should
add
it,
and
then
the
complexity
is
worth
it.
The
other
thing
I
would
say
is:
I
don't
think
this
is
just
for
extensions
like
this,
isn't
just
so
that
I
can
have
lots
of
paths
without
extensions.
It's
also
any
type
of
mapping
like
if
I
have
you
know
a
slash
disk
folder
and
inside
there
I've
got.
C
You
know,
500
files
that
follow
some
format.
I
might
want
to
do
like
left
hand,
side,
star.js,
right
hand,
side,
you
know
dot,
slash,
disk,
slash,
star.js
or
something
like
that,
and
you
know
that
wouldn't
like
an
extension
map,
wouldn't
help
with
that.
That
would
only
help
me
like
get
rid
of
extensions,
so
I
think
that
the
the
goals
of
this
are
broader
than
just
you
know
getting
rid
of
extensions.
It's
it's
more
of
a
lot
more
along
the
lines
of
making
whatever
kind
of
pretty
specifier
you're
aiming
for.
B
B
The
exports
field
provides
a
virtualization
of
the
package,
you're
you're,
creating
a
sort
of
a
virtualized
view
of
the
file
system,
and
this
was
enabled
the
moment
that
we
made
exports,
not
just
a
listing
of
the
public
files
in
the
package,
but
a
custom
mapping
of
those
specifiers
and
and
the
moment
we
did
that
exports
was
no
longer
just
hey.
Only
these
files
are
exported.
Like
an
array
of
list
of
them.
B
It
became
an
actual
mapping
system
and
so
a
virtualization
space
and
to
to
speak
to
jeffrey's
case
one
one
example
of
a
sort
of
a
mapping
that
would
be
larger
than
just
a
file
extension
mapping
could
be
something
like
say.
You
have
a
a
pattern
where
you
have
like
a
components
folder
and
in
the
components
folder.
You
have
a
naming
system
like
you
call
each
component
like
node
component.js,
and
then
you
have
also
like
browser
component.js.
B
So
if
you
wanted
a
mapping
for
that
one,
one
mapping
could
be
like
components:
star
maps
to
sorry,
I'm
just
writing
it
out.
It'll
appear
shortly.
B
So
I
just
want
to
give
give
an
example
of
how
you
can
actually
use
it
to.
Firstly,
how
how
it
can
work
well
with
conditional
exports
and
then
also
how
the
naming
actually
can
be
more
than
just
extensions.
B
B
So
so
that's
an
example
of
how
these
things
kind
of
play
together.
So
so
you're
getting
compatibility
with
conditional
exports
and
compatibility
with
custom
naming
schemes
either
with
conditional
exports
or
otherwise
I
mean
we
could
have
called
it.
No
dash
component
name
without
it
being
a
conditional
export
as
well,
but
just
to
give
an
idea.
E
Mean
expanding
on
what
guy
said,
we
do
have
a
variety
of
packages
internally
at
godaddy,
which
do
have
similar
conventions
where
we
have
directories
for
components
and
they
each
are
named
after
the
kind
of
component
that
they
are
and
they
contain
an
index
file
in
them.
E
E
It
would
still
allow
us
to
have
specific
react,
native
and
particular
conditions
that
would
reroute.
B
And
in
terms
of
the
sort
of
static,
dynamic
question,
what's
what's
worth
bearing
in
mind
is,
is
when,
when,
in
the
past,
spoken
about
a
completely
static
mapping
based
on
configuration
that
is
maintained
by
this,
all
you
need
is
the
configuration
and
the
specifier,
and
you
can
work
out
what
it's
going
to
map
into
you
don't
have
to
look
at
the
file
system.
You
don't
need
to
stat
anything.
You
don't
need
to
read
anything
else.
B
You
don't
need
to
read
another
see
if
any
file
exists,
you
don't
need
to
see
if
a
package
json
exists
with
just
the
configuration
and
the
original
package
specifier,
you
know.
Okay,
it's
definitely
going
to
be
this
file
within
the
package,
that's
being
loaded,
so
it's
a
direct
static
mapping.
B
A
So
I
guess
a
request
that
that
I
could
make
here.
I
think
something
seeing
these
specific
use
cases
that
both
guy
and
brad
have
brought
do
make
me
feel
a
little
bit
more
comfortable.
A
I'm
still,
I
still
have
like
just
complexity
and
magic
in
general
makes
me
queasy,
although
I
see
this
as
more
complexity
than
magic
with
these
specific
examples,
I'll
review
the
pull
request
again
and
I'm
going
to
make
a
request
right
now,
which
may
already
be
there
so
apologies,
but
I
think
documenting
these
use
cases
potentially
even
having
a
couple
of
example.
A
Repos
that
show
like
the
file
structure
and
explain
like
how
it
would
be
consumed
would
be
very
useful
here,
not
just
for
like
not
just
for
kind
of
teaching
the
complexity,
but
also
for,
like
kind
of
instilling
some
best
practices
about
how
to
use
this.
I
guess
one
one
question
that
I
do
have.
I
have
to
dig
up
the
pull
request
again,
but
there
was
a
comment.
A
Let
me
see
if
I
can
dig
it
up
here
from
from
sakura
and
in
particular
he
was
asking
about
the
relationship,
oh
god,
that
was
the
wrong
copy
paste.
One
second
here
I
pressed
the
wrong
button
here
we
go
so
is
is
from
sakura
from
about
a
week
ago.
A
I
would
favor
this
feature
instead
of
directory
export
ending
with
slash,
since
it
does
not
require
dynamic,
resolving
based
on
directory
content,
it
would
be
cool
to
deprecate
directory
exports
and
fi
in
favor
of
wildcard
exports,
guy
and
and
brad
as
the
two
who
seem
to
be
the
most
bullish
on
this
feature.
A
How
do
you
feel
about
that
particular
request?
It
does
seem
like
something
that
folks
from
the
tooling
ecosystem
would
would
be
plus
one
on.
B
Some
very
large
packages
have
do,
though
that's
the
thing.
The
biggest
issue
is
static,
breaking
change.
What
we,
what
we
could
possibly
do
is
is
effectively
the
soft
deprecation
of
the
directory
exports
and
say
it's
encouraged
to
do
an
then
do
a
process
of
next
major
introducing
explicit
warning
major,
finally
deprecating,
but
I
don't
think
we
can
realistically
remove
it
at
this
point.
We
could.
A
Do
a
runtime
deprecation
like
printing
a
warning
in
15
and
remove
it
in
16.
B
The
the
other
concern
there
is
that
if
an
old
package
is
published,
you
can't
expect
a
package
to
change
like
that's,
that's
a
lot
of
the
problem
with
this
stuff,
and
then
you
end
up
with
you
know
back
to
that
old
story
of
pages
of
warnings,
just
because
you
happen
to
be
using
some
old
packages,
but
I
think,
as
a
rule
like
in
the
notepads
ecosystem,
just
because
a
package
hasn't
updated
in
a
year
doesn't
mean
that
you
should
get
a
page
of
warnings
just
for
for
using
it,
and-
and
so
that
would
be
my
concern
with
trying
to
push
something
out
there
too
too
quickly.
B
A
I
mean
we
could
do
a
doc
deprecation
as
well.
Follow
like,
like.
I
just
think
the
the
general
way
we've
done
things
in
node
and
we
could
do
this
for
15
is
we
could
introduce
a
runtime
warning
in
15
and
if
people
get
pissed
enough,
we
remove
it,
but
if
we
land
this
wild
card
feature
prior,
I
think
adoption
is
still
early
enough.
B
We
should,
since
we've
got
well-defined
package
scopes,
maybe
it's
time
to
start
thinking
about
having
warnings
that
only
apply
to
local
code
versus
node
modules
code,
because
if
we
can
do
that,
then
you
could
say:
hey
your
local
package
is
doing
this.
You
should
fix
it
and
it's
definitely
your
code,
so
you
can
do
it
yeah
and
we.
A
Acquire
other
things
we
have
prior
art
for
that,
as
well
with
with
the
buffer
deprecation.
A
So
we
could
always
just
put
like
a
package
scoped
deprecation
warning
for
using
directories
with
slashes,
and
we
could
leave
that
for
a
very
long
time,
but
at
least
would
make
it
really
annoying
for
the
package
authors
and
then
they
would
have
an
alternative
that
they
could
use.
The
other
thing
that
soccer
asked
for
was
potentially
a
different
symbol
rather
than
star,
because
it
might
be
conflict
confused
with
globs
and
I'll
be
honest,
like
I
have
had
a
hard
time
thinking
of
this
proposal,
not
as
globs.
E
B
D
I
mean
we
could
you
could
imagine
instead
of
a
string,
you
have
an
array
and
every
segment
in
the
array
is
a
star
implied.
So
you
just
put
your
chunks,
I
don't
know
you
like.
You
can
come
up
with
something
that's
more
than
just
a
string
and
like
it
would
be
harder
to
figure
out,
but
it
would
not
be
red
jexy.
B
Yeah,
I
I'm
completely
open
to
these
kinds
of
suggestions.
I
I
mean
I
said
it
said
in
the
original
part.
Pr,
like
I'm
open
to
semantic
changes.
Maybe
if
people
want
to
pick
up
these
discussions
in
the
pr
itself,
we
can
continue
to
work
through
some
of
these
technical
details.
A
Okay,
so
so
I
think
maybe
that
seems
good
to
me.
I
think,
like
the
one
thing
are
the
two
things
that
that
we
need
to
consider
here
from
a
timing
perspective,
though
december
major
cutoff
for
note
15
is
coming
up
in
a
couple
weeks,
so
I
I
think
that
if
we
want
to
land
this,
and
if
we
wish
to
do
a
runtime
deprecation
of
of
slash,
we
need
to
do
the
runtime
deprecation
before
december
major
cutoff.
Probably
we
can
maybe
like,
and
I
can.
A
Although
this
we
we
may
just
decide,
hey
we're
not
really
there
for
12
12
is
about
to
go
into
maintenance
mode,
so
we're
kind
of
we're
about
to
miss
the
the
train
on
being
able
to
make
any
large
changes
to
12
at
all,
which
might
be
fine.
But
it's
worth
it's
worth
being
aware
of
that.
A
And
I
get
I
guess,
guy
to
you
to
like
kind
of
speed
this
up.
I
think
that
a
plan
that
includes
at
the
very
least
a
dock
but
potentially
a
runtime
deprecation
to
the
directories,
consensus
around
the
wild
card
and
slightly
more
in-depth
documentation
of,
like
example,
use
cases,
would
flip
my
bit
from
like
a
minus
zero
to
a
plus
zero
and
perhaps
even
a
plus
one.
B
Great
I'll
follow
up
on
those.
B
All
right,
we've
already
used
up
most
of
our
time.
The
the
next
one
is
another
issue
we
have
discussed
in.
In
the
past
few
meetings
repeatedly
the
package.json
file
resolution.
Has
there
been
any
progress
on
that?
Does
anyone
want
to
discuss
this.
A
A
I
guess
one
of
the
things
there
also,
and
maybe
we
could
dig
into
this
a
bit
more
is
like,
while
some
people
have
been
frustrated
by
this
have
not
like
it's
kind
of
it
flared
up
and
then
it
was
chill
and
then
it
kind
of
like
flares
up
when
someone
new
realizes
that
it's
a
pain
and
a
package
breaks
and
then,
like
the
package,
adds
package
json
to
the
export
map,
and
then
people
forget
about
it
until
the
next
time
it
breaks
someone.
A
So
I
don't
know
if
people
are
like
super
clamoring
for
this
api
jordan.
I
know
you
had
some
specific
thoughts
on
it.
Please
let
me
know
if
you
think
I
miscount
characterized
it
there.
D
A
D
D
A
D
Yeah,
so
I
guess
that's
a
good
point,
so
there's
not
actually
a
time
crunch
on
it,
but
yeah.
I
think
that
the
the
sooner
we
can
get
it
into
14,
the
better
it
you
know
would
even
be
nice
to
be
able
to
backport
it
to
12..
I
don't
know
what
the
timing
is
for
that,
but
I
think
there's
a
little
while
left
there
right.
D
E
E
D
D
D
D
Correct-
and
this
will
not
change
that
this
api
does
not
give
you
the
package
json
contents,
as
currently
discussed
it
gives
you
I
mean
we
could
do
that,
but
it
I
believe
the
intention
at
the
moment
is
to
have
it.
Give
you
the
path
to
the
directory
that
contains
the
package
json,
and
then
it's
still
up
to
you
to
use
file
system
methods
to
get
to
it.
A
I
guess
the
I
guess
that
is
only
partially
true,
and
I
believe
that
I
could
be
wrong
that
if
you
use
require
and
the
full
path
to
the
file,
that's
never
that's
using
a
relative
path.
That's
never
hitting
the
package
exports
resolution
algorithm.
There
would
be
no
way
to
prevent
that.
Yes,
this
would.
E
D
A
E
To
my
knowledge,
yes,
but
we
already
have
people
in
the
ecosystem
doing
that
and
package
exports
are
only
scope
to
bear
specifiers.
We
shouldn't
be
trying
to
expand
their
scope
in
this
pr
right.
A
A
D
All
the
tools
for
all
the
bundlers
that
need
resolution
tools,
you
need
to
be
able
to
read
package.json
to
do
what
node
does
and
resolve
it,
and
on
top
of
that,
it's
like
you
could
argue
anything
as
part
of
the
api
contract,
but
the
I
think
that
if
you
have
an
exports
field
and
something's,
not
in
that
field,
it
is
explicitly
not
part
of
the
api
contract,
and
even
I
who
still
supports
node
0.6,
would
not
consider
any
anything
breaking
if
it
messed
with
something
outside
of
that
exports
field.
I.
A
Get,
I
guess
what
I
would
I
guess.
What
I
would
say,
though,
is
I'm
not
a
hundred
percent
convinced,
and
I'm
not
saying
we
shouldn't
make
this
api,
but
I'm
not
100
convinced
that
this
is
not
a
hundred
percent
doable
in
user
land
via
a
module
like
resolve.
If
all
we're
talking
about
is
like
hey,
if
I
have
a
dependency,
that's
in
my
package,
json,
that's
a
top
level
dependency.
The
root
folder
will
literally
always
be
node
modules,
slash
that
folder
relative
to
the
file
at
which
I've
I've
required
it
from
or
imported
it
from.
A
And
we'd
be
guaranteed
that
it
would
be
at
the
top
level.
So
it's
like
I'm,
I'm
not
100,
convinced
that,
like
we
need
this
api
inside
of
core,
because
it's
not
like
such
a
complex
thing
that
you
need
internal
access
to
the
runtime,
to
figure
it
out
reliably
and
consistently.
D
I
mean
so
that's
a
fair
point
and
perhaps
it
would
be
possible
then,
to
write
a
user
land
module
to
do
this.
I
I
think
that
the
the
benefit
here,
though,
isn't
just
we're
not
trying
to
give
a
capability
to
tooling
what
we're
trying
to
do
is
get
user
land
adoption,
because
we
we
don't
want
package
authors
to
feel
pressured
to
included
packet,
include
package
json
in
their
exports.
Nor
do
we
want
like
them
to
feel
pressured
to
not
use
exports
at
all
like
we
we
want.
D
We
could
try
and
advocate
that
they
use
my
package
but
like
that
people
are
a
lot
less
willing
to
add
a
dependency
or
to
add
a
dependency
that
has
a
single
maintainer
and
so
on,
like
than
they
are
to
just
use
something
that's
in
node
core,
and
I
think
that
in
this
case
the
goal
is
not
restricting
the
capability.
The
goal
is,
is
adopting
it
so
that
we
can
keep
exports
clean
of
package.json
so
like
so
I
hear
you.
Maybe
maybe
it
is
not
a
like
capability
that
node
must
add,
but
it
like
it.
A
E
So
that's
not
true
for
common
js.
Unfortunately,.
B
Checked
we
likely
only
have
time
for
one
more
item
on
the
agenda.
We
try
and
wrap
this
one
up
within
the
next
minute
or
so.
A
A
B
Okay
yeah.
I
just
like
to
get
get
to
this
next
item
quickly.
While
we
still
have
time
because
it's
it's
an
important
one-
the
exports
detection
for
commonjs
I've
updated
the
pr
to
support
the
patents
for
star
exports,
and
we
also
had
an
out-of-band
meeting
with
gus,
where
he
basically
said
that
he
he
would
be
happy
if
we
could
get
95
of
packages
supporting
the
correct
set
of
named
exports
within
whatever
we
decide.
B
Should
you
know
so,
whatever?
Whatever
we
decide
should
be
the
the
support
criteria,
as
it
were
that
in
that
criteria
we
should
get
95
and
four
packages
by
restricting
to
packages
that
are
exporting
the
es
module
flag,
so
predominantly
transpiled
modules,
and
then,
with
the
new
work
on
export
support,
I
managed
to
get
the
support
on
the
test
packages
that
jeffrey
was
running
from
about
89,
so
I
believe
around
95
percent.
B
We
still
need
to
confirm
the
exact
numbers
which
seems
like
it
will
actually
solve
block
to
me,
so
I
think
it
looks
likely
that
we
have
overcome
his
block.
We
still
need
to
get
final
confirmation
on
that,
but
assuming
that
we
can
move
towards
that
at
a
band,
does
anyone
any
other
thoughts
on
this
named
exports
problem,
any
other
concerns,
or
would
people
be
okay
for
it
to
land
between
meetings?
Does
anyone
have
any
questions
about
the
approach,
the
implementation,
the
details
of
the.
B
B
B
I
was
just
saying:
does
anyone
have
any
further
clarifications
feedback
questions
points
for
points
against,
or
is
this
something
that
we
want
to
continue
outside
of
the
meeting
process
and
separately
move
towards
merging.
A
I
guess
I
could
add
a
statement
of
support.
I
think
the
way
in
which,
right
now,
we
have
scoped
to
modules
that
have
metadata
in
them
that
explicitly
imply
that
they
are
transpiled.
Modules
that
were
like
meant
to
target
multiple
environments
makes
me
feel
a
lot
more
comfortable
about
it.
It
unlocks
use
cases
that
we
hadn't
talked
about
before
about
essentially
being
able
to
support
named
exports
from
a
umd
module,
which
is
a
very
valid
format
to
want
to
publish
in.
If
you
want
to
be
able
to
have
a
single
output
file
support
multiple
runtimes.
A
I
think
that
if
we
can
hit
that
level
of
95
percent
with
those
heuristics,
I
I'm
personally
in
support
of
landing
this,
and
it
also
doesn't
mean
that
we
don't
continue
to
do
research
about
other
ways
to
continue
to
improve
this
notice,
a
project
that
improves
things
all
the
time.
I
think
that
this
is
a
very
nice
carve
out
and
scope
that
improves
the
status
quo
and
potentially
also
supports
a
lot
of
existing
transpiled
modules
on
npm
that
may
or
may
not
actually
get
updated
in
in
a
very
accurate
way.
D
So
I
just
want
to
clarify
if
I
currently
am
importing
default
from
one
of
these
modules.
What
happens
when
this
pr.
B
Lands,
so
what
we're
currently
discussing
is
that
it
will
continue
to
behave
exactly
the
same,
and
this
is
a
divergence
from
transpilers,
because
transpilers
will
expect
that
default
to
be
the
default,
export
or
undefined.
If
there
was
nothing,
but
we
are
specifically
discussing
maintaining
this
invariant.
B
E
I
just
want
to
say
that
that
seems
reasonable
to
me.
It
means
that
using
this
isn't
a
breaking
change
also.
I
just
am
skeptical
that
a
lot
of
packages
are
mixing
default
and
named
exports,
and
if
you
are
doing
default
with
transpilers,
it
already
is
very
confusing
and
you
have
to
use
default.
Sometimes.
A
I
guess,
like
one
thing
that
we
could
maybe
do
there
potentially
would
be
in
the
cases
of
like
a
default
conflict.
Like
the
example
I
would
give
would
be.
A
transpiled
module
has
a
default
export,
but
we're
exporting
the
name
space.
Maybe
we
could
give
it
clear
warning
potentially
scoped
to
the
package
that,
like
hey,
we've
done
this
because
for
legacy
purposes
of
how
node
works,
but
it's
possible,
but
like
the
package
that
you're
importing
has
a
name
default
that
you,
you
may
not
be
getting
exactly
what
you're
expecting.
E
I'm
very
wary
of
that.
So,
if
you
look
in
the
wild,
a
lot
of
people
make
a
transpiler
output
that
has
the
default
export
explicitly
point
to
the
name
space
on
purpose,
to
get
other
tools
to
work
with
it.
It
it's
frequent
enough
that
I
know
it's
in
the
wild,
so
I
think
a
warning
would
just
be
too
common.
A
B
So,
just
to
talk
about
the
kind
of
practical
process
to
land
there
there's
a
few
things
that
that
need
to
be
done.
I
tried
to
embed
it
as
native
code.
Unfortunately,
the
the
native
changes,
because
they
were
sort
of
binary
breaking
it
was
too
much
it
see.
It
seemed
like
a
lot
of
riverhead
and,
in
addition,
the
c
code
needed
a
lot
of
refactoring.
B
We
also
need
to
finalize
the
metrics
and
the
numbers
and
then
move
towards
getting
direct
approval
from
gus,
and
so
it's
still
going
to
be
a
little
bit
of
a
process,
but
I
guess
the
main
thing
is
just
if
we
continue
to
make
those
steps
that
we
have
the
support
of
the
group
and
if
anyone
has
any
remaining
concerns
to
to
say
now,
otherwise
we
will
continue
to
try
and
move
this
forward
in
the
in
the
pr
and
and
and
move
towards
landing
it.
We.