►
From YouTube: Node.js Foundation Modules Team Meeting 2018-11-21
Description
A
We're
now
live
on
YouTube,
with
the
November
21st
2018
meeting
of
the
noches
modules
team.
We
have
eight
members
on
the
call
right
now,
which
was
not
quite
quorum,
so
we
may
need
to
punt
on
things
that
have
to
do
with
making
decisions
about
landing
things.
But
in
the
meantime
you
know
what
you
have
a
pretty
full
agenda.
We
could
dig
into
things
so
I
guess
like
one
thing
that
I
think
we
can
maybe
even
just
move
forward
on,
because
it
has
one
two
three,
four,
five,
six,
seven,
eight
there's
nine
sign-offs.
A
If
everyone
could
look
at
number
218
really
quickly,
which
is
just
it's
changing
the
rules
to
be
more
explicit,
that,
like
individuals
were
requesting
to
join
the
team,
if
there's
no
objections,
they
can
show
up
to
their
first
meeting.
I
think
this
is
and
I
think
a
nice
thing
to
be
clear
about.
If
you
can
pop
in
to
that
issue
and
just
give
an
LT
GLG
TM
on
it,
assuming
you
agree
with
it
and
then
you
know
if
we
can
reach
quorum
in
there,
and
perhaps
we
can
just
land
it
independent
of
the
meeting
quorum.
A
A
A
C
I
guess
it'll
be
the
same
thing.
That
applies
to
your
PR
as
well,
but
we
discussed
this
last
week
and
it
does
a
number.
It
has
a
number
of
improvements
to
error
handling,
and
then
there
was
one
case
around
the
main
handling
that
Gil
had
some
questions
about,
so
we
actually
removed
that
from
the
PR.
So
it's
basically
almost
exactly
matches
what
we
have
right
now,
the
current
implementation.
C
It
just
makes
sure
that
there's
an
exact
spec
and
that
the
code
of
how
the
resolver
works
exactly
matches
that
spec
and
I
feel
like
that
puts
us
on
a
good
footing
where
you
know,
as
we
make
changes
to
the
resolver,
the
the
code
and
the
spec
and
kind
of
group
side
by
side.
So
I
was
hoping
to
get
that
emerge
today.
Everyone
on
the
call
now,
if
you
could
at
least
if
you've,
had
a
look
if
you
could
approve
it,
that
would
be
a
huge
help.
D
A
D
A
Okay
is
that
it
for
now
yeah.
B
A
B
Added
a
comment
to
that
thread.
As
we've
been
working
on
the
proposals
for
the
phase
2
stuff.
There
are
definitely
some
questions
that
are
basically
like.
We
wonder
what
the
users
would
prefer
for
this
and
I
think
it'll
absolutely
be
something
that
could
be,
you
know,
could
become
a
survey
or
the
questions
where
it's
to
answer
that
question
about
user
preferences,
I
think
would
will
lead
kind
of
naturally
into
a
survey.
A
Okay,
perfect
one
thing
that
we
could
potentially
rely
on
I'd
have
to
reach
out,
but
I
know
that
NPM
is
doing
their
large
survey
soon
and
one
of
the
people
from
NPM
reached
out
to
me
about
you
know
if
there's
questions
that
I
think
we
should
have
so
perhaps
I
can
ask
them
about
us
participating
in
their
survey.
Is
they
have?
You
know
everything
on
Rails
and
a
pretty
wide
distribution?
And
so
maybe
we
could
get
some
of
the
questions
we
want
to
ask
into
that
broader
ecosystem
survey,
yeah.
A
I'll
follow
up
with
my
contact
there
on
that,
then,
okay.
So
the
next
thing
that
we
have
on
the
agenda
is
number
123
thinking
about
deadlines.
We
have
a
five
minute
time
box
so
that
we
may
not
need
it.
I'll
kick
off
the
discussion.
You
know.
We've
got
some
consensus
as
to
the
things
that
should
be
in
phase
two
and
we're
beginning
discussions
around
what
phase
three
would
be
looking
like.
A
So
you
know,
perhaps
deadline
is
not
the
right
term
to
use
because
it's
it's
you
know
a
loaded
term,
but
something
just
like
goals
for
completion.
Perhaps
is
a
nice
way
to
put
it,
but
I
do
think
that
we
should
start
thinking
about
timelines
as
to
when
we
would
like
to
have
these
phases
done
so
I
was
kind
of
wondering
to
the
group.
You
know:
do
people
have
any
sort
of
opinion
as
to
what
kind
of
timeline
we
should
be.
E
So
I
don't
know
if
we're
gonna
actually
do
that
in
Phase
two,
but
since
it
seems
like
loaders
are
related
that
might
get
pushed
more
towards
Phase.
Three
we're
still
waiting
to
hear
back,
I,
don't
know
if
y'all
miss
on
the
call,
but
me
and
Jung
need
to
sync
up
again
sometime
and
get
back
to
the
group
on
what
we
talked
about.
So
that's
it
for
me.
D
Yeah
so
I
think
one
it's
an
issue
like
I'm
just
trying
to
get
the
number
so
so
my
understanding
from
last
meeting
is
that
we
actually
have
to
you
know,
break
off
into
groups
discussing
the
different
topics
and
yeah,
to
my
surprise,
basically
I'm
waiting
for
the
discussion
to
want
to
happen
and
I
think
Bradley
pointed
out
that
he
and
Yan
will
be
continuing
the
discussion.
So
there's
obviously
an
disconnect
I.
D
I
actually
kind
of
those,
because
if
we
move
something
to
Phase
three
without
actually
the
people
who
are
discussing
it,
agreeing
to
that
then
it
kind
of
like
effect
when
phase
three
will
actually
start,
because
you
know
we.
If
we
move
it,
then
you
can
start
phase
three
assuming
if
we
don't
move
it,
then
we
start
after
we
discuss
the
basis
and
so
to
be
exclusion,
you're
talking
about
taking
things
that
are
currently
Phase
two
and
moving
them
to
Phase
three
objecting
to
it.
D
A
I
think
I'm
getting
what
you're
putting
down,
although
I
think
that
it
is
a
little
bit
D
railing
from
the
topic
at
hand.
It
sounds
like
you
see
a
risk
with
having
deadlines
based
on
this,
but
it's
like
I
guess
what
I
can
take
away
from
that
is.
Do
we
perhaps
we
should
take
a
moment,
perhaps
not
on
this
meeting,
but
to
confirm
that
we
still
have
consensus
around
with
phase
two,
which
is
something
that
we
reach
consensus
on.
So
perhaps
that's
something
that
we
should
do
separately
in
our
next
meeting.
If
that
makes
sense,.
A
Okay,
I
think
we're
running
out
of
time
on
this
I
would
love
to
see
you
know,
phase
two
completed
before
the
end
of
q1
and
I.
Don't
think
that
that's
unreasonable,
I
would
even
like
to
see
us
have
some
good
progress
on
Phase
three
as
well,
so
just
kind
of
setting
that
into
people's
minds.
Thinking
about
what
it
is,
keep
in
mind
that
April
is
when
we're
gonna
cut
node
twelve,
so
you
know
I
think
this
is
timeline
of
April
is
good
to
think
about,
and
this
leads
right
into.
A
You
know,
let's
change
the
order
here
for
a
second
I'm
gonna.
We
have
an
issue
about
dropping
the
moratorium
and,
let's
just
jump
right
into
that,
because
I
think
it's
more
connected
and
so
kind
of
the
context
that
I'll
add
here
is
you
know
one
of
the
reasons
for
having
that
time
line
and
thinking
about
deadlines
is
especially
with
what
we
have
right
now
is
a
moratorium.
We
can't
be
updating
things
upstream
right
now,
Jeremih,
we
were
you
gonna,
say
something
about
the
previous
thing,
or
is
this
about
what
I'm
getting
into
right
now.
F
C
Thanks
sorry,
I
was
just
wanting
to
dig
into
that
and
find
out
how
much
time
we
think
is
adequate
for
you,
because
you
know
should,
should
we
be
targeting
a
month?
Should
we
be
targeting
two
weeks
so
that
you
know,
should
we
be
thinking
much
or
or
mid-march
short
of
it?
So
it
would
be
useful
to
kind
of
have
an
idea
of
what
that
process
will
be
when
we're
ready,
so
that
we
can
make
sure
that
we
there's
enough
time
for
the
right
checks
and
balances
there.
A
So
dying,
I'm
gonna
hold
that
thought
for
a
second
and
preface
it
with
the
moratorium
that,
because
I
do
think
one
of
the
things
that
we
can
consider
here
is
the
Delta
that
we
need
to
get
reviewed
and
how
much
things
we
actually
need
to
land,
and
so
you
know
when
we
examine
what
we
have
with
the
moratorium
right
now.
You
know
we're
working
inside
of
a
fork,
we're
doing
everything
inside
of
a
fork,
we're
not
up
streaming
anything
we're
not
changing
anything.
A
It
means
that
what
we're
doing
this
people
in
the
ecosystem,
continuing
to
move
forward
with
the
semantics
and
the
way
in
which
the
current
the
current
implementation
work,
which
has
been
out
there,
you
know
for
about
a
year.
So
it's
you
know.
People
are
starting
to
really
rely
on
that.
So
I
personally
believe
that
if
we
have
consensus
that
certain
things
are
going
to
be
changing,
we're
breaking
we're
different
that
we
should
be
up
streaming.
A
Those
unlikely
up
streaming
them
to
11
as
soon
as
possible
and
I
think
the
sooner
that
we
get
the
Delta
closer
between
upstream
and
our
fork,
the
easier
it
will
be
for
us
to
upstream
things
later
so
very
much
to
what
Jeremiah
was
saying
about.
Like
hey.
You
know
we
want
to
maybe
have
this
in
March
or
maybe
we
want
to
have
it
in
February.
You
know
if
we
upstream,
the
majority
of
what
would
be
the
quote,
unquote
breaking
changes
far
in
advance
of
that
and
simply
landed
enhancements
as
we
move
forward.
A
We
do
have
a
lot
more
flexibility
on
timeline,
even
like
not
necessarily
for
something
like
loaders.
If
it's
not
ready
for
production,
you
know
that's
something
that
could
come
after
the
cut
of
12,
although
I
do
know
that
people
have
strong
feelings
about
not
removing
things
from
the
current
implementation
until
we
have
alternatives,
but
if
we
know
that
the
current
version
is
simply
not
going
to
be
supported,
I
don't
know
that
we're
doing
anyone
a
favor
by
leaving
it
in
there
guy
it's
up
to
you,
yeah.
C
I
mean
I
always
feel
slightly
the
opposite
way
actually,
but
I
think
it's
great
that
we
should
upstream-
and
you
know
like
with
the
dynamic
modules
refactoring
that
gusted
and
things
like
that
like
if
we
can
be
refactoring
those
improvements
and
that
helps
reduce
the
dip
in
grades,
but
pushing
up
breaking
changes
at
random
times.
I
always
imagined
the
sort
of
that
with
when
it
experiments
or
modules
was
removed.
That
would
be
kind
of
shift
into
into
the
new
paradigm,
but
I
mean
yeah.
It's
it's
our
concern,
interpretation,
I,
guess
but
yeah.
A
Yes,
I
do
okay
cool
and
then
you
know,
as
you
object
to
that.
What
would
you
want
to
see
as
like?
Do
you
think
that
we
could
go
through
per
commits
so
like
one
that
I'm
thinking
of
in
particular
is
Gus's
refactoring
right,
like
I?
Don't
see
any
reason
why
that
shouldn't
be
up
streamed
if
it's
existing
in
both
works
and
in
both
branches
and
not
making
any
differences,
are
we
open
to
on
a
commitment
by
commit
basis,
potentially
up
streaming
things
that
make
sense?
D
You
know
used
over
the
minimal
implementation
that
we
have.
You
know
how
much
work
would
it
take
to
actually
make
the
to
you
know
work
so
obviously,
loaders
will
then
be
something
that
will
be
changed
down
the
road
and
we
have
to
make
that
very
clear,
but
I
don't
know
how
much
gap
we're
talking
about
and
how
much
work.
You
know
if
it's
even
possible
so,
but
it's
just
an
idea
right.
C
Was
just
going
to
clarify
there
as
well
is
so
from
the
github
issue,
as
Sal
I
mentioned.
You
know
the
thing
that
that
I
felt
was
important
in
that
one
was
that
we
should
still
have
loaders
because
of
the
fact
that
people
are
experimenting
with
loaders
and
it
allows
them
to
use
your
tools
and
node
with
other
custom
functionality,
which
feels
useful
to
me
and
to
suddenly
take
that
away
is
one
of
the
things
that
would
worry
me,
but
I'm
all
for
up
streaming
and
as
much
as
we
can
I'm,
definitely
open
to
that.
A
G
B
A
B
Well,
then,
I,
don't
I,
don't
know
how
this
necessarily
relates
to
that.
But
what
I
was
going
to
say
is
I
the
thing
that
concerns
me
is
like
I'm
thinking
of
that
that
guy
that
that
posted
an
issue
on
our
on
one
of
our
repos,
basically
being
like
you
know
what
are
the
docs
for
this
gonna
look
like
when
it's
you
know
am
I
gonna
have
to
use.
Mjs
am
I,
gonna,
be
used,
J
s
et
cetera,
and
we
were
basically
responded
to
her
like
we
don't
know
and
I
think
you
know.
B
That
would
be
the
kind
of
thing
that
like
before
we
I
mean.
Maybe
that
shouldn't
be
something
we
that
holds
up
up
streaming
but,
like
you
know,
users
are
going
to
notice,
I
think
when
the
when,
when
what
gets
shipped
changes
UX,
and
so
we
should
have
some
kind
of
a
you
know,
a
blog
post
or
some
kind
of
explanation,
of
what
that
change
is
and
where
we
think
it's
going
like.
Are
they
gonna
have
to
start
using
MJS
extension?
Do
we
think
that's
going
to
be
the
final
version
of
this
etc?
B
E
The
value
in
up
streaming
is
being
able
to
update
what
we
have
consensus
on
to
be
in
master
I.
Think
things
we
expect
to
change.
I
would
feel
uncomfortable
up
streaming,
a
variety
of
things
stating
they're
not
going
to
change
and
keeping
other
things
which
are
expected
to
change
in
light
of
that,
I
really
don't
feel
comfortable
keeping
the
loader
flag.
If
we
do
upstream,
because
I
have
believe
want
to
change
that
load
or
flag
in
a
variety
of
ways.
So.
A
C
I'll,
try
and
summarize
what
I'm
thinking,
but
basically
like
we,
especially
with
the
minimal
it's
a
very
opinionated,
and
you
know,
can
so
far
as
one
isn't
providing
the
final
solution
as
it
were,
I
think
it's
it's
useful
for
users
to
be
able
to
plug
in
custom
resolvers,
and
so
you
know,
I
think
that's
important
for
people
to
be
able
to
use
it
in
real
use
cases
where,
if
they
don't
want
to
use
MJ
s,
for
example,
and
they
they
have
real
ways
to
get
around
that
and
load.
C
C
Also
think
if
we
look
at
phase
2
and
phase
3
is
separate,
there's
no
reason
we
couldn't
upstream,
you
know,
phase
2
with
the
load
of
flag
and
then
upstream
the
new
load
of
work
after
that
or
you
know,
I
know
that's
exactly
against
what
Bradley
was
saying,
but
just
trying
to
think
of
ways
of
packaging.
This
I
think
that's
sort
of
about
working
out
those
boundary.
A
Be
very
explicit
for
right
now
we
have
an
open
poll
request
that
or
the
the
PO
requests
that
just
landed
from
Gus
of
refactoring
dynamic
modules
that
lands
cleanly
on
master
and
it's
in
our
fork.
It
doesn't
change
any
behavior
and
it's
just
an
extra
commit
that
were
that
we're
floating
that
we
don't
need
to
be.
A
A
Okay,
cool
take
that
I'll.
Take
that
as
a
no
and
I'll
take
the
action
item
on
that.
The
next
topic
that
we
have
on
the
agenda
is
keeping
the
script
modules
up
to
date.
A
quick
update
on
that
I've
been
doing.
The
rebase
is
and
then
kind
of
pushing.
If
the
rebase
is,
you
know
not
causing
any
conflicts
and
then
when
there
was
conflicts,
for
example,
yesterday
I
opened
a
pull
request
and
ran
CI
on
it
and
then
landed
it
after
CI
was
Green.
A
Does
anyone
have
a
problem
with
that
process,
as
we've
been
doing
it
right
now,
cool
Michael
you
had
been.
You
had
talked
about
some
of
the
way,
the
that
you're
automating
it
and
I
know
that
in
the
last
meeting,
I
think
it
was
that
who
was
it,
who
Oh,
whose
wall
was
saying
that
they
would
maybe
go
and
looking
to
working
with
the
build
group
working
group
to
automate
it,
but
it
doesn't
seem
like
there's
been
any
movement
on
that
Michael.
A
A
A
Okay,
yeah
I'll
reach
out
to
them
and
we'll
follow
up
and
we'll
try
to
just
improve
it,
but
at
the
very
least,
we're
kind
of
unblocked
on
keeping
things
up
to
date,
although
it
would
be
nice
to
be
less
manual.
The
other
thing
just
for
a
heads
up
to
people
we
moved
in,
so
that
we
now
have
the
master
branch
and
a
module
is
lkl.
Kgr,
last
known,
good
release,
branch
master
is
consistently
just
being
kept
up
to
date
with
upstream,
and
the
modules
lkg
are
is
being
rebased
against
that.
A
So,
if
you
take
a
look,
the
PO
requests
against
mod.
The
pull
request
against
the
branch
are
coming
against
modules:
okay,
gr,
but
when
we
have
conflicts
with
the
rebase,
then
those
pull
requests
are
coming
against
master
and
we'll
just
you
know,
let's
just
keep
doing
it
and
iterating
and
we'll
see
it
appears
that
Michael
Dawson
has
joined
us
in
the
meantime
and
we
now
have
quorum.
So
we
have.
We
did
have
two
bits
that
we
needed
to
play
by
the
way
we've
moved
a
couple.
A
People
during
this
meeting
I
reached
out
to
a
couple
people
and
three
people
have
moved
to
observers.
So
11
is
now
all
we
need
for
quorum
as
there
is
currently
only
21
active
members.
So
with
that
being
said,
we
had
two
issues
that
we
wanted
to
try
to
approve
from
PR
s.
The
first
was
governance,
the
explicit
about
meetings
and
new
member
new
members
can
join.
There's
anyone
object
to
landing
that
excellent,
we'll
move
forward
with
that
and
then
the
next
one
that
we
have
is
the
ESM
resolve,
respect
and
implementation
refinement.
A
A
H
There
isn't
too
much
to
say
basically
just
so
implementation
where
code
things
are
happening
and
when
issues
with
that
code,
pops
up
I
think
it
would
be
nice
to
you
know,
put
those
with
the
code
right
now.
People
I've
seen
issues
opened
on
the
core
repo
and
I've.
Seen
issues
opened
on
the
our
modules
repo,
both
of
which
seem
like
poor
places
to
track
that.
A
F
A
B
Okay,
I
guess
I'll
just
take
over
yeah,
so
I
don't
know
if
so
I'm
we're
happy
I'm
happy
to
punt
this
to
next
meeting.
B
B
Just
assuming
people
could
read
it,
but
I
can
I
can
explain
it
in
summary,
I
guess
if
people
want
so
basically
it's
going
through
like
how
to
handle
this
part
of
an
import
statement
right
so
for
packages
this
you
know
a
specifier
that
starts
at
the
bare
specifier.
You
know
I'm
just
kind
of
deferring
to
the
other
proposal
for
ESM
files,
if
it's
relative,
so
it
starts
with
dot.
Basically,
it's
going
to
resolve
it
as
ESM,
including
if
it's
an
MJ
s
or
J
s
extension.
B
We
reserved
stump
specifiers
to
start
with
a
slash
for
future
use
because
there's
a
question
about
how
those
should
behave
being
compatible
or
not
with
browsers,
because
browsers
have
this
relative
to
the
host.
No
traditionally
has
had
a
relative
to
the
root
of
the
file
system,
which
we
felt
like
isn't
the
most
useful
thing
to
have
these,
because
that's
you
generally
can't
share
code,
that's
written
with
that
and
it
wouldn't
be
compatible
with
browsers.
B
That's
again
also
outside
of
the
scope
of
this,
but
just
covering
those
and
then
this
is
basically
covering
all
the
same
things
for
you
know
if
what
you're
looking
for
is
commonjs.
So
if
it,
if
it's
a
pair
specifier
or
starts
with
a
pair
specifier,
then
we
have
to
look
at
the
package
of
jason
for
that
package,
and
then
that
tells
you
how
to
either
find
the
entry
point
or
find,
or
you
know,
deal
with
deep
imports.
And
then
this
is
probably
the
most
controversial
part
based
on
some
research.
B
I
did
of
existing
ESM
packages,
almost
a
thousand
of
them.
There
aren't
that
many
cases
like
less
than
5%,
where
users
and
even
that
might
be
high,
because
of
because
of
the
way
I'm
getting
that
number
where
users
are
using
an
import
statement
to
pull
in
a
common
J's
file
as
opposed
to
a
common
test
package,
and
so
there
is
already
a
way
to
do
that
create
require
from
path.
So
we
were
thinking
like
that
might
be
just
enough
for
now,
and
then
there
are
various
options
for
making
it
easier
for
people.
B
But
basically
this
is
like
a
value
judgment
where
we're
deciding
that
treating
thing.
Cheating
jeaious
and
MJS,
as
ESM
by
default,
is
kind
of
more
likely
to
be
what
users
prefer
and
that
it
should
be
more
effort
to
do
something
other
than
that,
so
the
non
default
behavior
to
do
to
do
comedy
is
Interop,
but
that
since
ESM
is
the
standard
now
and
it's
the
future,
that
should
kind
of
be
the
default
and
it
takes
more
effort
to
mix
the
two.
So
that's
the
the
summary
version
of
it.
I
I
B
E
This
is
basically
all
I
want
to
talk
about,
because
I,
don't
think
was
brought
up
in
depth
enough.
The
one
thing
that
I
had
going
through
and
reading
this
was
to
ensure
that
no
absolute
specifier
in
import
would
ever
be
ambiguous
in
formats
roughly
something
that
wasn't
really
talked
about
here
is
inside
of
package
JSON.
They
are
kind
of
pushing
out
how
to
define
if
something
is
a
common
J's
package
or
it's
an
e
sm
package,
and
so
by
specifying
your
package
has
to
be
in
one
of
two
modes.
E
B
B
This
will
basically
say:
that's
that's
a
signifier.
This
is
this
package
exports
ESM.
It
might
also
explore
a
command
j
s,
but
you
know
the
existence
of
this
key
means.
This
is
an
e
sm
package
at
least,
and
we
may
we
may
add
other
signifiers
in
the
future,
guys
mode
proposal
or
something.
So
it's
in
terms
of
the
way
this
proposal
was
written.
It
was
sort
of
like
exports,
you
know
and
or
other
things
in
the
future
that
also
signify
yes,
M.
If
we
also,
you
know,
adopt
other
proposals.
In
addition,
so.
E
Just
to
clarify
that
a
little
it's
a
little
vague
on
saying,
we
have
to
choose
a
specific
thing.
It's
just
stating
that
packages
will
be
in
one
mode
at
any
given
time.
So
the
the
format
of
anything
on
disk
has
a
statically
queryable
format
that
import
notes
it
doesn't
affect
the
behavior
of
require
changing
require
is
very
dangerous
and
I
would
be
very
scared
of
changing
how
require
treats
formats.
I
E
Know
so
to
understand
this,
you
have
to
kind
of
take
the
scope
of
the
proposal
into
account.
The
scope
of
the
proposal
is
only
about
how
import
functions
require
itself.
Remaining
unchanged
means
that
it
will
always
treat
stuff
as
commonjs
by
not
reusing
main
for
import
in
this
proposal
is
in
its
examples.
It
doesn't
produce
a
collision.
E
Polly
gems
are
very
bad.
They
they're
pretty
much
the
only
thing
I
look
for
now
when
talking
about
resolvers.
If
you
follow
react,
graph,
QL
create
react,
app
or
some
of
John
David
Dalton's
ESM.
Work
like
ambiguity
in
specifiers,
has
caused
an
enormous
amount
of
headache
and
cause
like
people
to
drop
MJS
support,
because
it
allows
the
ability
to
have
two
formats.
I
E
E
A
I
had
tried
going
through
the
proposal
briefly
and
I
will
spend
more
time
afterwards,
but
one
thing
that
I
that
I
think
the
proposal
would
benefit
from
would
be
an
executive
summary
at
the
top,
like
what's
a
tldr
of
what
the
difference
is
from
what
we
have
today
to
what
would
happen
and
I
know
that
there's
a
lot
of
context
in
here
about
like
why
or
exactly
how
it
would
implement.
But
if
there's
a
way
that
this
could
be
like
five
or
six
bullet
points.
A
F
B
Yes,
if
you
look
under
proposal,
I
kind
of
broke
it
up
into
two
big
sections,
so
I
was
like
first
is
like
importing
from
ESM
and
then,
if
you
go
down
a
bit
import
statements
from
commonjs
and
then
there's
basically
three
types
of
imports,
there's
importing
just
the
package
route
or
package
main
importing
from
a
package
something
inside
of
it:
okay,
a
deep
import
and
then
there's
just
a
loose
loose
files.
So
that
would
be.
F
B
What
I
was
get
so
this
is
tentative,
so
the
intent
is
to
make
this
work,
but
we're
also
very
concerned
about
the
points
that
Bradley's
bringing
up
about
conflicting
specifiers.
If
this,
if
there's
a,
if
there's
any
potential
for
this
causing
some
kind
of
conflict,
then
this
would
be
dropped
into
like
the
same
bucket
of
this,
where
it's
basically
like
use
create
require
from
path
but
yeah.
If
we
can
find
a
way
to
make
this
work
without
it
causing
issues
of
conflicts,
then
the
intent
is
yeah.
Something
like
this
line.
F
B
C
If
we
get
import
that
meta
dot
resolve,
people
are
gonna,
be
wanting
to
pass
the
resolved
URL
into
dynamic
import
again.
Will
you
know
treat
that
as
as
the
module
and
if
it
suddenly
loads
differently?
That's
kind
of
odd,
so
I
tend
to
think
that
that's
a
very
important
invariant
of
this
sort
of
way
of
thinking
about
package
boundaries
that
they
exist
for
both.
J
B
C
E
B
G
Just
a
quick,
I'd
know
I
think
it's
a
lot
easier
to
understand
whether
the
package
boundary
makes
a
difference
for
these
relative
or
absolute
URLs
when
you
just
when
you
separate
out
the
resolving
to
a
URL
from
determine
the
format
but
from
the
format.
That
is
where
the
package
boundary
is
then
also
considered,
and
that
in
that
way
there
is
no
difference
between
dots
helpers,
temperature,
MGS
or
the
full
file
URL.
In
both
cases,
it
gets
resolved
to
the
same
after
jor-el
and
then
put
that
absolute
URL.
The
package
boundary
matters.
G
A
B
B
This
doesn't
mean
that
they're
accepted
or
anything
like
that.
It's
just
that
their
suggestions,
for
you
know
those
those
points
on
the
on
the
Phase
two
and
then
I
also
put
a
link.
I
mean
if
people
object
to
this
I
can
take
this
out,
but
I
put
a
link
to
the
plan
for
new
models,
implementation
file
from
the
main
readme
and
a
link
also
to
the
echo
script
modules
repo
from
the
main
read
B.
You
know
just
because
those
are
very
relevant
and
seems
like
we
should
probably
link
to
them.
A
A
B
Miles
can
I
ask
so
I'll
I'll
make
those
changes
to
the
proposals.
Both
proposals
are
in
repose
of
their
own,
so
people
can
please
open
issues
there
to
raise
points
at
them.
Appraised
points
about
them
and
we'll
try
to
address
all
of
them
and
then
I'd
love
to
try
to
move
them
towards
I
guess
approval
at
some
point,
so
we
could
start
making
implementations
based
off
them,
assuming
that's
probably
the
way
forward.
Yeah.
A
Mean
I'm
a
huge
plus
one
on
the
myself
like
and
I
think
like
especially
maybe
having
executive
summaries
at
the
top
I
know.
That's
maybe
an
obnoxious
way
to
frame
it,
but
you
know
there's
a
lot
of
context
spread
throughout
them
and
a
combination
of
like
a
short
summary
and
specification
text
and
actually
kind
of
cut
right
to
the
meat
of.
What's
going
on.