►
From YouTube: Node.js Foundation Modules Team Meeting 2019-07-17
Description
A
B
Yeah
thanks
a
lot.
I
really
appreciate
the
time.
I
tried
to
summarize
the
issue
a
little
bit
in
the
negative
issue
for
this
meeting,
essentially
for
the
github
package
registry.
We
want
to
be
good
citizens
and
try
and
figure
out
a
way
to
kind
of
coexist
with
NPM,
but
as
I
kind
of
detailed
there's
a
bit
of
problem
about
name
spacing
and
so
we're
trying
to
figure
out
what
the
best
kind
of
resolution
is.
B
Namespace
not
sure,
if
that's
the
actual
term
for
it,
but
you
know
when
you're
looking
for
react
to
just
have
a
single
react
package
without
a
URL
that
kind
of
gives
you
a
domain
destination
for
that,
so
we're
trying
to
figure
out
how
we
can
integrate
so
I'd
love
some
feedback
on
the
proposal.
I
saw
a
couple
notes
in
there.
I
think
I
posted
this
earlier
in
the
TSC
meeting,
and
so
some
of
the
discussion
is
also
having
there
as
well.
A
So
some
of
the
stuff
that
I
can
add
Brian
that
we've
been
having
discussions
about
specifically
around,
like
namespaces,
there's
kind
of
like
two
different
bits
here.
One
is
name
spaces
for
built-ins,
so
there's
a
proposal
at
tc39
recently
changes
name.
It
was
JavaScript
standard
library.
Now
it's
built
in
modules,
they're,
looking
at
creating
built
in
embedded
modules
into
like
essentially
the
JavaScript
VM.
Those
are
being
looked
at.
As
you
know,
I
think
UUID
is
an
example
of
one
that's
being
explored
right
now,
like
what's
a
module.
A
That,
like
is
not
necessarily
a
core
language
feature,
but
is
something
that's
you
know
written
a
whole
bunch
of
different
times
can
be
made
against
some
sort
of
RFC,
but
that
would
have
to
live
in
some
sort
of
namespace
and
the
ones
that
were
tossed
around
where
STD
and
Jas
I
think
Chase
is
what
they're
moving
forward
with
and
there's
some
kind
of
meta
questions
about,
whether
or
not
there
should
be
different
namespaces
for
different
kinds
of
modules.
That
does
not
have
consensus
around
it.
A
So
would
there
be
like
a
web
colon
and
a
jeaious
colon
and
a
maybe
sound
:,
but
it
was
just
kind
of
like
if
there's
things
that
are
Dom
specific
does
that
belong
in
a
gif
same
space
or,
alternatively,
is
the
jas
namespace,
something
that
you
know
any
standards
body
can
publish
to,
in
which
case
we
need
some
sort
of
joint
governance
process
around.
That,
so
kind
of
that
is
one
place
where
things
are
being
explored.
The
web
assembly
working
group
is
also
working
on
huazi.
The
web
web
assembly
system
interfaces
and
we're.
B
A
A
A
D
Yeah
one
thing
I
want
to
throw
in
as
like
related
to
work.
That's
currently
going
on
is
also
entropic
who's
very
early
stages,
but
they
are
also
trying
to
figure
out
a
way
to
distinguish
between
different
origins
for
packages
as
an
additional
namespace.
In
that
case,
a
a
protocol
definitely
has
to
become
awkward
because
of
every
single
instance
of
entropic
or
any
other
distributed
package
registry
would
get
its
own
protocol.
C
Okay,
Michael
yeah
I,
just
I
guess
I
was
thinking
as
you
were
talking
that,
like
the
name
spacing
you
were
describing,
this
is
quite
different
than
the
name
spacing
based
on
location
right.
It's
so
and
they
would
almost
be
like
you'd
have
that
double
them
up,
potentially
double
names
name
spacing
because,
like
two
of
those
two
of
those
Styles
could
apply.
So
if
there
was
some
way,
I
mean
I,
guess
the
challenge
is
that
it's
hard?
A
Yeah
I
think
for
me
there,
a
lot
of
it
was
about
like
we
could
do
like
NPM,
colon
or
github
colon,
or
something
like
that
inside
of
the
specifiers,
but
that
was
that
was
kind
of
a
solution
that
a
I
was
mentioning
a
couple.
Tsc
members
were
not
very
fond
of
like
having
kind
of
leak
into
the
specifier
itself.
A
E
I
think
you
could
take
some
experience
if
you
look
at
what
happened
on
mobile
operating
systems
into
account.
The
original
way
that
you
would
do
deep
linking
into
apps
was
with
protocols
that's
now
round
upon
for
a
variety
of
reasons,
and
so
looking
at
historical
reasons
on
why
the
like
having
tons
of
protocols
would
lightning
here.
E
We
don't
have
to
discuss
that
right
now,
but
what
they
moved
on
to
is
something
that's
generally
called
Universal
links
where
an
app
can
occupy,
essentially
a
scope
within
a
existing
protocol
for
mobile
operating
systems.
That's
generally
going
to
be
HTTP,
so
they
have
a
similar
problem
where
they
have
to
delegate
to
the
proper
app
within
these.
F
Yeah,
so
this
part
of
the
conversation
is
kind
of
new
to
me:
I
I!
Guess
it's
not
really
something
I
consider
before
maybe
heard
about
in
the
conversations
I
haven't
felt
as
good
and
maybe
could
but
I'm
kind
of
maybe
the
telescope
for
this
particular
conversation,
but
I'm
kind
of
interested
to
know
where
people
think.
If
we,
if
we
have
see
multiple
specifiers
or
whatever,
we
want
to
call
them
four
different
registries
or
essentially
different
installs,
where
those
things
will
live
on
disk
or
network
or
wherever
you're
actually
pulling
the
file
from.
D
Yawn
yeah
I
mean
just
for
prior
work,
there's
also
the
go
and
well
originally
I
could
guess
the
Java
ecosystem,
where
you
would
just
have
a
chrome,
dot,
guitar
dots
as
a
namespace,
which
gives
you
a
URL
dns-based
name
spacing
and
ownership
concepts
that
has
been
scaling
well
in
that
ecosystem.
As
far
as
I
know,
at
least.
A
G
A
G
A
A
We
are
we
using
the
specifier
text
to
explicitly
differentiate
between
those
sources
of
truth,
or
are
we
keeping
everything
in
like
a
flat
namespace
and
then
relying
on
package
managers
to
kind
of
smartly
decouple
that
the
latter
has
obvious
security
concerns,
but
the
former
also
has
kind
of
like
a
leaky
abstraction
as
far
as
like
bifurcating
the
ecosystem.
So
you.
G
A
G
Let
me
assume
for
the
rest
of
my
comment
that
we're
not
going
to
make
any
major
architectural
changes
to
the
way
that
modules
work
in
node.
The
only
thing
that,
like
the
specifier,
has
rules
that
it
already
follows,
and
we
like,
let's
assume
we
stick
to
those
which
means
that
the
package
is
what
installs
it
NPM
already
has
the
capability
per
scope
to
install
from
different
registries.
G
G
And
so
the
addition
of
github
to
that
to
me
is
something
that
I
think
node
and
modules
group
should
somewhat
weigh
in
on.
But,
like
you
know
just
but
in
terms
of
like
usability
and
DX
and
stuff,
but
that
it's
pretty
much
exclusively
an
NPM
decision
and
yarn
and
you
know
other
clients,
but
like
a
package
manager
decision
I,
don't
think
it
would
be
a
easy,
short-term
or
really
even
a
good
idea
for
node
to
become
directly
involved
in.
Where
do
packages
come
from.
B
Yeah
I
think
this
a
bunch
of
stuff
I
wanted
to
try
to
respond
to
so
like
yeah
I.
Think
I
generally
agree
with
what
Jordan
was
saying
there.
That's
like
it.
Listen
to
the
problem
we
ran
into
rate.
Is
that
because
NPM
is
has
been
very
nice
and
done
really
specific
things
about
github
URLs
over
time
means
that
we
are
in
this
spot,
where
it
generally
thinks
to
go
to
get
because
we
haven't
had
a
packaged
registry,
so
it's
very
hard
to
actually
feed
it.
B
A
URL
where
you
would
say
I
want
you
to
talk
in
the
m2,
this
github
URL
and
that's
like
one
of
the
binding
problems
that
we've
kind
of
found
here
like
and
I.
Don't
know
that.
Actually
you
can
tell
it
to
talk
to
other
registries
in
the
same
way,
but
it
always
assumes
that
a
github
URL
is
doing
certain
things
against
kit
so
that
that
kind
of
comes
to
like
why
we
liked
the
concept
of
the
NPM
colon
protocol,
because
isit
I
created
a
new
space
where
we
could
say.
B
B
I,
don't
know
how
to
weigh
in
on
that
specifically,
but
yeah
like
I,
guess:
I've
seen
that
and
as
a
web
person
who
used
to
work
for
Mozilla
for
a
long
time,
I
totally
fear
extra
protocols
as
well
and
and
then
you
know,
like
I,
guess,
going
back
to
the
time
the
location
of
the
package
or
tying
the
package
back
to
a
location.
Every
time,
I
think
for
us.
We
gonna
look
at
this.
B
Hopefully,
in
the
long
run
as
kind
of
an
IPSS
style
like
system
really
helping
out
here,
because
I
think
there
will
be,
they
may
be
a
lot
more
locations
involved
in
packages
and
that
we
can.
We
can
mitigate
a
lot
of
this
by
understanding,
what's
actually
within
the
package,
by
helping
like
having
metadata
that
more
concretely
describes
what
the
packages
this
matters
a
lot
to
us
github.
B
What's
in
the
package
itself,
which
means
that
then
we
could
really
help
describe
the
data
that
you're
getting
and
anyone
else
could
use
that
information
as
well
to
say
they
have
the
exact
same
package
that
github
has
but
you're
just
getting
it
from
a
different
source
location,
and
so
that
kind
of
is
how
we
hope
in
the
future.
Multiple
registries
having
the
same
package
might
be
medicated.
E
B
B
If
the
MDM
client
does
make
these
changes,
so
that's
kind
of
like
we
might
effectively
yeah
I'll,
participate
and
I
think
we'll
probably
bring
two
solutions
to
this.
Where
we're
saying
here's
our
long-term,
like
URI,
like
thing
that
we
figured
out
that,
like
you
all
agree-
and
we
agree-
is
like
a
good
path
going
forward
for
the
long-term
and
then
probably
here's
like
also
our
short-term
hack.
That
makes
the
NPM
client
work
for
existing
Klan
existing
services
and
Brian.
B
A
The
concern
was
far
more
about
like
this
leaking
into
specifier
text
and
being
inside
of
the
source
tree
itself,
so
like
yeah
it
more
about
like
not
wanting
to
see
like
like
NPM
colon,
lodash,
github
colon
thing,
so
that
you
would
actually
be
like
the
problem
would
be
more
about
explicit
explicitly
having
that
in
source
text.
There
wasn't
actually
really
any
concern
about
it
being
something
that
be
handled
by
NPM.
Okay,.
B
And
to
just
to
clarify
you're
saying
that
that
concern
isn't
about
like
the
package.json,
where
we're
referring
to
where
it's
coming
from
it's
more
about
the
source
text
or
is
it
impacting
yeah?
The
concern
was
not
about
the
package.json
at
all.
Okay,
cool
yeah
I
mean
I,
think,
that's
that's
exactly
how
we
want
it
to
work.
It's
just
but
yeah
like
right
now.
Npm
assumes
a
lot
of
things
about
github
URLs,
so
we
can't
offer
it's.
It's
found
to
be
very
difficult
to
offer
a
thing
where
we
point
to
get
up
as
a
registry
just.
A
A
So
because
we're
looking
into
trying
to
see
like
hey,
can
we
have
this?
You
know
be
standardized
and
go
through
the
official.
They
need
to
do
that
cool.
So
I
think
that
that
that
is
that,
on
this
topic
of
the
the
next
topic
that
we
have
lined
up
intersects
with
this
a
bit
because
it's
something
that
could
be
used
in
userland
to
implement.
A
D
Thing
I
would
maybe
do
is,
maybe
you
could
use
kind
of
the
use
case
that
Alex's
couldn't
be
running
into,
because
I
think
it
demonstrate
its
quite
nicely.
Some
of
those
restrictions
problems
with
what
the
current
loader
API
looks
like
I,
have
my
motivate
some
of
the
ideas
that
we
have
been
throwing
around
in
the
past.
H
Sure
yeah,
so
I'm
Alex
Pappas
Sean
I've
been
at
Google
for
a
bit
working
on
experiments
into
transparently
loading
dependencies
from
a
bundle
of
trying
to
get
something
that
works
that
doesn't
require
buying
into
a
particular
dependency
loading
system
like
web
pack,
and
it
could
be
applied
to
projects.
More
generally
and
up
to
this
point,
that's
required.
H
Loaders
multiple
hook
are
composing
multiple
loaders
into
one
and
how
to
manage
that
as
well
as
a
lot
of
other
things
and
I
kind
of
am
hoping
to
kick
off
discussion
again
on
that
front
and
hopefully
get
things
in
a
place
where
it's
actionable
in
terms
of
creating
prototypes
and
making
progress
on
that
front.
So
I'm
really
interested
in
the
topic
and
I
hope
to
like
work
on
it.
A
E
We
could
discuss
that
at
large
I'd
be
curious
as
to
what
you're
wanting
to
do
a
lot
of
the
latest
loader
designs
and
stuff
we've
talked
about
this
year
have
been
kind
of
based
upon
the
old
designs
from
like
you
said
last
year
and
I
was
wondering
if
you've
looked
at
those
designs
from
middle
of
so
of
last
year
or
if
you
think
you
need
more
api's
than
just
the
loader
hooks
themselves.
I
did
see
you
also
link
to
a
generalized
resource
API,
so
just
general
thoughts
on
that
I
guess
is
what
I'm
asking
sure.
H
So
I
mean
right
now:
I've
been
working
with
common
J's.
Just
because
that's
worth
a
lot
of
the
ecosystem
is,
though
I'm
interested
in
looking
at
DSM
as
well.
I'm,
definitely
playing
catch-up
with
a
lot
of
things,
but
from
what
I've
seen
of
the
like
the
current
loader
API,
it
doesn't
seem
like
there's.
H
One
thing
that
seems
to
be
missing
to
me
is
the
ability
to
basically
compose
loaders
like
if
I,
create
a
loader
and
have
it
as
the
last
loader
on
a
project.
How
do
I
know
that
I'm
not
overriding
the
functionality
of
previous
loaders
in
some
kind
of
stack?
That's
what
was
most
notable
to
me
and
on
the
commonjs
side,
I
figure
that
if
you,
if
we
were
to
work
on
an
API,
that's
general
enough.
Something
like
the
resource.
I
D
And
just
to
amend
some
observations
on
that
from
my
front,
I'll
I
think
in
the
past
year,
or
so
the
conversation
like,
for
example,
trouble
came
out.
The
first
thing
they
said
was
Oh
yen.
Of
course,
we
will
not
be
just
loading
the
module
content
from
load
modules,
because
a
new
system
shouldn't
be
doing
that
and
entropic
obviously
is
not
actually
here,
but
tink
is
not
too
far
away.
J
Hopefully
this
is
an
autop
ik,
but
something
you
see
when
you
said
something
that
made
me
think
about
something
I've
been
talking
about
earlier
with
somebody
which
was
like
not
knowing
how
loaders
work
under
the
hood
or
too
much
about
them.
My
naive,
like
as
a
developer,
what
I
wish
they
could
do
would
be
like.
J
Let
me
give
a
function
that
node
would
call
either
before
or
after
it
resolves
specifier
in
case
I
want
to
say,
like
Oh
results
of
this
path
instead
and
then
ditto
before
and
after
it
actually
like
loads,
a
source
source
code
or
content
from
disk
like
it
loads
a
CoffeeScript
file,
I
transpile
it
and
send
and
return
the
JavaScript.
Instead,
both
of
those
things
could
easily
be
agnostic
as
to
the
module
system
like
they
could
be.
J
I
guess
like,
along
with
what
what
is
to
be
loaded
I,
would
assume
that,
like
my
function
review
past,
whether
it
CSM
or
comment
yes,
so
that
I
know
like
whether
to
generate
calm
and
jsps
M
output,
for
example,
but
but
yeah.
These
could
absolutely
be
lower-level
things
that
could
be
that
can
apply
to
both
systems
as
we
like
work
to
merge
the
systems
so
yeah,
all
in
favor,
of
what
your.
What
you're
talking
about
is
I
mean
it's
something
along
the
lines
of
what
I
just
described
or
enabled
what
I
just
spread.
I
I
just
wanted
to
mention
that
you
know
the
fact
that
the
common
jeaious
hooks
that
we
have
today
through
required
extensions
and
I
forget
what
the
other
one
is.
The
the
resolver
file
module
or
something
like
that
that
hasn't
inhibited
the
growth
of
ecosystems
around
these
kind
of
loader
workflows
in
command,
jeaious,
TS
node,
does
type
script
compilation.
We
have
coffee
script,
transpilers
doing
some
of
the
things
j
Daltons
as
a
project
that
this
works
that
exists
and
that,
for
example,
the
work
that
you're
exploring
there
Alex
I.
I
I
We're
hitting
a
number
of
constraints
on
that
design,
including
things
like
security,
where
we're
considering
whether
we
should
have
the
load
is
running
on
separate
threads
and
things
like
that
and
I
guess
we
could
tie
it
all
together
and
have
one
nice
system,
I
I,
just
personally
see
there
being
a
lot
of
Ohio
priorities.
First,
to
tie
together
a
nice,
yes,
module
loading
interface,
but
I
certainly
agree
with
the
sentiments
here.
A
K
So,
but
if
we're
going
to
try
to
break
that
barrier
and
say
this
is
a
more
Universal
thing,
then
you
will
likely
have
a
package
author
of
some
abstract
nature.
We
don't
know
today
say
that
my
content
needs
to
be
load
this
way.
They
know
how
their
particular
modules
should
be
loaded
and
I
believe
this
is,
you
know
at
least
unexplored.
K
L
M
So
one
of
the
things
that
is
somewhat
taken
for
granted
in
ESM
is
the
ability
to
have
module
resources
that
are
not
necessarily
local
disks,
like
local
disk
resources,
like
you
mentioned,
like
loading
things
out
of
an
archive
that
you
know,
might
not
necessarily
even
need
to
extract
the
archive
to
disk.
To
do
that,
you
can,
you
know,
load
parts
of
it
into
memory,
and
these
things
really
do
not
play
well
with
comm
Jess.
M
Not
that
I'm
saying
we
shouldn't
like
try
to
pursue
these
goals,
but
certain
things
like
even
the
keys
in
the
cat
and
the
require
cash.
If
they're
like
there
was
trol,
though
denote
I,
don't
remember
if
it
was
for
the
repple
or
the
e,
which
changed
the
specifier
that
that
code
runs
under
in
an
attempt
to
improve
the
stack
trace
and
it
broke
packages
in
the
ecosystem
that
assumed
that
that
would
always
be
under
a
the
select.
M
The
specifier
would
always
either
be
a
file
name
to
a
place
on
disk
or
like
rap,
alors
eval,
and
so
like
these,
these
constraints
really
like
I'm,
just
concerned
that
trying
to
move
forward
with
this,
we
will
hit
these
kind
of
things
that
can't
really
be
fixed
in
common
Jeff's
like
if
we
try
to
make
a
common
API
between
these.
If
a
call
comes
from
es
sound,
you
know
it
makes
perfect
sense
to
give
it
some
random
RAM
location
as
a
resource,
but
a
feature.
M
L
So
that's
a
pretty
good
segue
into
like
the
context
of
this
project
we
had
over
here
for
a
while.
We
needed
a
a
way
to
load
the
resources,
not
from
disk.
That
was
that
didn't
need
that
couldn't
be
done
at
a
platform
level
that
wasn't
like
developer,
aware
right
so,
and
to
do
that,
we
had
to
know
so
much
about
common
jeaious.
We
had
to
re-implement
common
jeaious
that
I
could
work
and
in
memory
I'm
we
optimized.
L
We
made
a
bundle
format
so
that
okay,
we
had
the
package.
All
the
source
text
functions
would
start
up
faster,
a
similar
use
case
to
NCC,
and
we
have
that
we
have
all
the
files
on
this
were
building
the
IDs
and
specifiers
and
everything
stuff
they
gnashed
files
on
disk,
but
none
of
the
source
text
actually
comes
from
disk.
We
just
absolutely
do
not
want
to
read
from
disk,
because
I'm
hitting
the
old
file
system
cache
in
a
container
just
takes
too
long
right.
Yeah.
D
Just
to
clarify
on
what
Gus
just
said
is
this
is
not.
This
is
not
soft,
but
also
not
theoretical,
like
there
is
a
set
of
programs
written
in
college,
yes,
that
this
can
run
definitely
answer
problems
like,
for
example,
a
thing
like,
don't
know,
binary
files,
we
kind
of
know,
that's
a
no-go
because
not
on
all
operating
systems,
all
contacts,
it's
easy
to
make
them
local
from
memory,
but
there,
if
you
don't
go
for
so
basically,
this
would
always
be
an
opt-in
feature.
It
would
not.
You
know,
default
behavior
to
load
from
this
those
archives.
D
You
would
not
just
by
installing
note,
get
this
behavior.
So
then
107
coverage
of
comment-
yes,
definitely,
is
not
possible
having
it
as
an
as
a
feature
that
people
can
opt
into
and
platform.
Support
for.
Api
is
that
those
tools
are
easy
to
write
and
maintain
without
requiring
certain
monkey
patch
magic
function,
pieces
possible.
What.
L
E
So
I
think
the
most
telling
thing
here
is:
we
have
multiple
different
PI
level
runtimes.
They
generally
call
themselves
what
what
is
it
like
new
package
managers
or
install
this
package
managers
these
days,
we
even
see
the
presentations
about
them
at
node,
convey
you
where
people
are
monkey
patching
the
file
system
API
to
do
stuff
like
this
and
relying
on
conscious,
internals
they're
not
going
to
stop
doing
that
unless
we
provide
a
alternative.
E
A
D
A
I
Let
me
just
try
a
context
off
as
well
from
writing
all
these
notes.
It's
actually
is
surprising
amount
of
effort
to
run
all
right
notes.
Yeah
I
just
wanted
to
mention
on
this
point
of
a
resource
or
kind
of
a
file,
loading
API,
and
that's
that
III
think
that's
it.
It
seems
like
a
really
simple
concept
to
just
have
a
fetch
hook
or
we're
sorry,
a
load
or
a
read
file
hook,
but
that
can't
be
separated
from
the
static
that
happens
in
the
resolver
as
well.
I
And
so
then
you
need
a
stat
hook,
but
then
we
have
resolve
is
all
over
the
place
and
and
now
you're
back
on
pausing
and
now
you're
back
into
URLs,
and
then
again
that
the
problem
gasps
mentioned,
of
having
both
URLs
and
pods
in
these
two
different
module
systems.
So
I'm
just
worried
of
us
oversimplifying
that
hook
and
that's
what
I
wanted
to
say.
D
Right
so
DPR
was
mostly
written
by
guy
originally,
which
is
just
a
very
basic
there.
There
are.
Exports
are
now
recognized
by
the
ESM
loader.
So
if
you
have
a
package
that
has
an
Xbox
field
and
you
try
to
import
a
path,
the
relative
to
the
specify
a
experts
will
be
used
and
other
acts
package
will
be
blocked.
D
Otherwise
it
will
just
fall
through
to
the
old
behavior
of
by
default.
Dot.
Slash
is
mapped,
it
out,
slash
and
all
files
are
accessible.
There
is
currently
only
input,
so
there
are
multiple
items
out
under
the
PR
description
of
things
that
we
explicitly
pondered
on
and
said.
G
I
just
wanted
to
cook
and
clarify
I
think
we're
on
the
same
page
about
the
semantics
of
what
happens
when
you
omit
exports,
but
you
described
it
as
a
the
default
being
an
object
of
dot,
slash
Max
to
dot
slash.
Wouldn't
it
have
to
be
like,
like
effectively
every
file
that
exists
in
the
package
mapping
to
itself
or
something
like
like
I'm,
not
right
here
on,
like
cuz.
D
D
G
A
Okay,
I
think
that's
about
it.
We
have
two
minutes
left
on
the
meeting,
so
I'm
going
to
wrap
it
up
just
as
a
heads
up
to
I'm
but
to
head
out
of
office
for
two
weeks,
so
I'm
not
gonna
be
around
to
run
the
next
meeting.
So
you
you're
gonna,
have
to
find
someone
a
chair
and
someone
to
help
with
the
stream.
So
you
may
want
to
kick
off
in
the
issue,
just
finding
people
to
make
sure
you
have
all
the
things
specifically
someone
who
has
access
to
the
zoom
account
other
than
that
I
think.