►
From YouTube: Node.js Loaders team
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
Aha,
but
yeah
one
day
over
100
is
really
really
abnormal
for
a
full
year
in
texas
it
but
texas,
due
to
where
it
is
in
the
jet
stream.
It's
supposed
to
get
like
wetter
and
nicer,
but
yeah
one
day
over
100
is
really
really
abnormal.
For
okay
am.
A
What's
going
on,
I
apparently
when
you
start
streaming,
it
immediately
goes
in
to
the
view
thing.
Okay,
we
should
be
live.
Yes,
we
are
live.
Okay,
so
hey
everybody!
It's
what
august
20th-
and
this
is
the
loader's
working
group
meeting-
we're
have
a
very
light
agenda
this
time,
just
about
trying
to
merge
in
the
big
consolidation
pr,
so
yeah
we're
gonna
talk
about
that
cool
jeffrey,
isn't
here,
but
he
has
messaged
the
slack
channel
and
myself
and
he's
got
comments
on
the
pr
with
his
opinions
so
jacob.
A
I
think
both
jeff
and
my
opinion
is.
We
should
move
forward
with
it
just
do
one
last
round
after
we
get
those
nits
fixed
up
and
then
land
it.
I
know
that
we're
gonna
see
some
backlash
whenever
we
change
an
api.
We
already
have
like
a
lot
of
warnings
if
you
use
this
api,
but
we're
gonna
get
that
question,
but
it'll
be
good
to
see
what
backlash
we
get
in
case.
We
missed
anything
on
the
pr.
So
that's
expected
yeah.
What
are
your
thoughts.
B
I
would
hope
it
wouldn't
be
too
controversial,
but
in
terms
of
like
getting
emerged,
yes
is
there
anything
oh
yeah
we
need
to
do.
I
don't
think
so.
Well,
I've
got
the
the
knits
from
you
and
I
think
there
was
one
from
jeffrey
that
came
in
yesterday.
I
think
so.
Yeah
get
those
up.
It's
pretty
well
tested.
At
this
point,
I
think
we've
got
the
one
known
like
incompatibility
thing,
but
aside
from
that,
I
think
we
have
found
all
of
the
nooks
and
crannies.
A
That's
working
as
intended
as
as
much
as
we
all
hate
it.
It
is
well.
B
Yeah,
so
nothing
additional
is
like
broken
because
of
this
just
like
it
might
be
unexpected.
That
particular
aspect,
so
I
added
some
extra
notes
to
the
esm,
docs
to
say
like
if
you
try
to
do
this,
like
very
specific
thing,
know
that
that
does
that
never
worked.
A
I
think
let
me
double
check
in
the
consolidation
pr.
I
know
we
have
messages
if
you
have
the
deprecated
hooks,
but
those
don't
show
up.
If
you
have
the
modern
import
hook
right,
the
load
hook.
Sorry.
B
B
I
think
they
do
like
if
you
export
any
deprecated
hooks,
it
will
give
you
a
deprecation
warning
for
the
hook
that
the
deprecated
hook
that
you
have
exported,
but
it
still
continues
to
function
right.
Yes,
yeah
yeah,
so
like
it
figures
out
what
you're
what
you
were
trying
to
do
and
then
it
it
does
that
and
then
tells
you
like:
hey,
update
your
stuff
too
yeah.
This
will
work
for
now.
A
I
don't
want
to
back
port
this
pr.
I
think
it's
too
big,
I
don't.
B
I
don't
think
there
was
any
plan
in
place
for
how
long
the
deprecation
warning
should
be
there
and
how
long
we
should
support
the
old
hooks,
because
they
were
always
experimental
so
that
it
doesn't
fall
under
the
standard
policy,
and
I
think
there
was
no
original,
like
mandate
to
add
the
deprecation
warnings.
I
just
added
them
in,
as
I
was
going
and
was
like
this
would
probably
be
nice
to
let
people
know.
A
Yeah,
I
think
that's
fine.
We
already
have
warnings,
so
it's
not
like
we're
in
a
case
where
we're
adding
warnings
where
there
were
none
before,
because
that
that
is
actually
considered
a
problem
for
breaking
changes,
because
some
people
rely
on
there
not
being
any
warnings.
A
C
A
Hey,
I
can
do
this
now.
There
are
other
media.
C
A
A
A
C
Yeah,
that's
what
yeah!
That's
what
I
had.
I
think
I
said
earlier,
but
yeah
I
I
was
saying
that
I
was
going
to
do
that
yeah
jacob.
If
you
want
to
ping
me
as
soon
as
all
of
the
knits
are
resolved,
I'm
hoping
I
can
do
this
this
weekend,
but
I
feel
like
it's
famous
last
words.
C
I
promise
I
want
to
do
it
really
soon
is
as
soon
as
you
tell
me
that
the
branch
is
fixed,
I'll,
pull
it
down
on
my
local,
build
node
I'll
pull
down
the
latest
of
that
example
repo
and
then
just
make
sure
that
at
least
on
my
machine
just
kind
of
a
double
check,
I'm
sure
you've
done
it
on
your
machine.
Just
that.
C
You
know
the
examples
work
on
on
my
machine
as
well,
and
then,
assuming
that
that's
assuming
it
does,
then
I
should
be
done
and
I
can
I'll
approve
the
pr
and
then
I'll
go
through
all
the
I'll
look
up
the
steps
because
it's
been
a
while,
but
I'll
go
through
all
the
steps
to
actually
land
it
cool
and
oh
one
thing
I
was
gonna
ask
you
is
I
I
know
we
obviously
we're
going
back
and
forth
a
lot
about
the
coffeescripts
loader
and
the
example
repo.
C
Yeah,
that
was
something
I
mentioned
in
the
in
the
pr
discussion
when
he
was
fixing
it.
I
was
like,
oh
by
the
way,
I
should
have
put
a
big
comment
here,
that
that
returning
format,
common
jf's
has
just
like
never
worked,
and
I
just
I
asked
him
to
add
a
comment
about
that,
so
that.
B
A
C
Well,
I
think,
actually,
the
coffeescript
loader
and
probably
the
typescript
or
someone
writes
one
would
be
those
cases
where
it's
like
you
know.
In
a
in
a
project
that's
written
in
either
of
those
languages,
you
might
have
a
mix
of
files
with
import
statements
and
files
with
required
statements.
I'm.
A
C
A
C
It
doesn't
work
that
way
I
mean
I
I
feel
like
it's
to
your
point
yeah.
I
think
it's
probably
an
edge
case.
I
feel
like
it's
enough
of
an
edge
case
that
we
should
at
least
document
it,
because
it
is
part
of
the
api
that
you
can
return
for
my
common
js.
So
it's
like
it's
not
unrealistic
to
think
that
someone
might
might
write
a
loader.
You
know
doing
what
we
say
they
can
do
in
the
docs
right.
C
So
if
it's
not
gonna,
if
it
doesn't
work,
then
we
should
that
should
at
least
be
mentioned
in
the
docs,
and
maybe
we
never
fix
it,
but
you
know,
I
think
we
at
least
need
to
document
it.
B
A
C
Sure
I
mean
I
feel,
like
I
kind
of
feel
like
this
is
like
an
edge
case
that
we
can
like
almost
like
bump
to
the
end.
You
know
what
I
mean
like:
let's
implement
chaining
first
and,
like
you
know,
get
the
get
the
important
things
that
are
on
our
roadmap
done
and
at
least
make
a
mention
of
this
in
the
docs
like
you
know,
for
now,
and
then
we
can
loop
back
to
this
and
be
like
okay.
What
are
the
very
you
know,
aside
from
just
documenting
that
it's
broken.
C
What
are
the
various
options
that
we
have
like
yeah?
Adding
warnings?
Is
there
a
way
to
make
it
work?
You
know
et
cetera,
and
we
can
you
know
kind
of
tackle
that
as
its
own
thing,
like
the
thing,
I'm
thinking
is
like
the
way.
The
way
that
this
might
become
more
important
than
just
like
random
edge
case
is
like
say
the
the
instrumentation
use
case.
You
know
like
whatever
new
relic,
I
think
was
the
company
that
was
on
a
few
weeks
ago.
A
C
So
like
say,
you
have
an
esm
entry
point
and
it
has
obviously
lots
of
imports
and
some
of
those
imports
are
for
common
js
dependencies.
Like
that's,
certainly
going
to
be
the
case
for
every
app
for
the
near
future.
It's
going
to
be
a
while
before
everyone
has.
You
know
no
comma.js
dependencies
anywhere
in
their
application
tree,
so
the
lo,
the
the
presumably
the
instrumentation
library,
doesn't
want
to
just
implement
like
first
party
application
code.
C
I
assume
it
wants
to
implement
the
entire
app,
including
their
you
know,
third-party
dependencies,
and
so,
if
that's
the
case
well,
then
it's
gonna
need
to
support
like
sometimes
those
import
statements
are
going
to
be
importing
common.js
files.
So
then,
this
is
not
not
really
so
much
of
an
edge
case.
It's
kind
of
you
know
becomes
quite
prominent
all
of
a
sudden
because
you
can't
really
instrument
the
whole
app
until
we
solve
this.
Or
am
I
missing
something.
A
A
You're
you're
absolutely
correct,
and
I'm
just
trying
to
think
of
ways
you
can
take
action
on
the
problem
yeah,
because
there
isn't
much.
We
can
actually
do
there's
some.
We
can
do
if
we
move
loaders
off
thread,
there's
some.
We
could
do
if
we
expose
the
like
named
exports
detection
api,
but
all
of
these,
like
just
aren't,
really
things
that
people
want
to
do.
What
they
really
want
to
do
is
like
just
know
like.
A
If
I
do
this,
will
I
suddenly
and
magically
be
able
to
make
a
wrapper
module
around
a
common
js
module
like
the
format
common
js,
that
you
would
return
from
a
loader,
because
you
almost
never
want
to
return
format
comma.js,
you
almost
always
want
to
return
type,
module
or
format
module
and
just
show
them
what
that
wrapper
would
look
like.
A
We
have
a
really
old
example
for
that,
and
we
could
just
merge
it
into
the
docs,
update
it
and
merge
it
into
the
docs,
because,
basically,
what
you
have
to
do
is
return
a
format
module
that
does
interest.
A
Yeah
but
the
problem
there
is,
you,
don't
know
the
actual
export
names
of
the
common
js
thing
like
the
perpetual
problem
with
esm,
and
so
we
at
that
point
you
have
to
like,
expose
somehow
the
named
exports
of
a
module
to
loaders,
which
we
can
do.
C
Well,
I
think
the
thing
is
is
like,
if
the,
if
the
ultimate
use
case
is
instrumentation,
the
problem
there
is
that
it's
like,
like
kind
of
by
definition,
it
needs
to
support
anything.
You
know
like
they're,
not
going
to
know
anything
about
the
imp.
You
know
the
dependencies
of
the
app,
so
they
need
to
really
be
able
to
handle
like
a
hundred
percent
of
whatever's
out
there
in
terms
of
commodities
dependencies
that
could
potentially
be
unless
they,
unless
they
just
throw
like.
Maybe
that
could
be
the
first.
C
The
first
pass
of
this
is
like
you
know:
if
there's
a
common
js
dependency
anywhere
in
your
tree,
we
throw
in
her,
and
that
could
be
like
the
first
version
to
just
get
something
out
the
door
and
then
and
then
the
question
would
be
like:
how
do
we,
you
know,
go
to
the
air
so
that
it
actually
works,
or
something
like
that?
You
know.
C
C
A
Won't
get
100
esm
coverage,
there's
like
a
whole
twitter
flamewar
today
about
this,
but
no.
What
we
need
to
do
is
like
just
keep
moving
forward
with
spr
get
it
done,
and
then
we
have
to
reevaluate
some
stuff
for
them
in
particular.
How
you
can
intercept
commanders
there's
like
multiple
ways.
We
can
do
it
they're
all
gross.
A
C
C
A
C
C
That's
an
option,
but
anyway,
I'm
just
saying
like
node,
does
something
with
that
function
like
there's
some
chunk
of
code
somewhere.
I
know
that
runs
your
registered
function
at
some
point
and
whatever,
wherever
node
runs
that
callback
that
you've
registered
it
could
also
run.
You
know
the
resolve
hook
or
something
I
don't
know
like.
That's
I'm
just
thinking
like.
Maybe
we
could
kind
of
integrate.
A
B
Yeah
part
of
the
problem,
part
of
the
problem
was
that
in
the
coffeescript
loader
it
has
a
require
extensions
and
it
runs,
and
it
does
what
it's
supposed
to
do
and
then
after
it's
done
whatever
after
it's
finished,
whatever
it
has
done
just
like
disappears.
A
A
Okay
that
returns
the
module
exports,
so
it
yeah
that
is
the
current
api
design.
It's
pretty
wild,
there's
nothing
about
formats,
there's
nothing
about
source
text.
There's
there's
just
like
no
way
for
you
to
like
provide
a
way
to
instrument
it.
But
if
we
change
that
api
to
be
like
here's
a
file
path
and
if
you
return
a
function,
it
does
one
thing
it:
we
could
alter
it
to
either
have
more
parameters.
So
it's
file
path,
and
these
are
loader
hook
parameters.
We
could
change
the
return
value
to
be
polymorphic.
A
So
if
you
return
a
function
or
if
you
return
an
object,
do
two
different
things.
So
then
it
could
be
like.
Oh,
I
actually
do
have
you
know
a
way
to
get
the
source
text
of
things,
but
that's
that's.
Basically
what
jeffrey
is
talking
about?
We
have
to
like
figure
out
a
way
to
get
require
extensions
to
be
able
to
move
forward.
A
A
C
B
A
No
like,
like
literally
like
this,
is
a
really
bad
problem
that
was
discovered
as
people
start
using
worker
threads
with
typescript,
because
worker
threads
were
not
going
through
required,
dot,
extensions
on
their
entry
points
and
so
typescript
entry
points
to
worker
threads.
Using
the
standard
way
you
get
typescript
running
in
node
no
longer
work.
B
C
Going
to
be
a
while,
before
someone
reports,
a
bug
for
the
converse
script
version
of
the
same
thing,
but
yes
I
mean
so
I
mean
this
could
be
an
opportunity
that,
like
okay,
the
time
has
finally
come
get
rid
of
required
ad
extensions,
replace
it
with
the
new
new
api.
C
A
It
should,
but
we
have
to
provide
an
upgrade
path.
So,
like
a
good
example,
is
this
consolidation
pr?
You
can
write
a
loader
that
works
both
in
the
consolidated
form
and
the
legacy
form.
It
still
runs.
You
get
more
warnings
now,
but
they
both
well.
You
can
ship
one
file
that
runs
on
the
old
version
without
the
consolidated
form
and
one
that
runs
on
the
new
version,
with
the
consolidated
form.
C
A
And
then
we're
gonna
rip
it
out.
We
we've
done
this
before,
where
we've
ripped
out
a
few
return
types
on
these
loader
hooks
and
things
like
that.
But
if
there's
no
way
to
upgrade,
I
mean
a
wholesale
upgrade
is
unrealistic
unless
we
provide
some
way
for
them
to
dynamically
at
runtime,
select
which
way
they're,
gonna
patch
them
well,.
C
I
feel
like
it's
as
simple
as,
like
you
know,
which
version
of
node
the
newer
api
shipped
in,
and
you
could
just
like
branch
on
the
version
of
node
like
it's
it's
it's
not
like.
You
need
to
feature
detect
something
like
this.
This
is
like
literally
tied
to
the
version
of
node.
You
know
of
what
the
api.
B
A
This
is
true,
and
with
git
with
global
preload
code,
you
can
ship
require
extension
polyfills
inside
loaders.
So
I'm
fine
with
that
approach.
We
just
have
to
like
be
super
clear
on
like
if
you
are
using
require
extensions.
This
is
how
you
upgrade,
even
if
it's
just
about.
C
Let's
step
back
for
a
second
first,
we
need
to
solve
the
problem
between
ourselves
of
like
what
we
think
we're
replacing
required
extensions
with
or
how
we're
extending
required
extensions
or
whatever
it
is.
We
need
to
figure
out
what
we
want
to
propose
and
then
yeah.
We
can
figure
out
the
communication
strategy
and
upgrade
strategy,
but
stepping
back
for
a
second
can
we
implement
the
rest
of
the
loader's
to-do
list
first
and
solve
this
problem
at
the
end
like
can
we
implement
chaining
and
whatever.
A
C
A
C
C
A
A
Yeah,
so
moving
off
thread
will
be
a
large-ish
pr.
It
won't
be
tiny.
C
A
It
can
be
done
piecemeal.
Is
these
completely
discreet
steps
like
you
described,
moving
it
off
thread?
I
think
the
only
outstanding
thing
is
there's
another
pr.
That's
already
up
that
just
adds
a
synchronous
communications
channel
so
that
loaders
can
actually
communicate
without
using
globals
with
the
application
code.
A
So,
but
we
already
have
a
pr
for
up
for
that
and
then
yeah,
so
we're
pretty
prepped
to
go
out
changing
the
api
signatures
of
hooks
doesn't
matter
for
movies.
A
Adding
more
chaining
doesn't
matter
for
moving
stuff
off.
Well,
there's
a
slight
thing
about
chaining
moving
off
thread.
We
have
some
very
old
designs
about
off-thread
stuff
and
about
parallelism,
off-thread
stuff,
which
we
can
get
to
when
we
get
to.
C
Now,
when
you
can
you
just
so
I've
used,
I
don't.
I
haven't
used
worker
threads
that
much
I've
used
in
a
browser
a
few
times,
but
I've
never
used
a
worker
thread
in
node.
So
I'm
not
that
familiar
with
what
it
entails.
So
I
guess
question
one
is
when
you
say
move
it
off
thread.
You
mean
using
like
new
worker
as
the
api
or
is
it
a
different
api
and
then
question.
A
A
In
practice,
most
loaders
won't
change
how
they
look.
It
just
means
that,
instead
of
blocking
the
main
thread,
you
actually
run
in
the
background.
Essentially
the
big
things
that
will
change
are,
if
you
mutate
the
globals
in
your
loader,
it
won't
mutate
the
globals
for
your
application,
like
that's
it.
That's
the
big
thing.
C
Like
we
could
document
that
I
mean,
and
that
would
should
be
enough
because,
like
not
many
people
are
gonna,
be
writing
loaders.
You
know
like
the
people
who,
like
the
typescript
developers
and
I've
had
you
know
like.
I
can't
I
feel
like
there's
only
gonna
be
a
few
dozen
loaders
ever
written
that
are
going
to
be
popular.
A
A
So
none
of
the
existing
stuff,
I
believe,
should
be
affected
because
just
doesn't
use
loaders.
They
like
completely
recreated
esm
in
user
space.
B
A
A
A
A
Others
wanted
a
thread
per
loader,
but
there
was
general
consensus
that
if
we
move
loaders
off
thread
all
the
threads
for
node,
all
of
them
would
only
need
one
thread
per
loader.
A
C
C
B
C
Balance
when
the
loaders
are
chained,
it's
like
they
need
to
pass
objects
to
each
other,
because
that's
how
chaining
works,
so
it
feels
like
they
all.
I
mean
my
instinct.
I'm
happy
to
be
proven
wrong.
It's
not
like
I'm
saying
it
has
to
be
this
way
or
anything,
but
my
instinct
is
that
all
the
the
whole
loader
chain
should
be
together
in
one
thread.
Yeah
now.
C
A
We
started
this
journey
in
2014.,
so
loader
thread
investigation.
I.
B
A
So
this
is,
this
is
roughly
what
the
naive
thought
is.
If
you
move
workers
off
thread,
you
have
to
send
data
serialized
to
the
thread
whatever
that
data
is
here
at
this
time
it's
referred.
Specifier
data
there's
now
conditions
a
few
other
things.
So
what
happens?
If
you
have
multiple
loaders
one
of
the
idea
was
you
have
multiple
threads
one
for
each
loader,
so
this
means
that
multiple
loaders,
if
they
take
a
lot
of
cpu
time,
they
don't
cause
head
of
line
blocking.
A
So
if
you
have
two
big
ast
transforms,
you
can
actually
go
and
have
a
single
like
communication
that
doesn't
block
either.
So,
if
you
have
two
very
compute
heavy
loaders,
for
whatever
reason
multiple
code
transforms,
don't
know,
don't
really
care,
they
can
do
it
in
parallel.
B
A
So
it's
not
a
significant
difference
from
just
moving
them
off
thread.
Once
you
have
a
single
one
off
thread,
you
have
to
enable
serialization
between
loaders,
so
the
bigger
problem
is
going
to
be
things
like
this,
where
you
have
many
and
they
start
short
circuiting.
A
So
currently,
when
you
spin
up
a
worker
thread
in
node,
you
can
dynamically
specify
which
loaders
get
loaded,
so
you
can
actually
encounter
a
case
where
you're
always
short-circuited,
because
you
have
dropped
one
of
the
loaders
say
you
have
a
worker
thread
that
doesn't
want
to
do
some
kind
of
code
coverage
transformation.
A
This
means
that
if
all
the
worker
threads,
if
all
of
the
loaders
are
in
a
single
thread,
you
now
have
to
track
which
loaders
you
invoke
for
any
given
worker,
so
that
worker
that
is
missing
the
top
loader
here
when
it
serializes
to
the
first
loader.
It
could
be
all
the
loaders
in
that
thread
in
a
single
thread
when
it
serializes
data
there.
It
has
to
know
not
to
use
the
code
coverage
loader.
C
All
right
how
about
this,
it
sounds
to
me
like
we
can
implement
chaining
next
and
we
don't
have
to
tackle
any
of
the
thread
or
worker
thread
stuff
right.
Yes,
yes,
okay,.
A
A
A
Gosh
require.extensions
does
not
propagate
across
worker
threads,
which
is
problematic.
I
don't
want
to
open
that
other
window,
whereas.
A
Yes,
currently
loaders,
if
you
automatically
propagate,
unlike
require
extensions,
that's
partially,
because
the
api
design
of
required
extensions.
A
This,
so
this
is
basically
explaining
it.
A
Unfortunately,
when
you
get
require
extensions
or
just
the
common
to
ask
us
in
general,
by
default,
it
would
have
to
call
back
to
the
main
thread,
and
this
is
why
it
has
to
be
moved
off
thread,
because
you
can't
do
I
o
or
other
things,
a
variety
of
operations
on
the
main
thread.
Synchronously.
B
A
B
C
Let's
postpone
this,
I
mean
I
feel,
like
I'm
also
open
to
the
concept
of
finally
like
node,
17
or
node
18.
Whatever
literally
does
not
have
required
odd
extensions
anymore,
and
but
we
have
to,
I
think,
have
at
that
point
the
load,
the
new,
the
new
loaders
api
would
need
to
be
complete,
it
would
need
to
be
non-experimental
and
it
would
need
to
apply
to
commerce
yeah,
but
if
we
could
do
all
that,
then
sure
this
is
like
a
way
better
replacement
for
required
extensions,
and
it
obviously
then
would
apply
to
commodores
and
esm.
A
So
so
we
can
do
it,
but
like
no
matter
what
we
do.
The
point
is
like
having
loaders
on
a
single
thread
where
you
have
like
10
loaders
on
a
single
thread
versus
10
threads
with
10
different
loaders.
That's
not
the
complexity.
A
To
something
on
the
web,
so
if
you've
ever
used
shared
worker,
I
think
it's
shared
web
workers.
Yes,
these
aren't
just
enabled
everywhere,
but
essentially
for
a
given
url
across
your
entire
browser
or
in
our
case
a
node
process.
It
would
always
refer
to
the
same
instance,
and
this
is
where
having
all
the
loaders
in
a
single
thread
really
goes
bad,
where,
if
you
have
like
50
loaders,
let's
say
per
thread
like
things
would
be
bad,
so
you
want
to
instead
be
like
okay,
this
thread
our
application
thread.
A
Our
main
thread
has
these
three
urls
for
its
loaders,
and
so,
when
you
create
a
request,
you
look
up
your
shared
loader
like
cache,
and
it
sends
messages
out
to
those
three
loaders.
If
they're,
all
on
the
same
thread,
things
get
a
little
weird.
A
If
they're
all
on
different
threads,
I
mean
it's
just
calling
sending
the
messages
like
normal,
but
how?
How
do
they
enforce
sequence,
or
just
when
you
send
the
payload
to
the
threads
for
workers,
you
encode
the
total
list
of
the
loader
chain.
A
B
But
if
each
one,
if
each
loader
is
in
a
different
worker,
only
only
the
the
particular
loader,
that's
in
that
worker
needs
to
be
aware
of
itself
right.
So
then
it
just
needs
to
know
the
next
one
to
call
like
a
linked
list.
A
C
C
Okay,
good
because
I'm
just
imagining
like
say
you
have
a
npm
dependency
and
the
impact
dependency
calls
new
worker.
It's
not
going
to
know
whatever
what
the
workers
were,
that
the
consuming
application
might
have
registered
so
yeah.
You
know
okay,
but
yeah.
If
that's
the
default,
then
I
think
that's
fine.
A
A
We
could
try
to
mandate
that
there's
only
ever
a
single
one
for
the
node
process
and
remove
the
ability
of
worker
threads
to
dynamically
configure
their
loader
list.
I'm
okay
with
that.
C
Anyway,
all
right
so
yeah,
we'll
land
this
one
chaining
jacob,
are
you
up
for
taking
on
chaining
once
we
get
this
one
landed,
yeah,
okay,
all
right!
Is
there
anything
any
questions
you
have
about
that
one
or
do
you
feel
like
you
already
know?
Well,
I
guess
the
big
question
we
have
to
decide
is
the
the
two
proposed
designs.
B
Right,
we
need
to
resolve
that
and
actually
sorry
before
we
move
on
to
that,
I
was
just
looking
through
the
pull
request
and
what
I
said
earlier
is
not
entirely
true.
The
change
that
we've
made
to
the
loader's
api
is
not
fully
backwards,
compatible
some
loaders,
sorry,
some
hooks
whose
names
have
changed.
It
will
issue
a
warning
and
then
just
assign
the
hook
of
the
old
name
to
the
new
name,
but
if,
like
the
hook,
has
changed
so,
for
instance,.
B
Yeah
so
like
what
we
could
do
is
there's
get
source,
get
a
transform
or
something
and
like
we
could
create
a
wrapper
and
just
like.
If
you
supply
a
get
source
and
if
you
supply
a
transform
source
run,
get
source
first
feed
that
into
transform
source.
But
I
feel
like
no.
C
Let's
not
add
stuff
to
make
a
backward
compatibility
transition
path
easier,
like
we
need
to
be
able
to
quickly
iterate
on
this
thing
to
to
get
it
to
the
end
and
yeah,
I'm
not
that
concerned
about
people.
You
know
the
handful
of
people
that
have
written
experimental
loaders
based
on
this
can
just
update
them.
I
don't
you
know,
yeah
no
one's
using.
A
A
A
C
Okay,
all
right!
Well,
we're
we're
just
about
out
of
time,
so
we
shouldn't
dive
into
the
whole,
which
api
first
training
do
we
want,
but
do
we
want
to
at
least
have
a
plan
for
resolving
that
I
mean
we
could
just
wait
until
the
next
meeting
and
talk
about
it
then
devote
the
whole
meaning
to
it.
But
if
you.
A
C
All
right!
Well,
so
maybe
you
could
do
that
before
the
next
meeting
and
if
it
feels
like
you,
know,
you're
ready
to
go
and-
and
we
need
to
just
have
this
discussion-
maybe
we
can
have
like
an
impromptu
meeting
like
next
friday
or
something
to
to
try
to
settle
down.
What
do
we
want
this
design
to
look
like
and
then
you
can
get
going?
C
I
feel
like
jacob
you're
the
one
implementing
this,
so
it
should
really
like.
I
really
kind
of
feel
like
I
should
defer
to
you,
but
I
would
like
for
us
to
make
a
to
try
to
reach
a
consensus
decision.
If
we
can
okay.
B
Cool
just
the
implementation
of
the
return
one
seems
like
it
would
be
significantly
easier
for
the
other
one.
B
B
I
can't
remember
sorry.
C
Well,
all
right,
we
don't
have
to
dig
into
it
now
I
mean
maybe
let's
just
land,
the
first
pr
and
yeah.
We
can
start
thinking
about
it
and
you
know
figure
out
a
way
to
make
this
decision
and
and
hopefully,
let's
try
to
make
the
decision
no
later
next
next
meeting,
if
that
works
for
everybody
and
that
way,
and
if
we,
if
we
can
make
it
sooner
then
great
and
then
jacob
is
unblocked
and
we
can
and
he
can
get
going
cool
that
does
that
sound
good
bradley.
A
A
C
A
C
We
can,
we
can
have
that
debate
again.
Yeah,
I
mean.
C
Instrumentation
for
esm,
which
means
no
one
can
use
esm
for,
like
you
know,
most
like
any
big
company
production
website
like
I
can't
ship
a
website
in
production
that
doesn't
support
instrumentation
at
my
job,
so
that
just
means
I
can't
use
esm
at
work
and
that's
like
a
no-go
like
you
know,
we
have
to
be
able
to
support
it.
Even
if
there's
a
performance
hit.
You
know.
C
B
Okay,
cool-
I
shall
do
I'll
aim
to
get
it
done
tonight
because
I
think
they're
quite
simple.
It's
like
yes
prototypes.
B
Type
thing:
okay,
cool,
yeah
I'll,
try
to
get
that
done
tonight.
If
not,
then,
probably
sunday,
okay,
cool
sounds
good
thanks,
guys,
bye,
bye
thanks.