►
From YouTube: Node.js Foundation Modules Team Meeting 2019-09-11
Description
A
Okay,
this
is
the
11th
of
September
node
modules,
meeting
we're
coming
up
on
almost
a
month.
That's
all
the
b12
LTS,
so
we've
got
to
be
very
careful
genders
at
this
point,
I
think
so,
let's
get
going
with
today's
agenda.
The
first
item
we
had
was
actually
before
I
start.
Is
there
someone
available
to
take
notes
for
today's
meeting.
A
B
Yeah
sure
I
mean
I,
don't
think,
there's
anything
like
surprising
your
controversial
here.
It's
just
kind
of
an
update
reflecting
where
we
stand.
I
don't
know
if
people
want
to
suggest
any
broader
changes
as
a
result
of
anything
we're
trying
to
talk
about
today,
but
updating
links,
I
moved
exports
into
the
done
section
and
I
think
that's
it.
C
I'm
not
sure
about
how
LTS
exactly
would
work
here,
but
is
unflagging
exports
for
CJ
s,
and
let's
say
we
land
be
the
PR
that
has
at,
for
example,
as
a
shortcut
resolved
to
the
package
route
unflagging
both
of
those
for
common
je
s.
Is
that
something
that
could
happen
in
v12,
while
it's
still
in
CJ
s
like
in
a
minor
or
is
that
something
that
people
would
likely
be
gun-shy
about?
Once
12
has
entered
LCS.
A
C
Well,
I
mean
I'm
flagging
ESM
is
is
a
longer
discussion
than
unflagging.
These
two
features
for
CJ
s.
My
hope
is
that,
while
obviously
it's
great,
if
we
can
all
find
a
way
to
agree
on
unflagging
all
of
these
things
for
12
LPS,
even
if
n
flat,
if
ESM,
does
not
get
unflagged
for
12
LTS
I
would
like
to
see
those
two
features:
unflagged
for
command
j
s
for
node
12
LTS.
D
I
I
think
I
agree
with
Jordan
that
trying
to
unlock
the
command
is
affecting
things
earlier
or
as
early
as
possible
might
be
good
also
because
they
are
about
changes
in
behavior,
so
they
are
actually
things
that
can
break
people
so
having
more
discussion
around
it
and
having
well
expecting
more
discussion
around
it
is
reasonable.
So
if
we
can
start
the
process
of
unflagging
banging
them
early,
it
might
de-risk
and
flagging
modules
right.
C
E
B
F
About
the
flags
being
double-edged
in
you
know,
whatever,
whatever
good
can
be
gained
from
having
them
unflagged
for
part
of
the
module
system,
the
flipside
is
that
it
could
tire
hands
in
delivering
ESM
down
the
road
just
by
saying
that
they
are
unflagged
and
people
started
using
started
using
them,
so
that
closes
design
space
as
well
in
a
particular
direction.
So
it
could
be
both
helpful
or
hurtful
depending
on
how
you
look
at
it
right.
So
that's
it.
C
A
Okay,
the
next
item,
if
we're
happy
to
move
on
Geoffrey
I'll,
take
your
evening
at
the
confirmation.
The
next
item
is
the
divergence
first
fire
hazard.
As
we
discussed
last
week,
a
371
I
believe
we
had
quite
a
long
discussion
around
a
lot
of
the
nuances
to
do
with
Jim
Gilmer
packages
and
in
specifiers
diverge.
B
I
also
did
a
PR
with
the
documentation
update,
also
for
our
last
meeting
I.
Think
Jordan
had
asked
for
like
more
explanation
of
how
someone
would
publish
a
package
that
had
common
GS
and
ESM
sources.
So
that's
up
there
once
this
other
PR
about
dot
main
gets
merged
in
it.
Would
the
my
PR
would
get
expanded
a
little
bit
to
cover
that
like
now,
we
have
two
mains
situation,
but
you
know
I
wrote
this
for
the
current
situation
until
that
PR
then
would
amend
it.
B
C
Think
the
PR
meets
what
I
asked
for,
which
is
an
explanation
of
how
one
would
do
it.
The
conclusion
is
what
I
expected,
which
is
there,
isn't
a
organ,
amah
Quay
to
do
it?
The
answer,
is
you?
Don't
you
just
have
to
like
publish
two
packages
or
read
documentation
and,
like
you
know,
learn
the
language
of
the
readme
if
necessary,
and
then
figure
out
exactly
what
so
it's
best
if
I
were
to
use
so
like
to
me
that
I
appreciate
the
effort.
C
Thank
You
Geoffrey
I
think
that
if
we
ship
with
this,
that
documentation
is
useful
and
important,
but
to
me
I
think
it
underscores
that
this
is
one
of
the
think
more
important,
like
use
cases
from
our
original
dock
forever
ago,
that
we're
not
meeting
yet
and
I.
Think
it's
something
that's
really
important
to
me
or
there's,
just
not
a
really
a
migration
strategy.
C
C
Like
basically
I'm
very
concerned
and
I,
don't
want
to
be
I,
don't
want
to
be
in
a
position
where
I'm
the
only
one
blocking
a
thing,
progress,
I,
don't
want
to
block
progress
like
that
was
an
uncomfortable
place.
We
all
got
to
a
while
back
and
I.
Don't
think
any
of
us
wants
to
repeat
it,
but
like
I'm,
very
concerned,
if
we
were
gonna
on
flag
without
this
use
case
being
that
I
think
that
it
it
would
be
better
not
to
have
modules
at
all.
Well,.
B
C
I
mean
I
was
to
have
ship
a
single
package
that
can
work
for
both,
and
you
know
I
guess
in
slide
to
me
was
ergonomic,
yes,
I
mean
and
technically
you
can
still
do
it
with
different
entry
plants.
You
can
have
no
main
and
you
could
like
tell
people
manually
pick
one
or
you
know,
there's
there's
lots
of
ways
you
can
I'm
like
forced
the
explicitness.
That's
true
yeah.
B
I
think
the
only
other
point
I
would
make
about
the
docs.
That
was
one
of
your
comments
that
you
didn't
like
was
that
I
kind
of
encouraging
people
to
use
the
module
field,
even
though
node
ignores
it?
It
at
least
gives
them
like
a
standardized
place
to
look
as
documentation
like,
rather
than
reading,.
B
C
I
mean
I,
agree,
I,
agree
that
that's
structured,
and
that
makes
it
better
for
sure,
but
like
if
note
is
gonna
recommend
it
knows,
node
should
be
using
it,
and
the
reverse
to
me
is
true
and
I
think
that
it
is
just
like
we
don't.
You
know
it's
a
bad
idea
for
everybody
to
like
install
random
crap
on
a
radar
prototype.
It's
a
really
bad
idea
for
people
to
add
new
package.json
fields
like
sometimes
it
works
out
really
well
and
many
times.
C
It
ends
up
kind
of
poisoning
that
field
for
future
use
by
the
community,
and
that's
what's
happened
with
module
if
everyone
had
stuck
with
Jase
next
main,
even
because
that
one's
super
ugly,
maybe
we
could
have
used
module
and
not
had
to
worry
about
stepping
on
semantics,
but,
like
the
community,
ended
up
stealing
the
best
name
from
node
for
a
field,
because
it's
so
like
I
think
it's
just
a
really
bad
idea
to
recommend
things
were
not
that
notices.
Looking
about
looking
at.
D
D
So
that's
currently
where,
where
we
are
at
and
I
agree
that
this
will
be
an
issue
with
migration
like
if
you
are
a
package
that
it
has,
that
is
at
the
end
of
the
multi-level
dependency
chain,
you
enabling
ESM
will
most
likely
for
the
longest
time,
not
matter
because
none
of
the
intermediate
packages
will
actually
use
that
code,
which
is
you
know
too
bad
and
I
agree
that
that
is
not
a
great
outcome.
I'm,
just
not
seeing
an
alternative
so
far
that
doesn't
have
the
wrists
and
I'm
on
the
side
of
I'd.
D
Much
rather
have
a
ecosystem
where
people
don't
accidentally
break
and
have
to
roll
back,
and
we
get
into
weird
hope
your
package
does
it
and
breaks
the
internet
and
all
these
kinds
of
things
so
I
would
a
on
that
side
right
now,
which
means
that
yes,
upward
economics
right
now
is
not
a
great
story.
Yeah.
C
C
So,
like
I,
agree
that
that's
a
I
don't
want
either
of
these
hazards.
Obviously
they
both
suck
but
like
the
singleton
hazard
is
already
understood.
It
already
happens
with
duplication
and
peer
deafs
remains
the
solution,
and
I
reaiiy
realized
and
agree
that
the
ESM,
the
ESN
thing
adds
another
way
that
it
can
bite.
G
C
But
all
the
people
maintaining
singleton
things
are
already
super
paranoid
about
their
Singleton's
and
they've
like
so.
I
think
the
likelihood
that
it
will
happen
frequently
is
low,
I'm
sure
it
will
happen.
It's
already
happened
once
as
was
pointed
out,
but
like
I
think
that,
and
when
it
happens,
the
solution
is,
would
be
straightforward.
C
A
If
I
might
just
add
to
that
as
well,
I
think
there's
a
whole
space
of
ways
that
people
can
approach
handling
this
from
dynamic
input
with
top
level
of
weight
or
require
checks
or
lots
of
different
ways
of
sort
of
looping
through
the
different
module
systems.
And
we
have
to
remember
that
the
JavaScript
community
is
in
general,
incredibly
creative
when
it
comes
to
backwards,
compatibility
and
using
new
features
and
there's
probably
a
whole
bunch
of
ways
that
stuff
can
be
done
and
I
guess.
A
We
just
need
to
be
aware
of
that
and
make
sure
that
it's
that
we're
managing
the
part
of
it
that
we
can
manage
and
I
think
that
we've
approached
this
hazards
in
such
a
sensible
way
is
great.
But
I.
Don't
think
we
should
overlook
that.
There
will
be
a
whole
bunch
of
ways
of
handling
these
problems
and
user
lands
that
probably
crop
up
too.
And
it's
probably
also
worth
thinking
that
I
know
it's
the
next
agenda
item.
A
But
it's
probably
also
worth
thinking
about
what
the
implications
are
for
an
exports
field
on
that
as
well,
because
that
also
provides
a
sort
of
a
a
branching
out
of
her
environment
level,
which
is
very
different
to
within
the
same
environment.
Branching,
which
is
the
bad
thing
yang,
did
you'll
serve
another
point
on
that.
Yeah.
D
It
doesn't
reflect
suddenly
claims
that
it
is
the
exact
same
package,
but
it
has
now
a
TSM
implementation
and
everything
blows
up
because
it
wasn't
actually
the
exact
same
interface
and
the
using
package
now
implicitly
gets
switched
over
to
that
in
quotation
marks
new
ESM
implementation
and
I'm
also
concerned,
like
speaking
about
people
accidentally
doing
these
de
facto
breaking
changes
in
minor
versions.
That's
another
one
and
I
think
that's
in
the
large
scale
of
things.
That
would
be
the
thing
I'm
actually
more
concerned
about
that.
D
The
single
hazard
I
agree
with
Jordan
that
the
single
hazard
is
for
very
specific
packages
that
are
very
stateful
and
do
instance
of
checks
which
are
not
very
common
in
the
ecosystem,
otherwise,
but
people
thinking
that
they
didn't
break
the
interface
by
adding
an
SM
version.
That,
for
me,
is
the
more
likely
one
that
could
lead
to
problems
accidentally.
D
C
D
They're
dependent
will
not
implicitly
switch
over,
so
if
the
dependent
is
they
acquire
and
explicit
yeah
yeah,
you
have
to
actually
change
the
way
in
both
the
package
to
get
the
different
version.
Now,
there's
still
the
chance
that
they
have
a
minor
version
and
they
populate
they
make
the
default
years.
M,
never
CJ
s.
You
know
they
make
a
very
explicit
choice
to
mess
up.
C
And
for
what
it's
worth,
I
have
no
objection
to
as
a
package
author
to
putting
something
in
my
package
JSON
that
enables
it
to
be
kind
of
dual
mode
in
the
ways
we've
talked
about,
thus
making
it
an
explicit
choice,
and
perhaps
addressing
that
concern.
My
goal
is
that
consumers
of
my
package
don't
have
to
make
an
explicit
choice.
You
know
and
I
don't
mind
having
to
do
a
little
extra
work
to
convince
node.
That
I
mean
it
if
that,
if
that
would
suffice,
yeah
I
think.
D
There's
a
good
thank
you
for
thinking
about
that
sensible
thing
there
might
be
also
an
additive
feature
even
like
it
wouldn't
have
even
have
to
be
in
the
very
first
version,
because
it
would
be
an
additive
thing,
but
I
think
it's
very
worthwhile
to
think
about
something
at
that.
That's
a
good
point.
F
A
A
A
motivating
use
cases
are
both
a
kind
of
a
Jew
environment
use
case,
as
well
as
ensuring
that
all
the
features
available
to
exports
are
also
available
to
the
main
entry
point
and
and
going
into
example,
of
sort
of
a
polyfill
use
case
around
how
you
might
polyfill
a
standard
module
with
that
I've
got
a
PR
up
on
node
core.
For
this.
Let
me
just
get
the
PR
I.
D
A
Got
it?
Okay,
perfect?
So
that's
two,
nine
four,
nine
four
and
so
yeah
that
this
means
that
we
can
merge
this
and
as
well
as
supporting
the
dock
main.
It
also
supports
a
shorthand
form
which
is
a
direct
string,
so
you
would
be
able
to
use
in
the
package.json
file
exports
as
a
field
map
to
a
string
which
would
apply
both
in
common
Jess
and
in
ES
modules.
Basically,
then,
acting
like
a
new
main,
but
with
the
added
feature
that
it
encapsulates
the
package.
G
F
Our
we
think
that
this
is
all
going
to
be
a
bear
package
or
unless
it
has
a
nested
package
it
will.
You
know
like,
like
I,
think
import
package
name,
for
instance,
is
different
from
import
package
name,
slash
sub
package
name
that
has
a
different
package
JSON,
so
a
first
name
dot.
Slash
here
effectively
makes
this
a
bear
package.
Does
it
eliminate
sub
packages
that
have
their
own
package
J
songs
from
being
searched?
Yan
was
your
commonly.
D
Just
very
quickly,
in
terms
of
reducing
confusion,
we
will
only
ever
look
at
a
single
exports
entry
and
only
ever
forbear
specifiers,
which
means
that
if
you
have
a
sub
directory
that
has
another
package
Jason
that
tries
to
remap
something
to
something
that
then
remaps
again.
It
will
not
work.
So
we
look
at
exactly
one
package
Jason
that
has
the
exact
mapping
and
from
there
it
just.
That
is
the
resolution.
F
D
Doesn't
go
up
basically,
so
the
thing
that
it
does
is
it
pre
parses
the
specifier
splitting
it
into.
This
is
the
name
of
the
package,
and
this
is
the
sub
path
and
will
only
then
look
for
a
package
Jason
for
the
package
name,
which
means
that
exports.
As
is
a
note
right
now,
dust
encode,
that
a
package
is
either
a
scope,
slash
name
or
just
a
name.
It
does
not
allow
you
to
create
node
modules,
/foo,
slash,
Bartlett's
lashes,
app
and
treat
that
as
a
package.
A
A
G
I,
don't
want
to
spend
a
lot
of
time
on
this
right
now.
Honestly,
I
think
there
are
more
pertinent
things
for
getting
12
out
the
door,
but
we
did
split
up
the
hook
into
different
resolve
and
retrieve
hooks
which
we
agreed
upon.
We've
altered
the
data
format
somewhat
and
I've
tried
to
update
the
examples.
G
We
added
a
kind
of
interesting
solution
to
a
problem
with
composing
nested
instrumentation.
We
still
have
to
add
some
more
success:
criteria
about
nested,
instrumentation
of
user
land
modules
and
not
just
built-ins,
but
overall
I.
Think
it's
ok,
I,
don't
think
we'll
get
progress
enough
on
this
for
LTS
constraints
that
we're
talking
about
for
other
features.
We'd
have
to
try
to
unplug
it
during
the
LTS
like
they
did
for
HTTP
2,
so
I
think
we
can
focus
elsewhere
for
now,.
B
I
just
had
some
questions,
so
one
I
guess
maybe
we
should
probably
update
the
docks
before
LTS
just
to
let
people
know
ago.
This
is
still
in
progress.
This
is
what
we're
thinking
blah
blah
blah
just
because
I
feel
like
once
we
unflagged
ESM
in
general.
People
are
gonna.
Ask
about
this,
so
I
assume
that's
probably
doable
before
LTS
and
then
the
other
question
I
had
was.
B
G
G
B
D
I
F
Just
one
thing,
I
want
to
point
out
is
at
some
point:
I
used
the
old
loader
hooks
to
prototype
the
package
exports
and
all
of
that
I'm
wondering
and
it's
something
I
can
also
participate
in
if
we
can
do
first-class
implementation
on
the
existing
loader
hooks
to
mimic
the
prototype
of
the
future
hooks
that
we
want
to
actually
achieve.
It's,
like
you
know,
making
a
a
loader
for
the
them
to
make
us
simulate
how
the
new
one
would
work.
F
We're
currently
the
loader
hooks
that
are
in
and
node
are
basically
I.
Think
just
the
one
result
hook
is
there
a
way
we
can
try
to.
You
know
get
more
out
of
that
hook
in
the
tour.
It's
the
behaviors
that
are
being
proposed
in
the
new
design,
so
so
by
simulate.
Here
is
like
using
the
existing
hooks
to
to
showcase
how
the
new
hooks
would
behave.
Basically,
is
there
a
you
know
a
good
way
to
wrap
the
existing
hooks
to
give
the
illusion
of
the
new
hooks.
I
That's
a
possibility,
I
guess,
there's
a
lot
of
deeper
implementation.
That
would
happen
need
to
happen
for
separate
worker
thread
loaders
and
things
like
that.
But
I
do
have
a
cleaned
up:
multiple
loader
hook,
composition
based
on
the
current
implementation
branch
that
I
could
potentially
merge,
or
at
least
like
test
with
and
maybe
add
some
of
the
other
features
that
were
talking
about
in
the
design
dock.
So.
F
D
B
D
A
If
I
would
just
add,
it
sounds
given
that
loiters
has
become
this
kind
of
big
monolithic
thing.
That's
difficult
to
tackle.
It
does
seem
sensible
if
we
can,
if
we
can
try
to
approach
it
in
in
maybe
smaller
chunks,
so
perhaps
supporting
the
the
PR
is
progressively
like
landing,
multiple
loaders
and
then
landing
various
upgrades
to
the
API,
and
so
we
reach
convergence
with
the
design
dock
which
itself
stable.
At
this
point,
I
mean
Bradley.
Would
you
say
the
design
dock
is
ready
to
go
and
ready
for
implementation,
yeah.
A
G
There's
a
mental
there's,
some
history
here
for
HTTP
two
at
least-
and
there
are
two
things
we
could
do
most
likely.
What
TSE
will
want
us
to
do
is
keep
the
experimental
flag
for
loaders.
However,
we
can
still
unflagged
and
have
breaking
changes
on
experimental
features.
Http/2
had
a
breaking
change
without
a
flag
in
a
minor
because
they
put
the
api
is
experimental
even
after
they
unflagged
it
likely,
at
least
for
the
loaders.
We
could
try
to
do
that
and
have
it
marked
as
experimental
and
breaking
with
it
being
unflagged.
G
I
don't
think
people
would
like
if
we
shipped
a
big
breaking
change
for
that.
However,
if
that
doesn't
work,
we
can
still
ship
with
the
loaders
under
an
experimental
flag.
So
it
would
be
up
to
the
TSE,
basically
just
to
give
us
the
go-ahead
that
we
can
remove
the
experimental
flag
for
loaders
for
http/2.
They
did
allow
removing
the
flag,
even
though
a
breaking
change
was
expected.
A
It
sounds
sensible
to
me,
and
we
should
probably
move
on
that
sooner
rather
than
later,
because
if
it's
going
to
be
a
problem
week,
we
need
to
know
about
it
and
another
option
could
be
if
we
could
work
out
how
to
make
the
band
minimum
changes
to
the
later
API
such
that
it
can
be
backwards
compatible
or
forwards
compatible
with
the
with
the
new
design.
And
maybe
there
is
a
way
that
we
could
do
that.
A
For
example,
it
could
still
be
running
in
the
same
realm
and
thread,
but
still
that
exposed
that
the
new
modern
API
that
we
have
from
the
design
documents.
They
would
still
be
a
risk
of
breaking
changes
if
it's
experimental,
but
it
might
get
us
closer
to
something
that
would
provide
that
backwards.
Compatibility
on
the
LTS
so
on
yeah.
F
F
But
if
we
want
to
support
backwards,
compatibility
for
more
hooks
like
the
dynamic
instantiate
I,
believe
it
I
believe
it
will
get
very
tricky
to
try
to
promise
enter
off
backwards,
compatibility
based
on
the
new
design
and
rounds
and
all
that
I
didn't
to
think
that
it
will
be
possible
to
to
have
a
good
backwards
compatibility
story
with
the
existing
way
we
looked
at
it.
I
might
be
wrong.
G
D
D
D
D
And
I
think
what
is
special
about
the
loader
api
is
its
top
level.
It
doesn't
bleed
into
the
ecosystem
as
much
as
other
module
system
things,
so
it
would
be
less
concerned
about
breaking
changes
because
you
don't
have
ten
levels
of
dependencies
depending
on
the
loader
flag.
Most
likely
you
have
maybe
a
load
of
dependency
depending
on
the
interface,
but
then
you
explicitly
set
a
flag
to
use
that
loader
defense.
He
likes
it's,
not
an
ecosystem.
Braking
change,
it's
just
a
very
specific
thing.
A
I
personally
think
it
would
just
be
useful
to
ensure
that
there
are,
even
if
it
is
a
breaking
change,
a
way
to
write
loaders
that
can
still
work
in
previous
versions
of
notes.
So,
for
example,
currently
we
rely
on
the
exports
of
the
loader
module
and
just
just
ways
to
ensure
that
that's
still
manageable
from
a
kind
of
a
J's
feature.
This
action
perspective,
so
you
don't
suddenly
get
locked
out
of
you
either
building
a
loiter
for
a
note
or
plus
or
not.
It
would
be
nice
to
still
be
able
to
support
that.
A
A
D
There
has
been
a
bunch
of
discussion
back
and
forth
about
options.
Specifiers
I
I
think
that
as
far
as
I
can
tell,
there
is
acceptable
compromise
now,
with
the
at
sign,
where
some
nobody
is
actively
objecting
to
it.
It
doesn't
have
any
wildly
used
existing
semantics.
It's
kind
of
you
can
think
about
it
as
the
non
scope,
so
you
can
even
come
up
with
a
way
of
explaining
it
with
the
prefix
for
MPM
scopes.
It's
you
know
you
can
explain
it
away
if
you
want
to,
but
I
think
it
was
one
of
the
last
actually.
D
Important
blockers
for
exports,
where
something
needed
to
be
done
for
exports,
so
I
think
this
unblocks.
It
I
think
it's
a
feature
is
also
useful
for
some
applications,
especially
if
the
application
itself
is
not
using
extra
or
butts
then
suddenly
turns
into
a
convenient
require
from
hoods
which
I
personally
hate.
But
you
know
people
didn't
wanted,
so
if
they
really
want
to,
they
could
misuse.
D
B
D
I
just
want
to
make
sure
that,
without
that
it
doesn't
get
merged
accidentally,
because
there
are
no
war
collaborators
that
are
going
through
PRS.
Looking
what
it's
possible
to
merge
and
then
merge
it,
so
yeah
I
definitely
am
looking
forward
to
correctly
quickly
now
remove
that
do
not
merge.
There
is
still
work
to
be
done
also
like
right
now.
It
only
has
a
common
implementation
and
it
doesn't
really
have
a
lot
of
tests
and
no
documentation,
so
I
would
have
to
add
pieces,
but
I
didn't
want
to
get
that.