►
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
Andrew
bradley's
response
who's
concerned
about
this.
B
All
right,
we
are
live
on
youtube.
This
is
the
march
1st
2022
meeting
of
the
node.js
loaders
team.
The
agenda
today
is
the
ambient
loader
proposal
from
mayo.
Am
I
saying
that
right?
Yep,
okay
and
that's
all
that's
on
the
agenda
today,
so
yeah,
but
I
guess
before
we
get
into
the
meat
of
it.
I'd
love
to
merge
in
that
pr
like
just
simply
merging
it
in
doesn't
necessarily
mean
like
we've
agreed
to
do
it
or
anything
like
that.
But,
like
you
know,
we
should
at
least
have
a
proposal.
B
I
think
in
the
repo
and
then
that
that
implies
at
least
we're
considering
it,
and
then
we
could
like
add
it
to
the
github
project
and
so
on,
create
tickets
for
it,
but
before
we
merge
it
in,
I
feel
like
we
need
to
resolve
all
the
remaining
on
there
so
like
there
was
one
that
was
like.
Please
add
this
example.
Please
add
this
link
etc.
B
So
if
you
have
time
to
to
just
get
all
those
resolved
like
the
simple
things,
then
we
can
at
least
land
that
pr
and
then
we
can
continue
iterating
on
the
proposal
itself
by,
like
maybe
new
pr's
against
the
proposal
to,
like
you
know,
add
new
sections
or
change
text
or
whatever
else.
If
that
works
for
you,
yeah,
that
makes
sense
so
yeah.
B
I
think
I
feel
like
the
biggest
question
raised
on
that
was
like
hey,
but
what
about
reentrancy-
and
I
wish
bradley
were
here
because
I
feel
like
he's
the
only
one
who
can
explain
reentrancy,
or
at
least
the
only
one
I've
heard
explain
really
interesting-
can
either
of
you
explain
what
this
is
and
why
it's
a
concern.
A
I
think
yes,
or
do
you
want
to
handle
that
meow.
A
So,
at
least
for
me,
the
concern
is
that
if
you
have
a
series
of
things
that
are
basically
constantly
changing
the
status
of
the
world
in
in
series
and
then
they
would
need
to
basically
like
retroactively
change,
something
for
a
loader
that
came
before.
A
I
I
think
of
that,
as
what
reentrancy
like
the
way
that
you
would
facilitate,
that
is
reentrancy,
so,
like
you,
kind
of
like
you're
you're
going
along
and
then
like
the
world
changes.
So
you
have
to
stop
and
go
back
and
incorporate
the
change
of
that
world
into
into
this
process,
and
then
it
continues
on
and
then
at
some
point
the
world
needs
to
change
again
and
you
go
back
and
you.
C
A
And,
and
so
you
can
have
basically
like
this
multiverse
like
marvel
multiverse
thing
happening
and
it
becomes,
I
think,
basically,
what's
the
what's
the
term
non-deterministic
so
like
your
your
inputs,
don't
guarantee
your
outputs.
C
I
think
there
are
two
different
things
on
one
side
there
is.
The
family
reaction
is
mostly
just
calling
a
function
itself
with
whether
you're
running
a
process
and
then
you're
restarting
from
the
beginning,
but
that
doesn't
mean
that
you're
aborting.
That
just
means
that
you're
yielding
to
to
call
yourself
basically
a
sort
of
recursion.
A
I
think
you
do
well,
you
don't
necessarily
have
to
abort,
but
I
think
basically
you
putting,
I
don't
know
a
flag
in
the
ground
or
something
and
anything
that
would
happen
after
that
would
be
useless.
So
you
would,
you
would
stop
and
then
start
again
like
you
could
continue
on,
but
anything
that
happens
after
that
point
is
just
crap
like
garbage.
B
It's
like
like,
if
a
function
kept
running
after
the
return
statement,
or
something
like
that,
yeah.
C
To
to
keep
to
keep
going
after
that,
for
example,
I
let's
say
I
was
to
implement
json
as
or
let's
say
I
was
to
implement
a
loader
that
was
adding
support
for
both
json
and
the
dozen
five.
C
B
B
It
strikes
me
as
like
really
hard
to
implement
in
a
way
because
like
right
now
when
we
like,
we
sort
of
have
the
framework
built
already
for
chaining
we're
just
not
supporting
it
yet
like
in
that
we
have
the
node
default
hooks
and
then
the
custom
hooks
and
they're
already
like
an
array
of
now,
there's
like
an
array
of,
say,
two
resolve
hooks,
an
array
of
two
load,
hooks,
etc
and
so
expanding
that
array
to
multiple
is
fairly
trivial,
but
expanding
that
array
where
it's
almost
like.
B
B
A
Necessarily
what
would
happen,
I
think,
with
normal
loaders,
let's
call
them
light
loaders.
I
don't
know
they're
regular
loaders.
That
does
not
change,
I
think,
with
ambient
voters.
A
That's
the
only
bit
that
changes
and
the
change
that
happens
is
conditional
and
contextual
based
on
sort
of
what's
happening
in
this
upper
cloud
of
things,
and
I
think
part
of
the
problem
is
that
when
things
are
moved
off,
thread,
you'll
basically
have
a
cloud
of
your
ambient
motors
here
and
your
cloud
of
ambient
loaders
over
here
on
your
different
threads
and
the
cloud
of
immediate
loaners
over
here
in
the
club.
A
A
and
b
are
not
necessarily
the
same
so
when
and
which
thread
a
regular
loader
passes
through,
is
not
guaranteed
and
is
not
controlled.
So
if
your
loader,
if
your
thing
is
getting
loaded
by,
say
a
you
would
get
a
different
result
than
b
and
but
you
have
no
way
to
tell
or
or
force
which
one
it
goes
through,
and
that
is
the
danger.
A
Because
you
basically
have
different
instances
of
your
ambient
loaders
up
here
and
they
could
their
their
path
of
reentrancy
and
all
that
sort
of
stuff
does
not
necessarily
have
to
be
the
same.
Why
would
it
be
different
on
3
different
instances.
B
C
Would
each
loader
live
in
its
own
thread
or
would
all
loaders
live
in?
One
thread
like.
B
One
loader's
thread,
so
I
don't
know
I
you
know.
I
think.
A
You
have
to
figure
that
out
one
you
can
have
multiple
and
I
think
we
would
probably
in
future.
If
you
have
I
unknown
tons
of
things
happening.
Probably
we
would
want
to
spawn
multiple,
and
in
that
case
the
all
ambient
loaders
would
need
to
exist
on
all
threads
that
are
handling
this,
but
then
the
individual
loaders
don't
necessarily
need
to
go
to
all
of
those
threats.
So
it
could
be
like
something
happens
over
here
and
then
get
passed
over
here.
C
A
Well,
I
think
I
think
we
need
to
consider
it
because
on
our
roadmap,
the
threading
loaders
is
scheduled
before
ambient
voters,
so
that
would
need
to
be
incorporated
into
the
proposal
as
it
would
exist
by
the
time
this
happens.
B
C
That's
that's
different,
because
if
there
is
a
single
thread
for
all
loaders,
then
there
is
no
problem
at
all
because
all
live
in
the
same
instance.
So
what
you're
saying
is
that
this
potential
special
case
could
exist
only
if
there
are
one
loaders,
sorry,
one
thread
by
loader,
which
is
even
one
step
further
than
just
moving
the
loaders
in
the
thread.
A
You
know
thread
yeah,
but
if
we,
I
think
we
need
to
consider
it
now,
because
if
we
don't,
then
we
would
potentially
slash
very
likely
screw
ourselves
in
future
and
then
like
coat
ourselves
into
a
corner.
A
B
Okay,
let
me
ask
a
different
question:
sorry:
why
do
we
need
two
types
of
loaders
like?
B
Why
not
just
have
it
be
like
if
you
have
loaders
a
b
and
c
like
if,
if
all
three
are
ambient
like
dash
dash
ambient
loader
a
ambient
letter
b,
ambient
blur
c-
and
you
don't
need
the
other
type
of
like
theoretically,
any
loader
could
be
an
ambient
loader.
It
seems
like
so
why
not
just
make
regular
dash
dash
loader,
be
this
ambient
loader
behavior,
where
loader
a
affects
the
behavior
of
b
et
cetera,
and
we
only
have
we
still
just
have
one
type
of
loader.
C
From
my,
if
I
remember
right,
bradley
mentioned
that
it
was
because
he
wanted
to
be
able
to
have
efficient
loaders
and
if
there
is
something
about
having
multiple
thread
one
by
loader.
So
something
like
jacob
was
mentioning,
and
in
that
case
that
would
require
to.
C
C
The
reason
for
that
is
an
attempt
to
keep
loaders
as
isolated
as
possible
to
allow
follow-up
improvements
like
reusing
them
across
workers.
Oh,
that
was
workers
here
or
scaling
them
up.
If
all
loaders
were
influenced
by
prior
loaders,
they
would
effectively
coalesce
into
a
single
one
which
would
prevent
such
work.
A
Yeah
and
I
think
the
reason
that
we
and
also
one
of
the
reasons
we
wanted
to
separate
them
conceptually,
is
because
most
like
the
vast
majority
of
loaders,
don't
need
the
extra
complexity
that
this
ambient
motor
thing
could
provide
and
there's
way
more
opportunity
for
a
foot
gun
with
the
ambient
loader
stuff.
So
we're
trying
to
kind
of
like
save
people
from
stuff
that
they
almost
surely
don't
need.
But.
C
Those
that
don't
need
basketball,
this
complexity,
that
you
mentioned,
aren't
those
the
loaders
that
are
actually
only
loaders,
not
resolvers.
B
A
B
I
could
see
another
example
where,
like
you
want
an
ambient
say,
an
ambient
type
script
loader
so
that
the
like
say,
loader
a
is
this
type
script:
loader
loader
b
could
be
a
loader
written
in
typescript
or
you
know,
or
copy
script,
or
name
your
whatever
your
language,
and
that
way,
as
long
as
you
put
the
type
group
one
first,
all
of
the
following
letters
could
also
be
written
in
typescript,
etc.
A
B
A
I
I
think
potentially
another
case
would
be
when
you
need
multiple
things
like
you
have
multiple
dependency
in
a
chain.
You
can't
really
have
that.
So,
like
let's
say
I
don't
know
a
and
b
sorry
c
and
c
and
b
both
depend
on
a
and
so
like.
You
don't
have
like
a
funnel
shaped
dependency
type
thing.
Does
that
make
sense,
so
that
would
be
a
use
case
of
an
mba
loader.
Now,
let's
say
I
don't
know
your
your
loader.
A
Your
subsequent
letter
is
written
in
typescript
and
also
it's
loaded
over
https
and
also
it's
got
like
I
don't
know
some
zip
stuff
and
so
in
order
to,
and
it
itself
has
a
dependency
on
something
else
and
in
order
to
resolve
all
of
these
things,
they
all
have
to
be
able
to
access
and
interact
with
each
other
and
they
can't
merely
just
pass
along.
B
Is
that
just
yeah,
I
I
kind
of
feel
like
the
the
the
more
ideal
developer
experience
would
be
if
we
don't
have
two
different
types
of
loaders.
We
just
have
one.
So
maybe
we
just
have
the
regular
loader
behave
as
ambient
loaders
and
then
the
question
is:
is
it
possible
to
just
adopt
this
behavior
where
every
loader
affects
the
following
one
without
breaking
anything
like
like
it
sounds
like
bradley's
concern
with
it
was,
it
would
probably
be
a
performance
hit
which
is
fair,
but
I'm
also
kind
of
thinking
like.
C
B
But
so,
where
I
was
going
with
this,
was
that,
like,
I
would
think
it
seems
pretty
clear
that
we
could
have
one
thread
for
all
loaders,
like
you,
don't
have
to
put
each
loader
in
a
separate
thread.
B
I
would
think
because
we're
not
we
don't
have
that
yet,
like
they're
all
on
the
main
thread
right
now,
and
we
already
essentially
have
a
chain
of
two
loaders
on
the
main
thread,
so
even
moving
them
off
thread
doesn't
necessarily
mean
you
have
to
move
each
loader
to
an
independent
to
its
own
thread
like
you
could
just
have
a
loader's
thread
with
all
the
loaders.
On
that
one
thread,
I
would
hope,
and
then,
if
you
do
that,
then
they
could
behave.
B
However,
we
want,
I
think,
and
what
I'm
thinking
is
like
having
the
loaders
together
in
the
same
thread,
is
probably
a
more
desirable
developer
experience
than
having
developers
needing
to
worry
about
how
to
communicate
from
one
loader
to
the
next
across
threads
like
for
them.
It
just
feels
like
it
does
now,
where
they're
all
together
in
the
same
like
global
name
space
and
what,
but
what
we
lose
is
the
performance
that
all
the
loaders
would
be
running
on
the
same
threat.
B
B
C
B
Well,
what
I
was
going
to
say,
though,
is
like
the
other
thing
I
was
thinking
was
like
say:
you
wanted
to
have
two
monitoring
systems
in
place.
If
you
were
concerned
about
the
performance
hit
about
having
them,
you
know
on
the
same
thread
or
whatever.
Then
I
think
what
you
could
do
is
just
use
some
kind
of
build
tool
to
merge
them
together.
B
You
know
somehow
and
then,
and
even
maybe
within
this
loader,
it
itself
spawns
worker
threads
or
something
like
that
to
to
get
work
off
the
main
thread,
but
that's
at
least
like
node,
wouldn't
be
handling
it.
That
would
be
the
responsibility
of
this
build
output
loader
to
handle
its
own
performance
concerns.
You
know
what
I
mean.
A
If
yeah,
if
we
have,
if
we
had
those
monitor
type
things
as
ambient
loaders,
would
it
create
a
likely
scenario
of
these
monitors
monitoring
each
other
inadvertently
and
like.
B
B
You
know
you'd
probably
load
them
in
that
order,
so
that,
if
pmp's,
if
the
pmp
loader
throws
an
error,
the
datadog
loader
catches
it
and
reports
it
back
to
the
datadog
dashboard.
You
know
what
I
mean.
You
don't
want
the
datadog
loader
to
be
ignorant
of
all
the
all
the
other
loaders
that
follow
it.
You
know.
A
No
sorry
monitors,
let's
say
I've
got,
I
don't
know
a
new
ally.
I
don't
know
what
the
difference
between
these
things
are.
I
don't
know
what
they
do,
but
let's
say
you've
got
a
new
relic
one
that
does
something
specific
and
another
one
that
like
datadog.
That
does
some
other
kind
of
specific
monitoring.
A
A
A
A
B
That's
why
you
kind
of
have
to
choose,
like
I
mean
I
think
nowadays,
both
new
relic
and
datadog
do
lots
of
things,
but
I
think
like
when
they
first
started.
Datadog
was
focused
on
logs
and
due
relic
was
focused
on
like
errors
and
and
performance
like.
Oh,
you
have
high
cpu
and
things
like
that.
B
But
if
there
was
an
error
thrown
by
datadog
new
relic,
would
never
be
able
to
notice
it
or
if
datadog's
loader
itself
caused
a
cpu
spike,
then
they
then
knew
if
data
dogs
do
well
datadog's
loader
caused
a
memory
spike
new
alex
one
wouldn't
be
able
to
catch
it
because
due
alex
would
be
second,
you
know,
or
vice
versa,
depending
on
like
what
you
want
to
be
first
and
then
it's.
B
A
I
thought
that
part
of
what
ambient
loader
was
trying
to
solve,
because
you're
saying
mail
that
it-
and
I
agreed
with
this-
that
is
loaders-
should
not
be
aware
of
each
other
and
unless
we
have
like
an
army
that
is
like
creating
these
wrappers
for,
say,
datadog
and
new
relic.
A
That
and
that
rapper
has
knowledge
of
how
those
two
things
work.
But
that
would
be
terribly
impractical.
B
B
A
C
C
C
That's
for
a
different
use
case.
That's
not
related
to
the
ambient
loader,
but
that's
something
that
even
I
mean
loaders
will
need
to
do,
because
that's
a
regular
concern
to
give
you
some
id
in
yeon.
We
have
a
plug-in
system
and
we
have
two
ways
of
handling
that
either
you're
calling
the
next
loader
or
you're
calling
the
first
one.
You
don't
know
what
are
the
one
before
you,
but
you
know
that
you
can't
call
from
the
beginning
and
that's
very
important,
because
otherwise
it
means
that
you
you
are
skip.
C
And
let's
say
that
that
might
be
for,
for
example,
to
give
you
an
idea.
Let's
say
that
I'm
trying
to
make
a
resolution
of,
I
don't
know
a
json
file
or
also
anything
I
might
need
to
make
the
route
to
do
other
resolution
before
and
if
I'm
doing
all
the
resolution.
In
order
to
derive
the
resolution
that
I
need
to
make
for
the
primary
request,
then
I
need
to
do
it
from
the
beginning.
Otherwise
I
will
skip
all
those
that
were
before
me,
so
it
has
to
be
that's.
B
C
Totally,
and
and
also
another
thing,
I
think
this
reentrancy
thing
is
also
a
matter
of
how
the
loaders
are
written.
So
if
they
have
side
effects,
then
yes,
it
might
get
a
bit
dicey,
but
a
loader
is
not
supposed
a
resolver.
At
least
it's
not
supposed
to
have
a
side
effect
at
best,
it's
supposed
to
cache
things
so
that
they
are
not
recomputed,
but
that's
not
really
at
best,
but
they
are
not
supposed
to
affect
the
world.
C
No
object,
loader
or
separate
thing.
I
think
they
are
not
related
to
to
to
re-entrance
it's
just
something
that
is
needed.
It
just
says
something
that
in
general
in
the
loader
team.
I
don't
think
that
we
should
prevent
free
entrances,
because
it
will
be
important
when
writing
loads,
because
I
I
feel
like
reentrancy
is
always
a
subject
in
in
all
the
topic.
I
open.
B
Well,
I
mean
you
should
maybe
make
a
separate
issue
just
for
it
that
not
only
explains
what
it
is,
because
I
feel
like
there's
a
lack
of
full
understanding
of
it,
but
also
of
the
use
case
like
you're
saying,
and
especially
if
you
can
have
a
example
from
somewhere
else
of
where
it's
implemented
successfully
and
doesn't
cause
like
the
world
to
catch
on
fire.
That
would
be.
That
would
be
good,
like.
C
B
Thinking
sure
one
thing
I
was
thinking
of
too
is
that
the
esm
package,
written
by
john
david
dalton,
I
remember
like
looking
at
source
code
years
ago,
to
try
to
see
how
is
it
doing
what
it's
doing
and
it's
essentially
a
common
js
loader
and
it.
B
It
has
it,
it
has
a
dependency,
I
want
to
say
it
was
called
like
pirates
or
something
or
pirate,
that
essentially,
because,
like
common
jf's,
loaders
are
very
much
like
affects
the
world
type
of
thing.
Like
you,
you
know,
you
add
something
to
require
dot
extensions.
It
affects
every
comma.js
resolution
like
in
your
app,
including
all
dependencies,
so
there
was
some
dependency
called
pirate
or
something
like
that
where
it
would
make
sure
that
the
esm
package
only
affected.
B
So
that's
something
you
might
want
to
look
at
because
it's
like
we
all,
should
probably
look
at
or
understand
because,
like
what
are
the
use.
Cases
like
there's
probably
a
good
use
case,
say
for
having
a
loader
that
only
affects
first
party
code
that
never
like
once
that
package
boundary
is
crossed
into
like
the
node
modules
folder
and
then
farther
down
that
we
don't.
We
never
want
our
loader
to
affect
any
of
that
stuff.
For
example,
you
know.
C
I
would
love
to
to
bounce
soon,
so
what
would
be
the
next
action
item
for
the
rfc.
B
So,
let's
at
least
get
that
proposal,
cleaned
up
and
merged
just
to
the
resolve,
all
the
things,
and
then
we
can
merge
that
in.
If
you
have
time
to
write
a
separate
thing
about
like
resolve
from
start
or
reentrancy,
I
would.
I
would
really
appreciate
it
like,
even
that,
whatever
that
form
may
take
like
just
an
issue
on
the
repo
or
another
document
to
into
the
design,
docs
or
something
or
a
proposal.
B
I
don't
I
don't
know
if
it
needs
to
necessarily
be
done
as
part
of
merging
the
proposal
in,
but
just
like
a
discussion
somewhere,
maybe
a
separate
issue,
or
something
like
that
where
we
talk
about
like
why
shouldn't
all
loaders
just
be
ambient
loaders
like
what
would
be
the
pluses
and
minuses
of
taking
that
approach,
I
think
that's
am
I
missing.
A
I
something
think
so
I
just
did
a
quick
scan
through
and
the
open
threads
in
the
proposal
don't
seem
to
be
related
to
like
the
proposal
itself,
like.
B
Well,
it's
just
like
so
good
they're,
just
like
ways
to
improve
the
proposal
itself
to
be
a
better
proposal.
Like
oh
add
this
other
example,
which
I
feel
like
should
be
trivial
to
to
do,
but
like
actually
debating
the
proposal
itself
and
how
the
proposal
should
be,
we
could
do
as
follow-ups
I
feel
like
yeah
yeah.
Does
that
sound
good
to
you?
Male?
Am
I
missing
anything
yeah
sure.
C
I
will
I
will
make
a
commit
with
the
fixes
in
the
proposal.
Then
we
can
merge
it
regarding
the
reentrancy
thing.
So
again,
I'm
not
myself
seeing
the
problem,
so
I
can
explain
how
I
could
see
it
being
used,
but
I
will
not
be
able
to
explain
why
it
will
be
a
problem.
That's
something
that.
B
B
Whatever
it
is,
you
know,
or
maybe
it's
maybe
the
use
case
is
more
important
like
maybe
this
use
case
is
like
something
we
really
want
to
support,
and
so
therefore
we
never
move
loaders
off
thread
or
we
move
them
off
thread
that
always
just
one
thread.
You
know
I
think
that's
worth
discussing
and
debating.
B
Cool,
thank
you
all
right.
I'm
going
to
add
these
to
the
document
before
I
forget
and
feel
free
to
add
anything
else.
I
forgot
into
the
to
the
google
doc.
Let
me
share
the
link
to
it.
B
Yeah
any
notes
you
can
remember,
please
feel
free
and
yeah
I'd
love
to
get
that
merged
in
as
soon
as
it's
ready
and
then
we
can
go
from
there
like
it's.
I
feel
like
we
have
to
implement
chaining
and
maybe
even
threads
before
that.
So
it's
like
a
ways
off,
but
we
can
at
least
get
the
proposal
and
design
as
nailed
down
as
possible
and
if
you
can
help
with
any.
C
B
B
I
mean,
maybe
we
don't
need
to
do
the
thread
work
you
know,
but
I
think
we
at
least
need
to
get
chaining.
If
you
can
help
on
that,
I
would
just
coordinate
with
jacob,
because
I
think
he
was.
I
don't
know
if
he
already
started
on
it
or
was
going
to
start
on
it.
So
you
know
just
make
sure
we're
not
duplicating
effort
but
by
all
means
you'd
love
for
help.
So
we've
been
talking
about
chaining
for
months
and
not
writing
any
code
for
it,
so
nothing
against
jacob
there.