►
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,
this
is
the
february
15
2022
meeting
of
the
node.js
loaders
team
on
the
agenda
today
is
import.meta.resolve
resolve
and
its
relationship
with
the
web
api,
as
well
as
the
ambient
loaders
proposal.
A
So
why
don't
we
get
started
with
import
meta,
resolve
I'm
going
to
try
to
find
the
google
doc
and
get
that
started?
Maybe
guy
do
you
want
to
introduce
this.
B
Right
yeah
great
to
see
everyone
so
and
thanks
for
making
a
slot
for
this
at
the
last
minute.
It's
appreciated
yes,
so
basically,
this
has
been
something
that's
been
going
on
for
a
long
time,
discussions
of
import
method
go
back
many
years
in
import
meta
resolve,
and
I
guess
it's
a
path
that's
been
laid
for
the
web,
where
a
synchronous,
import
master
resolve
has
been
the
goal
of
those
working
on
the
web,
specs
and
and
to
kind
of
fill
in
the
picture
on
the
webspace
side
of
it.
B
If
you
think
of
it
all
the
way
to
like
module
redirects
were
designed
so
that
they
return
the
url.
That's
returned
for
the
301.
Redirect
is
a
separate
url
in
the
module
record,
so
it's
not
deduped
at
resolve
time.
So
that
way,
redirect
network
redirects
are
still
synchronous
as
we're
having
some
discussion
there
now
and
also
import
maps
are
carefully
designed
to
make
sure
that
their
resolution
is
synchronous
when
you
load
an
import
map
into
an
html
page.
B
That
import
map
is
stops,
delays
all
module
loading
on
the
page
until
that
import
map
is
loaded,
and
only
once
the
import
map
is
finished,
loading
will
modules
start
resolving.
So
so
no
modules
are
executed
until
the
input
map
is
loaded.
If
the
import
map
request
is
blocked,
all
module
execution
is
blocked,
even
if
it's
completely
unrelated
to
the
import
map
and
as
soon
as
you've
loaded
a
module.
B
The
entire
html
page
switches
state
from
a
a
waiting
for
import
map,
states
into
a
import
maps,
ready
state
and
that's
a
that's,
a
one-way
state
change.
Once
it's
in
that
import
maps
ready
state,
it
can
never
go
back
to
loading
import
maps.
In
fact,
it
throws
an
error
if
you
try
to
load
an
import
map
on
the
page
afterwards,
so
at
all
these
different
levels.
It's
kind
of
designed
around
this.
I
don't
personally
agree
with
all
those
decisions,
but
it's
not
really
my
place.
B
For
example,
I
think
that
it's
a
problem
that
we
can't
have
dynamic
import
maps
because
I
think,
there's
a
lot
of
use
cases
where
users
want
to
be
able
to
dynamically
load
mappings,
and
we
see
that
with
es
module,
shims
and
system.js,
and
there
are
ways
to
make
that
work
again.
Whether
that
implies
a
synchronous,
resolver
or
not.
Is
another
question
and
another
rabbit
holes
on
this
on
this
line
of
thinking.
B
But
I
think
the
focus
for
today
was
when
it
comes
to
node.js.
We
designed
the
most
general
loader
hooks
and
completely
asynchronous
resolver,
and
since
the
web
is
looking
at
implementing
a
synchronous,
import.metadot
result
and
we've
already
gotten
async
one
behind
a
flag.
B
Do
we
want
to
try
and
come
up
with
a
coherent
node.js
position
where
we
can
say
that
the
node.js
project
feels
it
wants
an
asynchronous
resolver?
For
these
reasons,
or
maybe
the
node.js
project
doesn't
have
any
need
for
an
asynchronous
resolver
and
therefore
we're
willing
to
take
the
path
of
compatibility
or
some
kind
of
middle
ground
where
we
could
say
that
we're
undecided
and
so
that
that's
the
kind
of
options
if
there
is
a
unified
path,
it
would
obviously
clarify
things
and
make
things
simpler.
B
It's
obviously
a
lot
simpler
for
everyone,
if
there's
a
spec
that
works
across
platforms
and
and
solves
a
general
use
case,
and
it's
nice
to
align
with
that.
If
we
can
and
so
to
try
and
have
that
discussion
about
the
node.js
needs
for
an
asynchronous
resolver.
If
that's
something
we
see
as
being
useful
in
node.js
or
maybe
useful
or
not
useful
at
all,
and
and
just
to
get
some
opinions
about
that
topic
to
see.
If
there's
there's
a
unified
position,
we
can
potentially.
A
A
B
I
think
it's
mostly,
as
I
don't
think
there
is.
There-
is
any
major
driving
use
case
or
that
I
that
I
know
of
at
least
as
far
as
I'm
aware,
it's
it's
a
kind
of
a
simplicity
thing
where,
in
particular,
with
dynamic
import
maps,
not
wanting.
B
Like
if
there's,
if
there's
any
ambiguity
about
what
the
resolution
will
be
because
ambiguity
could
affect,
if
you've
already
started
loading
some
modules
and
then
the
map
changes
and
then
you're
loading
new
modules?
Does
that
mean
you
don't
have
a
well-defined
resolution
and
I
think
there
are
ways
to
tackle
that
question.
But,
as
I
say,
that's
this
is
a
rabbit
hole,
that's
very
web
specific
where
maybe
we
can
try
and
focus
on
the
node
specific
arguments
or
if
there's
time
we
can
dive
into
that.
More
perhaps
I
don't
know.
C
Of
the
not
why
I
raise
my
hand,
my
understanding
of
their
desire
for
it
to
be
synchronous
goes
all
the
way
back
to
when
miles
was
helping
with
the
import
map
spec
get
formed
out.
There
was
objection
from
chrome,
not
from
other
browsers,
to
adding
things
to
the
task
queue
in
order
to
perform
resolutions,
they
felt
it
would
be
too
slow
this
okay,
I
don't
agree
with
it,
because
you
don't
actually
add
that
many
tasks.
A
C
C
C
I
think
yeah
I
raised
my
hand
because
I
think
before
we
get
into
all
this
argument
and
stuff,
we
should
also
question
like
what
the
end
user
story
would
differ.
If
we
had
an
asynchronous
one
and
the
web
had
a
synchronous
one
like
if
we
don't
agree
how
much
damage
would
it
be,
and
my
stance
is
minimal
at
best,
if
you
always
add
in
a
weight,
it
works
in
both
environments
and.
C
I
think
the
problem
here
is
the
type
systems
people
use.
You
would
you'd
get
into
weird
situations
where
people
are
upset
that
they
can't
use
stuff,
synchronously
and
node.
C
C
E
Don't
quite
understand
is:
we
are
not
talking
about
the
resolution
of
chrome
by
itself.
We
are
talking
about
import.meta.resolve,
it's
an
api
that
most
people
will
never
actually
use.
It
will
only
be
used
by
very
special
projects.
So
why
wouldn't
this
api
be
able
to
be
asynchronous.
C
A
D
A
Mean
it
sounds
like
it
could
be.
It's
not
quite
that
I
would
assume
that
it's,
maybe
it's
not
quite
that
obscure.
Like
you
know,
we
don't
have
import
like
we
just
added
sort
of
the
import
of
jason,
but
we
don't
have
import
of
wasm.
Yet
I
could
easily
see
people
want
to
do
import.metadata
resolve
to
get
the
path
to
a
wasm
file,
that's
out
of
a
package
and
then
they
use
fetch
for
it,
etc,
etc.
So
yeah,
this
is
perhaps
like
a
fairly
general
use
case.
E
And
with
most
functions
in
the
web
platform,
usually
being
a
sync
nowadays,
wouldn't
it
make
sense
for
web
browser
to
implement
it
as
resolve
sync
kind
of
like
what
not
does
you
mean
result
amazing,
no,
to
call
the
function,
resolve
sync
and
to
reserve
the
resolve
to
be
async.
C
B
So
back
to
your
question
bradley:
are
you
saying
what
is
the
damage
if
there
is
divergence
between
the
specs,
where
to
locate
your
wasm
in
a
cross-platform
way,
you
would
have
to
rely
on
top
level
weights
with
important
meta
resolve,
and
then
it's
just
in
the
synchronous
case
that
a
weight
is
just
doing.
Nothing.
C
B
Yeah
and
and
the
conclusion
can
certainly
be-
we
need
more
time
to
discuss
it
and
engage
about
it.
I
mean
at
the
same
time.
This
is
something
that
has
been
on
on
the
the
list
for
a
long
time
where,
if,
if
it
is
something
yeah,
you
know
a
convergence,
obviously
a
good
thing
and
then
the
other
hypotheticals.
C
I'm
asking
about
the
damage
just
so
that
we
could
really
like
prioritize
this.
If
there's
almost
no
damage,
if
we
disagree,
I
don't
think
we
really
need
to
discuss
it.
Well,.
A
A
He's
being
very
he's
being
very
inflexible,
I
think
before
we
get
to
the
question
of
like
how
bad
would
it
be
if
we
diverge-
let's,
let's
first
even
see
if
we
want
to
diverge
right
so
like
what
that
was
like
what
I
was
my
point
on.
The
thread
was
like:
what
do
we
lose
if
we
just
go
sync
for
this
api.
C
So
mile
mentioned
it
and
we've
talked
about
it
before
you
lose
essentially
any
sort
of
concurrent
io
operation
that
you
may
want
to
do
so.
A
good
example
was
you
proposed
something
in
the
what
wg
thread
where
it
uses
the
import
maps
synchronously
well
using
import
map
synchronously
for
node
that
the
equivalent
is
using
a
policy
synchronously?
C
You're,
preventing
any
form
of
large
subsystems
of
node
to
always
be
synchronous,
and
when
you
do
file,
I
o
in
particular,
you
don't
want
to
block
everything
historically
for
node.
This
has
been
faster
for
our
esm
loader,
but
that
might
not
be
true
anymore,
and
it
also
means
that
for
your
hooks,
when
you
write
them,
you
have
to
know
that
your
resolve
has
to
be
synchronous,
and
this
is
where
we
get
back
to
the
blocking
thing.
C
If
resolve
is
synchronous
and
we
have
chaining,
that
means
that
any
sort
of
chaining
mechanism
has
to
be
synchronous.
C
Because
they
never
do,
I
o
okay,
that
is
a
hard
requirement
of
policies,
is
they
must
never
do
io.
B
And
and
you
don't
see
any
kind
of
like
prompt-based
permission
systems
in
future
that
might
want
to
like
escalate
a
query
to
the
user
or
something
like
that.
C
F
Yeah,
I
was
just
curious
about
the
details
so
like
bradley,
you
were
talking
about
the
basically
user
land
implication
of
it
being
synchronous
is
that
it
would
block
all
sorts
of
things,
and
I
was
relating
that
in
my
head
to
a
comment
someone
made
in
the
thread
where
or
one
of
the
threads
were
like.
That
was
one
of
the
reasons
why,
like
typescript,
for
instance,
re-implements
resolve,
was
to
make
an
asynchronous.
F
My
question
is
what
would
prevent
someone
from
just
like
basically
wrapping
that
call
inside
of
a
promise
and
then
taking
advantage
of
the
future
infrastructure
in
order
to
to
get
around
that
synchronous
nature?
Or
is
it
the
fact
that
resolve
has
to
be
implemented
a
certain
way
that
prevents
that's
kind
of
solution
from
being
relevant.
C
So
the
reason
that
typescript
and
a
bunch
of
other
people
do
it,
I'm
sure
yarn-
has
this
somewhere
in
their
re-implementation
of
stuff.
A
F
But
with
that
that
would
make
the
bit
non-blocking
under
the
hood.
C
It
makes
the
hook
non-blocking
in
the
thread,
but
on
the
main
thread
it
would
block
it.
Sorry,
a
guy
has
his
hand
up.
It's
been
up
for
a
while.
B
I
I
just
wanted
to
get
back
to
the
design
of
the
function
a
little
bit.
So
I
I
guess
on
on
the
the
synchronous
issue.
As
said,
node.js
has
a
synchronous
resolver
and
it
is
actually
faster
than
doing
the
the
ff
that
the
resolver
does
asynchronously
for
whatever
unknown
reason.
Also,
with
with
the
resolver
that
we've
got
for
es
modules,
we
already
removed
a
lot
of
the
starting.
B
So
it
is
touching
the
file
system
less
and,
as
a
result,
is
more
suitable
as
a
synchronous
resolver
in
fact
than
than
the
older
node.js
resolver,
which
was
also
synchronous,
but
the
design
of
import
metadata
resolve
it's
the
kind
of
modern
version
of
required
results
and
if
you
think
of
the
use
cases
for
required.resolve,
it's
the
same
use
cases.
B
So
the
first
one
that
we
discussed
at
the
beginning,
the
asset
loading
like
finding
a
wiresome
file
or
something
like
that
and
then
the
second
one
is
to
basically
have
a
resolver
that
that
matches
your
import
system
that
you
can
call
out
into.
B
So
if
you
think
of
the
times
that
you've
used
require
resolve
in
in
code
scenarios,
it's
perhaps
to
locate
a
third-party
module
parts
or
a
module
directory
based
on
its
path
or
something
like
that
and
basically
getting
a
hook
into
the
node
modules
resolution
and
exposing
the
resolver
in
a
way
that
any
any
user
can
get
access
to
it.
The
the
form
that
we
have
a
node
is
also
slightly
different
to
the
browser
in
that
there's.
B
A
second
argument,
which
is
the
parent
url,
so
you
can
pass
any
parent
url
in
and
get
a
resolver
as
if
it's
relative
to
that
parent
url,
the
browser
spec,
the
pr
that
we're
discussing
doesn't
actually
have
that,
although
dominic
does
see
that
as
a
potential
add-on
in
future.
B
B
So
I
guess
in
node
the
same
thing
will
apply,
but
in
the
browser
it's
there
there's
a
kind
of
a
restriction
that
you've
got
a
more
static
module
environment
where
you
can't
install
new
modules
and
an
asynchronous
resolver.
Is
that
that's
the
other
use
case?
B
I
kind
of
see
for
an
asynchronous
resolver
is
the
idea
that
you
could
it
could
effectively
act
as
a
kind
of
a
installation
hook
where,
if
the
modules
aren't
present
in
the
important
apple
aren't
ready
for
the
synchronous
resolver,
it
allows
you
to
have
a
place
where
you
can
say
here's
the
work
that
needs
to
be
done
to
prepare
the
resolution
for
this
package
or
install
it
or
make
it
present,
and
so
that's
the
other
aspect
of
asynchronous
resolution,
but
that
doesn't
actually
affect
node
and
right
now
it
doesn't
affect
the
browser.
B
A
But
yeah,
let
me
just
propose
this,
though,
is
like
we
can
always
add
some
api
that
someone
imports
like
import,
resolve
from
module,
or
something
like
that-
probably
not
that,
but
something
along
those
lines
so
like
if
they
ship
the
one
with
only
the
one
argument,
and
we
really
want
the
version
with
stu.
Maybe
import.meta.resolve
is
the
api
that
browsers
have
shipped
and
then
you
know,
import
resolve
for
a
module
could
be
the
version
that
takes
two
arguments
or
something
of
that
effect,
and
it
could
be
async.
It
could
be
whatever
we
want.
C
So
like,
if
we
want
to
frame
it
like
that,
I
think
that's
a
great
solution
where
we
know
we
can
force
our
async
form
to
look
synchronous
and
we
can
tell
people
they
can
use
it
for
compatibility
reasons.
Just
do
this
other
thing
for
performance
reasons,
so
anywhere
down
the
line
like
as
a
compatibility
api.
I
think
there
is
benefits
in
just
matching
if
we're
trying
to
own
the
api.
That's
different.
A
Well,
so
here's
here's
another
thought
I
was
thinking
in
my
head
was
like
say:
you're
trying
to
do.
You
know
import.meta.resolve.
A
You
know
lowdash
to
pick
up
a
package
name
and
in
a
browser
that
would
resolve
to
that
would
only
resolve
that
they
had
an
import
map
loaded
and
that
import
map
had
a
an
entry
for
blue
dash
to
some
url
right
for
node.
A
Presumably
that
would
resolve
like
it
would
do
a
file
system
look
up
to
see
if
you
had
like
dot,
slash,
node
modules,
slash
low
dash
et
cetera,
I
think
right,
and
so
the
node
version
would
involve
a
bunch
of
file
system
calls
which
we
probably
would
want
to
be
async
now
or
we
could
say.
Oh
import.meta.resolve
only
looks
in
your
module
cache.
A
So
if
lowdash
has
already
been
resolved
because
there's
an
import,
there
was
an
import
statement
for
it.
It
returns
that
resolution,
otherwise
it
you
know
throws
or
returns
undefined
or
something,
even
though
an
import
of
that
string
would
find
it
because
it's
not
in
the
cache.
Yet
you
know
or
if
and
when
we
support
import
maps,
because
it's
not
in
the
import
map.
That's
been
loaded,
we
return
return
undefined
similar
to
how
the
browser
would
you
know
either
throw
or
return
undefined
or
whatever
it
does,
when
they
can't
find
something
in
the
import
map.
A
D
D
A
A
C
B
Could
be
so
yeah
that's!
The
next
question
is
if
the
resolve
loader
hook
was
altered
to
be
asynchronous.
That's.
D
Difference
but
shouldn't
the
resolve
hook
be
able
to
influence
import
meta,
resolve.
A
A
C
I
have
a
workshop
if
you
want
to
go
through
it,
I
wrote
basically
on
the
main
thread.
There's
this
thing
called
atomics
and
you
say:
hey
wait
on
this
array
that
is
shared
between
the
two
threads.
Until
this
value
changes
so
index,
zero,
wait
for
it
to
change
and
then
the
main
thread
stops
processing
the
worker
thread
keeps
processing
the
resolve,
does
whatever
async
kerjiggery
it
needs
to
do
and
then,
when
it's
done,
it
tells
javascript,
hey,
I'm
changing
index
zero
on
the
shared
array
to
the
value
one,
and
that
restarts
the
main
thread.
A
A
Well,
I
almost
feel
like
maybe
in
the
short
term,
since
no
one
seems
to
be
using
async
resolve
right
now,
as
a
loader
hook
like,
I
almost
feel
like
making
a
pr
that
just
changes,
both
the
loader
hook
for
resolve
the
synchronous
and
changes
the
experimental
import
meta
resolve
that
we
have
to
be
synchronous
and
to
lose
the
second
argument
and
just
throw
a
pr
up
that
does
that,
and
that
way
we
can
shake
out
any
other.
A
A
E
A
C
Yeah,
so
all
right,
I
mean
you
also
have
to
remember:
dsm-
only
has
very
limited
parallelism
in
actuality
for
its
resolve,
so
really
you're
only
getting
parallelism
for
children
of
a
single
module
record,
normally
if
you're
doing
async
operations
so
getting
the
whole
tree
to
actually
resolve
all
at
once.
Also
clogs
up
the
file
system
and
the
disk
access
controller
does
not
like
that.
A
E
B
But
I
mean
there
is
also
a
like
a
even
if
it's
possible
it
doesn't
mean
it's
a
good
idea
right
so
notice,
right
now,
if
they're
doing
asynchronous
resolution
at
least
they're
not
blocking
up
the
main
thread
when
they
do
that,
whereas
now
that
any
asynchronous
steps
will
fully
block
up,
so
it's
like
it's
like
giving
users
think
xhr
right.
It's
it's
it's
it's
a
it's
a
superpower,
but
you
you
really
don't
want
people
to
do
it.
B
So
in
some
ways
it
could
also
be
worth
encouraging,
asynchronous
resolver
by
actually
just
making
the
synchronous
results
of
the
defaults,
at
least
because
you
don't
want
users
to
have
lots
of
async
work,
that's
just
gonna,
slow
down
and
and
cause
unnecessary
performance
bottlenecks.
B
I
do
quite
like
the
idea
that
it's
it's
a
nice
way
to
catch
in
the
ecosystem.
Async
usage.
Maybe
it
is
too
breaking.
Maybe
there's
a
way
to
do
it,
that's
less
breaking,
but
if.
E
B
If
it's
very
breaking,
then
that's,
we
could.
A
G
E
E
A
E
A
I
mean
the
other
thought
I
had
was
that,
like
you
could
have
a
resolve
hook,
that's
just
like
a
pass-through
that
doesn't
actually
change
anything
and
then
in
your
load
hook
like
if
the
resolve
hook
was,
you
know,
zip
colon,
slash
flow
dash,
slash,
index.js
or
whatever,
then,
and
then
you
just
pass
that
same
string
through
without
touching
it
and
then
in
the
load
hook.
You
can
do
all
the
async
work
of
opening
up
the
zip
and
blah
blah
blah,
because
load
is
gonna,
have
to
stay
async.
C
Just
like
people,
don't
don't
give
you
access
to
synchronous
apis
that
often
the
ecosystem
level,
but
even
with
all
this
like
unconditionally
we're
gonna
move
loaders
off
thread
so
er,
I
don't.
I
don't
know
if
we
want
him
to
block
the
main
thread,
so
it
can't
do
more
work
at
the
same
time.
That's
okay,
but
there's
no
reason
to
convert
it
to
synchronous
because
we
got
a
security
complaint
to
move
them.
B
E
E
C
E
C
C
A
A
C
B
B
The
entire
use
case
it
actually
does
work
out
fine,
because
the
first
one
just
blocks
the
initial
car
and
then
the
other
should
hopefully
have
a
cache
that
they're
that
they're
sharing
but
yeah.
If
you're
loading,
five
different
tar
packages
corresponding
to
five
different
tar
archives,
then
you're
not
able
to
parallelize
any
of
that
work.
Certainly.
E
B
E
B
A
C
A
We
if
we
keep
our
loader
hooks
as
if
the
loader
hook
resolve
stays
async
then
yeah.
I
could
see
us
wanting
to
add
some
api
that
lets
you
do.
An
async
version
of
resolve,
so
import.meta
resolve
would
almost
be
like
just
a
compatibility
api
to
match
the
browser
and
it
would
still
resolve
the
same
get
you
would
get
the
same
result
as
calling
our
version
of
the
resolve
api,
but
our
version
would
just
be
faster
under
some
circumstances.
C
The
browser
is
fairly
adamant
that,
even
if
we
ship
something
that
is
asynchronous,
they
are
never
going
to
have
an
asynchronous
version
on
their
own,
so
whatever
we
do
whatever
different
api
we
generate,
that
is
asynchronous,
is
just
going
to
be
inherently
garbage
to
the
browser
side
of
the
ecosystem.
E
I
mean
if
we
ship
an
s
version
and
they
don't.
What
what's
going
to
end
up
is
that
people
are
going
to
polyfill
it
by
just
wrapping
import.net
dot
reserve
into
a
nursing
version,
and
that
won't
be
honest
that
will
be
on
web
platform.
But
that's
just
friction.
B
There
are
some
strong
static
analysis
benefits
of
the
direct
import
metadata
resolve
as
well,
because
build
tools
can
see
it.
So
it's
a
really
useful
thing
if
we
can
get
agreement
on
it,
so
I
just
posted
a
link
to
ann's
comments
where
he
says
that
it
could
be
worth
having
a
js
host
discussion
place
for
these
kinds
of
things,
which
I
think
is
a
really
positive
step.
Do
we
want
to
try
and
come
to
a
conclusion
today
or
a
position?
I
don't
know
how
I
mean
we've
gone
way
over
time.
B
A
A
Someone
is
going
to
try
to
implement
that.
If
that
pr
is
successful
and
survives
code
view
and
lands,
then
it
sounds
like
we
don't
have
a
conflict
and
they're
free
to
ship
the
api
that
they
want.
If
our,
if
that
pr
is
not
successful,
then
we
should
probably
talk
further
before
they
ship
anything
and
that
so
that
delays
them.
You
know
a
few
weeks
or
something,
but
this
has
already
been
a
years
long
effort,
so
they
could
probably
presumably
wait
a
little
bit.
B
Yeah
does
that
sound
like
a
way
forward?
We
could
do
that
if
that
gets
delayed,
we
could
just
make
the
loader
hook
synchronous
by
default
and
then
and
push
that
through
by
first
deprecating
and
then
do
a
defecation
release
right.
B
E
A
A
E
B
But
if,
if
chrome
is,
for
example,
looking
at
shipping
this
in
a
few
weeks
say
then
that
means
that
we've
got
an
incompatible
api.
So
there
is
some
kind
of
timeline
there
where
we
do
want
to
put
pressure
on
this,
and
especially
if
we
go
forward
and
say
that
our
position
is
that
we
think
we
can
chrome
goes
ahead
and
ships-
and
now
we
don't
want
to
you-
know-
keep
keep
the
diversion
for
too
long.
So
just
I
just
feel
like
it
shouldn't
get
too
late.
Well,.
A
C
C
Don't
know,
I
think,
either
way
we
can
go
back
to
what
wg
and
say
we're
going
to
run
a
test
to
see
how
breaking
it
is
for
us
and
that
will
at
least
buy
time
and
so
like
make
a.
A
A
B
B
C
Currently,
the
the
current
loader
hooks
are
on
the
same
thread.
I
don't
know
what
this
expectation
is
to
get
them
off
the
main
thread
like
timeline
wise,
but
I
don't
think
it'll
be
short.
A
A
This
hook,
if
so,
please
add
a
comment
on
this
github
issue
like
something.
C
C
The
whole
point
of
your
wizardry
was
that's
a
timeline
thing
like
this
is
all
about
timelines.
It's
great
to
have
an
idea
that
we're
gonna
fix
everything
before
chrome
rolls
stuff
out
and
forever.
Everything's
always
synchronous,
but
we
don't
know
even
the
use
cases.
Chrome
doesn't
even
know,
use
cases
for
people
doing
async.
We
are.
B
Not
even
doing
user
investigations,
I
think
that
that
feedback
to
give,
I
guess
the
risk
is
just
if
every
loader
hits
the
warning
path,
and
now
every
user
has
a
warning.
Maybe
there
is
a
way
to
have
warnings
that
are
specific
for
for
load
or
auto
time
as
opposed
to
users
as
well.
That's.
A
B
A
E
Something
I
don't
like
with
the
idea
is
that
we
are
going
to
be
penalizing
people
who
work
through
loaders
that
are
supposed
to
work
where
the
api
that
have
been
provided
to
them.
A
Okay,
so
why
don't
we
just
take
out
the
idea
for
the
warning
for
a
second
like
we
could
do
that
without
telling
what
we
see
about
it.
So
maybe.
B
A
first
step
is
is
to
provide
a
synchronous
variant
of
the
resolver
hook,
that
where
you
encourage
the
sync
form
in
the
docs
note
that
the
async
form
is
possible
but
might
be
deprecated
in
future
and
at
least
do
a
documentation.
Pr
on
that
and
and
change
the
loader
hook.
I
think.
A
C
D
C
D
Okay,
sure,
chrome,
ships,
it's
synchronous,
one,
I
don't
know
next
week
or
however
fast
they
turn
that
out
and
then
we
say
cool
where
we
can
do
this,
but
or
we
think
we
can
do
this
and
we're
targeting
like
three
months.
So
if
you
want
to.
D
Yeah
yeah.
Might
they
consider
that,
instead
of
like
releasing
it
to
the
general
public,
no.
C
A
C
Well,
we
don't
even
need
to
finish
it.
We
just
need
to
get
the
proof
of
concept
all
done,
and
so
we
on
a
on
the
thread.
The
guy
just
well
put
in
the
chat
a
little
while
ago,
like
seems
fine,
with
opening
up
a
discussion
across
different
hosts,
say:
let's
open
up
the
discussion
there
and
we
are
going
to
see
what
we
can
do
to
provide
compatibility
like,
but
we
need
time
to
actually
go
and
you
know
implement
a
proof
of
concept.
C
B
C
We
have
old
design
docs
that,
like
a
google
intern
was
supposed
to
implement,
never
finished
so
I
mean
there's,
we
got
drive.
B
Docs
from
old
modules
working
work
days,
perhaps
it's
it's
a
tentative
intent
to
synchro
file,
our
works,
but
with
user
feedback
we
still
need
to
go
through
some
implementation
and
use
the
feedback
process,
and-
and
you
know
what
that's
that's-
a
good
enough
position-
it's
not
a
strong
negative.
It's
saying
that
we're
we're
moving
in
this
direction,
but
we're
not
doing
it
immediately
and
it's
it's
not
a
guarantee,
and
then
you
know
we
need
to
find
the
the
loader
implementation
work
to
to
achieve
it.
Certainly-
and
it's
not
going
to
be
easy.
A
A
D
Think
sophisticated.
A
B
I
mean
yeah,
we
have,
we
have
a
say
in
in
choosing
not
to
converge
basically
and
and
have
our
own
position
but
yeah
it.
It
sounds
like
we.
We
want
to
find
our
conversions
and
I
think
that's
that's
a
positive
thing.
I
I
just
hope
we
can.
We
can
work
towards
that.
A
All
right,
I
put
it
in
the
google
doc,
if
you
all
can
see
that
is
this
just
right
here.
Does
this
sound
like
what
we're
landing
on
or
would
anyone
make
any
changes
to
this.
D
C
That
seems
fine
to
me,
so
the
actual
algorithms
for
doing
some
stuff,
off-thread
or
ancient
doc,
looks
like
it
was
made
in
2019
by
the
modules
working
group.
A
B
A
Okay,
I
think
why
don't
we
keep
it?
Do
you
wanna
continue
the
discussion
on
the
pr,
because
I
think
there
were
some
notes
there
and
then
we
can,
like
maybe
we'll
see
like
the
end
of
this
week
or
so.
If,
if
that,
all
the,
if
everything
is
resolved
on
pr,
we
can
then
at
least
land
it
as
a
proposal
and
then
discuss
it.
I
guess
a
week
from
today.
If
those
discussions
are
still
ongoing,
I
guess
we
could
discuss
it
two
weeks
from
today.
Does
that
sound
good,
I'm
good?