►
From YouTube: Node.js Foundation Modules Team Meeting 2020-02-26
Description
A
And
we
are
live
on
YouTube
with
the
February
26th
edition
of
the
no
gist
modules
team.
If
you're
wondering
why
emphasize
the
are
in
February,
it
is
because
it
is
the
month
of
my
birth
and
I
went
over
20
years,
not
realizing
that
there
was
a
second
are
in
there,
and
so
it's
a
deep
shame
that
I
continue
to
live
with.
But
that
is
not
the
topic
of
today's
meeting,
we're
here
to
talk
about
modules
and
we
have
a
fairly
full
agenda.
A
B
So,
as
we
discussed
in
the
last
meeting,
we
had
issues
coming
up
with
projects
like
pre
acts
that
are
now
shipping
exports
in
their
package.
Anthem,
which
means
that
uses
her
running
nodejs
13
are
getting
these
warnings
when,
when
they're
running
and
another
case
came
up,
where
I
had
a
user
of
es
module
lexer,
who
was
asking
for
the
main
to
point
to
the
the
es
module
file
and
I
indicated
to
them.
B
B
If
we
want
to
be
thinking
about
back
porting
to
12
in
April,
we
want
to
be
sure
that
there
is
real-world
feedback,
real-world
usage
feedback
and
we're
not
going
to
get
that
while
exports
is
giving
this
morning
because
packages
like
these
are
going
to
resist,
publishing
and
resist
driving
down
and
getting
that
that
usage
going.
So
the
PR
was
to
remove
the
warnings
for
conditional
exports
and
remove
the
warnings
for
self
resolution,
which
is
also
an
export
feature
and
then,
in
addition,
someone
brought
up
that
we
should
actually
remove
the
experimental
Manzo's
warnings
as
well.
B
So
I
thought
it's
really
a
good
time
to
discuss
that
as
well.
So
this
kind
of
ties
into
last
meeting
where
we
said
that
we
should
create
an
issue
to
discuss
timelines
around
removing
these
moon
wings.
Do
we
remove
them
all
together
when,
when
are
people
comfortable
with
removing
them?
Does
everyone
agree
that
we
should
remove
condition
or
export
warnings?
Now,
that's
the
pitar.
A
Yeah
I'll
just
try
that
a
bit
thinking
about
it
like
I,
guess,
I
guess.
The
balance
here
that
we
need
to
maintain
is
ensuring
that,
like
six
using
these
are
aware
that
that
they
are
experimental.
So
you
know
there
have
been
a
handful
of
occasions
where
people
have
jumped
into
issues
of
breaking
changes
that
we've
made
pointing
out.
Oh
my
god,
you
made
like
a
breaking
change
and
we
can
point
at
the
warnings
and
we
comported
the
point
at
the
documentation.
A
C
A
So
at
least
the
intention
on
12
is
that
none
of
these
features
are
accessible
or
usable
without
the
experimental
modules
flag
which
rows.
The
experimental
modules
warning.
I
think
there
is
something
to
be
said
about
like
keeping
things
consistent
between
12
and
13
there,
but
I
would
probably
want
to
like
have
a
little
bit
of
time
with
it
on
12.
Before
we
waterfall
yawn
your
hand
is
up.
E
The
world
it's
it's,
it
is
what
is
actually
happening.
The
feature
is
out
there.
People
have
writing
package.json
files
that
are
referencing
the
semantics
of
the
feature
right
now.
It's
just
painful
that
they
have
to
write
it
in
a
very
specific
way.
So
you
don't
accidentally
trigger
the
warning
if
they
do.
This
makes
it
official
that,
yes,
that
is,
that
is
the
state
of
the
world.
A
Jordan,
do
you
mind
if
I
ask
you
on
a
quick
question
before
you
go
so
I?
Guess
the
the
the
thought
that
I
have
here
and
it's
not
necessarily
changing
my
take
on
it,
but
it
seems
like
the
warning
actually
accomplished
part
of
its
goal
in
which,
like
people
seeing
in
the
warning
and
being
annoyed
by
it
came
back
to
us
to
let
us
know
that
they
were
annoyed
by
it,
which
in
turn
that
actually,
let
us
know
a
handful
of
these
larger
projects
that
were
adopting
it.
A
E
Adoption
mister
clarified.
The
reason
why
I
brought
it
up
was
not
because
of
one
of
those
larger
projects,
but
because
of
me
randomly
finding
a
github
issue
of
a
smaller
project
that
saw
what
the
larger
project
did.
So
we
didn't
know
about
it.
They,
like
ones
one
of
the
larger
projects
run
into
it
and
became
imputation
back
to
public
knowledge.
The
warning
is
no
longer
reaching
us
because
they
search
they
google,
they
find
the
issue
they
make
the
change
they
in
the
commit
message.
They
say
workaround
the
annoying
warning
message
and
that's
it.
A
So
I
think
I
guess
I
guess
the
thing
for
that
there
is.
They
are
writing
things
in
such
a
way
that
in
common
Jas
they
are
arguably
not
using
any
of
the
experimental
features
that
I
realize
that
that's
pettit
ism,
like
I'm
being
pedantic
about
it,
but
yeah
I
think
we
should
remove
the
warning.
But
I
do
think
that
there
has
been
value
in
having
the
warning.
D
D
They
can
of
course
decide
that
they're
not
breaking
changes
in
han't
wave
their
hands
but
like
despite
our
warnings,
pre
acts
developers
who
are
who
are
experienced
still
use
this
experimental
feature,
not
even
in
a
major
new
major
version
and
like
on
top
of
that,
like
your
point,
is
valid
miles
that
the
that
we
do
still
hear
about
it.
When
the
consumers
see
the
warning.
But
you
know
Jeffrey
and
yawns.
D
Point
is
also
valid
that
now
that
they
know
how
to
get
around
it,
we're
not
going
to
get
that
anymore
anyway
and
then
also
like,
because
the
warning
is
not
being
surfaced
to
the
people
who
can
do
anything
about
it
like
I,
don't
think
it's
achieving
much
so
like
it
was
I
mean
I,
think
it
was
fine
too,
with
a
warning,
but
I
also
like
think
that
it's
that
features
like
this
that
leak
they're
not
encapsulated
right
like
it's.
You
know
it's.
It's
really
hard
to
make
these.
D
These
warnings
have
any
effect,
and
so
like
at
this
point,
they're
out
in
the
wild
things
are
using
them
like
the
fact
that
we
can
technically
get
rid
of
them
or
break
them
or
whatever
to
me,
is
sort
of
irrelevant
like
we
need
a
really
good
reason
to
want
to
do
that,
I
think
and
I.
It
doesn't
seem
like
any.
Such
reason
is
forthcoming.
So,
like
I
like
to
see
us
remove
the
warnings
at
this
point,
yeah.
A
So
the
the
bit
that
I
was
gonna,
add
is
my
understanding
is
for
some
of
the
warnings
related
to
unsafe
uses
of
the
buffer.
Api
did
do
something
like
this,
where
it
was
only
the
use
within
your
own
package,
but
not
within
the
dependencies
that
threw
the
warning,
and
we
could
do
something
like
that.
That
is
an
option
and
I
guess,
like
my
question
to
the
room
is
like:
is
it
worth
the
engineering
effort
to
do
that,
or
should
we
just
remove
the
warnings
I.
D
Mean
the
challenge
there,
too,
is
that
it's
with
use
of
the
API,
like
that's
gonna,
happen
with
any
exercising
of
your
first
party
code,
and
so
then
that
engineering
effort
has
the
desired
effect.
But
with
this
one,
unless
they're
using
self
self
reference,
like
the
self
package
name,
import
they're
not
actually
using
a
feature
in
their
own
code,
so
they're,
even
their
tests,
are
not
going
to
trigger
that
warning.
So,
unless
they're
using
the
their
own
package
name,
they
are
never
gonna,
see
the
warning,
no
matter
what
effort
we
put
into
it.
D
A
B
B
A
B
D
A
B
D
A
C
C
E
C
C
C
A
Jeff
I
agree
with
you
on
principle
there,
but
especially
when
we're
talking
about
things
like
warnings
or
we're
talking
about
things
like
stability
index.
It
is
a
different
story
to
make
these
changes
to
an
LTS
branch
than
to
an
on
LTS
branch
and
I'm,
not
saying
yes
or
no,
but
I
think
that
it's
I
think
that
it
would
be
beneficial
for
all
of
us
to
separate
the
discussion
of
kind
of
timelines
in
what
we
do
on
those
two
branches.
All.
A
You
cool
so
the
next
item
we
have
here
is
add
support
for
extension
list
workers
in
ESM
eval.
This
is
an
upstream
PR.
It
got
flagged
for
the
modules
agenda
by
me,
but
I
think,
and
some
in
current
correct
me
if
I'm
wrong,
that
the
work
is
actively
happening
there.
Brad
I,
see
you
were
one
of
the
last
people
to
comment.
Is
there
a
need
for
us
to
discuss
this
in
the
meeting
today
or
is
the
work
that's
happening
on
github
good
enough.
F
There's
just
a
need
to
be
aware
of
it:
I
think
there
are
different
ideas
on
how
to
take
the
PR.
It
seems
like
the
way
the
PR
is
right
now
goes
against
one
of
the
design,
I
would
say,
patterns
we've
been
doing
in
this
working
group,
where
they're
having
the
consumer
defined
the
format
of
a
target
resource
and
so
they're
just
alternatives
in
that
thread.
It
just
to
be
aware
that
it
exists
I,
don't
think,
there's
anything
necessarily
discussed
that
needs
to
happen
here.
Go
to
the
issue
through.
A
Okay,
thank
you.
Thank
You,
Brad
I'm
gonna
go
ahead
and
remove
the
modules
agenda
issue
label
from
that
issue.
For
now
and
folks
now
that
you're
aware
of
it,
please,
you
know,
go
in
and
take
a
look
and
in
general
you
know,
there's
lots
of
activity
that
happens
on
core,
so
in
general,
making
sure
that
those
things
get
labeled
with
the
es
modules
label
and
when
it's
important
to
flag
to
the
team
that
the
appropriate
labels
are
put
in
is
really
helpful.
So
please,
you
know
if
you
see
stuff
label
it
very
much
appreciated
okay.
A
F
Been
open
for
quite
a
while
I'd
like
to
move
it
forward,
but
I
still
don't
have
a
good
hook
for
global
attenuation,
which
was
something
that
was
brought
up
a
while
ago
about
it.
At
this
point,
I
feel
like
we're.
Just
gonna
have
to
split
the
work
and
either
move
forward
or
completely
block
this
until
we
find
a
way
to
attenuate
well
on
the
global
we've
tried
a
few
different
approaches.
F
In
the
past,
one
was
basically
adding
a
hook
for
require
style
reloads
and
that
made
the
timing
of
nodes
bootstrap
incredibly
difficult
to
wrangle,
especially
with
how
async
hooks
are
set
up,
so
I
kind
of
abandoned
that,
and
then
I
was
going
through
and
trying
to
figure
out.
If
we
should
just
allow
loader
hooks
to
give
a
source
text
that
can
be
run
on
bootstrap,
but
if
that
does
any
async
work,
that
also
has
problems
with
the
bootstrap.
F
F
B
B
B
Yeah,
but
it's
not
just
for
dynamic
instantiate,
it's
also,
you
know
a
loader
should
be
able
to
be
self-contained.
You
shouldn't
need
to
have
the
usage
of
the
loader
also
in
invoking
a
require
flag
or
something
like
that,
and
a
lot
of
ATM
systems
need
to
hook
into
the
require
system.
I
think
that's
fine,
but.
B
F
E
So
I
I
do
agree
with
guy
that
a
global
some
way
of
running
code
globally
before
any
application
code
runs,
should
somehow
be
able
to
access
the
built-ins
like
the
the
buildin
modules,
because
that
just
captures
a
lot
of
current
use
cases
and
yes,
that
overlaps
with
does
require.
So
in
theory,
people
who
need
that
could
just
pass
require
and
they
could
pass
loda
as
two
separate
arguments,
one
with
the
bootstrap
code,
one
with
the
with
the
actual
loader
hooks,
but
to
be
fair.
E
E
But
if,
if
I
think,
we
are
definitely
getting
to
the
point
where
we
need
to
decide
if
we
wanna
block
this
PR
on
bootstrap
code
on
enter
attenuation
code
on
stuff.
That
in
theory
could
also
be
passed
in
require
technically
or
whether
we
were
good
moving
forward
with
this.
Even
though
it
means
that
loaders
by
themselves
cannot
do
a
generation,
they
need
a
second
flag
to
require
to
make
it
happen
to.
F
F
A
A
A
Chartering
the
team-
let's
just
dig
right
into
that
I-
think
the
next
step,
if
we
wanted
to
move
forward
with
this,
would
be
to
make
a
pull
request
against
the
TSE
repo.
There
is
a
document
in
there
for
working
groups
which
has
a
list
of
all
active
working
groups
as
well
as
what
the
scope
of
the
working
group
is.
I
can
dig
up
that
document
and
drop
it,
so
people
can
take
a
look
so
I
think
what
we
primarily
need
to
do
is
reach
consensus
as
a
group
about
what
we
would
outline
in
there.
A
So,
like
specifically
like
if
you
look
at
build,
for
example,
it's
like
the
build
working
groups
purpose
is
to
create
a
maintain
a
distributed.
Automated
automation,
infrastructure
responsibilities
include
producing
packages
for
all
target
platforms,
running
tests,
running
performance
testing
in
comparison,
creating
and
managing
build
containers.
So
what
we
would
need
to
do
is
like
define
the
scope
of
what
we're
asking
to
be
chartered
for.
A
You
know
that
that
could
be
like
final
arbitrator
of
decisions
regarding
the
ESM
module
infrastructure
in
node.js
core
to
other
things
and
I.
Guess,
like
one
of
the
kind
of
core
questions
here
is,
if
you
look
at
like
streams,
for
example,
says
the
streams
working
group
is
dedicated
to
support
an
improvement
of
the
streams
API
as
used
in
nodejs
and
the
NPM
ecosystem.
A
We
seek
to
create
a
composable
API
that
solves
the
problems
of
representing
multiple
occurrences
of
an
event
over
time
in
a
humane,
low-overhead
fashion
improvements,
the
API
will
be
driven
by
the
needs
of
the
ecosystem,
interoperability
and
backwards
compel
it
a
bit
compatibility
with
other
solutions
and
prior
versions
are
paramount
and
important
responsibilities.
Responsibilities
include
addressing
stream
issues
on
the
node.js
tracker
authoring
and
editing
stream
documentation
within
the
node.js
project.
A
Reviewing
changes
to
the
stream
subclasses
within
the
node.js
project,
redirection
changes
to
streams
from
the
node.js
project
to
this
project,
assisting
in
the
implementation
of
stream
providers
with
a
node
recommending
versions
of
readable
stream
messaging
about
future
of
streams.
Personally,
I
find
the
scope
that
streams
has
to
be
a
very
similar
scope
to
what
we
should
probably
being
asking
for
I
like
that.
It
is
very
much
about
like
responsibility.
A
Is
anyone
like
particularly
motivated
to
even
do
this
for
what
it's
worth?
There's
lots
like?
We
have
been
able
to
do
everything
that
we've
wanted
to
do
without
chartering.
It
hasn't
really
gotten
in
the
way
of
us
being
productive
of
shipping
things,
so
I
guess
the
flip
side
is,
since
it
doesn't
seem
like
folks,
have
a
lot
of
feedback
on
this
at
least
not
immediately.
Are
we
good
with
just
maintaining
the
status
quo?
Or
did
people
want
to
pursue
chartering,
I.
C
D
Sorry
go
ahead,
no
I
mean
there's
like
there's
a
nonzero
right
ignition
piece,
but
I
think
that
it's
like
that's
not
really
what's
important.
Obviously,
I
think
that
the
if
there's
not
a
material
difference,
if
it's
just
about
like
whether
we
have
authority
versus
whether
we
are
given
like
conditionally
given
authority,
then
maybe
it
doesn't
matter,
but
it
still
seems
like
the
right
thing
to
do
and
there's
gonna
be
I.
Think
there's
gonna
be
more
decisions
in
the
future.
D
That
needs
to
have
a
separate
group
set
aside
to
do
it
and
it
seems
like
if
the
group
is
chartered
it
will
be
easier
to
get
that
going.
Then
if
we
have
to
just
kind
of
reconvene
like
if
we
just
stop
stop
meeting,
because
we're
done
and
then
like
in
a
year
was
a
module
show
up
and
we
have
to
like
you
know.
We
have
to
kind
of
forget,
though
interested
people
back
together.
It
seems
like
it'll,
be
easier
if
we
had
to
do
that
for
me
little
charted
group,
but
for.
A
C
A
C
A
The
general
like
collaborator
ship,
probably
wouldn't
allow
it
and
again
I
think
looking
at
the
streams
groups
charter
is
a
really
good
one
to
compare
to.
If
we
look
at
I'm
trying
to
see
another
one,
that's
of
a
similar
scope,
but
like
specifically
here
with
streams,
there's
nothing
here,
saying
that
they
own
decisions
for
all
changes
to
it.
It's
more
like
addressing
the
issues
in
the
tracker
authoring
and
editing,
documentation,
reviewing
changes
so
yeah
we
would,
we
would
be
able
to
like
I
personally,
would
be
uncomfortable.
A
For
example,
with
us
saying,
our
group
owns
a
subsection
of
the
code
base
and
nothing
can
happen
without
our
review
or
our
work,
but
we
do
have
enough
members
who
are
participating
in
core
that
can
you
know
effectively
block
things
if
we
are
uncomfortable
with
them.
Unless
has
their
hand
up
so
I'll?
Let
Wes
go.
G
I
just
wanted
to
mention
with
the
package
main
is
working
group.
We
did
do
a
proposal
for
an
addition
to
package
Jason,
which
then
NPM
folks
ran
with
and
made
in
addition,
which
goes
through
no
process
so
like
that
kind
of
logic,
I
well,
I
think
there
would
be
some
great
benefit
in
having
a
group
that
considers
those
things
explicitly
and
owns
them,
which
would
be
not
NPM,
preferably
not
anything
against
them.
Just
like
that's,
you
know
they
have
a
lot
of
free
rein.
G
A
So
so
here
here's
a
here's,
a
good
question
to
the
group.
I
don't
have
time
to
do
this
for
a
while.
Does
anybody
want
to
take
the
time
to
draft
up
a
potential
charter
that
we
would
add
to
the
working
groups
document
that
outlines
what
the
responsibilities
of
our
group
would
be
if
we
wanted
to
charter.
A
A
Let's
keep
it
open.
What
I
would
say,
though,
as
a
group
is
that
if
no
one
is
able
to
find
the
time
to
do
the
work
and
I
I
think
that
it
is
a
relatively
strong
signal
that
we
are
not
being
blocked
in
any
sort
of
way
by
being
chartered
or
not
being
chartered,
and
so,
unless
someone
wants
to
like
kind
of
step
up
and
do
this
work,
I
think
at
one
point
we'll
just
have
to
say:
okay,
it's
just
not
happening,
and
it's
not
a
big
deal.
A
There's
lots
of
other
teams
and
groups
that
you
know,
I,
guess
one
advantage
that
we
don't
have
right
now
is
discoverability
from
the
TSC
working
group
readme.
But
you
know
that's
neither
here
nor
there
I
think
we
should
move
on
for
now.
The
next
issue
that
we
have
here
is
loader
hooks.
Is
there
any
update
on
where
we're
at
with
loader
hooks?
Does
anyone
want
to
take
this
issue
on.
C
A
C
This
is
what
the
what
we
were
talking
about
was
like.
Oh,
we
really
need
to
focus
on
this
like
this
is
the
last
no
I
don't
know
about
last
but
like
this
is
a
kind
of
a
prominent
missing
piece
that
we
need
to
fill
in
on
the
ESM
implementation.
I,
don't
know
of
anything.
That's
happened
in
the
last
two
weeks,
but
I
think
we
were
just
trying
to
keep
our
focus
on.
A
A
C
Think
yang
might
have
said
this,
some
skepticism,
that
we
could
make
that
work
in
a
reasonable
way,
and
that
and
the
like,
the
argument
went
along
lines
of
you
know
the
user
would
have
to
figure
out
some
way
to
tell
know
the
order
that,
to
put
these
say,
if
you
had
three
transform
hooks
in
and
rather
than
node
coming
up
with
yet
another,
you
know
strange
config
file,
you
know
if
you
had
three
functions
that
are
transformed
functions.
Well,
you
as
the
end
user,
could
write
your
own
loader.
C
That
has
a
transform
function
that
within
the
function
body
of
your
transform
function
calls
those
other
three
functions
and
then
that
way,
it's
like
you
didn't
write
a
config
file.
You
just
wrote
code
to
make
a
parent
function
that
calls
the
other
three.
So
that's
something
you
could
do
now,
assuming
that
the
loaders
that
you
know
the
three
loaders
that
you
want
actually
export
their
functions
for
use
in
this
way,
so
that
that
might
be
the
best
that
we
can
do.
C
H
Okay,
so
I
guess
kind
of
my
expectation
was
just
by
order
of
the
arguments.
So
if
you
have,
if
you
use
loader
three
times,
then
my
expectation
would
be
that
you're,
basically
adding
to
the
stack
of
loaders.
My
issue
with
this
suggestion,
with
what
you
just
said,
is
again
for
NYC.
It
actually
injects
a
transform
into
child
processes
and
I.
Just
don't
see
how
that's
I
don't
see
how
we
deal
with
this
situation,
where
somebody
is
using
NYC
but
they're,
also
using
say
TS,
node
or
a
babel.
C
E
So,
for
example,
things
like
hey
I'm,
a
TS
transform,
so
I
try
to
detect.
If
what
I'm
currently
trying
to
transform
is
typescript,
so
I
check
for
the
file
extension,
but
then
I
have
an
HTTP
loader
that
actually
wants
to
load
resources
over
HTTP
and
uses
users,
content
type
headers
and
the
file
extension
might
not
even
be
present,
but
it's
the
typescript.
So
now
you
need
the
typescript
loader
to
somehow
be
able
to
get
the
information
from
the
HTTP
loader
about
something
at
the
time
code.
Loader
should
fundamentally
not
care
about.
E
It
is
non-trivial,
so
I
haven't
so
far
seen
a
good
story.
How
the
user
experience
of
using
multiple
loaders
could
be
good
and
the
user
experience
of
writing
loaders
that
actually
compose
well
with
others
can
be
good
while
still
having
a
simple
piece.
Five
different
loaders
change
them
in
this
exact
order
and
everything
will
be
fine,
interphase
provided
by
node,
and
that
might
just
me
being
not
big,
create
creative
enough.
But
so
far
that
is
my
impression.
My
impression
is
that
it
would
be
better
for
users
if
there
would
be
a
userland
solution.
E
The
node
thing
will
be
all
you
need,
but
if
you
have
an
complex
development
or
test
setup
with
multiple
transformations
that
need
to
feed
into
each
other,
you
kind
of
want
to
have
something
as
actually
smart
about
where
explains
forms
and
which
features
and
I.
Don't
think
that
node
is
the
place
to
do
it,
because
node
is
not
something
that
loads,
complex,
config
files
or
bootstrap
files,
so
I
just
don't
believe
it's
a
good
fit.
A
A
Okay,
with
with
no
objections
going
to
timelines
and
I,
think
for
you
know
the
the
sake
of
a
timeline
here,
where
we
only
have
seven
minutes.
I'm,
just
gonna
share
my
really
raw
thoughts
on
this,
and
we
can
document
this
on.
Github
folks
may
disagree
with
my
thoughts
here:
I'm
open
to
being
wrong.
I.
Think
a
good
example
of
this
is
our
shift
today
about
removing
warnings
that
wasn't
something
I
thought
that
we
would
be
doing
as
soon
for
the
conditional
exports.
But
you
know
you're.
A
Here's
where
we
find
ourselves
today,
I
think
that
removing
the
flag
for
experimental,
the
warning
for
experimental
modules
is
something
that
we
really
should
not
be
doing
until
we
are
fairly
close
to
wanting
to
move
towards
stabilizing
the
API.
I
was
even
in
a
process
where
I
was
unsure
that
we
would
want
to
remove
that
flag
immediately.
When
14
is
being
cut,
we
would
probably
want
the
flag
to
be
removed
by
14.
A
Altea
I
mean
the
the
warning
to
be
removed
by
14
LTS,
but
I
would
want
to
see
personally
more
general
engagement
and
and
use
of
it,
including
use
on
LTS
of
the
feature
without
a
flag
before
we
start
to
remove
the
warning.
An
API
such
as
FS
promises,
for
example,
which
was
like
far
less
of
an
important
API,
had
a
warning
significantly
longer
and
was
a
warning
that
you
would
get
even
if
the
dependency
was
deep
in
your
graph.
A
If
someone
that
you
consumed
used
it,
we
have
a
history
of
having
warnings
and
other
api's
such
as
HTTP
such
as
worker
threads.
There
is
history
of
removing
those
warnings
during
LTS,
so
that
is
not
an
issue
and
I
I
think
that
it
is
absolutely
premature
to
be
removing
that
warning.
Come
April
in
12
I
think
it
may
even
be
premature
to
remove
it
from
13
and
potentially
even
in
master
by
April
and
I
apologize
to
folks,
if
we've
had
conversation
that
have
led
them
to
believe
otherwise.
A
B
I
think
you
have
to
think
about
what
the
utility
of
a
warning
message
is,
and
basically
the
warning
message
achieves
a
few
different
things.
Firstly,
it
discourages
adoption,
it
discourages
users
from
using
a
feature
or
pushing
a
teacher
to
they
uses
because
users,
don't
like
warnings,
warnings
I'm,
not
just
you
know,
in
invisible
things
in
note,
they're
very,
like
the
user
interface
of
nodejs
is
the
console.
Output
and
warnings
come
straight
in
that
console
output,
so
there
for
a
lot
of
use
cases
there.
E
I
think
trying
to
think
through
the
kinds
of
differences
it
would
make
I
think
removing
the
warning
would
to
me
at
first
glance.
The
biggest
difference
would
be
that
if
I
want
to
publish
a
seal
I
to
or
start
using
modules
in
a
CLI
tool
that
I
polish,
the
NPM
I
could
only
really
realistically
do
it.
If
the
experimental
warning
is
completely
removed,
I
cannot
publish
a
CLI
tool
as
long
as
the
experimental
one
is
there,
because
it
would
just
not
be
reasonably
working.
A
So
a
couple
thoughts
to
add
here:
oh
we're
at
we're
at
four
o'clock,
I'll
be
really
quick
and
then
I
may
get
kicked
out
of
this
room
and
then
well
then
the
meeting
said
so
slowing
down.
Adoption
is
potentially
a
feature,
not
a
bug,
the
second
that
we
unflagged
this
on
LTS
and
if
we
also
removed
the
warning,
we
will
get
an
exponential
curve
of
more
adoption,
which
also
means
an
exponential
curve
if
more
usage
of
bugs
of
reports
of
issues,
if
we
have
something
that
we
did,
that
was
wrong.
That
was
broken.
A
That
hasn't
surfaced
yet
because
we
haven't
had
that
level
of
adoption.
We
have
that
much
less
flexibility
to
make
larger
changes
that
we
need
to
make
the
amount
of
timeline
that
we're
talking
about
is
difference
in
n
months.
Not
any
ears.
I
agree
that
we've
been
working
on
this
for
a
long
time,
but
a
lot
of
the
features
I'm
getting
kicked
out
a
lot
of
the
features
that-
and
you
know
like,
walk
and
talk
and
try
to
find
a
room.
A
A
lot
of
the
features
that
were
that
we're
talking
about
having
shipped
now
that
we're
stabilising
have
only
really
been
worked
on
for
n
months,
like
less
than
a
year.
Have
we
been
working
on
them
and
shipping
them
there?
They
are
not
as
mature
as
we
would
like
them
to
be
the
last
bit
here
with
regards
to
that
would
be
if
we,
if
we
want
this
to
be
successful,
I
think
we
need
to
be
careful.
A
Also,
people
can't
just
start
shipping
things
as
long
as
there's
versions
of
a
node
that
don't
support
modules,
nodejs
10
is
still
actively
being
maintained
and
will
continue
to
be
maintained,
I
believe
until
next
April,
so
I'm
not
saying
that
we
should
wait
until
next
April
to
do
all
these
things.
But
I
do
think
that
there
is
something
to
be
said
about
thinking
about
that
as
a
timeline
to
which
folks
can
really
start
shipping
modules
without
breaking
folks
from
underneath
so
I
think.
A
Perhaps
if
we
wanted
to
sit
down
and
start
sketching
out,
like
the
worst
case,
timeline
looks
like
versus
the
best
case
time
on.
Maybe
what
we
could
do
is
start
sketching
out
around
like
hey,
when
does
tengo
end-of-life,
what
are
the
major
milestones
between
now
and
then,
and
where
would
we
like
to
be
with
the
modules
system
in
each
one
of
those
phases,
so
we
could
be
intentional
about
it
and
I'm
very
willing
to
change
some
of
my
opinions
on
this.
What
I
think
would
be
really
useful
is
like,
let's
be
holistic.
A
A
Cory
said
something
about:
he
worries
about
unflagging
in
12
before
removing
the
ESM
warning.
First
I
will
I
will
to
take
an
action
item
to
open
up
an
issue
and
document
some
of
these
thoughts
and
let's
kick
off
a
discussion
in
there
and
then
maybe
make
that,
like
the
first
agenda
item
that
we
dig
into
in
the
next
meeting,
people
cool
with
that.