►
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
All
right,
we
are
live
on
youtube.
This
is
the
june
21st
2022
meeting
of
the
node.js
loaders
team.
A
The
only
item
on
the
agenda
is
the
pre-import
proposal
from
guy
bedford
and
we
have
guy
here
and
yeah.
We
were
just
going
through.
We
just
got
to
look
at.
There
were
some
comments
that
just
happened
like
a
few
minutes
ago.
So
we
just
about
to
look
at
those
so.
B
Okay,
I
simply
start
by
introducing
the
proposal,
so
I
guess
the
overarching
theme
is
trying
to
align
with
browsers
where
we
have
a
synchronous
resolver,
where
the
input
map
is
sort
of
semi-static
I
mean.
Hopefully
it
will
be
dynamic
in
future
and
it'll
be
extensible,
but
it's
this
kind
of
static
thing
that
can
be
synchronously
resolved
against.
B
So
your
resolution,
source
of
truth,
is
pre-populated
in
the
browser
and
therefore
all
your
resolution
operations
are
asynchronous,
and
so
there
was
this
kind
of
performance
argument
that
the
resolver
is
a
fast
path
when
you
have
a
lot
of
module,
specifiers
and
a
lot
of
resolutions,
and
if
you
have
ticks
on
every
single
and
promise
objects
on
every
single
sub-resolution,
and
so
the
argument
was
made
quite
strongly
for
browsers
that
we
should
have
the
synchronous,
import,
meta,
resolve
for
performance
and
simplicity
and
that's
what
we
look
like
we're
heading
towards
today
in
browsers
and
so
node.js.
B
Right
if
it's
async
there's
a
whole
bunch
of
you
have
to
have
a
tracking
object
for
each
one,
and
then
those
objects
will
have
to
be
hand,
managed
and
garbage
collected,
and
things
like
that.
So
there's
a
whole.
C
A
B
Does
I'm
trying
to
make
sure
that
arguments
are
perspective
and
yeah
I
mean
it's,
it
is
minor,
but
it
was
deemed
a
strong
enough
argument
that
it
would
be
introducing
too
much
overhead
to
have
an
asynchronous
result
because
you're
creating
all
of
the,
and
so
it's
it's
not
just
you
know
for
import
meta
resolve
it's
also
internally
in
the
resolver
that
they
don't
want
to
have.
All
of
this.
B
You
know
promise
based
stuff
happening
for
every
single
specifier,
because
each
module
is
going
to
import
from
multiple
other
modules,
and
so
you
you're
not
just
getting
off
the
order
of
the
number
of
modules
you're
getting
you
know,
n
times
the
number
of
modules
of
these
resolution
operations.
You've
got
a
thousand
modules.
You've
got
like
10
000
resolutions
and,
if
they're
all
synchronous,
they're
highly
optimized
single
function
calls.
B
C
So
that
is
their
argument.
There
are
other
counter
arguments.
I
don't
think
they
matter
to
the
web
browsers.
They
don't
care
in
my
discussions
with
them,
but
these
do
take
note
that
their
argument
is
for
performance
they're,
not
willing
really
to
compromise
on
that
they're
also
not
willing
when
I've
discussed
at
least
with
some
of
the
what
wg
people
to
have
a
more
performant
api
than
import
meta
resolve.
C
C
A
B
A
I
mean,
let
me
just
ask
a
simple
question,
though,
is
like
the
10
000
resolutions,
or
whatever,
like
that
happens
for
regular
import
statements
which,
like
couldn't
the
like
internal
machinery,
for
resolving
imports,
be
sync
and
optimize
the
way
they
want
it,
but
then,
like
specifically
import
that
meta
resolve
would
just
be
like
in
there.
You
know
if
we
wanted
that
to
be
async,
specifically
import,
that
metadata
resolve
would
be
some
function.
That's
a
that
just
calls
this
internal
resolve
wraps
the
promise
around
it
and
returns
that,
and
that
way
it
can
be
yeah.
E
A
C
C
True,
so
there
there's
a
bunch
of
stuff
going
on
here,
but
one
of
the
key
differences
is
node.
Does
io
in
a
lot
of
its
load
hooks,
not
just
the
core
runtime,
but
userland.
Hooks
too
browsers
explicitly
do
not
want
to
support
that
workflow.
C
B
Was
one
of
the
big
things
that
was
a
lesson
with
early
work
on
system.js
was
that
the
resolver
is
important
that
like,
even
though
you
think,
I'm
just
doing
this
trivial
amount
of
work,
because
it's
such
a
hard
time.
E
B
Function,
resolver
performance
is
actually
really
important,
and
so
I
I
I
can
agree
with
those
findings,
and
that
was
my
experience
as
well
and
I
then
didn't
stopped
even
using
the
url
constructor,
because
it
was
too
slow
and
actually
wrote
an
optimized
version
of
a
subset
of
the
url
resolution
that
could
run
much
faster
as
a
string,
manipulation
system,
because
it
was
worth
the
perf
savings
to
do
that
because
you
know
the
the
the
costs
really
do
add
up
when
you're
doing
this
amount
of
work
in
the
resolver.
B
C
C
The
point-
the
point
is
exactly
that:
you're
making
a
performance,
optimization
argument
that
this
ux
is
important
enough,
that
we
want
to
not
encourage
essentially
a
nice
city
for
ux.
Instead,
we
want
you
to
attempt
to
write
code
that
approaches
a
performance
metric
and
the
performance
metric
will
always
be
inferior
to
like
a
common
workflow
that
exists
today.
B
B
C
B
I
don't
know
so
I
mean
if
we're
looking
at
the
browser
case.
You
know
yeah,
you
probably
only
want
to
have
about
less
than
100
modules
in
your
import
map
that
are
kind
of
these,
these
third-party
libraries
that
you're
managing,
but
that
doesn't
preclude
like
like
performance
growth.
I
mean
put
this
way.
I
just
think,
like
you
know
it's
like
something's
possible
and
then
it
gets
used
and
then
it
gets
scaled
and
then
it
gets
used.
And
it's
like
you,
never
know
what
the
future
holds
and
like.
B
Okay,
so
in
the
browser
specifically,
I
mean
like
yeah.
If
we
want
to
discuss
the
like
general
loading
concerns
and
stuff,
I
think
that's
like
a
general
discussion.
B
No,
I'm
certainly
not
disagreeing
with
that.
I,
this
is
not
my
preferred
outcome
either.
I
would
much
prefer
that
we
had
an
asynchronous
resolver.
In
fact,
when
the
module
spec
was
first
proposed,
it
had
a
synchronous
resolver,
and
it
was
like
the
first
thing
that
I
engaged
on
in
module
stuff
was
tweeting
to
david
herman
that
we
should
have
these
signatures
over
and
it
shouldn't
be
forced
to
be
sick
again
later,
and
then
it
was
changed
in
what
workload
from
that
discussion.
B
So
it's
it's
always
been
something
that
I
would
have
preferred,
I'm
just
making
the
browser
argument
to
justify
where
we
are
today
to
justify
what
node's
gone
sync
and
then
to
justify
why
the
pre-import
proposal
aims.
I
don't
think
we
need
to
justify.
C
A
B
So
when
you
hit
a
top
level
import
and
one
way
of
thinking
of
pre-embody
is
a
little
bit
like
it's
like
a
you're,
generating
your
input
map
right
and
that's
why
I
use
like
jsp
generator
in
the
examples,
because
it's
an
input
map
generator,
and
so
it
will.
Yes,
you
use
you
before
the
import
even
gets
processed
by
node.
You
now
have
an
initial
phase,
that's
doing
a
pre-passing
of
the
whole
module
graph.
It's
resolving
everything,
maternity
and
pre-populating,
the
cached
import
map.
B
That's
then
used
in
the
resolve
book,
so
it's
effectively
splitting
the
module
pipeline
into
two
phases.
Where
you
have
an
initial
phase.
That's
that's
able
to
go
through
and
work
out
all
the
resolutions
in
the
case
where
any
of
those
sub-resolutions
required
asynchronous
work
that
that
asynchronous
work
could
have
been
done
ahead
of
time
and
another
way
to
think
about.
B
It
is
imagine
if
you
were
running
node.js
on
an
import
map,
but
you
were
using
a
just-in-time,
install
tool
to
install
your
packages
and
mode
modules
and
generate
an
information
all
that
was
kind
of
running
so
yeah.
It's
opening
up
that
phase
of
a
pipeline,
so
it's
sort
of
like
a
generation
or
an
install.
C
So
I
had
a
question
regarding
that,
so
for
a
variety
of
things,
you
actually
have
to
parse
the
module
source
code
to
tell
what
is
trying
to
resolve
against.
B
B
B
Yeah,
if
you
had
a
search,
if
you
wanted
to
make
sure
that
you
were
getting
the
right
source,
the
load
hook
would
have
got
when
you're
doing
this
analysis,
you
could
expose
some
kind
of
function,
which
represents
the
final
change
log,
look
to
the
loader
itself
that
it
could
then
call
from
the
pre-input
when
it's
doing
its
subpipeline
and
then
yeah
the
es
module,
except
for
the
specifiers
and
then
the
resolver,
and
then
that's
it
you've.
Mostly.
There.
B
Yeah,
I
mean
that's
a
question
for
the
chaining
model,
but
I
think
regardless
of
the
chaining
model,
you
still
want
the
ability
to
get
the
final
hook,
and
so
that's
the
sort
of
api
question.
C
A
Well,
that's
that's.
That
was
that
so
there's
that's
the
other
like
item
on
the
roadmap
that
I
was
hoping
to
do,
which
would
be
like
expose
a
whole
bunch
of
helper
functions.
So
that
say
you
could.
You
know,
instead
of
copy
pasting,
a
thousand
lines
of
internal
node
code
to
re-implement
the
esm
resolution
algorithm.
You
could
just
call
you
know
five
functions
or
ten
functions
or
whatever
that
are
the
core
pieces
of
it,
and
you
know
that
way.
It's
like
you
can
you
know.
Yes,
you
could
re-implement
it.
Yes,
yeah
build.
A
You
know,
piece
piece
it
together
and
then
insert
whatever
custom
logic
you
need
in
between.
But
it's
you
know,
five
to
ten
lines
of
of
code,
calling
defined
functions
that
are
isolating
and
abstracting
like
the
node
logic,
rather
than
you
copying
and
pasting
all
the
node
logic.
C
C
A
The
idea
or
my
idea
for
helper
functions
is
to
have
them
all
be
like
pure,
where
yeah
they
don't,
they
don't
get
a
reference
to
the
loader
or
something
like
that
or
a
reference
to
the
module.
A
These
are
both.
These
are
both
pre-import
hooks
like
two
separate
loaders,
each
defining
a
pre-import
hook
correct.
Well,
this
is
for
the
current
proposal
for
pre-import.
It's
not
changed.
It's
just
like
separately
run
for
each
loader
and
each
loader
can't
talk
to
the
other
one
yeah.
So
that's
similar.
A
A
E
A
C
I've
told
jeffrey
and
jacob
this
I'm
out.
I've
been
recommended
by
mental
health
professionals
to
take
a
year
off
from
open
source
software.
So
I'm
out
it
doesn't
really
matter.
B
Okay,
sure
well
yeah,
sorry
to
hear
that,
and
thank
you
for
your
all
of
your
work
for
such
a
long
time.
It's
it's
been
really
enjoyable
to
work
with
you
from
my
own
perspective,
yeah.
A
A
C
B
A
Looking
at
the
comment
that
c-spot
code
posted
half
an
hour
ago,
it
was
also
kind
of
like
that
raised
a
similar
question
of
like
how
do
we
get
the
results
of
whatever
we
do
in
pre-import
available
wherever
we
need
them
later
so,
like
you
know,
he
was
suggesting
it's
like
be
on
some
kind
of
object
that
gets
passed
in
as
the
into
the
input
of
resolve,
not
really
any
different
than
attaching
it
to
some
object
in,
like
the
scope
of
the
loader
that
both
hooks
can
access
doesn't
make
much
difference,
I
mean
maybe
whatever
gets
returned,
might
be.
A
Re-Import
gets
passed
in
to
resolve
like
on
context
like
context,
dot,
pre-import
data,
or
who
knows
what
I
mean
we
can
fiddle
with
whatever
api
structure
makes
the
most
sense
to
us,
but
I
think
there
is
that
that
concern.
If
it
is
something
that's
returned,
then
that
opens
up
the
possibility
of
chaining
it
where
like
yeah,
where
like,
if,
if
there
are
multiple
pre-import
hooks
whatever
you
know,
whatever
results
get
generated
by
one
if
they're
returned,
then
that
could
become.
A
You
know
on
the
context
for
the
next
free
and
poor
hook
or
something
like
that,
and
then
you
get
the
opportunity
to
do.
Some
of
the
stuff
like
like
bradley
was
saying,
like
maybe
the
first
pre-import,
maybe
the
first
loader
generate
theme
park
map.
The
second
loader
looks
at
the
import
map
to
know
what
things
to
auto,
install
or
who
knows
what
you
know,
and
then
you
can
kind
of
take
advantage
of
you
know.
B
The
other
we
used
to
have
like
a
this
context
like
a
this
dot
api
method
in
the
logo,
because
I
know
we've
nodded
this,
but
we
could
always
you
know
reconfigure
it
to
an
api,
this
api
or
yeah,
some
kind
of
handle
to
the.
I
think
we.
A
Already
have
that
context
parameter
that
feels
a
lot
like
this
yeah,
that's
true
anyway.
These
are
just
like
things
to
think
about.
I'm
not
saying
I
have
an
answer
right
now,
but
it's
maybe
something
to
consider
that,
like
you
know,
one
of
the
games
like
these
being
like
running
in
parallel
without
being
able
to
talk
to
each
other
versus
the
like
chain,
like
the
middleware
chaining
model,.
B
Yeah
I
mean
one
thing
I
would
be
weary
of
is
trying
to
over
engineer
some
of
the
training
stuff
like
when
bradley
says,
like
order.
Install
goes
to
you
know
like
an
older
installer,
isn't
gonna
work
unless
it
has
a
resolver
right.
So
it's
like,
I
think,
focusing
too
much
on
the
kind
of
advanced
chaining
stuff
can
distract
from
just
creating
the
right
primitives
that
enable
the
use
cases,
and
then
you
know,
chaining
conveniences
can
always
be
added
over
time.
As
as
cross-cutting
concerns,
I
mean.
B
A
We
also
need
to
get
a
bigger
list
of
use
cases
because
it's
sort
of
like
auto
install.
Why
can't
that
just
happen
in
a
load
hook?
For
example,
you
know
what
I
mean,
I
mean
else.
It
has
to
influence
resolution,
but
I
don't
know
so.
A
The
kind
of
thing
that
I
had
commented
about
on
the
on
this
was
like
the
idea
of
when
it
runs
or
how
often
it
runs
because
like
if
this
runs,
essentially
after
after
whatever
v8,
I
guess
or
node,
has
parsed
the
whole
module
graph
or
this
chunk
of
the
module
graph
from
the
entry
through
the
end
of
all
the
static
imports
and
then
and
then
each
dynamic
import
would
kind
of
start
a
new
module
graph.
B
Let's
just
run
right,
that's
getting
that
information
requires
running
the
resolver
and
if
the
resolver
is
sync
and
is
waiting
for
information
from
the
pre-importer,
then
you've
got
a
circular
dependency.
So
you're
saying
you
want
the
inputs.
Well,
doesn't
the
current
version
of
this
run
many
times,
so
it
runs
before
any
resolution
or
anything.
So
this
is
a
whole
phase
before
module
resolution,
and
it's
just
saying
someone
is
wanting
to
import
this
module.
Okay,.
B
B
But
we're
going
to
load
this,
and
just
now
in
the
load
of
pipeline,
we're
going
to
run
a
synchronous
resolve
pipeline
that
might
need
to
know
async
work
that
we
already
need
to
do
now
to
work
out
how
we're
gonna
resolve
everything
we
need
craigs.
B
B
So
if
there's
multiple
of
them
in
different
loaders,
they
don't
have
to
block
each
other,
because
there's
no
reason
that
they
should
have
to
wait
on
each
other,
because,
unlike
a
book
which
has
a
return
value,
these
are
the
these
are
independent
pieces
of
work,
and
so
the
important
thing
is
just
that
you're
waiting
for
them
to
for
the
promised
result
for
it
to
be
finished
during
that
setup.
So,
as
I
say,
you
end
up
being
building
this
subpipeline
and
yeah
having
a
context
dot.
B
The
context.load
and
a
context
context.resolve
could
well
be
used
for
api
functions
to
help
build
this
because
then
you
could
call
context.
get
the
source
for
a
module
pass.
The
dependencies
called
context
start
resolve,
but
yeah
yeah,
it's
complex,
but
at
the
end
of
the
day
it's
it's
more
of
a
primitive
than
a
nice
to
use.
But
you
know
a
lot
of
aren't
expected
to
be.
B
It
doesn't
have
to
be
easy,
but
the
point
is
that
it's
possible
and
yeah
it's
not
ideal,
but
we're
working
with
with
what
we've
done.
E
It
sounds
like
a
a
very
specific
thing
to
address,
with
a
whole
lot
of
stuff
needing
needed
to
make
it
happen,
which
sounds
like
it's.
It
smells
like.
I
feel
like
we're,
we're
missing
something
that
there
there
should
be
some
other
way
to
get
this
done
without
basically
reinventing
the
wheel
just
to
get
some
like
.001
of
something
am
I
oversimplifying
it.
B
B
Like
when,
when
the
sync
resolve
goes
out,
it's
gonna
break
a
lot
of
things
and
it's
gonna
make
a
lot
of
people
happy
and
they're
going
to
be
innovative
and
they're
not
going
to
know
how
to
do
things
and
then
they're
going
to
come
up
with
a
bunch
of
use
cases
and
say
like
well.
How
do
I
do
this.
B
B
And-
and
I
mean
it's,
the
simplest
answer,
but
it's
it's
the
fundamental
design
constraint.
Any
other
answer
is
going
to
be
more
complicated.
This
is
the
simplest
way
to
solve
that
problem.
Given
the
design
constraints
we
have,
and
it's
that's
just
the
fundamental
situation
of
things.
E
E
What
if
we
give
them
like?
I
don't
know
two
different
options,
or
we
say:
if
you
make
your
resolve
hook
asynchronous,
then
it's
not
included
it's
ignored
before
the
resolve.
E
B
So
so
you're
saying
if
employment
resolved
probably
came
back
so
you're
saying,
if
you
have
a
did,
you
say
bradley's
back.
A
B
Okay,
so
bradley
just
to
summarize
jake
was
just
suggesting
that
if
you
had
a
if
we
allowed
both
asynchronous
and
synchronous,
resolvers
and
only
called
synchronous
resolution,
sorry-
and
let
me
know
if
my
summary
is-
I'm
reframing
it
a
bit
yeah
but
you're
only
called
the
synchronous
resolvers
when
you
call
input,
don't
matter
dot
resolve,
whereas
when
you
run
the
normal
module
resolution,
we
call
them
all.
So
something
like
that
yeah
exactly.
E
Maybe
we're
creating
an
enormous
problem
that
is
too
confusing
for
people,
but
it
seems
like
the
crux
of
this
is
import
meta
result
needs
to
be
synchronous,
and
that
is
preventing
all
resolve
hooks
from
being
synchronous.
I'm
wondering
if
that
is
maybe
an
artificial
limitation.
C
C
E
C
C
C
B
We
could
cash
flow
resolutions
and
then
import
metadata
results
can
be
synchronous
and
use
the
cash
version,
because
it's
you
you're
supposed
to
always
return
the
same
resolution
for
you
know
espresso.
I.
E
C
B
B
Right
so
then
that
means
it's.
B
B
And
and
so
maybe
could
we
forgo,
could
we
just
kind
of
yeah,
it's
a.
C
No,
this
is
old,
seems
like
a
year
old
or
something,
but
basically
they
made
a
vote
on
primordials
and
they
basically
said
only
module.
Loading
should
need
to
adhere
to
primordials.
They
also
made
a
vote
on
what
to
consider
when
having
like
these
protected
stuff
and
the
general
consensus
by
the
tse
was
moving
stuff
off.
The
main
thread
is
the
solution.
E
B
A
A
A
C
E
We
are
we're
marching
ahead
with
the
off
thread
thing
anyway,
so
well.
A
A
Right,
I
miss
yon.
You
should
come
back
to
these,
but
before
we
get
to
before
we
get
to
scheduling
stuff
for
a
second,
do
you
do?
All
of
you
then
think
that
maybe
what
we
should
do
is
just
revert
the
pr
that
made
resolve
sync
and
yeah.
We
could
always
unrevert
it.
D
D
B
B
B
E
A
C
B
Well,
we
should
try
and
move
towards
stabilizing
some
of
that
process
and
start
thinking.
Maybe
in
terms
of
you
know,
major
minor
changes
and
things
like
that
over
time,
but
that
yeah
that
does
sound
like
an
approach.
I
think,
if
yeah
this
is
the
simplest
way
to
mitigate
the
fallout
and
the
pre-import
proposal,
and
if
there
are
other
ways,
then
let's
let's
tackle
that
and
pull
out
the
the
synchronous
resolver
for
now.
A
All
right,
so
I'm
going
to
write
this
down
and
then
okay
plan.
For
today
we
will
revert
the
sync
resolve.
A
Change,
import,
meta,
resolve,
sync
change
with
a
note
that
it
will
go
back
in
in
long
few
weeks
months
if
we
can't
keep
our
async
resolve
hook
with
sync
looking
import.metadissolve
via
moving
loaders
off.
C
Yeah,
so
we
have
a
couple
discussions
minor
points
about
moving
off
thread
that
we
just
need
to
agree
upon,
since
I
don't
know
who
all
or
has
even
seen,
jan's
old
stuff
so
for
chaining,
there's
some
stuff
where
and
loaders
will
intentionally
only
be
talking
directly
to
each
other
until
it
gets
to
the
end
of
the
chain
at
the
end
of
the
chain,
it
will
invoke
the
default
loader
within
the
same
thread.
It's
not
going
to
spin
up,
but
another
thread
to
do
that
in
yawn's
design.
C
C
C
If
it's
not
deterministic,
if
it
like,
does
weird
calculations
and
stuff
like
bad
things
can
happen
for
mocking
loaders,
and
so
you
gotta
write
up
proper
way
to
use
pre-import
or
preload,
not
pre-import,
to
save
the
cache.
That's
in
the
test
for
the
mocks
already
should
work,
even
when
it's
moved
off
thread.
E
C
B
A
A
Really
the
deadline
is
once
we
know
once
we
know
the
answer
to
this.
C
A
Right
but
I
mean
like
we're:
gonna
start
working
on
off
thread.
Well,
okay,
the
deadline.
I
was
thinking
the
deadline
would
be
based
on
events
rather
than
like
a
certain.
You
know
arbitrary
date,
like
the
event
would
be
either.
We
know
the
answer
to
the
question
of
whether
off
thread
solves
it
or
not,
or
we
could.
C
A
B
And
if
the
loader
is
host
instrumenting,
how
portions
of
the
compartments
api
would
interact,
maybe
compartments
just
replace
the
vm
ability
and
and
aunt
are
something
still
entirely
separate
to
node.js
loaders,
but
it's
worth
kind
of
thinking
about
some
of
those
cross-cutting
concerns.
B
For
example,
there's
talk
at
the
moment
about
generalizing
source
text,
module
records
and
things
like
that,
and-
and
these
kind
of
I
guess
if,
if
we
know
that
node.js
loaders
are
specifically
based
on
serialization,
then
node.js
loaders
are
a
unique
loader
space
and
they're
entirely
independent
of
any
of
these
other
constructs
and
compartments
would
only
possibly
provide
module
evaluation
and
nested
environments
yeah.
I'm
just
trying
to
think
through
some
of
those
cross-cutting
concerns.
A
Yeah,
I
guess
jacob.
I
think
that
was
your
pr.
Do
you
mind,
opening
the
revert
one
and
I'll
I'll
publish
this
as
a
pr
on
the
loaders
repo
right
after
this
call?
So
then
you
can
link
to
that.
A
Know
well
her
and
beth.
I
think
whoever
else
was
the
releasers.
We
also
should.
So.
I
think
what
this
means
is
that
we're
going
to
release
chaining
kind
of
without,
like
we're
going
to
release
chaining,
though
like
we're
not
going
to
hold
anything
up
any
further,
we're
going
to
release
chaining
it'll
just
keep
the
async
resolve
hook.
That'll,
be
that
and
I
then
just
the
next
thing
will
be
the
off
thread.
Business
and
yeah.