►
From YouTube: Node.js Foundation Modules Team Meeting 2019-01-29
Description
A
A
B
So
not
much
is
going
on
for
this.
We
did
get
some
requests,
particularly
about
how
this
would
remove
dynamic
instantiate.
We
haven't
made
APR
to
completely
remove
it,
because
we're
not
landing
this
PR
right
yet,
but
we
also
did
get
some
interesting
facts
about
people
using
dynamic
instantiate.
They
are
actually
doing
so
to
mutate,
Global's.
Sometimes
so,
I've
been
trying
to
figure
out
what
the
best
way
to
allow
people
to
mutate.
B
C
B
A
I'd
like
us
to
start
quickly
with
the
discussion
around
unless
people
have
a
problem
with
bumping
this
to
the
top.
We
receive
some
issues.
I
think
it
was
early
this
week
about
people
who
are
using
conditional
imports
getting
the
experimental
conditional
exports
warning
when
like
if
they
weren't
supporting
conditional
exports,
it
would
be
like
the
equivalent
so,
like
specifically
in
the
case
of
someone,
has
a
project
that
project
natively
supports
CJ
s.
They
want
to
offer
support
for
ESM.
A
They
want
to
use
conditional
exports
to
be
able
to
do
it
because
they
want
to
use
the
exports
field,
but
the
second
that
they
do,
that
they're
getting
the
various
warnings
in
the
console
which
is
to
design
right
now.
But
in
the
case
that,
like
let's
say,
the
main
entry
point,
is
identical
to
the
require
entry
point.
In
theory,
it
could
like
fall
back
to
that
and
like
whether
or
not
there
should
be
a
warning
is
kind
of
up
in
the
air.
Does
anyone
have
a.
D
D
Specifically
came
up
for
me
with
the
next
version
like
v2
of
resolve,
has
conditional
exports
in
the
package.
Jason
and
I
intend
to
be
like
I
want
to
use
the
feature
and
be
as
future
compatible
as
possible
and
so
on.
I've
defined
require
import
and
default
for
all
of
my
entry
points
and
in
the
case
of
the
require
entry
point
and
the
default
entry
point,
they
are
all
identical
to
what
it
would
be
if
I
just
deleted
the
exports
field.
D
D
Did
it
because
I
don't
want
the
warning
but
like
because
they
so
that's
kind
of
like
I'm,
basically
wondering
like
I,
obviously
I
think
we
want
the
warning
if
the
conditional
export
would
result
in
a
different
module,
but
if
it
would
result
in
the
same
module,
it
seems
like.
The
warning
doesn't
really
serve
a
purpose,
but
there
might
be
like
an
implementation
costs
or
like
in
terms
of
complexity
or
whatever,
to
differentiating
us.
So
if
I
was
worth
discussing.
A
Yeah
I'm
not
sure
if
this
is
a
change
that
want
to
make,
but
like
I
personally
think
I'd
be
comfortable
with
before
throwing
the
warning
essentially
doing
a
check
to
see
if
the
export
require
was
the
same
as
main
like
that
seems
very
reasonable.
Now,
the
only
challenge
to
that
that
I
would
say,
gets
kind
of
weird
is
like
we
probably
don't
want
to
do
that,
support
for
all
of
the
deep
imports
or
deep
back
sports,
but
then
it
starts
becoming
really
edge.
Kc
because,
like
it
isn't
actually
the
same.
A
D
D
A
D
D
Oh
I
get
it
I'm,
not
saying
that's
adjustable,
that's
a
defense
against
like
let,
therefore
we
shouldn't
have
the
warning
I'm.
Just
saying
like
that
would
be
an
unfortunate
consequence
and
I
think
it
would
drastically
inhibit
adoption.
People
don't
want
that
warning
when
like
like,
when,
if
someone's
using
import
they're
using
it
in
there
like
instead
they're
using
an
experimental
feature
so
seeing
an
experimental
warning
is
fine,
no
matter
where
it
comes
from,
but
if
they're
using
require
they're,
not
using
an
experimental
features
like
I.
A
A
D
B
B
A
E
E
D
C
Think
there's,
if
I
can
put
it
in
sorry
I
think
there's
me
go
yeah
third
option,
I,
don't
know
or
maybe
not
sure
if
this
is
possible,
but
I
would
think
that,
like
what
we
really
want.
Correct
me
if
I'm
wrong
is
like
we
want
the
package
authors
to
see
a
warning
that
like
they're,
using
something
that's
experimental
but
not
necessarily
the
end
users,
who
are
just
installing
something
off
of
NPM
like
if
that
were
somehow
possible.
We
do.
A
C
A
A
A
A
Experimental
experts,
I
guess,
like
one
other
option,
that
we
could
that
we
could
explore.
Although
I
don't
know
if
we
want
to
add
this
to
the
algorithm,
is
for
conditional
exports.
If
there
isn't,
if
you
are
requiring-
and
there
is
not
a
require
that
is
defined,
you
could
fall
back
to
the
main,
in
which
case
is
technically
not
using
the
exports
functionality.
But
the
the
challenge
and
the
thing
that
I
like
yeah,
because
we
don't
have
any
it,
doesn't
seem
like.
We
have
any
warning
that
throws.
If
you
just
use
exports
correct.
D
Like
right
now,
I
have
a
number
of
pack
most
of
my
packages.
Don't
have
conditional
exports.
They
only
have
default
in
the
click
in
the
object
form
and
there's
no
warning
issued
by
a
require
with
that
and
it's
the
way
I've
built
them.
If
we
shipped
a
node
thing
that,
like
a
new
node
version
that
skipped
exports
and
less
require
was
specified,
then
that
wouldn't
break
anything.
My
packages
would
just
pretend
like
suddenly
start
like
pretending,
like
they
didn't,
have
an
expert's
field
so
that
that's
fine.
D
So
I
don't
know
if
it
is
possible
but
like
if
which
every
suggested
is
is
a
way
is
the
way
forward.
Like
if
we
could
say
like
you
know
when
requiring
any
path
in
the
current
package,
or
you
know
when
using
the
self,
the
self
X,
the
self
reference
feature
or
something
used
to
be,
the
warning
I
don't
know
like
that
would
be
fine.
E
Yeah
I
think
coming
back
to
my
earlier
point
and
kind
of
following
up
on
what
John
said.
The
whole
point
of
having
the
experimental
is
that
we
want
people
to
try
it
and
I
think
expose
is
somewhat
special
in
that
people
cannot
meaningfully
try
it
if
they
can't
publish
it
so
I
think
it's
a
place
where
warning
is
weird,
because
it
goes
directly
against
people
being
able
to
actually
try
it,
because
without
publishing
it
doesn't
really
have
a
meaningful
user
experience
that
people
would
actually
be
able
to
observe.
A
C
So
one
thing
I'm
pretty
sure
about,
and
if
anyone
disagrees
with
this,
please
speak
up
I
think
we
don't
want
exports
and
conditional
exports
to
behave
differently
like
if
one's
gonna
throw
warnings.
The
others
should
throw
warnings
like
it's
not
like
one
was
any
less
experimental
than
the
other.
So
the
fact
that
exports
like
plane
exports
is
not
warning
us
right
now
is
a
bug,
because
that
doesn't
seem
to
be
intentional.
C
That
said,
yeah
I
mean
I
haven't
really
thought
through
all
the
consequences
of
this
but
I
I.
You
know
if
it
seems
okay
with
everyone
else,
maybe
if
we
can
somehow
make
the
warnings
only
appear
for
package
authors.
Maybe
that
could
be
the
the
solution.
I
guess
and
then
the
question
would
be
if
we
can't
figure
out
a
good
way
to
do
that,
then
maybe,
like
y'all
said
we
just
don't
show
warnings
for
these
two
features.
C
D
In
another,
alternative
is
like,
which
would
be
a
cheap
check.
I
think
when
we
pull
out
the
require
condition.
We
can
also
say:
is
there
a
default
condition
and
is
it
the
same
file
and
if
so,
don't
issue
a
warning
and
if
it's
different
still
issue
the
warning,
because
that
will
that
would
actually
be
differentiating
between
when
conditional
exports
makes
it
like
makes
a
difference
over
exports
versus
not.
You
know
what
I
mean
yeah.
C
D
And
that's
there
that's
already
a
case
like
I've
made
tests
in
my
packages
that
use
conditional
exports
to
test
the
ESM
stuff
and
use
the
self
references
and
whatnot
and
I
have
to
use
I
use
like
I
use,
dynamic
import
in
those
and
those
issues
like
with
self
reference
and
those
issue
that
warning,
and
so
that
like
that,
is
definitely
a
bit
of
an
inhibition.
But
because
all
imports
are
experimental
like
a.
It
doesn't
didn't
feel
as
bad
to
me,
but
you're
right
in
that
it
potentially
inhibits
the
doctrine
in
the
same
way.
I.
C
E
Think
I'm
getting
to
a
point
where
I'm
but
I
think
we
should
remove
the
warning,
because,
even
if
we
would
figure
out
a
way
to
only
warn
the
maintainer
I,
don't
think
that
that
would
really
be
meaningful
because
at
like,
if
I'm
writing,
a
library
that
I'm
going
to
publish
I,
would
see
the
warning.
Only
at
the
very
beginning
of
running
my
test
suite.
That
then
gets
immediately
swallowed
away
by
the
output
of
my
test
suite
and
it
would
just
be
noise
most
likely.
E
I'm
not
sure
if
that
is
it's
not
like
the
buffer
warning,
where
we
then
expect
the
maintainer
to
stop
using
buffer
or
the
buffer
constructor,
and
then
the
warning
goes
away.
It's
just.
We
are
training
to
maintain
us
to
ignore
the
warning
because
cannot
do
anything
that
would
remove
the
warning
as
if
they
actually
want
to
try
it,
so
it
doesn't
feel
like
we
are
training
people
to
do
something
good.
C
E
Say
for
any
feature
where,
for
example,
exports
is
a
feature
that
is
definitely
controlled
by
the
publisher:
I,
don't
care
less
about
import,
because
the
moment
that
the
user
is
using
imports
as
at
least
one
warning
anyhow,
but
for
require?
Definitely
there
is
no
reason
for
why
it
should
print
something
on
the
user
side.
If
the
user
cannot
actually
do
anything
about
it,
I
think
it's
a
little
bit
different
for
an
our
import
Jason,
for
example,
where
the
user
hope,
where
people
maybe
shouldn't,
be
publishing
code
that
uses
import
Jason
and
the
pen
testing.
C
Rather,
if
the
may
be
a
simpler
way
of
putting
it
would
be,
if
the
user,
the
end
user,
isn't
using
a
flag,
they
shouldn't
probably
be
seeing
warnings
like
right,
I
mean
that
would
only
affect
exports
and
conditional
exports
and
self
result
I.
Think
but
like
we
don't
want
the
user
to
see
warnings
that
they
didn't
themselves
trigger
by
opting
into
it
with
a
flag.
Is
that
fair
to
say.
C
Cuz,
that's
what's
annoying
to
user,
so
it's
like.
Why
is
I
getting
this
error?
You
know,
I,
didn't
I,
didn't
opt
into
this
and
I
have
no
way
to
opt-out
of
it
other
than
to
suppress
all
warnings.
You
know,
I
mean
I
mean
the
other
thing.
I'm
thinking
is
like
we're
in
13
it's
already
marked
as
experimental
in
the
docs.
We
can
make
some
ver
major
changes
before
14.
If
we
want
so
we
could
really
change
anything
we
want,
but
you
know
until
1400
in
April,
I
think
so.
E
Where
I
would
draw,
the
line
is
if
the
feature
is
experimental
because
we
haven't
committed
yet
to
the
exact
API.
So
normally
it
is
by
design
that
we
don't
want
people
to
publish
anything
using
it
right.
We,
we
don't
write
packaged
authors
to
adopt
x-men,
who
wasn't
modules
right
now
or
certain
I'm,
not
sure.
If
other
pending
features
that
are
not,
there
are
currently
triggering
warnings,
so
normal
self
is
all
normally.
E
It
would
be
by
design
that
package
authors
would
not
use
exports
right
now,
because
it's
experimental
and
not
conditional
exports,
because
it's
experimental
normally
these
features
shouldn't
be
appearing
in
published
packages.
It's
just
that
in
this
case,
that
is
really
hindering
us
being
able
to
evaluate
the
feature
if
they
don't
so
the
the
math
changes
slightly
sorry
I
didn't
mean
to
jump
over
John
there.
No.
D
It's
like
I
mean
this
is
something
I've
said
throughout
this
entire
working
group
process
is
that
modules
are
uniquely
different
thing
than
all
other
features,
because
it
like
is
viral
in
the
ecosystem
and
I
think
that
in
general,
like
errors
should
be,
should
punish
the
people
who
can
change
them,
and
then
fate
like
failing
that.
They
should
exert
social
pressure
on
those
people
indirectly
right
so
like.
D
There's
not
like
a
productive
way
to
to
both
get
adoption
of
the
feature
and
also
issue
those
warnings,
and
it's
just
ends
up
punishing
the
users
so
like
I
I'm,
totally
fine
with
like
I'm
still
fine,
with
keeping
the
warnings
for
import,
because
import
is
like
the
choice
of
the
consumer,
but
I'm
less
fine
about
it
with
the
you
know
for
require,
because
that's
like
the
current,
stable
non-experimental
thing,
but
I'm.
Also
fine.
If
we
remove
the
warnings
for
import,
because
that
just
encourages
people
that
you
test
it
out.
D
Was
one
of
things
that,
like
at
this
point
short
of
like
based
on
all
of
our
discussions?
Do
we
expect
really
any
changes
to
export
your
conditional
exports
yourself
or
package
name
resolution
before
we
backported,
like
we've
left
ourselves?
The
possibility
by
marking
it
experimental
but
like
short
of
something
like
require
ESM
happening
or
something
like
I've
gotten,
the
impression
that
this
is
probably
the
final
design
and
like
unless
something
you
know
new
happens.
So
it
seems
like
one
of
the
safest
times
to
start
letting
people
use
it.
You
know
sorry
go
ahead,
Geoffrey.
C
Gonna
say
I
would
agree
with
that.
I
think
I
was
gonna
say,
like
I
think
we
can
maybe
leave
the
nitty-gritty
details
of
this
to
the
to
a
PR
that
you
know,
I
would
say
somewhere
in
between
on
the
spectrum
of
you
know,
removing
all
warnings
for
exports
constructs
boards
or
removing
them
unless
the
user
is
using
some
kind
of
flag
or
removing
them.
Unless
they're
the
author-
and
you
know
we
can
figure
out
in
the
PR
like
when
exactly
the
conditions
should
be,
but
I
guess
do
we
have
agreement
on
that
and
also
that?
A
A
Think
I
may
have
just
found
a
bunch
of
bugs
I
think
that
conditional
exports
is
probably
something
that
is
not
going
to
change
yes,
but
I
am
NOT
a
hundred
percent
comfortable
with
just
removing
all
of
the
flags
or
removing
the
flags
in
a
way
that
is
inconsistent,
especially
since
one
of
the
things
that
we've
tried
to
do
here
in
our
design
is,
is
consistently
offer
the
same
support
for
CJ
s.
Ndsm
I
recognize
that
pragmatically.
A
A
I
am
not
a
hundred
percent
convinced,
yet
that
consumers
of
module
should
not
be
aware
that
the
module
that
they're
consuming
is
using
an
experimental,
API
and
I.
Don't
I'm
not
necessarily
convinced
that
this
is
a
special
edge
case
when
we
had
http/2,
and
that
was
an
experimental
API
with
FS
promises,
and
that
was
an
experimental
API
if
you
required
or
imported
a
package
that
was
using
those
experimental
API.
As
you
saw
the
warning,
this
isn't
special
for
modules.
Yon.
E
C
A
With
with
the
notion
that
that
it
should
be
put
behind
a
flag,
we
want
people
to
use
it
if
package
authors
do
not
want
to
use
it
because
they
don't
want
to
give
warnings
to
to
their
package
consumers.
That's
fine,
I'm,
a
package
author
I,
don't
mind,
publishing
an
experimental
canary,
build
that
people
can
play
with
that.
Isn't
the
main
line
stream,
putting
it
like
I,
don't
think
putting
this
behind
a
flag
and
experts
as
a
whole
behind
a
flag
is
a
massive
step
backwards
and
I.
E
E
D
B
So
I
I
kind
of
second
miles
here,
I,
don't
think
we
should
have
a
flag,
I,
think
package
authors,
it's
certainly
within
their
power
to
not
use
this
feature.
If
they
don't
want
to
see
the
warning,
so
that's
something
they
can
do,
even
if
they
do
have
multiple
release
channels,
I
mean
that's
not
the
same
as
what
Yann
was
talking
about
with
feature
detection
at
run
time,
particularly
exports.
Any
well
most
ways
in
which
you
can
consume
a
package
are
going
to
hit
the
exports
feature
before
they
hit
any
code
within
that
package.
B
So
it
seems
like
this
is
different
from
a
feature
detection.
If
else
branch
there
are
probably
ways
that
you
could
work
around,
that
I
mean
you
could
have
a
second
inner
package
that
has
it,
but
the
whole
point
of
exports
is
you're,
manipulating
how
resolution
works,
so
anybody
who's
trying
to
consume
your
package
is
going
to
hit
it.
B
It's
like,
if
you
had
that,
if
condition
we
were
talking
about
where
people
might
not
want
to
use
that
feature
at
the
very
start
of
things,
and
you
always
had
to
check
that
feature,
which
is
what
gives
the
warning
it
seems
like.
We
can't
compare
this
to
a
runtime
feature.
Detection
and
authors
don't
have
to
see
the
warning
because
they
don't
have
to
use
the
feature
so
I'm
not
sure
we
need
to
take
any
action.
I
think.
E
There
was
a
misunderstanding
with
what
he
just
said,
so
I
I
did
not
mean
to
say
that
I
was
literally
talking
about
an
if
branch
in
the
code
for
this
case
I
compete,
I
compared
it
to
worker
threats
and
then
using
an
if
branch
in
my
code.
So,
for
example,
I
am
the
owner
of
a
web
platform
at
my
last
company.
There
are
some
internal
libraries
where
I
would
use
this
feature.
E
For
example,
let's
say
it's
worker
threat:
it's
not
exports,
so
since
I
don't
want
to
expose
the
whole
fleet
of
applications
to
this
feature,
I
make
sure
that
it's
not,
incidentally,
used
by
everybody.
So
the
way
I
want
to
wanted
to
you
if
I
want
to
actually
give
meaningful
feedback
and
use
it
in
an
application
or
to
I,
don't
want
to
form
all
libraries
that
do
it.
I
want
to
keep
publishing
one
marching
line
of
libraries
because
there's
a
lot
of
releases
going
on.
E
And
I
don't
want
random
applications
to
see
warnings
or
random
applications,
potentially
even
to
get
the
feature.
So,
if
my
only
way
of
doing
it
is
either
I
cannot
give
feedback
or
everybody
gets
warnings
or
I
have
to
start
forking.
All
my
packages
that
I
want
to
try
it
out
with
I
will
choose
just
not
to
give
feedback
I.
B
A
B
To
the
CLI,
you
mean
to
note
to
the
command
line
interface.
No,
it
has
many
things:
where
is
the
which
flag
are
you
asking
about
experimental
expose
the
flag
that
we
used
to
have?
Okay,
even
then
I
don't
know
if
we
really
should
be
going
towards
that,
because
that
means
people
wanting
to
use
this
package
office
wanting
people
to
see
how
this
works
and
are
willing
to
have
their
consumers
see.
Warnings
will
basically
be
stuck
in
an
even
more
difficult
position
of
getting
feedback.
B
We
have
we've
taken
something
where
you're
concerned
about
getting
feedback
and
we're
just
making
it
harder
and
harder
to
get
feedback
button,
not
having
the
warnings
unless
you
have
this
flag
or
not
having
the
feature
at
all.
Unless
you
have
this
flag,
if
we
do
have
the
warnings,
a
package
author
can
still
ship
something
to
get
feedback,
but
without
the
flag
it
becomes
much
more
difficult
to
get
feedback.
A
D
Well
so
I
I'll
wait.
We
don't
have
to
respond
to
my
comment
until
after
we
see
miles
a
suggestion,
but
I
guess
it
feels
like.
It
still
feels
like
a
possibility
that
we
could
say
if
require
triple
equals
default.
Don't
like
skip
the
warning
but
like
because,
given
that
there's
no
warning,
if
I
just
delete
require
so
that
was
that
was
my
explicit
suggestion,
but
I'll
wait.
We
can
talk
about
that.
One
miles
talks
about
his
voters,
necks,
go
ahead,
I.
C
Was
just
gonna
say,
I
think
the
fact
that
conditional
exports
is
triggering
a
warning,
but
regular
exports
is
not
it's
just
a
bug,
and
we
should
fix
that.
Like
they're,
there
they're
both
experimental,
they
should
both
behave.
The
same
way
and
I
wouldn't
want
I,
don't
think,
there's
any
just
any.
Like
reason
why
we
would
want
package
authors
to
behave
as
Jordan
is
saying
that
he
wants
to
behave
which
is
like
to
leave
out
require
from
conditional
exports
would
include
the
other
things
like
if
you're
using
additional
exports
at
all.
C
You
should
get
the
warning,
I
feel
like
and
ditto
with
a
few
using
exports
at
all.
You
should
get
the
worm
so
I
don't
know
if
we
have
consensus
on
that
at
least
just
the
interim
like
status
quo
before
we
make
any
broader
decisions
about
removing
warnings,
but
I
wouldn't
say
that
the
current
exact
status
quo
is
very
defensible.
C
A
I
I
have
a
solution
that
requires
us
to
do
nothing
so
we
landed
experts.
We
landed
exports
without
a
warning.
Exports
was
a
fairly
fundamental
change
for
the
way
in
which
we
do
things
and
I
think
that
collectively,
every
single
person
in
this
room
at
least,
would
be
my
hope
can
reach
consensus.
That
exports
is
not
going
anywhere.
The
basic
idea
of
exports
itself
and
like
we
talked
through
that
a
bunch
I
think
it
is
more
stable
than
conditional.
A
We
literally
made
a
pretty
fundamental
change
to
two
conditionals,
just
between
thirteen
thirteen,
six
and
thirteen
seven.
So
it's
still
hot
fun
fact,
because
we
do
not
have
a
warning
in
exports
proper.
If
you
make
your
default,
the
commonjs
entry
point,
there's
no
warning
so
the
pattern
that
we
could
suggest
to
people
right
now
would
be
don't
use
the
require.
If
you
want
an
ESN
entry
points
specifically
use
the
module
or
the
import
as
what
we
call.
A
A
They
should
have
no
warning
when
you
require
them
and
that's
correct.
They
do
not
so
I
think
that
the
places
where
people
were
complaining
about
the
warnings
we
can
advise
them
use
import
for
your
entry
point
for
for
es
m
and
use
defaults
as
your
entry
point
for
con
and
Jas,
if
folks
are
doing
something
like
their
project,
is
by
default.
Es
m
and
they're
transpiling,
something
to
CJ
s
and
they
I
would
personally
and
I
have
a
package
it
does.
C
C
A
C
A
But
when
we're
talking
about
like
the
stability
index
inside
of
node,
that
we
use
there
is
like
from
experimental
to
stable
is
a
pretty
huge
jump.
I
would
not
say
that
expert
is
stable
yet,
but
I
would
say
it
is
stable
enough
in
the
experimental
stage
that
we
don't
need
to
be
giving
a
warning
for
it.
C
A
A
D
A
D
A
D
I
mean
we
already
have
an
if
statement
that
checks
the
presence
of
require,
presumably
right.
So
this
would
be
for
that,
for
only
if
that's
that's
there,
it
would
be
if
requires
present,
and
then
we
did
we'd,
alter
it
to
add
and
require
equals.
You
know
default
or
something
to
that
effect.
But
yeah
it
is
it's
not
zero
cost.
That's
that's
fair!
I.
A
Think,
like
the
other
thing
to
think
about,
there
is
like
it
also
creates
inconsistent
results
from
a
warning
perspective
across
versions.
It's
not
a
huge
deal,
but
it's
like
if
we
have
a
solution
that
doesn't
involve
us
changing
anything
and
personally
think
if
we're
thinking
about
it
in
the
sense
of
like
how
exports
works
versus
conditional
exports
for
saying
conditional
exports
is
still
experimental.
Default
is
just
supported
by
exports
already
so
like
you're,
not
actually
using
the
conditional
exports
feature
when
people
use
default
as
the
export.
A
D
A
B
A
A
A
Aside
from
that,
when
we're
talking
about
like
longer-term
I,
think
we're
still
on
track
for
April
as
a
potential
target
date
to
unflagged
on
12,
April
will
also
be
when
we
cut
14
and
I.
Think
at
some
point
between
April
and
October
is
when
we
should
consider
removing
the
various
warnings
that
we
have.
But
I
think
that
is
a
different
conversation.