►
From YouTube: Node.js Foundation Modules Team Meeting 2019-07-03
Description
A
So
we
are
now
live
with
the
July
3rd
meeting
of
the
node.js
modules
team
and
joined
by
a
number
of
my
colleagues
here
for
us
to
discuss.
You
know
whatever
we
have
on
the
agenda,
and
so
we
have
one
item
on
the
agenda
right
now,
though,
there's
something
else
that
I
think
we
should
discuss
as
well.
I'm
just
dropping
the
dock
into
the
chat,
and
please
add
your
name.
A
A
I
believe
that
there's
a
new
poll
request
related
to
modules
that
Gus
opened.
That
is
slightly
blocking
this.
Let
me
just
find
it
number
twenty
eight
four
six,
six
thank
you
for
being
patient
with
me.
Will
I
do
this
live
okay,
so
and
then
Jordan
has
joined
this
great
so
packaged
on
exports,
which
is
modules
issue
three
for
one
I
believe
that
economists,
that
a
pull
request
has
been
opened.
A
A
A
Was
about
like
including
the
ability
to
do
dot
for
an
alias
for
the
export
of
the
main
guy
has
just
joined
us?
Wes
is
mentioning
that
VHS
to
add
support
for
synthetic
modules
which
are
allowed
to
throw
during
exports
set
up,
which
has
some
questions
about
the
original
dynamic
modules
proposal.
The
West
are
you
talking
about
the
proposal
that
we
had
made
to
tc39.
A
B
B
That
could
be
worth
discussing,
for
example,
supporting
the
the
dot
for
the
main,
whether
they
should
be
a
boolean
property
and
how
that's
treated
and
various
things
like
that.
There
there
is
one
other
thing:
I
was
thinking
in
as
well
that
that
could
be
worth
discussing,
which
is
when
you
have
the
main
field
in
the
package.json.
You
can
choose
whether
you
want
to
have
the
leading
dot
forward,
slash
or
not
and
I'm
wondering
if
maybe
we
should
make
it
optional
for
exports
as
well.
C
E
C
Because
none
of
them
go
to
bear
identifier
like
you
can't
have
a
bear,
bear
identifier
there,
so
so,
if
they,
even
if
they
required
the
dot,
slash
main
has
been,
would
have
probably
had
the
throw
you
couldn't
make
your
main
be
one
of
your
like
node
modules
packages.
So
given
that
I
feel
like
it's
a
mistake
that
we
shouldn't
repeat
to
make
them
optional,
I
think
that
since
they're
like
that,
since
they
shouldn't
be,
bear
identifiers
that
it's
clearer
to
essentially
throw
when
the
dot
in
the
slash,
you
know
when
the
dot
isn't
there.
C
B
Janitor
response
your
comments
on
the
well-formed
field,
I'm
happy
to
work
that
out
in
the
issue
queue
with
you,
and
maybe
we
can
come
up
with
some
well-defined
semantics
there
and
points
certainly
taken
on
on
the
being
explicit
about
the
fathering
I.
Guess,
there's
also
a
certain
visual
cue
that
comes
with
making
sure
that
the
dark
/our
used,
which
could
be
useful
to
users
that
they
truly
understand
what
it
is,
that
they're
mapping
and
fit
there.
There
isn't
any
confusion
there,
so
I
can
get
both.
E
Yeah
I
am
obviously
always
in
favor
of
the
more
explicit
and
more
clear
option
so,
for
example,
exports
values
having
docked
at
the
beginning.
The
only
reason
why
I'm
I
should
I
think
we
should
be
careful
with
that
is
because,
because
of
the
existing
main
fields
like,
especially
if,
like
the
curve,
the
way
that
the
current
semantics
works,
it's
basically
dead.
Exports
is
a
pretty
straightforward
extension
of
the
main
field
or
the
main
it
becomes
just
randomly
one
of
the
exports
fields,
which
means
that
we
would
have
a
main
field.
E
That
is
basically
the
same,
but
it
works
differently
than
all
the
others,
which
is
also
kind
of
confusing.
So
if
we
disallow
the
traditional
main
field,
values
that
don't
have
a
leading
dot,
slash
I
think
we
should
definitely
be
careful
that
we
have
a
very
good
error
message
exactly
where
it's
wrong.
He
is
the
most
likely
thing
you
meant
kind
of
deal.
C
E
A
C
So
just
a
respond
to
that
question.
I
think
that
this
is
a
sort
of
like
we're
we're
aiming
to
get
the
behavior
in
both
mom
and
jessandian
m,
and
this
is
the
sort
of
behavior
that,
like
kind
of
needs
to
be
by
default.
Otherwise
someone's
package
isn't
going
to
work
the
way
they
expect
so
I
think
that
it's
that,
if
we're,
unless
someone
has
consensus
to
the
general
approach,
it
seems
like
all
those
you
know,
maybe,
except
for
a
brief
tryout
period,
if
she's
Bruton
to
get
it
done
flagged
as
rapidly
as
possible.
C
B
I
think
it
should
be
additive
for
common
jeaious.
The
thing
there
is
just
two
because
effectively
we
have
two
separate
resolvers,
the
common
Jarius
resolver
and
the
ESMA
resolver.
So
it
would
be
a
separate
piece
of
work
to
bring
it
into
the
comedy
resolver,
but
it
should
be,
in
theory,
relatively
straightforward,
I'm
sure
we'll
probably
discover
things
as
we
dig
into
that
yeah.
B
A
B
So
I
I
have
very
limited
time
at
the
moment,
so
whether
I'll
be
able
to
also
implement
the
common
J's
resolver
part
is
the
only
thing
that
I
am
uncertain.
Okay
I
mean
if
we
can
get
it
in
flagged,
and
then
you
know,
if
we're
looking
at
this
little
bit
two
months
sort
of
buffer
here,
then
then
I'm
sure
I
could
have
a
look
at
it
within
that
time.
B
C
Well
for
comment:
yes,
it
would
have
to
point
to
the
Maine
right
I
mean
because
that's
what
that's,
what
dot
means
it
means
do
it
resolves
in
this
directory,
which
goes
to
the
main
or
index
and
follows
extension.
Look
like
it's
fine
if
any
and
he
has
them.
It
doesn't
look
at
the
main
lead
debate
that
separately,
but,
like
I,
think
in
common
jazz.
That's
the
only
thing
to
do.
E
So
my
vote
will
definitely
be
to
remove
it
from
exports,
and
the
reason
is
that
dot
and
Maine
are
exactly
the
same
thing.
So
like
it's,
it's
the
exact
same
thing
that
they
map
so
having
both
seems
just
dangerous
and
confusing,
because
either
people
will
randomly
use
one
or
the
other.
So
it's
just
two
places
you
have
to
check
or
people
will
accidentally
put
two
different
values
into
both
and
then
it
will
break
or
get
confusing
error
messages.
E
So
I
think
just
disallowing
dots
specifically
in
the
exports
make
sense,
because
that
means
Maine
is
here
to
stay.
That's
the
thing
that
people
know.
That
is
how
they
map
this
part,
and
it
also
gets
rid
of
what
some
people
have
considered.
That
Sam
was
confusing
property
key,
which
is
just
a
dot
which
doesn't
is
not
as
evocative
as
dot
slash.
Something.
C
But
if
we
are
attempting
yes
and
so
like
when
wes
is
reply
like
it's,
if
if
we
actually
are
trying
to
say
we
don't
want
main
to
be
duplicated
in
exports,
then
we
need
to
actually
say
that
the
fully
resolved
key
in
the
exports
object
can't
map
to
like
can't
hit
that
package.json
or
something
to
that
effect.
And
if
we're
before
prepared
to
say
that
then
fine
that
sounds
good.
You.
B
B
Bring
up
another
interesting
point
there
Jordan,
and
that's
that
we
haven't
considered
what
our
permits
is.
It's
effectively
like
URL
validations
are,
for
example,
I,
believe
somewhere
we
have
a
rule
that
actually
doesn't
allow
dot
and
dot
dot.
I
forget
exactly
which
code
path,
it
is
I,
think
it
might
be
in
the
file
URL
to
pass
stuff.
We've
got
some
checks
like
that
sort
of
thing,
but
we
could
potentially
have
a
validation
that
says
if
you
have
a
dot
dot
or
dots
in
your
targets
in
a
thorough
validation
error,
and
then
you
want.
B
C
E
C
That,
if
the
keys
like
and
then
it-
and
it
knows
no
kind
of
naive
restrictions
on
the
string,
values
in
the
keys
are
actually
going
to
stop
the
edge
cases.
And
it's
fine.
If
we
want
to
add
that
those
restrictions
for
ergonomics
reasons,
but
I
think
that
we
still
need
to
be
actually
checking
whatever
the
fully
resolved
path
is.
If
that's
something
we
want
to
restrict
I.
C
C
C
A
C
But
like
a
leading,
slash
already
has
a
meaning
in
node,
which
is
the
root
of
the
filesystem
so
like,
if
I
think,
if
we
want
to
make
essentially
syntax
for
the
root
of
the
module,
which
would
be
awesome,
then
that
needs
to
be
something
separate.
You
know
like
chilled
or
some
other
bike
shed,
but
like
one
that
exists,
then
that
we
could
use
that
so.
B
One
way
to
restrict
it
would
be
to
say
effectively
for
now
your
right
hand.
Side
has
to
start
with
the
dock
forward,
slash
and
if
it
doesn't
that's
a
validation
error
and
then
also,
if
there's,
we
could
either
restrict
it
so
that
it
must
resolve
within
the
package
or
we
could
separately
not
commit
dot
or
dot
dot
segments.
Within
that
right
hand,
side
as
well.
Well,.
C
We
could
we
could
do
both
like
we
could.
We
can
assert
that
it
can't
have
the
dot
dots
in
it.
We
could
assert
that
it
can't
be
a
dot
by
itself.
We
can
also
assert
that
it
must
resolve
to
being
within
the
package,
like
the
the
adding
those
additional
constraints
just
gives
us
the
opportunity
to
give
better
error
messages
sooner.
You
know
and
cheaper
right.
B
F
I
just
wanted
to
mention
that,
like
we
can
look
at
it
as
we're
trying
to
define
the
rules
for
the
map,
or
we
could
think
about
it
as
if,
if
there's
any
folder,
that
has
a
package.json
that
has
a
main.
It
cannot
be
mapped
by
any
other
package,
because
the
care
package
has
sub
packages
and
those
soft
packages
have
package
you
know
like
have
mains,
then
you
shouldn't
be
able
to
define
a
mapping
for
a
folder
that
has
a
package.json
with
the
main
in
it.
F
I
think
that
should
be
a
rule
that
should
throw
whenever,
whenever
any
package
tries
to
find
anything
within
its
scope
that
was
over.
You
know
that
would
shadow
a
sub
package
in
a
folder,
because
that
would
not
have
a
double
dot
and
well
it
would.
It
would
effectively
be
defining
something
that
that
a
main
should
have.
You
know
the
priority
for.
B
E
What
I
was
about
to
say
was
if
we
want
to
end
the
first
Lanta
first
iteration
and
an
experimental
flag
anyhow
I
think
it
has
to
say
here.
The
following
things
are
currently
still
being
worked
out
and
will
be
resolved
before
we
remove
the
flag
like
for
me,
something
like
what
are
the
exact
restrictions
on
the
left
and
right
inside
of
the
Xbox
field
is
something
that
we
can't
totally
iterate
on.
While
it
is
flagged,
and
we
can
just
have
it
as
a
Disney
to
be
resolved
before
unflagging.
D
So
I
think
me
and
a
few
others
were
saying
that
the
key
in
the
exports
table
like
a
URL
fragment.
It's
meant
it
to
be
just
like
a
plain
string:
suffix
that
comes
after
the
package
name
as
you're,
defining
that
the
namespace
libs
public-facing
namespace
that
lives
under
the
package,
name
and
I.
Think
Jordan,
please
correct
me.
If
I'm
wrong
I
think
you
believe
that
it
ought
to
get
like
fully
resolved
right.
D
I
guess
the
main
thing
that
I'm
interested
in
is
that
when
you're
defining
your
packages
exports,
you
are
only
defining
the
public
entry
points
that
live
inside
your
package
and
the
results
are
fully
resolving
it.
For
example,
if
you're
allowed
dots
you're
allowed
to
escape
your
package,
then
you
would
be
almost
implying
that
you
can
redefine
any
parts
of
the
resolver.
Oh.
C
C
D
In
with
that,
so
I
don't
really
want
to
speak
for
the
CJ
s,
because
I'm
I
have
an
unhappy,
but
just
talk
about
the
the
import.
But
if
you
were
to
specify
that
fully
qualified,
and
so
the
package
name
slash
through
slash
index
tears,
but
that
there
then
that
is
remapped
as
the
exports
dictionary
dictates.
C
C
D
C
C
Resolution
it
would
apply
like
like
if
your
tea
was
foo
slash
index
dot
JSP
able
to
to
that
pass
will
work
without
needing
to
be
explicitly
specified,
collect
them
with
the
the
file.
So
if
I
5
past
the
flag
that
enables
extension
resolution,
so
we
still
have
to
answer
that
question
for
ESL,
because
we
have
that
behind
the
flag.
C
D
C
D
C
C
C
C
The
ergonomics
that
I'm
interested
in,
which
is
that
resolution
rules,
don't
have
weird
you
know,
on
algebraic,
educators
or
whatever,
like
things
that
don't
matter
everything
just
kind
of
works,
III.
C
Yes,
yes,
exactly
like
and
the
right
hand
side
would
be
real
access,
and
so
then
any
resolution
rules
that
apply
would
still
apply
or
don't
and
then
the
left
hand
side
would
be
the
virtual
file
system
essentially
which
doesn't
need
an
extension
because
note
can
get
its
own.
All
of
the
parsing
hints
it
needs
from
whatever
the
right
hand.
Side
is
yeah.
D
E
Yeah
trying
to
backtrack
a
little
bit,
so
the
current
expectation
is
that
you
fall
off
of
the
X
book.
Map
is
dot,
slash
maps
to
dot,
slash,
which
means
fate,
I
think
what
we
escaped
so
far
is
the
directory
mapping,
which
is
just
expose
this
filesystem
prefix.
As
this
other
process
of
prefix
and
dot,
slash
Maps,
the
dot.
Slash
is
basically
exactly
the
current
behavior.
E
The
problem
with
doing
expensive
or
well
elaborate
resolution
for
the
left
hand
side
is
that
you
lose
the
explicitness
of
what
your
exported
things
are.
So
basically
you
are
opting
into
refactoring
hazards,
because
now
you
have
to
also
make
sure
that
if
you
change
anything
about
details
of
how
your
exports
out
of
find
that
all
possible
resolutions
to
that
new
export
value,
still
work,
which
seems
like
that
seems
to
kind
of
contra
to
what
this
proposal
could
provide,
and
then
it's
also
metal.
E
So,
if
you
put
into
the
export
seafood
session
in
Dexter
chairs,
why
would
you
ever
do
that
instead
of
just
putting
into
the
export
map
foo
because,
like
how
many
consumers
of
your
package
would
then
go
out
of
the
way
to
pride?
Foo
/index
in
like
well,
your
package
name
slash
food,
slash
index
when
they
could
just
write
your
package
names
foo.
It
seems
there's.
E
But
you
know
why
would
the
like
that
seems
like
a
very
broken
lint
rule
away?
It's
about
packages
like
about
specifiers
/foo?
If
only
/
who
exists,
then
the
literal
really
should
be
fixed,
like
it's
the
same,
if
you
would
have
foo
J's
right
now,
like
it's
a
is
it
it's
definitely
a
choice
that
you
made
while
designing
your
package.
It's
not
a
really
a
literal
issue
at
this
point.
C
C
E
E
That
a
makes
it
a
lot
harder
for
a
human
being
to
understand
what
the
final
URL
will
be
because
is
resolved,
then
you
redirected
via
soon
link,
then
looked
up
an
Xbox
app
and
then
you
find
another
sibling
like
I
would
rather
keep
it's
already.
Adding
redirection
I
would
rather
keep
the
redirection
as
small
as
possible,
and
so
the
current
string,
concatenation
semantics
for
the
left
hand
side
where
it's
just
package
name
or
whatever
is
the
rest,
gets
concatenated
afterwards.
E
Basically,
no
semantic
analysis.
It
doesn't
technically
even
have
to
be
a
valid
URL
or
path
character
as
far
I
care.
So
if
you
wanna
have
package
name,
slash,
poop
emoji
in
theory,
it
would
just
work.
No
matter
what
the
file
system
is,
because
it
would
not
never
actually
hit
the
file
system
before
it
gets
the
mapping.
B
B
A
Okay,
so
with
all
that
being
said,
is
there
any
changes
to
our
current
plan
of
up
streaming?
It
seems
to
me,
like
it,
doesn't
change
our
exact
plan.
We
should
move
forward
with
what
we're
planning
on
doing,
and
these
are
things
that
we
would
want
to
see
fixed
in
between
you
know
now
and
unflagging
is
that
accurate.
A
I'll,
take
the
no
one's
saying
anything
as
approval
that
that's
what
we
want
to
do
great,
there's
random
question:
how
are
paths
in
the
package.json
resolved
of
the
package.json
itself
is
assembling
relative
to
the
link
location
or
to
the
real
path?
Well,
Wes.
My
brain
is
unfortunately
unable
to
figure
that
out
for
you
right
now,
but
guy
just
said:
J
package.json
is
not
real.
A
Past
I
would
like
to
suggest
that
we
take
the
rest
of
this
offline
for
discussion
and
we
take
the
last
13
minutes
that
we
have
to
discuss
two
more
things
really
quickly:
issue
28
466
from
the
main
repo.
This
was
open
by
Gus
and
it
hopes
to
expose
the
promises.
Api
is
a
little
bit
nicer
within
ESM,
because
right
now,
the
way
in
which
they're
exposed
does
not
allow
for
like
deep
searching
now.
A
I
know
that
there
were
concerns
about
some
of
these
patterns
originally,
and
maybe
we
want
to
take
a
slightly
different
approach
than
what's
been
handled
here,
but
I
believe
that
the
file
system
approach
wasn't
moved
forward
for
security
concerns
that
need
James
Stone
to
come
in
and
mention
that
again.
But
this
got
brought
up
in
light
of
another
PR
to
155
one
you
can
tell
by
the
in
almost
an
order
of
magnitude
earlier
in
issues.
F
Yeah
so
I
think
it's
gonna
come
off
not
now
that
a
lot
of
people
are
looking
at
the
colons
notation,
it
will
likely
end
up
making
more
sense.
After
you
know
all
the
disputes
and
all
the
different
arguments
that
those
would
actually
be
registered
schemes
and
I
think
there
was
an
issue
about
that
before.
But
it's
it's
really
a
security
aspect
that
if
it's
right
there
can
only
be
one
of
it
so
I'll
just
leave
this
point.
F
A
E
Yeah,
basically,
just
a
very
quick
I
believe
that
the
namespaces
make
sense
and
I
believe
that,
since
it
to
me,
Utley
looks
at
least
looks
like
the
browser's
going
with
STD
:.
The
colon
Berrien
seems
like
it
would
be
silly
for
no
chairs
to
not
then
follow
that
precedent.
At
least
that's.
That
would
be
my
opinion.
C
Okay,
so
I'm
still
trying
to
find
a
a
room
apologize
for
the
noise,
so
first,
the
specific
choice
of
protocol
name
is
something
that
I
think
isn't
a
foregone
conclusion,
and
it's
not
something
that
the
language
is
gonna
go
with
so
I
think
it's
likely
that
browsers
will
end
up
making
a
different
choice
once
the
language
has
selected.
Something
different,
but
certainly
browsers
are
just
always
going
to
use
a
protocol,
because
the
only
other
option
would
be
to
follow.
Node
and
I.
C
Don't
get
the
impression
that
the
folks
making
those
decisions
for
browsers
care
too
much
about
the
patterns
that
node
has
established
I,
don't
think
it
would
be
silly
for
Noah
to
do
something
different
than
browsers.
As
a
general
statement,
I
think
that
node
has
a
lot
of
capabilities
browsers.
Don't
in
many
ways
know
it
is
better
than
browsers
and
in
many
ways
node
should
not
itself
or
hamstring
itself,
rather
just
because
browsers
have
done
so
to
themselves
so
I'm,
not
very
a
fan
of
that
argument
of
like
well
browsers,
are
bad
in
this
way.
C
So
we
should
be
bad
in
this
way
too,
although
obviously
consistency
across
the
ecosystem
is
a
good
thing,
etc.
So
I
think
that
I
would,
as
I
opened.
You
know,
as
I've
commented
in
that
issue
many
times
and
discussed
with
Miles
a
number
of
times
as
well.
My
preference
would
be
to
go
to
follow
the
paved
cow
path
and
do
use
an
NPM
style
scope.
C
I
think
that
the
V,
like
C,
has
sort
of
shifted
such
that
it's
likely
that
it
will
end
up
being
a
protocol,
despite
my
efforts
and
preferences,
but
I
think
that
I
think
that
that
that
will
end
up
being
unfortunate
because
I
think
there's
a
lot
of
value
in
in
overlapping
with
the
node
modules
space
in
terms
of
like
poly
filling
and
things
like
that.
I
think
those
are
some
thoughts
of
off.
A
C
E
C
A
The
the
bits
that
I
would
say-
and
obviously
we
need
to
reach
some
degree
of
consensus
on
this
upstream
to
have
anything
happened.
We've
been
discussing
this
for
almost
a
year
and
a
half
now
and
it
is
blocking.
It
has
blocked
landing
new
things.
It
is
not
having
a
name.
Space
has
caused
us
to
name
modules,
names
that
aren't
necessarily
preferable
and
has
arguably
gotten
us
to
the
space
where
we
are
also,
you
know
having
functionality.
That
is
less
than
ideal.
A
What
I
would
like
to
say
is
see
if
we
could
is
making
some
level
of
decision
independent
of
our
group.
There
are
other
groups
within
the
note
project
who
are
interested
in
using
the
Aetna
Jaya
scope
to
publish
modules
that
are
maintained
by
core
I.
Believe
Jeffrey
is
one
of
them,
and
the
work
that
he's
looking
at
doing
for,
like
contains
module
syntax,
is
potentially
looking
at
being
an
ecosystem
module
as
well
I.
Think
there's
a
bigger
question
about.
A
If
we
should
even
do
that,
and
what
modules
would
exist
in
that
space,
but
just
stating
that
like
it
is
also
now
blocking
those
efforts.
I
absolutely
do
not
think
that
that
we
should
be
making
that
we
should
be
using
the
namespace
for
more
than
one
thing.
If
we're
gonna
use
at
nodejs
slash,
we
absolutely
should
not
be
using
it
for
both
built-ins
and
for
externals,
which
should
be
what
for
one
or
the
other,
and
if
the
browsers
and
other
runtimes.
This
is
not
just
node
in
the
browser,
but
this
would
be
other
JavaScript.
A
Runtimes
are
looking
at
using
JSON,
for
example,
as
a
built-in
we
will
be
getting
those
built-ins
in
our
runtime
and
Jordan
I.
I
know
that
you're
saying
that
you
don't
think
that
that
vendors
or
you
know
the
committees
would
listen.
I
disagree
with
that
sentiment.
I
do
genuinely
believe
that
have
node
were
to
make
a
decision
here
and
it's
a
decision
that
aligns
with
what
is
currently
in
the
spec
process.
A
As
far
as
like
the
mechanism
being
a
scheme,
I
genuinely
believe
that
that
would
be,
you
know,
push
people
more
in
the
direction
of
going
there.
I
think
it
will
be
very,
very
weird
if
we
end
up
having
built
in
namespaces
for
JavaScript,
that
rjs
:
and
all
of
a
sudden
nodejs
slash
is
just
for
the
node
built-ins,
like
that's
odd,
it's
weird
to
have
to
teach
people
multiple
things
and
I
understand
that
we're
already
talking
about
teaching
them
multiple
things
for
the
difference
between
built-ins
and
ecosystem
modules,
but
those
are
very
distinct
things.
A
F
F
A
F
A
A
You
know
I
would
like
to
seek
or
move
forward
on
this
sooner
than
later,
and
it's
important
that
the
folks
on
this
call
are
able
to
chime
in.
If
you
have
opinions
thanks
everyone
for
joining
and
the
meeting
is
there
any
last-minute
business
anyone
needs
to
bring
up.
Thank
you.
Okay,
great
everyone
have
a
great
long
weekend
for
those
of
you
that
have
one
at
a
great
short
weekend
for
those
either
don't
talk
to
you
soon.