►
From YouTube: Node.js Foundation Modules Team Meeting 2020-04-22
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
A
We
have
a
somewhat
light
agenda
today,
but
I
think
it's
worth
digging
into
what
we
have
I
guess.
We
could
start
with
announcements
and
I
would
love
to
announce
that
yesterday,
with
the
release
of
node.js
14,
we
removed
the
warning
for
ESM
in
node.
The
warning
still
exists
on
13
I.
Don't
think
we're
looking
to
backcourt
the
removing
of
the
warning
to
13
12
continues
to
have
the
warning
as
well
as
the
flag.
A
Okay
in
lieu
of
any
announcements,
we
can
get
right
into
the
agenda
I'll
remind
folks
to
please
add
their
names
to
the
docs
in
case
it
isn't
there,
including
your
github,
handles
because
sometimes
it's
nice
to
have
the
first
issue
on
the
agenda.
Right
now
is
development
and
production
export
conditions.
A
A
B
A
High
level
of
it
and
can
introduce
it,
but
essentially
there
were
some
discussions
in
different
communities
and
I
believe
it
was
specifically
the
reaction
community
that
inspired
this,
which
was
the
idea
of
creating
some
new
conditions
within
conditional
exports,
and
these
conditions
would
allow
to
break
in
this
PR,
specifically
on
either
development
of
production
in
the
no
dev
environment
if
it
were
set.
There
is
a
lot
of
discussion
in
here
and
in
fact,
some
explicit
minus
ones.
A
Those
minus
ones
are
less
about
conditional
exports,
but
more
about
know
traditionally
has
not
relied
on
behavior
of
node
n
for
how
note
itself
works
and
there's
a
number
of
TSE
members
who
are
not
super
enthusiastic
about
introducing
a
reliance
on
that
or
creating
any
sort
of
behavior
based
on
that,
especially
since
those
environment
variables,
don't
have
clear
defaults
and
different
libraries
utilize
them
differently.
So
there
is
an
active
discussion
around
things
that
could
change
that
could
get
people
on
board.
They
include
potentially
changing
a
mental
model.
B
I,
just
it
feels
like
conceptually
I
think
this
is
just
wrong.
That
resolution
should
not
be
affected
by
the
environment
like
clearly,
there's
use
cases
for
having
a
different
production
development,
build
and
clearly
there's
use
cases
for
having
debug
on
or
off
in
any
environment,
but
like
conditional
exports
is
about
which
implementation
do
I
want
and
production
versus
development
is
usually
about,
and
this
is
true
for
react
as
well.
It's
either
about
what
Babel
settings
I'm
not
using
or
like
what.
B
What's
my
targets
target
outputs,
but
then
it's
also
about
am
I
gonna
delete
some
code
or
include
it.
It's
not
like
like,
in
other
words,
production
and
development
reacts,
have
never
been
a
different
implementation.
They're
identical
it's
just
that.
There's
some
code
specifically
some
warning
code.
B
It
may
be
they're,
not
identical,
they
seem
identical,
they're
observably
identical,
but
they
there's
some
warning
code
deleted
in
the
production
version
and
like
that,
it
just
doesn't
feel
appropriate
to
me
that
that
should
be
kind
of
mushed
into
conditional
exports.
They're,
like
I,
can
understand
platform
node
versus
browser,
but
like
not
yeah
I,
just
I,
don't
think
environment
is,
is
the
proper
thing
to
or
that'll
do.
This
is
the
proper
place
for
environment
switching.
C
In
the
case
of
react,
they
aren't
changing
the
names
or
API
signatures
of
what's
exporter,
but
they
do
actually
have
side
effects
that
occur
only
in
the
development
and
debugging
environments,
particularly
they
hook
into
various
kinds
of
dev
tools
and
extensions.
So
they
actually
do
like
run
side-effects
when
they're
in
the
development
mode.
Even
if
their
import
wouldn't
be
used
any
differently,
they
do
have
effects
that
they
never
want
to
see
in
a
production
build
well.
B
B
B
C
C
B
C
B
A
I,
don't
think
that
we're
gonna
get
through
like
debating
the
validity
of
that
or
not
in
this
call
today,
especially
since
we
don't
have
everyone
on
the
call.
But
I
pointed
out
for
the
reason
they're
saying,
like
I,
think
that
there's
a
handful
of
kind
of
like
core
things
we
need
to
get
on
the
same
page
about
before
we
can
even
start
exploring
the
feature
itself.
A
One
would
be
like
our
conditional
exports,
something
that,
like
our
set
in
stone
at
at
launch,
or
is
it
something
that
can
change
based
on
like
something
like
if
you
set
process
ends
note
if
you
set
the
know
down
somewhere
in
the
lifecycle
of
the
app
should
later
imports
that
haven't
actually
happened
yet
or
requires
that
happen
later
after
that
execution
now
have
access
to
the
debug
version,
if
nothing's
in
the
cache.
Yet,
if
it's
already
in
the
cache,
what
should
we
do
there
like
I,
think
that
there's
like
high-level
discussion
have
there?
A
The
other
would
be
whether
or
not
we
want
the
conditions
themselves
to
be
static,
or
if
we
want
to
be
able
to
have
like
some
sort
of
statement
in
the
condition.
So,
for
example,
in
the
case
of
like
the
node
and
production
bit
here
like,
that
is
a
very,
very
specific
thing,
but
if
we
allowed
four
conditions
on
the
left
hand
side
so
something
like
process,
node
M
equals
equals,
equals
production,
I'm,
not
I.
A
C
C
All
these
things
are
set
when
node
starts
up
currently
I,
don't
think
we
should
vary
this
feature
to
be
the
one
feature
that
is
dynamic,
especially
given
I
put
a
comment
in
the
thread
most
of
the
use
cases,
including
bundling
technologies
and
stuff,
like
that,
do
it
only
at
startup
and
then
they
cache
values
or
they
delete
things
permanently
and
stuff
of
that
nature.
If
you
expect
this
value
to
be
dynamically
altered
and
respected,
that's
not
the
case
for
anything
to
my
knowledge
in
the
ecosystem,
including
the
existing
flags,
we
have
four
modules.
D
So
one
concern
I
kind
of
have
about
this
is
once
people
start
published
if
people
were
to
start
publishing
packages
that
have
conditional
exports
on
say
development,
then
that
could
be
surprising
to
somebody
that
just
wants
to
use
it
on
their
own
package.
One
thought
I
had
is
if
this
were
modeled
more
like
no
debug
like,
for
example,
no
devil
equals
my
package
or
no
devil
equals
some
other
package.
D
C
C
C
Well,
NPM
just
had
its
RFC
call
where
they
were
talking
about
overrides
and
the
potential
for
having
multiple
packages
with
the
same
name
being
overwritten
in
different
locations
of
your
install
per
the
actual
thing
about
opting
in
per
package
I
think
we
have
a
well-established
definition
of
package
boundaries
now,
so
it's
possible.
We
could
do
that.
I,
don't
know
if
having
things
done
on
a
per
package
level
is
realistic
because
things
like
if
react
suddenly
in
its
new
installation,
includes
a
sub
module.
A
So
one
thing
that
was
brought
up
in
the
thread
by
Gus,
which
I
don't
think
we
should
preclude
I
know
this
is
not
necessarily
the
solution
that
everyone
wants,
but
there
is
something
to
be
said
that
this
is
something
that
loaders
could
also
help
out
with,
especially
if
the
ecosystem
aligns
around
like
pattern
or
tooling.
That
is
on
top
of
node,
but
not
explicitly
note
if
people
ran
like
a
debug
loader
when
they
wanted
to
debug
and
that
debug
loader
had
the
information
that
it
needed
to
know.
A
A
C
C
Just
because
loaders
are
capable
of
doing
things
doesn't
mean
everything
should
be
a
loader.
Loaders
are
a
way
of
basically
overriding
default,
behaviors
and
default
configuration.
Even
so
we
do
have
flags
that
affect
things
like
the
particularly
the
symlink
flags,
where,
if
you
set
symlink
flags,
you
do
affect
the
default
loader.
We
don't
require
people
to
create
their
own
loader
to
respect
symlinks
in
the
way
they
want.
C
C
A
C
I'm
not
stating
that
we
have
to
do
the
same
as
this
PR,
but
it
doesn't
seem
clear
to
me
why
this
is
something
we
don't
want
to
be
configurable,
usually
I
would
consider
things
we
don't
want
to
be.
Configurable
are
things
that
could
cause.
You
know
security
problems
if
misconfigured
and
they
could
do
other
things.
But
when
you're
going
down
to
the
loader
level,
that's
much
more
dangerous
and
harder
to
get
people
to
properly
configure
a
loader
than
say
a
command
line,
flag
or
environment
variable.
C
But
it
just
seems
weird
to
me
that
we're
trying
to
shove
this
under
loaders
there
doesn't
seem
a
clear
reason
why
this
configuring
this
is
seen
as
problematic.
The
way
in
which
it's
configured,
no
D&B
seems
I,
guess
problematic
because
of
collisions
or
misuse.
But
if
we
solve
that
I
I
don't
see
the
clear
objection.
A
So
I
think
back
to
the
point
that
Matteo
is
bringing
about
wanting
it
to
be
dynamic.
I
think
that
at
least
my
gut
on
this
is
not
that
it
is
so
controversial,
but
it's
more
about
one
would
be
the
framing
of
what
these
conditions
mean.
I
think
that
people
are
not
super
thrilled
about
production
versus
development,
as
opposed
to,
like
you
know,
regular
versus
debug,
I,
I.
A
Wes
says
that
he
doesn't
think
it's
a
good
idea,
because
he
doesn't
think
presenting
a
conditionally
different
API
is
a
good
idea
period
ever
Prader
no,
but
he's
kept
mostly
quiet
on
the
thread.
Like
you
all
know,
prod
versus
dev
conditional
flag
is
going
to
make
packages
with
make
use
of
it
much
harder
to
statically
analyze
Brad.
A
C
Tools
in
the
ecosystem
already
have
to
deal
with
the
evil
of
process
E
and
V,
even
if
they're
not
running
in
node,
unfortunately,
most
tooling,
even
tooling.
That
is
not
specifically
targeting
node
bundlers
for
the
web
stuff,
like
that
support,
processing
and
B,
just
because
it
is
the
standard
way
in
which
people
are
configuring,
different
values
for
that,
and
they
do
some
kinds
of
code
elimination.
They
do
constant
substitution
things
like
that.
I
agree.
C
A
It
seems
to
me-
and
please
correct
me
if
I'm
wrong
is
that
kind
of
the
next
steps
that
need
to
be
done
here
are
likely
to
further
scope.
Kind
of,
like
there's
high-level
feature
asks
here,
but
there's
kind
of
like
low-level
assumptions,
so
we
probably
need
to
work
out
some
of
those
as
well
as
further
define
the
future
to
move
things
forward.
It
kind
of
feels
like
perhaps
we're
not
going
to
get
too
much
more
done
during
this
call.
A
A
That's
fair
I
mean
to
me
it
was
more
than
like.
This
is
a
feature
request.
That's
come
from
the
ecosystem
to
us
to
a
certain
extent,
so
trying
to
find
some
sort
of
path
towards
consensus
or
I
feel
like
either.
We
need
to
define
a
path
to
consensus
or
we
need
to
like
close
it.
Otherwise
we're
not
really
doing
anyone
a
service
by
having
ongoing
discussion.
So
I
guess,
maybe
the
question
you
Brad
would
be.
C
I
think
that
currently
discussion
doesn't
seem
to
have
direction.
You
probably
shouldn't
close
it
out,
but
we
don't
have
any
real
way
of
crossing
the
different
aisles
that
we've
established
of
wanting
dynamic,
not
versus
static
or
wanting
this
to
even
exist
at
all
versus
status
quo
of
ways.
People
are
doing
this
already,
so
I
think
we
could
just
put
it
on
some
level
of
block,
but
not
blocked
on
code
blocked
on
use
case
constraints
not
being
clear.
A
A
Okay,
the
next
one
we
have
up
is
number
three
two,
eight
three
eight
empty
fall
back
in
null.
Exports
has
not
exported
my
understanding.
Looking
at
this
quickly,
it's
a
pull
request
from
guy
and
I
think
it
just
limits
specifically
throwing
errors
when
you
pass
an
empty
array
or
null
on
the
right-hand
side
of
exports,
currently
I
think
they're
allowed,
but
they
just
don't
do
anything
so
disallowing
them
would
throw
earlier
errors.
A
C
Sure
so
this
is
a
build
option
for
people
who
want
to
make
custom
builds
of
node,
a
bunch
of
people
and
various
issues,
heads
on
the
social
medias
and
whatever
have
stated
they
want
to
change
the
default
package
type
be
there.
Currently,
what
note
is
shipping
or
sometime
in
the
future,
what
node
can
ship
in
the
future,
so
I
made
a
PR
that
would
let
them
do
a
custom
build
of
node.
For
this,
the
caveat
here
is:
virtually
nothing
runs.
C
If
you
set
that
flag,
you
can
run
some
little
toy
applications
with
it,
but
very
few
things
actually
run
with
it.
So
this
is
more
to
let
them
have
a
playground
to
work
with
stuff.
I
firmly
believe
we
should
not
make
this
a
runtime
configurable
thing
right
now,
because
people
will
start
relying
on
it
in
various
shell
scripts,
and
it
would
be
very
bad
when
using
child
process,
in
particular,
if
they
fire
up
a
child
process
with
the
wrong
node,
it
would
default
to
the
wrong
package
type
which
could
have
bad
effects.
So
that's
it.
C
C
C
C
A
Yeah
I
think
one
of
the
things
that
we
were
debating
there,
although
I,
haven't
followed
up
on
where
we
landed,
was
whether
or
not
we
wanted
to
create
the
same
binary
name
and
I
had
requested
that
perhaps
we
make
it
like.
No
ESM
are
just
like
something
that
was
explicitly
a
different
binary
name,
just
making
things
a
little
bit
more
explicit,
but
not
a
hell-like
can't
die
on
just
a
pot
Jordan,
you
of
your
hand,
oh
yeah,.
B
A
C
B
C
C
C
B
B
I
mean
I'm,
not
a
node
collaborator
and
I.
Don't
have
to
deal
with
it,
but
like
conceptually,
that's
a
good
thing
right
but
like,
as
Wes
pointed
out,
people
can
already
do
this.
Just
by
now
you
can
close
your
PR
and
they
can
just
float
that
PR
on
top
of
node.
And
if
you,
if
an
a,
if
the
parts
that
did
the
sort
of
single
source
of
truth,
refactoring
we're
up
streams,
then
your
PR
would
end
up
being
even
smaller.
So,
like
I
guess,
I
just
I
questioned
the
utility
of
landing.
B
B
Right
but
I
mean
they
were
all
talking
relative
terms,
but
I'm,
saying
that,
like
yeah
and
as
Wes
is
pointing
out
in
chat,
it's
like
it's
dead
code,
it's
never
gonna
be
unflagged
or
used
in
the
future.
It's
you
know,
potentially
even
untested
and
like
the
PR
exists,
so
they
can
now
float
that
patch,
whether
you
land
it
or
not,
but
like
I,
think
the
other
thing
is.
Is
it
shouldn't
be
made
any
easier,
even
if
it's
already
really
hard
it
shouldn't
like
a
hundred
hard
$2.99
hard
like
it
still
shouldn't,
be
made
easier?
E
A
A
And
I
see
this
is
actually
kind
of
similar
to
what
Wes
was
saying,
but
if
we
have
a
test
at
least
somewhere
that
can
like
run
the
configure,
yeah
I,
don't
know
Wes.
If
we
would
want
to
maintain
something
like
that
long
term
and
the
fact
that
it
would
be
a
build
time,
configuration
flag
would
essentially
require
us
having
like
a
whole
additional
compilation
just
to
test
this,
and
so
I
have
been
thinking
about.
I.
Think
there
is
something
valid
around
like.
A
If
we
can't
have
it
tested,
it
is
a
risk
keeping
it
in
the
source
tree
kori,
you
of
your
hand
out.
Yes,.
D
If
there
were
a
run
time,
flag,
I
would
have
an
objection
which
is
basically
that
I
don't
want
to
get
any
PRS
from
people.
You
know
asking
or
demanding
that
I
had
you
know
type
command
J
asks
to
every
package.
You
know
so
I,
don't
think
the
risk
of
that
is
high
for
a
build
time
option,
but
if
they
were
able
to
be
set
run
time,
I
could
see
people
pushing
bugs
for
that
great.
B
Is
it
even
clear
that
that's
something
that
we'll
ever
get
consensus
or
that
we'd
ever
want
to
do
enough
to
override
consensus
or
override
the
lack
of
I?
Don't
know
it's
not
something
I'm
ever
interested
in
doing
and
and
I'm
also
pretty
confident
it.
It
won't
ever
be
practical,
because
the
common
GS
is
gonna,
be
a
large
part
of
ecosystem
for
effectively
ever.
You
know
at
least
long
enough
that
we
probably
all
won't
be
here
when
we're
having
this
discussion
about
changing
the
default.
So.
A
C
I'm
fine
with
either
direction.
Actually
this
goes
so.
This
is
useful
I'm
wondering
if
we
can
get
consensus
that
we
will
never
try
to
change
the
default,
because
that
would
also
be
a
useful
outcome
here,
because
it
would
also
kind
of
do
the
same
effect
that
I
was
trying
to
do
with
this
PR.
It
would
give
a
kind
of
source
of
truth
to
these
people
asking
to
change
the
default.
C
A
Would
feel
comfortable
to
committing
to
the
fact
that
we
are
like
node
14,
for
example,
was
just
released
and
has
three
years
of
a
lifecycle
and
we're
absolutely
like
not
going
to
be
changing
that
in
the
next
three
years,
I
don't
see
how
it
could
happen
in
the
next
five
years,
and
no-
and
you
start
kind
of
thinking
about
how
that
creeps.
I
am
pretty
close
to
saying
that
I
don't
know
how
we
could
or
I'll
frame
it
a
different
way.
A
I,
don't
see
how
we
could
change
the
default
without
making
large
enough
language
changes
in
which
the
type
field
it's
silent
itself
might
be.
Deprecated
I
think
that's,
maybe
a
better
way
to
frame
it.
So
I
think
that
we
might
be
able
to
find
ourselves
in
a
world
in
a
world
where
Jas
means
ESN,
but
I
think
it
would
likely
also
be
a
world
where
we're
not
using
type
anymore,
I
think
we're
more
likely
to
deprecated
type
than
to
deprecated
out
of
the
box,
Jas
supporting
see
Jas.
Would
anyone
disagree
with
that
statement.
A
A
A
C
To
me,
just
like
you
said,
because
14
defaults
to
Jas
being
common
Jas
for
three
years,
that
means
likely
all
LTS
in
that
three-year
time
range
will
support
Jas
as
being
common
Jas
and
for
all
those
years
that
those
LTS
are
supported.
It
seems
like
this
is
a
no-go
to
change
just
by
Nature,
even
if
it's
a
hard
truth
to
swallow,
it
seems
that
we
have
some
feeling
that
this
PR
should
never
exist,
because
we
can
never
change
the
defaults
to
our
knowledge
of
type
package
type
to
be
clear.
That.
C
C
B
B
A
A
good
reason
for
like
import
meta,
also
as
an
example
or
like
the
equivalents
not
being
on
the
other
side.
We
could
explore
looking
at
allowing
a
top
level
the
weight
inside
of
carmen
jeaious,
but
both
Brad
and
I
have
Zen
experiments
that
seem
to
imply.
It
breaks
the
world
which
sometimes
is
fun
so
I'm.
C
C
E
B
B
Wanted
to
add
one
quick
note
with
self
exports.
We
ended
up
settling
on
the
name
and
then
kind
of
left
a
sigil
as
an
open
thing.
It
came
up
with
today
in
IRC
that,
like
it
really
sucks,
if
you
fork
a
package,
that's
using
self
exports,
because
then
you
have
to
rename
it
throughout
the
code,
whereas
if
we
had
an
additional
form
of
self
reference
that
was
independent
of
the
package
name,
then
that
problem
is
solved.
B
I,
remember
all
of
the
you
know,
discussion
around
at
versus
tilde
and
all
that
stuff,
but
like
it,
I
just
want
to
clarify
if
we
were
able
to
come
up
with
some
sigil
or
some
specifically,
some
way
that
it
self
reference,
the
independent
of
the
package
name
I,
want
to
confirm
that.
That's
something
that
we
could
consider
adding
as
a
Semper
minor,
potentially
assuming
we
talked
about
consensus
both
here
and
upstream
I.
C
That
sounds
okay
here.
I
do
have
a
issue
as
well.
We
have
a
older
PR
of
mine
that
I
need
to
rebase
to
move
loaders
into
worker
threads.
We
didn't
have
any
objections.
I
didn't
want
it
to
land
in
14
when
it
first
went
out
because
it
disables
one
of
the
loader
hooks
so
I'm
going
to
try
to
land
that
now
that
14
is
out,
and
we
should
probably
not
back
port
it
if
we
can
avoid
it.
C
Unfortunately,
that
means
that
15,
whenever
it
comes
out
would
have
a
different
loader
API,
because
one
of
the
hooks
would
cease
to
exist.
The
dynamic
instantiate
hook
that
we
talked
about
a
long
while
ago,
multiple
times
is
there
any
objections?
There
are
no
objections
on
the
PR
currently,
but
are
there
any
objections
for
us
moving
forward
with
15
in
that
break?.
C
In
particular,
we
did
have
an
objection
about
breaking
that
specific
API,
which
is
why
we
had
to
introduce
a
separate
hook
for
instrumenting.
The
global
code.
Wes
was
asking
our
West
was
saying
a
bit.
We
knew
there'd
be
breaking
changes,
still
loader
API.
That's
why
it's
still
experimental
I
would
feel
more
comfortable
if
we
landed
it
in
a
non
LTS
branch
for
people
to
play
with
then
in
the
LTS
branch
itself.
A
D
D
C
We
could
try
I
know
most
existing
loaders,
not
most
existing.
A
variety
of
existing
loaders
do
use
that
hook
and
having
it
work
on
LTS
seemed
more
prudent
than
breaking
it.
If
we
do
want
to
back
port
it
and
we're
okay
with
making
that
braking
change,
I
think
we
can
discuss
it,
but
we
haven't
really
got
field
testing
of
the
worker
thread
loaders,
so
I
don't
really
want
to
break
people
until
we
get
more
testing
under
the
hood,
at
which
point
we
could
back
port.
It.