►
From YouTube: Node.js Foundation Modules Team Meeting 2020-07-15
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
we're
not
alive
on
YouTube
with
the
July
15th
meeting
of
the
nodejs
modulus
team.
We
are
joined
here
by
a
number
of
members
of
the
team
and
we
have
a
fairly
full
agenda
today,
which
I
will
for
one
more
time
drop
into
the
chats
where
we
see.
If
you
can,
please
add
your
names
to
be
agenda
and
then
also
if
anyone
can
help
with
notes.
That
would
be
greatly
appreciated.
A
Okay,
well,
I
guess
an
announcement
that
I
will
make
just
because
I
hate
dead
air.
Note.
Fourteen
point,
six
point:
zero
has
a
release
candidate
out
to
release
candidates
now
actually,
and
it
is
targeting
to
be
released
tomorrow.
They've
got
delayed
slightly
because
we're
trying
to
get
v88
point
four
into
that
release.
A
At
the
moment
there
is
an
exciting
new
feature,
two
related
to
modules.
One
is
a
dr.
deprecation
of
module,
dot
parent,
which
has
you
know,
been
backed,
orders
from
master
and
the
other
is
the
inclusion
of
package
imports,
a
feature
that
guy
Bedford
had
been
working
on.
This
has
not
gone
out
yet
so
I
would
say
that
if
anyone
has
any
other
feedback
or
thoughts
about
it,
this
is
probably
the
last
moment
to
get
that
in.
A
We
do
not
have
it
on
the
agenda
right
now,
so
we
can
save
it
for
later,
but
if
folks
do
have
something
that
they
want
to
talk
about
regarding
package
imports,
you
know
say
it
now
or
forever
hold
your
peace
or
you
know
I
guess
the
time
thing.
So
the
first
thing
we
have
on
the
agenda
here
is
yes:
M
modify,
get
format
and
get
source
loader
hooks.
This
is
number
34
144.
A
This
is
actually
a
port
quest
from
Julian
Bond
on
Oh
Julian
did
I,
say
your
last
name
correctly:
yep,
that's
correct
and
Julian
what
we
usually
do
in
the
meetings
you're
a
newer
person
to
the
meetings
we
have
got.
We
usually
introduced
the
item
and
we
usually
have
the
person
who
owns
the
full
requester
opened
the
issue
to
introduce
it.
So
would
you
like
to
introduce
this
change.
B
A
No
one
Bueller
Bueller,
so
I
think
that
what
with
the
where
this
is
at
right
now
and
just
kind
of
like
looking
looking
at
this,
it
hasn't
been
touched
in
about
15
days.
Julian.
Was
there
particular
feedback
that
you
were
looking
for
to
kind
of
move
this
forward
and
get
it
out
of
out
of
a
draft,
or
is
it
kind
of
ready
to
continue
moving
forward.
B
Try
I
think
what
happened
was
I
I
thought
it
kind
of
stalled
out,
because
I
thought
it
turned
into
a
bigger
conversation
of
what
the
I
guess
a
conversation
behind
is.
Are
these
the
final
hooks
that
that
will
be
moved
out
of
kind
of
experimental
and
more
into
production,
so
I
I
thought
they
did
turn
into
a
bigger
conversation
and
therefore
it
kind
of
stalled
out,
but
so
I
wasn't
sure
how
to
move
forward
with
it.
Yep.
B
A
D
E
I
I
think
the
the
real
real
real
question
here
is
something
that
I
think
came
up
in
some
side
channels
as
well,
which
is:
are
we
expecting
loaders
to
be
generally
stateful?
So,
for
example,
how
we
load
us?
Are
we
expecting
loaders
to
track
metadata
during
gate
format?
Keep
it
in
memory
somehow
so
that
they
don't
have
to
repeat
operations
for
good
source,
or
do
we
want
to
design
the
hooks
in
a
way
that
allows
load
Lotus
to
have
minimal
State
themselves
and
in
the
forest
Claire
class?
E
The
question
would
be
to
me:
is
there
some
primitive
lacking
that
allows
notice
to
safely
store
metadata
without
having
to
worry
about
making
memory?
If,
for
example,
it
calls
gate
format,
but
the
never
calls
gets
awesome
that
loader
again
and
now
the
metadata
has
to
be
just
retained
forever,
because
the
loader
doesn't
know
that
it
doesn't
need
it
anymore.
I.
C
E
So,
very,
very
specifically,
here
for
the
HTTP
loader
example.
The
HP
loader
has
to
do
the
HTTP
request
in
get
format
to
actually
know
what
the
format
is
of
the
thing,
but
then
it
has
to
retain
the
response
somehow,
because
the
same
response
during
get
sauce,
which
is
I,
think
the
crux
of
why
the
pull
request
exists.
Why
why
Julian
wanted
to
have
a
way
forget
sauce
to
also
return
the
format,
so
it
doesn't
need
to
worry
about
it.
I.
C
Guess,
and
and
I
supposed
it
interacts
fine
with
the
with
the
loader
composition.
Does
it
so
I
mean
it?
It
fits
the
model
for
Colo
to
composition.
It
doesn't
violate
any
sort
of
authority.
Stuff
we've
been
trying
to
set
up
there
I'm
wondering
if
there's
any
weird
edge
cases
where,
if
you
compose
a
loader
that
does
get
home
at
with
with
something
that
does
this
kind
of
hook,
I,
don't
think
there
are
any
just
wondering
if
you
thought
those
those
cases
through
I.
E
I
think
for
me
the
question
there
is
because
there
I
think
my
other
comments
are
also
pointed
out
that
there's
some
real
weirdness
if
we
introduce
this
that
gets
sauce,
can
return,
sometimes
a
format.
Then
the
question
becomes:
what
does
the
default
implementation
in
node
of
get
format
off?
Get
sauce
do?
Does
it
return?
A
format
does
not
return
a
format
in
the
cases
where
it
would
return.
E
A
format
like
built-in
doesn't
actually
return
a
sauce
then,
or
does
it
just
get
sauce
between
a
format
but
not
sauce,
so
I
think
we
can
design
something
that
works.
The
question
is
kind
of.
What
do
we
think?
Should
the
priority
be?
Do
we
again
kind
of
coming
back
to
the
question
earlier?
Do
we
think
it
is
more
important
to
have
get
formats
as
a
separate
step
in
the
pipeline,
or
do
we
think
it
is
more
important
to
allow
loaders
to
not
require
keeping
state
about
the
resolution
Oh
about
the
loading
I?
Guess
you.
C
E
C
Well
then,
it
sounds
like
maybe
just
digging
into
some
of
those
cases
a
bit
and
being
sure
that
they
work
out
would
be
worthwhile
and
I
mean
other
thing
I
would
suggest,
is
on
a
PR
like
this.
It
would
be
nice
to
see
the
documentation
to
kind
of
outline,
maybe
some
of
these
things
and
then
also
the
the
usability
on
it
personally
I
don't
have
anything
in
principle
against
it,
I
mean
I've,
I'm
probably
a
plus
zero
on
it,
but
yeah.
I
be
interested
to
hear
what
others
think.
C
C
B
A
A
The
next
item
that
we
have
on
here
is
special
treatment
for
package.json
resolution
and
exports.
We
had
a
second
agenda
item
for
adding
an
API
for
the
package
Durer
that
I
shoved
in
here
as
like
a
reference,
because
I
believe
that
these
two
are
closely
related.
If
folks
disagree,
we
could
split
them
out
into
two
separate
topics
again.
A
A
F
The
way
you
would
always
do
that
is
just
require
package
name
slash
or
require
that
resolve
it,
and
then
you
get
you
know
you
can
do
package
package,
name
slash
package,
dot,
JSON
and
require
that
in
or
you
could
require
not
resolved
package
name
with
a
slash,
and
then
you
can
use
FS
operations
to
access
whatever
file
you
want
it.
The
ability
to
do
those
FS
operations
has
is
completely
unrelated
to
the
encapsulation
that
exports
is
intended
to
provide.
F
So,
for
example,
saying
that
these
are
my
three,
like
you
know,
entry
points
from
my
package
in
using
the
exports
field.
That's
restricting
my
cember
api.
That's
you
can
still
go
nuts
and
like
explore
my
packages
file
system,
but
if
I
change
that
and
break
your
script
like
that's
on
you,
the
file
system
is
not
part
of
the
api
contract,
so
that's
always
worked.
So
the
issue
is
that
if
I
put
package
JSON
in
my
exports,
then
people
can
just
require
it
and
tools
can
get
the
version
number
or
they
can.
F
You
know
figure
out
from
the
package
JSON.
They
can
figure
out
well,
what's
the
project
directory
and
that
do
three
FS
stuff.
Similarly,
if
a
tool,
if
a
packages
main
is
in
the
root
directory,
you
can
require
dot,
resolve
a
package
name
and
then
assume
that
that's
the
directory
and
you
know
and
work
from
there.
And
similarly,
if
the
thing
you
require
dot
resolve
isn't
is
in
a
directory
that
contains
either
no
nested
package.
Json
like
the
first
pack
is
JSON.
F
You
find,
as
you
traverse
upwards,
is
the
project
one
then
you're
good
or
if
the
first
package
JSON
you
find
with
like
a
name
or
a
version
like
if
you
can
use
heuristics
to
guess
where
the
project
directories
package
JSON
is
then
you're.
Also
good,
but
if
there's
any
situation
where
it's
hard
slash
impossible
to
distinguish
a
nesting
package
JSON
from
the
project
route
package
JSON,
then
it
becomes
impossible
to
generically
access
the
location
of
the
package
directory.
F
F
You
know
this
bear
identifier,
but
the
like,
probably
the
most
straightforward
or
the
most
clean,
would
be
just
give
me
the
path
on
the
file
system
that
this
is,
and
this
would
be
an
API
that
you
know
things
that
patch
a
node
to
not
have
a
file
system
so
like
yarn
to
I,
think
and
maybe
and
tink
and
a
few
other.
You
know,
but
those
types
of
approaches.
They
could
then
patch
this
API
and
provide
you
know
and
do
whatever
they
need
to
do.
F
So
the
I
don't
remember
if
I
said
something
specific
yeah
I
mean
the
I.
Don't
actually
feel
too
strongly
about
exactly
how
it's
spelled
like
where
it
lives
and
what
the
word
is
right.
I
mean
it.
F
Yeah
like
resolved
package
route
is
a
totally
fine
name
right
and
we
could
put
it
on
the
module
object,
module
dot
result
package
route.
That
seems
fine
to
me.
I
I
think
a
lot
there's
a
lot
of
folks
that
aren't
me
that
have
a
much
better
concept
of
all
of
node
and
like
where
stuff
really
belongs,
but
literally
just
an
API
that
takes
an
identifier
and
spits
back,
something
that
can
give
me
a
file
system
path.
It
can
be
a
URL
object.
F
It
could
be
a
promise
for
URL
a
the
object,
like
the
exact
semantics,
aren't
really
as
important
I.
Think
it
there's
probably
tooling.
That
does
need
it
to
be
synchronous,
so
it
would
probably
useful
to
have
it
be
synchronous
that,
but
other
than
that
you
know
it
seems
it
would
basically
be
just
like
require
dot
resolve
with
a
bear
identifier
and
a
slash
attached.
If
there
were
no
experts,
exports
field,
but
it
shouldn't
live
on,
require
because
it's
not
related
to
modules.
F
C
A
F
F
Correct
me
if
that's
wrong,
and
so
there's
not
like
necessarily
an
existing
cash
to
leverage
and
then,
as
is
that
right,
yeah,
yes,
okay,
cool,
so
I'm,
assuming
that
folks
would
not
be
content
with
expanding
whatever
it.
Node
does
cash
to
include
the
entire
package.json.
So
like
yeah,
something
on
the
module
interface,
it
could
be
a
static
function
on
the
module
module
or
it
could
be.
You
know,
like
the
thing,
be
module
instances
that
are
stored
in
required
cash
right.
It
could
be
just
an
instance
method
on
one
of
those
right.
F
Probably
a
good
might
be
a
good
way
to
cash.
It
because
then,
like
it's
part
of
the
require
cash,
but
you
know
because
there
is
some
require
resolution
happening
here,
and
this
you
know
obviously
as
I
say,
require
early.
It
would
be
the
same,
similar
approach
for
import,
but
it's
it
seems
like
just
a
top
level
like
static
function.
You
know
that
perhaps
leverage
the
module
cash
to
you
know
when
available
to
call
the
instance
method
or
something
like
that.
Something
like
that
would
work.
F
E
E
Yeah
plus
one
on
the
result,
a
crude
name
I
think
it
would
be
nice
to
have
it
available
to
ES
module.
So
if
you
write
a
tool
that
is
written
in
PS,
module
syntax
and
he
kept
access
to
it
easily,
but
as
long
as
it's
exposed
from
the
module
module
as
a
static
function,
somehow
I
think
it
would
then
need
a
second
argument
of
the
context
like
what
is
the
file
path
and
or
URL
of
the
thing
that
is
trying
to
find
the
package.
A
F
A
F
C
C
A
D
A
Into
maintenance,
it
doesn't
mean
that
we
can't
explore
these
things
on
future
versions,
although
I
do
think
having
having
like
that
as
like
a
pretty
big
difference
in
being
in
12
and
12.
Still
having
like
two
more
years
of
support,
would
maybe
make
it
a
little
harder
to
make
those
changes
in
other
versions.
Now,
for
what
it's
worth,
even
when
something
is
in
maintenance,
we
still
could
explore
making
broader
changes
like.
We
just
need
to
build
consensus
between
the
release,
team
and
potentially
the
TSC.
A
If
we
wanted
to
make
those
changes,
but
they
are
a
lot
harder,
but
we
have
historically
with
something
like
an
API,
for
example,
done
an
API
updates
into
maintenance
LTS
releases
to
keep
an
API
in
sync
across
all
the
release
lines
so
well.
I
think
that
it
is
not
ideal.
There
is
prior
art
here
that
we
could
that
we
could
point
to
about
making
a
change
like
that,
after
it's
a
maintenance
and
it.
E
C
C
D
D
C
D
C
F
It's
it's
worth,
I,
think
thinking
about
not
counting
blocks
but
like
thinking
about
this
categories
of
the
objections
or
like
the
spirit
of
them
right
so
like
the
ones
about
out
of
order.
Execution
are
because,
like
it,
it
violates
the
intention
of
the
spec
and
that's
that
seems
pretty
bad
as
a
concept,
regardless
of
whether
you
think,
even
if
you
think
that
this
specific
instance
is
okay.
F
C
C
F
But
I
mean
I.
Think
the
the
more
helpful
thing
to
probably
think
about
for
me
anyway,
is
if
we
ship
this
in
whatever
form.
What
as
a
developer,
do
I
have
to
keep
in
my
head
to
make
sure
that
when
I'm
writing
commonjs,
that
named
exports
are
there
and
similarly,
when
I'm
importing
a
common
J's
module
and
like
there
are
or
are
not
named
exports,
I
mean
I.
Guess
that's
just
gonna
be
try
it
and
see,
but
the
so
it's
more
about
the
authoring
side.
F
C
D
F
C
G
I
agree,
it
does.
I
might
have
less
of
a
negative
opinion,
but
I
do
think
if
we
have
precedent
of
trying
to
land
features
and
them
getting
blocked
based
upon
not
being
complete.
So
that's
one
of
the
reasons
why
the
repple
has
a
flag
for
enabling
a
weight
in
it
because
it
is,
it
does
alter
semantics
slightly,
so
it
wasn't
considered
complete
and
it
doesn't
really
have
a
path
to
removing
that
flag
ever,
but
we
did
land
it
behind
a
flag,
I'm
curious.
C
Just
to
try
and
read
in
to
Gus's
opinion
here,
I
think
what
he's
saying
is
that
he
doesn't
think
he
would
ever
permit
this
heuristic
ulm
ethic,
because
he
sees
it
as
imperfect
and
that
it
does
not
have
he.
He
kind
of
sets
a
bar
that
it
should
be
able
to
get
95%
accuracy,
which
it
simply
cannot
so
there.
There
is
no
path
to
getting
through
his
block.
Even.
D
D
C
D
G
Far
is
it
that
is
not
what
I'm,
seeking
by
shipping
a
flag
I'm
seeking
to
alleviate
pain
for,
essentially
using
es
modules,
I'm
not
seeking
to
have
some
sort
of
ulterior
motive
to
have
a
different
implementation
or
solution
eventually
in
the
future.
Based
upon
the
fact
that
we
already
know,
people
do
want
named
exports
from
common
J's
I.
F
Mean
the
other
thing
is
the
fact
that
users
want
it.
I
mean
users
wanted
to
transpile
CoffeeScript
on
install
also,
like
that's
that's
very
important
things
to
consider,
but
users
wanted
does
not
mean
like
we
must
give
it
or
should
automatically
like
in
this
case,
I
hope
we
find
a
way
to
make
it
work.
But,
like
you
know,
I,
don't
think
that
you
know
people
want
a
lot
of
things
and
sometimes.
D
D
F
Stronger
bar
all
right,
I,
agree
and
I
think
the
challenge
here
is
that
you,
when
you
users,
have
an
expectation
for
that
on
specific
packages
and
not
on
other
specific
packages
and
the
way
to
determine
that
is
not
run
time.
Reflection
of
the
module
dot
experts
only
it
is
that,
combined
with
reading
the
documentation
and
like
inferring
as
a
human.
F
What
the
author
intended
right-
and
so
there's
like
that,
like
Jeffrey,
did
a
lot
of
heroic
research
work
to
try
and
figure
this
out
and
like
it's
really
difficult
to
actually
even
measure
how
good
a
job
those
expectations
are
being
met
like
I,
want
them
to
be
met,
but
it's
like
that.
Iii
have
module
data
exports,
values
with
other
properties
on
a
number
of
my
packages,
and
there
there
is
one
export
on
this
packages
named.
Exports
should
not
work
on
those
right,
but,
like
I
know,
it's
I
think
it's
a
I.
F
F
D
Have
to
it
the
interesting
thing
about
definitely
typed
is
that
it
also
captures
another
level
of
expectation
beyond
what
like
a
heuristic
is
expected
to
find
definitely
gets
typed,
also
explicitly
elides
exports,
which
are
not
supposed
to
be
exported
by
documentation.
So
things
like
internal
feel.
All
those
things
that
are
label
is
for
test.
Only
those
are
explicitly
left
off
on
definitely
typed,
because
the
maintainer
x'
have
you
know,
comments
or
something
indicating
that
they
want
them
gone.
D
However,
for
a
named
exports
implementation,
you
kind
of
expect
them
to
be
there
because
again,
if
it's
only
available
for
test,
it's
only
supposed
to
be
alighted
and
documentation
like
completions,
that
typescript
provides.
It
should
still
be
there
in
the
wrong
time,
and
so
even
definitely
type
doesn't
actually
capture.
Everything
note
is
supposed
to
get
it's
just
like
a
minimum
set.
F
A
What
one
thought
here
of
the
direction
that
we
could
go
and
I
know
people
aren't
going
to
necessarily
love
this,
but
as
our
loader
implementation
begins
to
become
more
and
more
stabilized,
and
it
feels
like
we're
we're
getting
somewhere,
especially
with
the
composable
loader
stuff,
one
possible
route
to
take
this,
especially
for
thinking
about
like
using
definitely
typed
or
other
third
parties.
Would
you
like
writing
loaders
that
can
accomplish
what
we're
talking
about
here?
A
Perhaps
we
could
have
a
subset
of
kind
of
Leste,
loaders
and
workflows
that
we
just
ship
directly
with
node,
where
I
would
be
like
hey
like
the
default
experience
doesn't
allow
this,
but
you
can
always
use
one
of
these
built-in,
loaders
and
Brad
I
think
this
is
kind
of
similar
to
what
you
were
suggesting.
As
far
as
flags
are
concerned,
as.
D
D
A
Like
the
big
difference
that
I,
that
I
would
see
between
a
flag
and
a
loader
would
be
that
a
blast
shipped
loader,
even
if
it
is
not
the
default,
is
not
treated
as
like
an
experimental
thing
or
like
not
like
it's
not
default,
but
it's
not
experimental
it
also,
like
can
have
like
it
is
official
ich
for
lack
of
a
better
way
of
putting
it.
It's
just
not
the
default,
but
I.
Think
I.
Think,
like
the
use
case
where
this
becomes
interesting
at
least
to
me
is.
A
It
means
that
most
modules
and
libraries
will
not
use
this
pattern,
which
keeps
us
with
an
ecosystem
that
is
like
consistent
and
reliable,
but
allows
application
authors
at
the
top
level
of
their
packages
to
have
working
modes
that
are
potentially
more
convenient
for
them
within
their
application.
That
they're
building.
C
But
just
to
dig
in
very
briefly,
if
you
require
a
module
before
you
import
it
through
the
es
module
loader,
it's
already
put
into
the
es
module
loader,
so
you
don't
actually
get
to
hook
it
because
of
the
snapshotting.
So
I
could
separate
the
the
part
of
this
PR
that
disables
the
snapshotting
to
allow
this
to
work
as
a
loader,
which
it
doesn't
right
now
because
of
this
edge
case.
G
C
G
C
That
the
PR
would
remove
the
snapshotting
entirely,
so
mutations
would
be
permitted
and
then
possibly
later
on.
We
could
have
so
that
the
problem
is
when
you
require
before
you've
imported
and
and
if
you
are
going
to
be
injecting
it
early
into
the
cache
or
injecting
tool
into
the
cache,
with
some
special
hook.
C
G
C
G
A
A
To
interrupt
y'all,
we
only
have
two
minutes
left
as
a
conclusion
to
this
topic.
From
now.
For
the
moment
I'd
like
to
propose
is
that
it
seems
like
the
sentiment
is
not
that
we
want
to
let
this
that
we
want
to
let
this
line
that
we
want
to
continue
to
do
work
to
enable
this
use
case.
I.
Do
people
think
that
do
people
agree
with
that.
E
A
Don't
like
whatever
you
want
to
praise
it
I,
don't
think
that
they're
like
personally
and
I
recognize
there's
a
bias
as
I
am
a
TSC
member
I,
do
not
see
any
value
whatsoever
and
going
to
the
TSC
about
this.
The
last
time
that
we
tried
to
take
a
module
related
discussion
to
the
TSC.
The
response
from
the
TSE
was
okay,
spend
some
time,
educating
us
and
getting
us
up
to
speed
on
what
this
means
and
then,
after
that
it
was
basically
like
okay.
Well,
we
don't
have
enough
context.
You
tell
us
what
to
do
so.
A
I
think
that
and
I
guess.
Maybe
this
goes
back
to
some
of
the
discussions
we
had
about
chartering
and
a
reason
why
we
can
consider
being
charted.
I
think
that
we
need
to,
as
a
group
figure
out
a
path
forward
in
a
solution
here
and
not
be
making
like
an
appeal
to
Authority,
to
try
to
help
us
figure
it
out
because
right,
it's
not
good
ALP,
but.
C
Then
I
mean
the
other
option,
is
a
vote
and
also
I
mean
not
not
to
be
difficult
about
it,
but
I
mean
one
of
the
requirements
of
a
block
is
is
being
available
for
discussion
and
and
Gus
was
very
clear
about
the
fact
that
he
wasn't
going
to
be
participating
in
this
meeting
today.
I
just
think
that,
especially
in
a
situation
which
a
block
is
not
being
actively,
you
know
the
actively
move
forward
in
terms
of
being
able
to
have
those
discussions
that,
as
a
group,
we
should
have
an
alternatives.
A
So
I'm
sorry
to
interrupt,
but
we
are
now
at
time.
I
would
like
to
suggest
that,
like
there's
a
meta
topic
here,
it
seems
like
we're
talking
about
it
and
might
be
prudent
for
us
to
open
an
issue
on
the
modules
repo
to
discuss
and
tag
it
to
bring
it
up
in
the
next
meeting,
I'm
going
to
go
ahead
and
stop
the
stream.
Thank
you.
Everyone
who.