►
From YouTube: Node.js Foundation Modules Team Meeting 2018-12-05
Description
A
A
I
had
a
playing
in
the
background,
so
we've
got
a
feedback
loop.
Okay,
things
are
going
great
today,
so
we
have
a
slightly
shorter
agenda
than
usual
today,
which
is
going
to
give
us
some
time
to
dig
into
some
meteor
topics,
so
we're
gonna
get
started
with
the
first
item
on
our
agenda,
which
is
locking
down
the
process
and
buffer
Global's.
Would
anyone
like
to
lead
the
discussion
on
this
topic?
A
C
I
can
introduce
this
one.
Okay,
thank
you
guy
sure.
So
I
was
just
looking
so
something
that
I've
tried
to
do
before,
and
I
wasn't
able
to
do
successfully
because
of
some
performance
issues
was
to
try
and
remove
the
process
and
buffer
Global's,
which
are
both
available
as
Global's
in
ES
modules,
by
default,
when
we
run
es
modules
in
node,
and
if
you
look
at
those
objects,
they
give
a
lot
of
capabilities
that
we
don't
necessarily
want
in
the
future
of
modules,
to
be
giving
to
every
single
module.
C
One
thing
you
can
think
about
with
modules
is
as
we're
bringing
more
and
more
security
principles
to
JavaScript
developments
is
you
can
actually
start
to
lock
down
what
what
you
can
access
from
inside
a
module
and
the
global
is
obviously
the
tricky
area
where
we
can't
really
lock
that
down
and
right
now
on
through
those
Global's,
you
can
access
process
and
through
process
you
can
access
process
type
bindings.
You
can
get
access
to
all
the
native
bindings.
You
can
get
access
to
high
resolution
timers
and
so
from
a
kind
of
a
security
perspective.
C
C
D
So
I
in
general
think
buffer
is
a
weird
thing
to
be
global,
like
I
like
the
idea
of
not
making
it
having
it
be
a
global
I
like
the
idea
of
limiting
the
privilege
granting
things
that
are
on
process
from
being
globally
available.
I
have
a
few
concerns.
One
is
I
think
the
existence
of
process
is
critical
in
all
code,
because
people
use
it
for
platform
protection,
not
all
the
things
on
process,
but
the
object
itself,
and
probably
a
few
of
the
things
so
I,
don't
think
it's
reasonable,
I
think
I.
D
Think
a
better
approach
for
process
would
be
to
look
into
moving
the
dangerous
parts
off
of
it.
Instead
of
looking
into
getting
rid
of
the
whole
object
and
then
the
secondary
concern
or
the
not
secondary,
but
the
next
concern
is
I
really
think
it's
not
a
good
idea
to
try
and
be
opportunistic
about
ESM
as
a
way
to
allow
you
know
alleged
mistakes
to
be
corrected.
I
I
think
that
it's
totally
accurate
I
think
that
if
there
are
mistakes
we
want
to
clean
up
that
cleaning
them
up
prior
to
shipping.
D
Like
like,
if
we're
trying
to
look
into
restricting
module
capabilities
that
something
that
works
for
that
is,
gonna
have
to
work
for
CJ,
s2,
I
think,
or
at
least
it's
gonna
have
to
be
thought
out
for
how
it
works
for
CJ,
s2
and
I.
Don't
think
that
that
we
should
be
trying
to
leverage
yes
and
the
STS
M
initiative
to
try
and
do
things
that
aren't
actually
directly
related
to
ESM
so
like
I'm,
in
support
of
what
you're
trying
to
do
and
why
and
I
think
that's
it's
an
apt
time
to
be
talking
about
it.
D
A
D
A
Yeah
and
to
add
to
that,
you
know
like
as
long
as
we
have
interoperability
between
CJ
s
and
DSM
like
that,
can
easily
be
a
backdoor
to
doing
all
of
this,
like
there's,
no
reason
why
someone
couldn't
make
a
common
J
s,
module
that
simply
exports
the
process
object,
and
then
we
import
that
so
I
think
there
there
is.
There
is
some
concern.
What
I
think
may
be
an
interesting
splitting
of
the
difference
here
that
we
may
need
to
work
towards
is
what
are
the
things
that
people
are
using?
A
The
process
object
for
what
are
the
bits
from
that
that
people
actually
want
from
an
API
perspective
and
maybe
start
trying
to
transition
some
of
those
api's
out
of
the
process
object
into
their
own
individual
api's,
and
then
we
could
slowly
deprecated
the
process
object
itself
in
both
runtimes
now
I.
Don't
think
we
really
ever
could
do
that
in
CJ
s
because
of
all
of
the
code
that
relies
on
process.
A
D
F
Yeah,
okay,
so
I
want
to
mention
about
buffer
I
I
couldn't
find
it
but
I
know.
Maybe
someone
else
here
has
been
around
long
enough
would
recall.
I
think
there
was
some
discussion
at
some
point
that
we
tried
to
deprecate
that
as
a
global
and
I
think
it
didn't
work
out,
or
maybe
someone
investigated
if,
if
it
would
be
feasible
to
it,
really
shouldn't
be
a
global,
but,
like
everything
depends
on
it,
you
have
a
similar
problem.
A
process
like
removing
things
from
process
is
exceedingly
difficult
to
do,
because
so
much
tougher
relies
on
that.
F
I
think
we
would
probably
want
to
be
care,
like
so
I'm,
not
sure
I'm,
not
really
sure.
If,
if
we
were
removing
both
saying
sorry,
if
we
were
moving
things
from
process
in
both
environments,
I
think
that
would
be
well.
It
would
take
a
really
long
time.
There's
no
guarantee
you'd
be
able
to
be
done
if
we
do
it
separately.
For
yes,
modules,
I
think
that's
gonna
be
confusing.
F
F
A
C
B
Yeah,
you
were
talking
about
the
impact
of
people
who
were
already
writing
the
ESM
that
webpack
in
Babylon
5
script,
use
and
meeting
to
migrate
to
all
of
the
changes
that
we
build
in
TSM,
because
we
decide
it's
an
opportune
time
to
build
in
changes
for
some
reason
like
80's
extra
work
like
any
migration
like
because
they
think,
on
top
of
needing
to
migrate
off
of
their
tool
chain.
They'll
also
need
to
migrate
to
all
of
the
new
api's
and
all
the
other
decisions
we
make.
B
If
you
want
to
make
people
do
big
brain
migrations
where
they
need
to
migrate,
50
things
at
once,
then
sure
you
can
do
it,
but
I,
don't
think
a
lot
of
people
want
to
do
that
kind
of
stuff,
especially
if
it's
not
something
that
actually
gets
them
benefit
in
any
way
and
just
cleans
up
an
API
most
people
don't
care
how
clean
api's
are.
That's
just
what
it
is.
C
What
it's
worth
the
upgrade
path
is
adding
to
imports
in
the
top
field:
module
yeah,
so
I
am
fairly
optimistic
about
the
upgrade
path.
I
think
that
it'll
I
mean
the
amount
of
code
that
I've
seen
that
uses,
processing,
galuf
and
buffer
I,
don't
know
of
any
examples
where
vs.
and
buffer
are
accessed
directly
of
the
global,
so
I
think
any
deprecation
warning
would
affect
a
percent
of
a
percent
of
code
in
the
common
areas
case.
C
C
Was
I
saying
yes,
I'm
fairly
optimistic
about
it
and
I?
Guess
the
sorry
forget
what
the
other
point
was
there
I'm
sure
to
come
back
to
me,
but
oh
yeah,
so
vote
for
the
vote
for
the
the
cases
where
we're
doing
environment
detections
processed
our
environment
know
the
environments
yeah.
We
definitely
need
a
replacement
for
those
workflows,
so
I'm
interested
to
hear
what
people
think
are
useful
workflows,
and
this
is
probably
the
discussion
we
need
to
be
having
anyway.
C
How
do
we
want
people
to
be
doing
conditional
loading
between
browser
and
well
I
guess,
process
that
environment
under
the
environment
is
mainly
for
choosing?
Are
you
in
production
or
you
in
developments?
How
do
we
want
users
of
these
modules
in
those
who
note
whether
they're
in
production
or
developments?
You
know
if
we
do
deprecated
the
process
level,
it
could
be
import
process
and
then
check
that
or
do
we
want
to
put
something
on
import
done?
A
A
I
think
it
would
be
something
that
would
be
great
to
eventually
put
on
the
docket
here,
but
I
had
a
recent
conversation
with
Dominic
Nicola
about
namespaces
as
well,
and
one
of
the
things
that
can
become
really
interesting
about
namespaces
is
if
we
have
like
a
node.js
namespace
inside
of
cor,
that's
where
we
could
be
putting
things
that
could
be.
Arguably,
you
know
generally
on
a
global.
A
Think
that
there's
a
larger
platform
question
that
involves
more
stakeholders
than
we
have
in
the
meeting
right
now
about
how
this
actually
could
become
a
pattern
with
within
the
JavaScript
ecosystem.
You
combine
it
with
something
like
import
Maps,
for
example,
where
we
could
use
an
import
map
to
shim
the
node.js
module
system
echoes
the
node.js
namespace
when
you
import
something
from
the
node.js
namespace
in
the
browser,
and
this
could
all
work
without
build
steps
which
could
be
really
interesting.
You
know
the
semantics
of
how
we
implement
it.
A
So
Wes
with
your
thing
for
built-ins,
yeah
I,
think
that's
something
that's
going
on
at
tc39
as
well,
but
I
think
that,
where
did
the
debate
there
is
about
built-ins
would
be.
It
may
not
actually
make
sense
for
there
to
be
built-ins
that
are
part
of
ECMO
6.
But
there
already
are
built-ins
and
note
there
already
are
built-ins
in
the
web
and
all
the
what
working
group
api's
that
are
just
essentially
tagged
on
to
the
global
could
all
be
essentially
thought
of,
as
built-ins.
D
Is
something
that
many
people
want
for
many
reasons
and
have
wanted
for
many
years
and
are
very
excited
about
recently?
There
was
the
first
concrete
proposal
for
it,
which
is
the
one
that
was
linked
in
the
chat
and
that's
stage
one
at
the
moment.
It
just
means
tc39
will
continue
to
look
into
the
issue,
but
there's
nobody
has
yet
figured
out.
D
Basically
how
how
that
could
work,
because,
because
anything
that's
built
in
has
to
allow
for
poly,
filling
and
shimming,
meaning
like
adding
missing
implementations,
but
also
repairing
and
replacing
broken
ones,
and
also
deleting
or
denying
access
to
like
things
that
they
don't
want.
So
like
it's
very
critical
that
you
were
able
to
like
add
flat
map
to
a
radar
prototype
and
it's
very
critical
that
we're
able
to
like
replace
object
out
a
sign
for
the
lake.
There
was
a
period
of
time
where
a
bunch
of
browsers
implemented
it
incorrectly.
A
D
It's
also
important
that
we're
able
to
like
delete
date
now
for
environments
where
you
don't
want
to
provide
the
time
for
security
reasons
so
like
these
are.
All
of
these
things
have
to
be
supplied.
There
have
to
be
addressed
somehow
in
order
for
built-in
modules
to
be
a
thing,
and
no
one
has
yet
that
I've
seen
come
up
with
an
idea
that
can
so
it's
not
to
say
it's
possible,
but
I
would
not
rest.
Our
hopes
on
that.
Nor
would
I
expect
that
to
happen
anytime
soon,.
A
A
Perhaps
this
is
something
that
we
could
start
working
towards
and
getting
different
stakeholders
and
start
getting
people
on
board.
Then
maybe
we
could
have
like
a
day
of
the
summit
around
some
of
these
cross
platform
concerns
at
our
collaborate
or
summit.
Just
before
J
s,
coffee,
you
guy,
you
had
your
hand
up.
Did
you
want
to
add
one
more
thing
before
we
move
on
to
the
next
item?
No.
C
It's
just
gonna
say
that
I
mean
in
terms
of
the
scope.
The
I
I
feel
like
that.
The
way
that
the
discussions
played
out
there,
a
lot
of
people
were
saying.
Well,
let's
just
get
the
discussion
going
on
no
warrant
and
I
tend
to
agree,
and
it
isn't
necessary
really
something
that
the
modules
group
needs
to
focus
on
explicitly.
I
was
just
hoping
that
you
know
just
to
get
some
kind
of
support
for
for
thinking
of
module
security.
A
C
C
Yeah
the
the
response
he
said
you
know
it
was
that
there
were
still
some
questions
about
some
of
the
behaviors,
so
they
had
a
break
up
breakout
group
on
the
last
day
and
got
back
with
some
feedback
on
on
the
spec,
and
the
main
question
was
to
do
with
the
fact
that
if
you
have
export
star
syntax
re
exporting
from
a
dynamic
module
that
it
might
cause
issues
where
you
have
unknown
export
names
in
ES
modules.
During
during
that
circular,
reference
phase.
A
We
have
two
more
agenda
items
after
it
after
this
one
is
the
specify
import,
specify
resolution
proposal
and
the
had
package
export.
So
how
much
time
do
you
need
for
discussing,
like
maybe
15
minutes,
for
the
import
file,
specify
our
discussion
and
then
yarn?
How
much
time
would
you
need
for
the
add
package,
exports
discussion.
E
C
C
Proposal
and
then
deals
with
the
the
main
difficult
case,
which
is
the
dynamic
namespace
problem,
which
is
this
example
here,
where
you
have
a
common
J's
file
that
exports
a
name
and
you
need
to
export
it.
You
have
to
execute
that
common
J's
file
to
know
what
those
names
are
and
if
you
have
the
cycle
between
main
one
and
main
to
where
the
execution
order
will
end
up
being
that
main
to
execute
first,
because
it's
in
a
cycle
with
main
one,
so
we
execute
main
two
first,
then
we
execute
C
J's.
C
It
has
no
exports
in
that
cycle
case.
That
is,
extensible
property
returns.
True,
you
can't
write
to
it
and
then,
as
soon
as
that,
common
J's
module
gets
executed
here
and
it
sets
the
the
value
of
the
common
J's
module.
Was
the
name
export
equal
to
value,
and
it
knows
the
export
name.
Then
it
adds
all
the
exports
on
to
that
namespace
object
and
locks
it
as
is
extensible
false.
C
Could
we
just
ban
star
exports
from
dynamic
module
namespaces
entirely,
so
that
would
basically
be
the
if
I
tried
to
do
export
star
from
CJ
SJS.
Here
you
get
an
error
in
in
the
actual
JavaScript
that
didn't.
That
would
say.
You
cannot
star
e
export
from
the
dynamic
module
CJ,
yes
in
in
main
one,
and
that
was
what
tc39
were
asking
for,
because
they
said
it's
fine
to
have
all
these
namespaces
to
behaviours.
C
But
if
it
is,
you
know,
then
stability,
NCS
modules
as
well,
where,
if
you
have
a
cycle
with
main
one,
you
don't
know
its
exports
on
the
namespace
so
that
that
was
what
he
said
he
nine
were
asking
for
and
that
seemed
very
reasonable
to
me.
I,
don't
think
it
seems
like
a
huge
loss
to
lose
this.
You
can
still
do
named
exports,
so
you
can
do
export
name
from
Comcast
or
you
can
list
the
names
and
you
can
still
do
the
namespace
import.
C
You
just
won't
be
able
to
do
star
e
exports
from
common
J's
modules.
Basically,
so
that
will
be
the
one
restriction
and
then
tc39
burrow
open
to
extending
that
restriction
over
time,
for
example,
if
you're
not
in
a
cycle,
then
you
know
if
we've
already
executed
CGS,
we
know
all
its
exports.
So
there's
no
reason
why
this
can't
work.
So
we
could
potentially
then
come
back
to
those
use
cases
and
open
them
up,
but
the
initial
idea
was
to
just
lock
that
down,
so
that
was
more
or
less
the
feedback.
C
C
C
Right
now,
in
a
cycle
you
can
access
a
namespace
of
a
module
that
hasn't
executed,
but
that
namespace
object
will
have
all
the
exports
of
that
module
because
exports
in
ES
modules
and
statically
analyzable.
So
you
know
all
the
export
names
of
a
given
module
before
execution.
Common
J's
modules
are
different.
We
don't
know
the
export
names
before
execution.
We
only
know
the
explore
names
after
execution.
A
So
the
question
that
I
was
gonna
bring
up
was
just
kind
of
about
the
order
of
operations
in
which
this
was
gonna
happen.
So
if
I
recall
and
then
guide,
please
correct
me,
but
we
had
talked
about
before
was
like
tc39
was
kind
of
saying
that
they
would
do
it.
If
v8
would
do
it
and
be
able
to
do
it,
if
node
would
do
it
or
was
it
in
the
other
direction?
A
Sorry
can
you
just
say
that
again,
so
we
have
kind
of
have
an
order
of
operations
here.
You're
like
we
need
this
change
to
be
adopted
by
tc39
and
in
turn,
then,
for
it
to
exist
in
node.
We
need
it
implemented
in
v8
right,
which
I
believe
you
have
a
CL,
which
in
turn
also
requires
some
sort
of
consensus
in
node.
So
if
I
recall
correctly,
I
think
v8
was
waiting
for
kind
of
like
tc39
to
say
that
they
would
allow
for
this,
but
I
think
for
all
of
that
to
happen.
A
C
C
The
goal
has
been
to
get
tc39,
to
give
provisional
approval,
to
get
d8
to
say
that
if
node
wants
a
deal,
merge
it's
and
then
for
us
to
then
have
the
final
say.
And
then,
if
we
want
to
go
ahead,
we
can
go
to
v8
and
say
we
want
this
and
then
v8
can
go
to
tc39
and
say:
let's
merge
this
into
equity
60,
so
that
yeah.
That
was
the
kind
of
goal
no.
A
C
I
Bradley
is
hopefully
gonna
bring
it
up
at
the
next
tc39
in
January.
With
these
new
changes,
okay
and
then
hopefully,
we'll
get
the
provisional
approval
stamp,
it
won't
be
a
merge,
it
won't
be
in
the
spec
necessarily
I
mean.
Maybe
he
will
be
able
to
get
it
in
the
spec,
but
it'll
be
then
ready
for
us
to
go,
and
then
there's
still
the
question
of
getting
the
merge
in
the
eights
and
how
that
process
would
go
and
I'd
certainly
value
feedback
on
on.
A
Because
we
could
theoretically
float
that
patch
on
v8
in
our
tree,
Jordan,
I'm,
gonna,
add
one
more
thing
and
then
it's
all
you
what
I
think
we
need
to
do
as
at
least
the
module's
team,
though,
and
we
have
consensus
here
in
court-
we
have
quorum
here
right
now.
Is
we're
HAP's
for
each
consensus
that
we
want
to
do
this,
because
if
we
don't
have
consensus
in
this
group
right
now
that
this
is
a
change
that
we
want
to
see
that
I
think
we
need
to
be
working
on
that
in
our
own
house.
A
But
if
we
have
like
coalition
here,
saying
hey,
this
is
the
node
modules
team
stamp
of
approval.
I
can
go
and
just
tell
that
to
the
TSC
and
we
can
open
an
issue.
Encore
give
people
an
opportunity
to
object,
but
if
we
have
kind
of
Olive
node
not
having
any
objections,
I
think
that
just
removes
one
of
the
pieces
of
kind
of
unknowns
from
this
Jordan.
D
D
As
Gus
pointed
out,
you
currently
can
get
a
partially
evaluated
namespace
object
where,
as
guy
points
out,
all
the
names
are
statically
known,
but
there's
some
weirdness
that
was
filed
in
a
I
think
Gus
actually
filed
on
the
spec
itself,
where
some
of
the
reflection
methods
work
and
some
of
them
throw
and
some
of
the
ones
that
throw
you
might
expect
should
be
able
to
work,
and
so
we
kind
of
have
tried
a
few
things
to
look
into
that
to
see.
Well,
how
can
we
make
like
object?
D
Keys
should
be
able
to
work,
for
example,
since
you
know
all
the
keys
and
you
don't
care
what
the
values
are,
even
though
they're
indeed
easy,
but
it
turns
out
that
that
throws,
and
so
we
haven't
been
able
to
find
a
way
to
make
that
work,
that
that
wouldn't
be
like
terrible
for
a
lot
of
other
reasons,
and
so
someone
brought
up
I
think
during
the
tc39
meeting
and
I'm
Kevin.
It
might
have
even
been
you,
but
someone
asked
like.
Why
are
we
like?
Why
should
these
partial
namespace
objects
be
reflected
reflectable
anyway?
D
So
if
we
made
like
all
of
those
reflection
methods,
throw
consistently
would
that
kind
of
address
the
issue,
which
is
that
it
would
make
things
more
consistent
now
and
then
in
the
world
of
dynamic
modules,
you
wouldn't
be
able
to
observe
these
changes
when
it
was
partially
evaluated
anyway,
which
would
be
consistent
with
the
static
world,
and
then
the
discrepancy
no
longer
exists.
I
just
was
throwing
that
out
there
as
a
possible
direction.
D
A
A
Okay
great?
So
it
seems
we
have
consensus,
at
least
in
the
modules
group
to
move
forward.
Do
we
have
consensus
in
opening
an
issue
in
nodejs,
slash
node,
to
give
the
general
collaborators
an
opportunity
to
object
or
voice
any
problems?
Okay,
cool
so
got
a
guy.
Can
you
take
the?
Would
you
be
up
for
taking
the
action
item
of
opening
that?
Because
you
have
the
most
context
on
this
sure.
A
So,
let's
open
that
and
leave
that
up
like
between
now
and
the
next
meeting,
and
then
if
we
have
no
objections
or
any
problems
between
now
and
the
next
meeting,
I
think
it's
very
clear
for
us,
and
maybe
we
can
document
this
and
our
readme
or
somewhere
in
our
repo.
Maybe
we
could
even
bring
your
proposal
into
the
module's
repo
or
something
like
that.
A
I,
don't
know,
but
I
think
having
a
clear
signal
that
note
is
a
hundred
percent
behind
this
and
has
no
objections
to
it,
independent
of
how
it
lands
in
our
implementation
whether
it's
default,
like
those
are
semantics
but
I
think
that
very
clear
signal
will
help.
People
from
the
VA
team
and
tc39
make
this
decision.
Okay,
awesome.
The
next
item
that
we
have
is
going
to
be
Yuans
pull
request
against
Eknath
script
modules:
number
fourteen
add
package
exports
proposal
to
resolver
spec
yon.
Would
you
like
to
open
the
discussion
about
that.
E
Right,
let
me
just
quickly
I
gotcha
yeah,
so
we
talked
about
the
package.
Exports
proposal
in
some
of
the
previous
meetings
and
wealthier
outcomes
was
that
guy
asked
to
convert
some
of
those
semantic
changes
to
pull
requests
against
the
results
back.
So
we
have
a
more
well
specky
explanation
of
what
it
actually
does
without
having
to
rely
on
textual
descriptions.
E
Breaking
the
scope
in
this
case
that
I
am
planning
I
was
planning
to
rewrite
this
back
from
a
perspective
of
resource
loading
based
on
the
document
that
I
shared
earlier
that
that
Bradley
has
created
to
more
clearly
separate
out
where
exactly
this
would
happen.
If
and
when
we
go
for
resource
loading
as
the
sa
step
in
module
loading.
E
So
that's
why
it's
still
not
V
based,
and
it's
still
marked
s
do
not
merge,
because
I
want
to
see
if
I
can
I
can
do
that,
but
I
think
the
actual
algorithm
for
what
it
does
in
the
context
of
name
resolution
will
not
change
it's
just
a
refactoring,
not
a
actual
change
of
behavior,
so
I
think
what
I'm
looking
for
here
is.
There
were
some
common
threats
that
died
down
a
couple
of
weeks
ago.
I
J
Don't
have
any
objections,
I
was
just
gonna
say:
do
we
maybe
want
to
set
a
tentative
I,
don't
know
about
deadline
but
a
goal
for
maybe
by
the
next
meeting?
If
you
want
to
finish
the
spec
document,
you
were
working
on
and
then
I
guess
just
it's
on.
Everyone
has
homework
to
take
a
look
at
the
proposal.
Take
a
look
at
the
spec.
Take
a
look
at
the
open
issues
on
that
repo
and
then
look.
If
anyone
has
any
further,
you
know
notes
they
want
to
address
to
open
issues
on
that
repo.
I
I
I
can
open
up
an
issue,
maybe
if
it
hasn't
been
discussed,
but
the
whole
idea
is
if
we
have
two
sibling
packages:
a
and
B
and
an
inner
import
into
a
redirects
actually
into
B
and
B
redirects
back
into
a
basically
how
we
resolve
any
sort
of
cycle
or
make
it
so
they
can't
cycle
by
say
that
you
can't
have
your
exports
point
to
something
in
a
different
package.
I,
don't
know
yeah.
E
The
clarify
I
for
this
case
the
behavior,
does
not
allow
for
chaining
right
now.
The
only
thing
that
you
can
map
to
is
a
relative
URL
that
will
be
resolved
using
relative
URL
resolution
and
semantics
relative
to
the
package
boundary,
and
at
that
point
there
is
no
additional
resolution
allowed
anymore.
It's
just
a
relative
URL
relative
to
the
absolute
URL
of
the
package.json
file.
Basically,.
A
So
a
quick
question
for
you
yarn,
so,
like
I'm,
looking
at
this
I'm
seeing
you
know,
we
have
the
exports
I'd
love
to
see
something
better
than
the
empty
export,
like
that's
kind
of
like
a
weird
like
the
empty
string
there
and
I
know
that
that's
just
supposed
to
be
for
the
main,
but
that
kind
of
that
kind
of
weirds
me
out
a
little
bit
I'm,
also
curious
about
how
people
feel
about
extending
what
the
root
means.
So,
like
you
know,
in
node,
we've
been
pretty
consistent.
A
That
root
means
the
root
of
the
filesystem
rather
than
the
root
of
the
module,
but
this
has
been
an
inconsistency
and
will
be
an
inconsistency
with
how
ESM
works
in
the
browser.
So
this
actually
is
like
arguably
a
positive
thing
to
be
exploring,
but
it's
definitely
something
I
think
we
need
larger
buy-in
outside
of
this
working
group
and
then
the
last
bit
that
I
was
thinking
about
was
just
how
this
will
in
turn
interact
with
the
import
map
proposal.
A
I
think
that
this
very
well
is
like
metadata
that
can
be
used
for
generating
the
import
Maps,
but
I'd
like
to
really
work
on
ensuring
that
the
semantics
of
how
we're
doing
things
is
compatible
with
import
maps
and
complementary,
which
I
really
think
it
can
be.
But
it
seems
like
getting
someone
like
Dominic's
input
on
this
and
perhaps
even
a
caveat
into
the
import.
Mapkit
self
would
be
very
helpful
here.
I
I'm
super
crazy,
uncomfortable
with
rewriting
what
the
leading
slash
means,
because
it
won't
work
like
how
it
is
in
the
browsers.
So
in
particular,
if
you
have
two
packages
with
leading
slashes
and
the
browser,
it's
always
going
to
be
related
to
the
same
document
base.
And
if
we
do
it,
that's
not
going
to
be
true
a
node
just.
E
E
This
is
not
rewriting
the
leading
slash
in
an
import
statement.
Actually
that
is
a
potentially
different
proposal,
but
also
in
that
proposal,
it's
not
rewriting,
but
even
though
I
thought
providing
the
leading
slash.
This
is
in
the
axe,
so
just
to
take
a
step
back
to
what
Myles
was
talking
about
out
about
the
keys
in
the
exports
map
and
how
it
relates
to
the
impact
map
proposal.
E
So
a
it
is
directly
based
on
the
FFF
proposal.
In
one
place,
it
even
says
the
behavior
of
the
following
might
change
to
mirror
what
whatever
the
input
map
is
doing.
It's
just
written
against
the
current
version
of
the
proposal
and
the
leading
slash
in
this
context
is
just
the
character
after
the
specifier.
When
you
do
a
bear
import,
it's
not
a
leading
slash
in
the
URL.
It
does
not
appear
in
an
import
as
a
leading
step.
A
Bradlee
you've
got
your
hand
up
and
I
think
we
should
wrap
this
up
in
two
minutes,
because
we've
run
a
little
over
we'll
only
I'm,
just
tabbing
between
stuff.
Sorry,
it's
done
so
I
think
we've
identified
some
clear
stuff
that
we
need
to
dig
into
on
this
and
we
can
follow
up
in
the
PR
before
we
move
to
the
next.
If
you
yon,
are
there
any
hanging,
questions
or
thoughts
that
you
have
that
you
would
like
from
the
group.
E
A
Yeah
I
mean
I,
think
the
empty
string
is
essentially
main
or
module
or
whatever
like
that.
Endpoint
is
but
yeah
like
having
two
different
ways
to
do
it.
It
was
weird
or
having
one
place
to
just
do
the
main
and
another
place
to
do
all
the
other
ones
is
weird,
so
that'll
be
a
fun
one
to
iron
out
from
a
experience,
endpoint,
okay,
so
the
the
next
and
last
agenda
item
that
we
have
for
today
is
xmas
script
modules,
number
19,
specify
import
file,
specify
resolution
proposal.
A
C
Sure
so
you
can
kind
of
picture
this
one
as
being
the
sort
of
compliment
Tiana's
proposal
they
kind
of
go
together.
I
think
that
where
we're
going
is
to
kind
of
merge
the
the
proposals
into
one
and
that's
hopefully
where
we
can
get
to
net
by
next
time,
the
the
details
of
the
implementation
or
exactly
what
is
in
Jeffrey
booths
repo
jeffrey
booth,
node
import
file,
specify
specify
resolution
proposal
that
we
discussed
at
the
last
meeting.
So
it
kind
of
just
takes
that
proposal
and
turns
it
into
spec
language.
C
Just
like
yams
PR
does
for
is
proposal,
and
the
hope
was
that
I
could
get
us
to
a
place
where
we
can
discuss
the
specifics
with
reference
to
the
proposal
and
be
able
to
move
to
discussing
specific
cases
so
that
when
we
get
towards
implementation
and
consensus
directions,
we
can
have
already
have
had
some
of
these
discussions.
I
brought
up
two
points
in
that
PR
there
and
if
anyone
else
has
had
a
chance
to
look
at
it
and
has
any
other
questions
or
feedback
on
on
the
approach,
that
would
be
really
useful.
J
It's
just
sort
of
like
I
just
wanted
to
limit
the
scope
of
this
to
be,
like
you
know,
there's
a
lot
of
things
that
you
know.
This
is
not
the
last
PR
that
we
will
be
doing
on
ActionScript
modules.
So
you
know
if
we
want
to
do
another
PR
that
has
leading
/p
to
file
system
route.
That's
totally
fine
I
just
wanted
to
kind
of
punt
that
whole
discussion
and
debate
into
its
own
thing,
rather
than
try
to
like
slip.
That
in
is
just
like
a
bullet
point
in
this
other
proposal.
J
So,
if
that's
okay
with
people
and
and
yeah
as
far
as
empty
string
versus
default
or
main
or
whatever
or
whatever,
we
want
to
call
it
also
the
name
of
the
exports
I
mean
those
are
all
up
for
debate.
That's
I
feel,
like
you
know,
I
feel
like
that's
just
bike
shedding
at
this
point.
Well,
not
bike
checking.
It
is
important,
UX,
but
I,
don't
think
anyone's
talking
about
changing
the
behavior
of
it.
J
A
Think
something
that
would
be
really
useful
to
me
and,
like
sincere
apologies,
if
you
already
said
it
and
I
missed
it,
but
if
you
had
like
kind
of
a
point,
farm
executive
summary
of
exactly
what
the
changes
were
between
the
current
capabilities
of
the
loader
and
the
new
loader
after
these
changes.
That
would
be
really
helpful
to
me.
J
So
I
rewrote
this
miles.
Based
on
your
saying,
you
wanted
a
summary
version.
I
basically
started
writing
the
summary,
and
basically
it
ended
up
being
just
a
shorter
version
of
the
entire
proposal.
So
then
I
was
just
like
well,
let's
just
replace
the
proposal
section
with
this
new
shorter
one.
So
that's
if
you
want
to
just
skip
straight
to
the
proposal
section
here
in
this
thing,
this
is
pretty
much
it
and
it's
not
that
long.
J
You
know,
import
lodash,
take
the
string,
lodash
and
locate
okay.
What's
the
dais
file
that
should
be
loaded
for
this.
So
you
know
lodash,
slash
index
that
MJS
or
whatever
that's
covered
already
by
guys
spec.
This
document
is
like
okay,
once
we've
found
that
once
we've
looked
once,
we've
turned
this
into
essentially
this,
then
what
do
we
do
with
it
so
or
how
do
we
load
it,
etc?
J
A
So,
just
for
clarity's
sake,
what
it's
something
within
the
package
JSON
that
determines
whether
or
not
a
s
within
the
package
boundaries
is
parsed
as
ESM
rj
s,
yes,
okay,
and
how
far
are
we
expecting
these
kind
of
like
Patrick
the
the
package
boundary
specifics
to
extend
like?
Is
it
only
how
Jay
s
is
parsed?
That
would
be
within
those
package
boundaries?
Or
would
this
go
past
that.
J
J
Was
thinking
I
mean
this
only
concerns
itself
with
Jay
s,
&
MJ
s
files.
We
don't
really
go
beyond
that,
but
my
assumption
would
be
that
for
any
for
any
file
that
had
a
parse
goal
that
this
would
apply
to
any
such
file.
But
you
know
guy
is
more
the
expert
on
that
stuff.
So
maybe
he
should
take
that
Brad.
You
have
your
hand
up.
D
I
I
see
the
value
of
having
of
within
a
package
boundary
kind
of
being
able
to
essentially
make
your
own
import
map.
You
know
where
you
can
say
like
it's
like
in
the
screen,
that's
being
shared
worse
like
if
you
try
and
import
sign-on
slash
stub.
Instead,
you
go
into
the
dist
folder.
That
seems
hugely
valuable
right
now
for
all
the
current
use
cases
where
everyone
is
like.
B
D
This
would
kind
of
help
avoid
that
which
is
great,
so
I
guess
that
leads
to
my
next
question
is:
why
aren't
we
just
doing
this
in
CJ
s
and
also
for
ESM
like
why
limit
it
to
ESM,
and
why
have
it?
And
if
we
want
to
deal
with
parsing
goals,
then
cool?
We
should
build
in
a
extensible
way
to
do
that
and
that
parsing
goal
stuff
should
be
something
that
we
deal
with
in
the
modules
group,
but
like
the
route
capability
seems
to
me
to
be
very
important
for
use
in
CJ
s
as
well.
I
Can
directly
comment
to
what
Jordan
was
saying
so
a
while
ago
we
did
a
have
a
presentation
on
applying
loader
kind
of
semantics
to
commonjs
and
how
we
can
make
it
work.
Even
if
we
have
asynchronous
loaders
the
key
point
here
and
in
this
proposal
is,
it
introduces
a
system
that
we
can
query
without
collisions
about
what
the
expectations
that
a
file
should
be
interpreted,
as
that
doesn't
mean
that
all
api's
are
safe
to
use
on
it.
I
But
even
if
we
introduce
this
capability
for
CJ
s,
we
still
need
that
underlying
infrastructure
to
produce
that
aquaria
belén
Terr
face
that
we
have
this
collisionless
format
for
any
given
resource,
and
we
could
certainly
apply
this
to
CGS
I.
Think
CGS.
Loaders
are
very
hard,
but
we
can
work
on
them
if
desirable,
I,
just
don't
think
it's.
The
first
thing
I
would
do.
I
will
do
my
best
to
ensure
that
everything
stays
compatible,
that
we
could
apply
it
to
CJ
s
and
I'll,
probably
voice
angrily.
If
I
can't
think
of
a
way
it
could.
A
Yawn
I'm,
sorry
that
I
don't
think
we're
gonna
have
time
to
get
to
your
question
right
now.
I'll
have
to
get
back
to
the
pull
request.
I'm
gonna
get
kicked
out
of
this
room
right
at
four,
though
I
guess
one
thing
I
just
want
to
get
out.
There
is
perhaps,
if
his
lands.
This
seems
to
get
us
a
lot
of
the
capabilities
of
what
we'd
want.
I
wonder
how
much
more
we
would
need
before
we
could
move
towards
upstreaming.
A
Some
of
the
work
that
we're
doing
so
I
just
want
that
as
like
a
thought
in
people's
heads.
Just
as
we
continue
to
think
about
deadlines
and
goals,
I
mean
in
the
meeting
now
and
getting
kicked
out
thanks
everyone
for
joining
today.
This
is
a
great
productive
meeting,
lots
of
cool
stuff.
To
think
about,
say
all.