►
Description
A
B
E
Another
thing
not
one
for
you,
though
Sunday
so
that's
last
shot.
So
if
you
want
to
have
them
come
at
peak
and
not
something
you
know,
and
maybe
we
ran
through
my
stage
plan
I
think
is
listen
your
proposal
in
okay,
any
other
announcements
and
maybe
a
six
point.
Seven
release
is
going
to
come
out,
I,
don't
know
one,
but
I
don't
know
yet
so
done
so
then
one
we
think
they
are
cooked
program.
So
it's
probably
very
important
that
we
communicate
is.
E
A
A
B
B
G
So
basically,
this
came
up
when
http/2
is
imminent
and
one
of
the
things
I
maintain
is
resolved,
which
maintains
a
list
of
core
modules
by
node
version
and
I
noted
I
became
aware
of
it
because
someone
filed
an
issue
asking
like
one
of
the
dependencies
that
resolved
was
not
working
properly
with
the
http/2
module
because
it
didn't
know
it
was
core
and
so
I
basically
raised.
The
question
is
like:
can
we
stop?
Can
we
find
out
kind
of
a
deterministic
way
to
you
know
place
to
put
new
modules,
new
core
modules
partially
to
avoid
conflict?
G
So
someone
who
had
you
know
with
HTTP
to
the
ecosystem
conflict
was
explicitly
and,
like
you
know,
directly
resolved
by
working
with
the
maintainer
of
that
package.
But
you
know
in
the
future
the
because
NPM
is
a
bare
word
namespace,
that
you
know
we
might
not
have
that
option
and
then
separately.
Like
you
know,
my
selfish
goal
is
that
the
implementation
in
resolved
could
drop
from
a
hard-coded
list
of
modules.
To
does
this
module
name
start
with
something
or.
G
G
B
G
Gone
up
then,
but
yeah
so
essentially,
the
first
thing
that
should
be
decided
is:
is
this
a
problem
that
we
think
needs
solving?
Do
we
need
to
namespace
core
modules
somehow,
and
then,
if
we
agree
that
we
do,
then
the
kind
of
separate
question
is:
how
should
we
do
that?
There
is
some
if
we
pick
something
that
does
overlap
with
NPM,
namely
scoped
modules.
G
We
can
easily
pick
a
scope
that
node
owns
and
therefore
avoid
any
future
collision
problems
that
opens
the
door
to
polyfill
ability
and
users
being
able
to
override,
or
you
know,
to
to
use
overrides
in
the
way
that,
like
browserify
and
web
pack
does
they
have
a
you
know
core
module.
They
have
a
node
modules
module
that
can
be
a
browser
polyfill
for
the
core
module
things
like
that,
the
other
another
set
of
alternatives
is
coming
up
with
something
that
couldn't
exist
on
the
file
system.
G
The
upsides
is
that,
then
nobody
can
monkey
with
it.
The
downsides
is
that
then
it
can
never
be
polyfilled
and
it
may
overlap
with
you
know,
make
inflict
with
the
way
browsers
do
Pat
resolution
which
comes
into
play
with
the
modules
implementation.
So
my
personal
preference
and
recommendation
would
be
that
we
select
an
NPM
namespace
that
we
own
and
then
everything
just
goes
under
that
and
that
to
me
resolves
all
the
issues
at
hand
and
is
also
forward
compatible
with
whatever
modules
resolution
algorithm.
We
come
up
with.
B
I
J
So
I'd
like
to
note
that
tc39
actually
has
a
similar
problem
that
they're
going
through
with
respect
to
built-in
modules
for
JavaScript
the
language
hosts
entirely
control
of
module
specifiers
right
now.
So
there
are
internal
discussions
within
tc39
and
there's
been
reading
about
how
to
approach
built-in
modules
there.
J
There
isn't
much
leeway.
There
are
open
issues
about
should
it
occupy
the
string
import
specifiers
for
built-ins,
but
there
doesn't
seem
to
be
anything
about
reserving
based
upon
protocol
currently
for
the
JavaScript
import,
specifier
parsing.
There
is
an
open
discussion
about
matching
NPM
scopes,
but
that's
fairly
recent
I
don't
know
of
any
parser
problems
between
what
WG
import,
specifiers
and
node
zsm
imports
specifiers.
If
you
do
NPM
scopes.
But
if
you
take
up
a
protocol
like
Jordan
said
it
becomes
a
very
special
snowflake
that
we
can't
really
ever
polyfill
easily
across
systems
and.
G
In
respective
t39
stuff,
there's
a
lot
of
competing
constraints
such
that
I
think
it's
unrealistic
to
expect
anything
to
come
from
tc39
for
quite
a
while,
and
it's
possible
that
it's.
You
know
that
any
sort
of
built-in
modules
is
also
an
untenable
direction.
That's
a
very
real
possibility,
so
I
don't
think
that
node
should
wait
on
what
might
come
at
it
from
the
language
as
long
as
we
pick
something
that
is
not
knowingly
incompatible
with
you
know
something
that
might
come
in
the
future.
G
B
E
Sorry
I
lost
my
train
of
thoughts,
so
they
the
one
discussion,
it's
cancelled
out
of
the
ecosystem,
works
with
that
strong.
So
you
can't
reuse
those
magnets.
Without
with
that
scope
in
mind,
it's
a
major
problem,
if
you
start
doing
that.
So
if
you
decide
not
to
use
that's
going
to
be
there
also
the
moment
we
start
introducing
and
pushing
advertise
for
all
coal
modules.
What
will
happen
is
that
all
core
modules
will
all
core
modules.
E
Those
will
have
a
three-year
cycle
to
get
in
so
because
we're
releasing
it
in
a
minor
league,
but
you
know,
even
if
you'll
be
back,
for
people
keep
using
all
version
of
node.
So
if
all
of
this
with
the
three
year
cycles,
if
you
want
to
plan
to
migrate
everything
to
add
nodejs,
that's
that's
my
main
concern.
That's
my
main
concern.
So
that's
about
right.
G
So
from
from
what
I
heard
from
Mateos
comment,
one
of
the
things
that
jumped
out
to
me
was
he's
saying
a
three-year
cycle
to
get
the
namespace
into
node,
but
the
adding
as
long
as
his
node
owns
the
namespace
on
NPM
to
me.
That
could
be.
We
could
call
that
assembler
minor
and
backport
it
immediately
for
alma
core
modules.
G
E
G
E
Typically,
she
passed
on
the
latest
version
of
the
and
the
NTS
resist,
so
I
can
definitely
write
a
time
value
that
part
of
the
ties
with
the
latest
release,
but
using
the
new
at
UGA
/fs
sentence,
but
it
won't
really
pass
on
an
older
version
of
the
thing
causing
ecosystem
complexities
in
general,
all
the
other.
We
can
mitigate
this
as
much
as
we
want,
but
it's
just
going
to
create
stress.
E
J
Having
consistency
across
the
board
is
something
that
I
think
should
be
valued
because
you
know
like
Jordan
was
saying
these
are
mostly
just
you
know
redirecting
what
you're
importing
to
the
one
without
the
namespace
for
existing
modules,
we
don't
have
to
update
the
documentation
for
things
to
like
all
use
at
nodejs
/fs,
but
I.
Don't
think
anybody
is
in
a
rush
to
do
that
until
all
the
release
lines
are
supporting
this
feature,
but
I
would
like
whatever
it
is
to
be
done
consistently,
not
to
be
many
more
specific
modules.
I
agree.
E
A
B
Okay,
I
think
rich
has
his
hand
up
yeah.
Sorry,
I
can't
find
that
thing
in
the
client
Aires,
my
handsome
so
Joey,
just
just
to
get
this.
That
I
want
this
to
be
lost
for
the
recording,
but
Joey
had
a
comment
that
I
don't
think
we
should
polyfill
them
on
NPM.
Some
people
use
core
modules
because
they
come
out
of
the
signed
binary
and
should
be
secured
with
NPM.
You
don't
have
that
signing
story
and
Jordan
responded
it
to
be
a
reacts
port
of
the
node
core
module,
I'm,
not
sure
signatures
matter.
There.
B
D
So
I'm
not
a
fan
of
it
and
like
him,
it's
like
for
me.
It's
this
thing,
I've
liked.
It's
probably
not
worth
the
energy
of
fighting.
It's
like
I
mean
if
everybody
else
thinks
it
makes
sense
sure
like
for
me.
Consistency
also
means
that
that,
like
people
who
are
used
to
and
the
understanding
that
they
can
import
car
modules
with
just
require
some
name
that
that's
gonna
keep
being
that
way,
but
maybe
that's
just
me
so.
B
G
J
B
F
B
D
Mm-Hmm
I
mean
I
guess
what
makes
sense
at
this
point
is
like
it's
hard
to
bring
actual
arguments
for
like
keep
doing
it.
The
way
we're
doing
it
so
far,
I
I
mean
like
in
the
past.
We've
had
the
experience
that,
like
getting
modules
from
people
who
own
them
on
NPM
is
not
all
that
hard
except
like
me,
when
I
went
with
worker
I
mean
like
I,
guess
that
on
the
one
side
that
doesn't
really
scale
on
the
other
side,
well,
I
mean
like
do
we
want
car
modules
to
scale.
A
A
A
E
A
A
H
A
D
It
might
make
sense
like
put
the
issue
that
we
skipped
in
the
beginning
now,
which
is
like
the
Vargas
implementation
feels
like.
That
is
the
only
question.
That's
left
open
there
like
it's.
Currently,
the
module
worker
undersquare
threads,
which
is
not
taking
and
cannot
be
taking
them
in
at
p.m.
and
it's
like
are
we
it's
like
I
want
to
know?
Can
I
merge
this
PR
at
this
point?
It's
experimental
it's
behind
a
flag,
but
but
I
would
also
have
you
found
of
jb
changing
it
again
later.
B
D
J
K
K
A
D
A
D
B
B
B
D
B
A
B
B
B
L
Okay,
so
in
general,
I
creates
a
TPR,
because
it
is
out
of
my
perspective
about
the
user
experience
that
when
you
set
the
limit
into
any
arbitrary
big,
then
you
could
in
theory,
end
up
with
a
arrow
and
you'd
he'll
inspect
as
a
debugging
tool.
So
it
should
pretty
much
bring
the
best
experience
possible
to
the
user.
L
So
it's
an
edge
case
and
just
felt
natural
to
me
that
we
shouldn't
throw
an
arrow
I'm
totally
fine,
with
the
comment
that
and
I
has
in
there
about
right
now.
It's
still
emitting
an
arrow,
no
sorry
emitting
in
warning
in
case
the
maximum
called
sex
is
actually
reached
and
instead
just
adding
that
information
to
the
large
object
itself.
So
yeah
Bryan
was
against
it.
I.
Don't
really
have
a
lot
other
wants
to
say
about
it.
B
Yeah-
and
it
has
eight
other
approvals,
I
think,
seven
of
which
are
TSC
folks,
it's
a
relatively
short
thread
and
I
was
kind
of
hoping
that
we
could.
You
know
people
would
have
read
through
it
that
we
can.
We
can
resolve
this
today
quickly,
but
it
would
need
yeah.
It
does
seem
like
we'd
need
a
vote
because
Bryan
Bryan
objects,
and-
and
so
it
basically
can't
land
unless,
unless
the
SE
decides
to
break
the
impasse,.