►
From YouTube: Node.js Foundation Modules Team Meeting 2020-01-08
Description
A
A
Just
a
quick
ask
to
the
group
if
anyone's
able
to
spend
time
on
the
notes
that
would
be
greatly
appreciated,
we
do
have
the
link
I'll
put
it
in
the
chat
one
more
time.
Rob
says
that
they've
got
the
notes.
Thank
you
rob
so.
The
first
issue
that
we
have
on
here
is
from
no
jeff
snowed,
3100
8,
which
is
modules,
implement
logical
ordering
guy.
Do
you
want
to
take
this
one.
B
Yes,
so
we
have
a
are
up
for
a
slight
change.
Well,
quite
a
big
change
in
the
way
that
exports
are
matched
right.
Now
we
have
that
the
current
implementation
we
worked
with
so
far
has
been
based
being
some
kind
of
hidden
list
of
exports
conditions
within
the
resolver
itself
that
the
resolver
knows
about
and
when
it
looks
at
an
exports
object
of
conditions
like
browser
node
defaults,
maybe
production
and
development.
B
If
we
do
those
it
would
match
them
in
its
own
order
that
it
has
internally
and
the
concern
there
was
that,
if
user
is
writing
a
few
of
these
different
conditions,
it
would
be
there
which
would
be
used
in
which
priority,
because
it's
actually
implementation
detail
of
the
resolver
itself.
So
maybe
one
resolver
chooses
the
production
condition
as
the
highest
priority
and
another
chooses.
The
node
condition
is
a
higher
priority,
it's
difficult
which
exactly
will
match
when
they're
on
an
even
footing.
B
So
the
premise
of
the
PR
it
is
to
switch
to
the
object
order
so
that
the
package
author
defines
the
order,
entry
points
that
should
be
matched
it
with
another
feature,
which
is
when
nesting
of
conditions
a
specific
and
doesn't
match
anything.
It'll
fall
back.
So
the
rural
results
is
we
get
something
that
behaves
a
little
bit
more
like
imagining.
Those
exports
object
conditions
as
like.
B
C
It's
not
a
question
just
confirmation
that
the
previous
questions
we
had
about
if
you're
allowed
to
order
JSON
objects.
What
the
ecosystem
tooling
is
doing
and
support
for
this,
how
it
would
pan
out,
we
haven't,
found
any
issues
with
any
of
that.
It's
actually
a
very
well-defined
ordering
within
the
JavaScript
spec.
Some
people
didn't
think
that
was
true.
We
call
it
insertion
order
sometimes,
but
it's
ordinary
own
property
keys
is
the
exact
algorithm.
We
were
using.
B
So
Gus
also
had
a
specific
change.
He
requested
on
the
PR,
which
was
that
I
array
indexes
in
objects
follow
the
same
orderings.
If
you
have
a
number,
the
numbers
are
always
going
to
come
first
in
in
the
order
and
then
the
other
keys
in
insertion
order.
So
the
concern
there
was
that
userland
tooling,
if
it
happened
to
use
numbers,
would
be
in
a
situation
where
the
ordering
wouldn't
work
out
so
to
be
extra.
Cautious.
B
So
it's
fully
well
defined
in
that
sense,
in
an
alignment
with
the
spec,
so
we
got
that
merged.
We
got
it.
We
got
agreement
on
that.
We
came
to
consensus
on
that
within
the
node
process,
based
on
agreement
from
last
meeting
and
at
this
point,
I
feel
that
the
feature
like
to
me
that
makes
exports
feature
complete.
At
this
point,
we've
got
the
niceties:
we've
got
the
sugar
we've
got
the
the
ordering
it's
it's
looking
really
nice
and
the
only
other
PR
outstanding
on
exports
is
the
actual
on
buying
PR.
A
Yeah
I'd
say:
let's
discuss
that
separately
in
the
pull
requests.
That's
specifically
for
it,
because
I
think
we
have
that
yeah.
We
have
separate
items
about
that.
This
pull
requests
for
logical
conditional
exports
has
already
landed
as
far
as
I
know,
so
there
is
no
more
kind
of
action
on
that.
As
far
as
I
know
does
anyone
else
have
last
little
bits
to
add
to
this,
or
are
we
good
to
move
on
to
the
next
item?.
D
A
B
Can
briefly
update
on
some
of
the
details,
so
one
of
the
big
issues
with
this
feature
was
making
sure
that
it
was
backwards
compatible
for
common
jeaious
because
implements
it
and
there
happens
to
be
a
something
in
nut
modules
that
matches
the
package.json
name
and
people
were
relying
on
now.
It
could
tend
to
be
breaking
to
change
the
resolution
and
no
longer
respect
the
node
modules
resolution
and
the
compromises
we
came
to
on.
That
was
that
this
feature
is
only
supported
when
you
use
exports
in
the
package.json.
B
B
A
The
next
one
that
we
have
is
unflagged
conditional
exports.
This
is
3100
one.
This
was
also
a
guy
bedford
joint,
but
in
lieu
of
guy
bedford
yan.
Do
you
want
to
take
this
one
on,
or
I
guess
this
is
an
extension
of
the
conversation
that
we
were
just
having
specifically
that,
like
the
canoe
logical,
conditional
exports
landed,
it
seems
that
you
know
with
that
in
place.
We
kind
of
have
all
the
pieces
necessary
to
unflagged
conditional
exports.
A
I
do
know
that
one
of
the
things
that
you
know
had
been
discussion
was
whether
or
not
you
know
an
alternative
implementation
was
going
to
be
looked
at.
One
of
those
was
potentially
required
ESM.
My
understanding
from
looking
at
the
current
implementation
of
required.
Esm,
though,
is
that
like
one
does
not
necessarily
preclude
the
other
that
they
do
have
unique
benefits
for
both
patterns,
and
so
I
for
one
am
in
in
support
of
of
landing.
This
unflagging
guide,
you
have
anything
to
add
here,
I
think.
B
A
E
I'll
just
I
think
yes,
so
my
memory
is
that
we
were
supposed
to
discuss
so
basically,
Wes
isn't
here
and
I
feel
bad
about
us
making.
This
call
right
now,
when
kind
of
he
was
the
one
that
we
wanted
to
discuss
this
with
and
making
this
call
in
his
absence.
Fields
doesn't
doesn't
feel
great,
I
think
and
make
the
call,
but
I
think
I
would
prefer
it
if
we
can
get
wes's
if.
A
Not
blessing
that
at
least
his
awareness
yeah,
what
I
would
add
to
that
and
then
Brad
is
up
next
is
like
that
seems
reasonable.
I
also
think
for
the
timelines
that
we've
discussed,
like
all
the
behavior
changes
that
we
wanted
have
landed.
So
the
only
thing
that
we're
talking
about
right
now
is
the
commit
that
unflagged
it
and
you
know
for
the
timelines
for
backporting.
This
doesn't
affect
anything.
So
this
seemed
this
seems
reasonable
to
me.
Brad
yeah.
C
I
I'd
agree
with
what
Miles
said
it
might
be
possible
for
us
to
reach
quorum
here
and
then
take
it
directly
to
Wes.
So
we
don't
have
to
go
to
another
meeting
about
unflagging
it,
so
that
would
still
give
Wes
the
opportunity
to
reply
and
we
could
even
wait
on
a
reply.
I
think
he
might
be
on
vacation,
given
some
correspondence
I've
got
going
on
with
him,
so
we
can
wait
for
that.
B
A
B
A
And
I
guess
my
my
intuition
here
and
could
be
wrong.
Is
that
I?
Don't
think
that
this
affects
release
timelines
at
all
like
it
does
affect
the
conditional
exports
landing
in
assembler
minor
release
of
thirteen,
but
that
would
not
change
any
of
the
back
ports
to
twelve,
for
example,
and
it
wouldn't
change
any
of
the
behavior.
It's
just
whether
or
not
it's
flagged.
A
That's
reasonable,
so
yeah
I
think
we
have
consensus
on
next
steps
here,
but
I'll
try
to
be
a
little
bit
active
to
make
sure
we
can
move
things
forward.
The
next
one
we
have
is
number
three
one.
Oh
three
to
import
meta
resolve
I
believe
that
we
had
an
implementation,
we're
talking
to
what
working
group
trying
to
align
the
implementations
between
them.
Guy.
Do
you
have
an
update
on
where
that's
at.
B
Yeah,
so
this
is
an
interesting
one.
It's
been
in
discussion
for
quite
a
while
for
the
browser
and
it
sort
of
been
an
idea.
That's
been
bouncing
around
for
a
while
at
this
sort
of
respect
level,
with
import
maps
and
things
in
nodejs,
it's
the
equivalent
of
required
resolve,
and
it's
it's
kind
of
a
if
you
think
of
required.
That
resolve
is
one
of
the
use
cases
of
require.
One
of
the
core
use
cases
require
supporting
import
dumb
editor
resolve
is,
is,
is
a
important
convenience
feature
and
the
approach
of
the
PR
is.
B
It
calls
the
resolve
of
whatever
the
result
might
be,
including
any
loader
hooks
that
have
been
applied
to
the
resolver.
You
can
provide
a
specify
or
relative
specifier
a
package
name,
a
path
within
a
package
and
a
resolve
it.
You
can
also
provide
a
path
that
isn't
a
module,
so
even
if
the
module
type
wouldn't
have
been
interpreted
as
a
module,
it'll
still
support
it.
B
If
we
can
signify
it
over
the
load
of
boundaries,
async
feels
safer
because
in
theory,
if,
if
we
have
code
in
the
wild
using
a
weight
in
border
meta,
don't
require
something
sorry
don't
off
something
in
theory
that
same
code
would
run
if
we
then
sync
afire
resolve
in
future,
whereas
the
the
converse
would
not
apply.
If
you
have
import
meta,
resolve,
running
synchronously
and
someone's
not
putting
in
a
weight
in
there,
we
can't
as
easily
make
it
a
sink
in
future.
B
So
it's
a
sort
of
a
hazy
argument
for
it
being
a
slightly
safer
bath
in
the
browser.
There
is
an
argument
for
a
sink
because
of
package
array
fullbacks
in
import
maps,
which
in
theory
would
make
resolution
potentially
a
sink.
There
may
be
other
things
that
make
resolution
a
sink
as
well.
Like
example,
dynamic
map
injection.
B
Ie
sent
the
pr2
he
or
she
and
Dominic,
and
they
agree
a
sink,
could
be
in
alignment.
It
was
difficult
to
get
agreement
them
or
like
non
objection
from
them
or
anything,
because,
obviously
this
is
a
situation
where
the
browser
is
also
determining
what
it's
going
to
do.
What
makes
this
interesting
is
because
it
is
a
place
where
no
js'
might
actually
be
able
to
move
first.
B
So
it's
kind
of
like
do
take
the
leap
put
something
out
there
potentially
make
a
change
in
future
to
be
conservative
and
follow
the
browser,
but
this
is
where
noches
can
potentially
need.
I
would
like
to
land
it
personally,
but
I
can
understand
if
there's
resistance,
that
is
it
behind
a
flag
right.
The
current
implementation
is
not
like.
Okay.
C
We
don't
have
a
way
of
passing
conditions
to
this
resolve,
but
we're
using
conditions
in
our
exports
for
logical
ordering.
Similarly,
there's
the
tc39
module,
attributes
proposal
and
I'm
not
quite
sure
how
that
works.
This
there's
just
a
variety
of
things
where
I
feel
like
this
on
its
own
is
being
simplified
and
we
would
have
to
replace
it
with
something
more
feature-rich
in
order
to
get
a
lot
of
the
utility
of
having
a
resolver.
A
Brad,
what
I
would
add
to
that
is
like,
and
it
seems
like.
Maybe
we
could
meet
reach
consensus
on
this
similar
to
JSON
modules.
I
think
that
it
is
premature
to
land
something
like
this
unflagged
at
the
very
least
even
before
implementation.
I
think
we
could
probably
work
with
what
working
group
or
the
HTML
spec
on
spec
text
around
this
and
maybe
reach
consensus
and
I
would
be
I
would
be
concerned
about
us
unflagging
anything
if
we're
expecting
interoperability
before
there
is
some
degree
of
spectacle,
'evil
of
like
more
clear
consensus
across
our
different
groups.
A
B
B
You
know
hooks
into
package
resolution
things
like
that.
You
know
you
get
this
kind
of
super
resolve
of
concepts
and
I
think
that's
a
very
different
thing
to
import
down
metal
resolved
rather
than
being
an
80/20
situation.
I
think
it's
it's
they're
like
they're,
two
separate
things.
The
one
is
a
generic
resolve.
Anyone
can
use
as
a
library,
the
other
is
the
local
environment,
resolver
and
being
able
to
hook
into
it,
and
the
in
political
environment
and
resolver
is
set
to
the
local
environment.
B
So
if
you're
in
production
or
if
you're
in
the
browser
or
if
you're,
a
node,
it's
going
to
resolve
with
those
conditions,
just
like
an
import
does
and
that's
what
required
don't
resolve
does
as
well.
It
matches
the
current
environment
and
then
Bradley's
other
point
was
module
types
personally
types.
Sorry.
C
B
B
If
we
expect
some
spec
to
emerge.
That,
in
truth,
probably
means
some
of
us
putting
a
lot
of
time
into
it.
I
think
that
that
sets
us
back
a
whole
bunch
of
time
like
a
year
and
puts
us
in
a
very
different
situation.
So
I
I
would
love
to
just
put
the
accelerator
on
this
and
accept
any
breaks
down
the
line,
because
it's
not
as
critical
yeah
but
are.
A
C
C
We
could
make
some
kind
of
create
resolver
in
a
similar
manner,
because
this
API
is
it's
in
the
PR
even
allows
you
to
specify
a
different
URL
upon
which
to
do
the
result
against
it.
Doesn't
just
do
against
your
local
context,
your
current
URL.
You
can
actually
like
impersonate
other
URLs
to
do
things.
So
if
we
are
already,
including
that
behavior
it
might
be
possible,
just
to
you
know,
say
you've
got
to
import
this
for
now,
so
we
do
have
ways
of
doing
warnings
on
that.
C
B
No,
it's
just
about
timeline,
and
the
point
is
when
you're
dealing
with
build
tools,
one
of
the
primary
things
like
in
my
work
on
NCC.
One
of
the
primary
features
that
was
necessary
was
the
ability
to
analyze
asset
references.
There
was
Sebastian
mark
pages
asset
reference
proposal.
The
benefit
of
import
Dom
editor
resolved
is
it's
actually
statically,
analyzable
to
a
large
degree,
just
like
dynamic
import,
and
the
benefit
of
that
is
that
acid
references
become
statically
analyzable.
If
we
have
an
out
of
API.
B
B
What
I
was
discussing
at
the
beginning
was
the
sort
of
break
that
we
might
expect
is
something
like
the
browser
says:
hey
actually
like
we're
gonna
do
this
API,
but
where,
for
example,
not
going
to
support
the
second
argument
and
we're
going
to
make
it
sink
now,
if
someone
is
using
the
80%
usage
of
this
API,
which
is
their
awaiting
it
and
they're,
maybe
not
using
the
second
argument,
the
sort
of
impersonation
is
bradley
refers
to
it.
Then
they
would
be
in
a
position
where
their
code
would
still
work.
B
A
A
And
for
what
it's
worth,
III
wanna
like
encourage
the
experimentation
with
this
API,
the
engagement
with
what
working
group
and
trying
to
create
a
reasonable
timeline
on
getting
this
out.
I
just
want
to
like
ensure
that,
like
our
ecosystem,
doesn't
have
usage
of
an
API.
That
is
like
nothing.
What
like
what
it
will
be
in
the
future
without
there
being
like
really
clear
steps
to
kind
of
avoid
people
from
using
that
all
over
the
place,
because
especially
something
like
resolve
is
one
of
those
API
is
I,
could
see
people
picking
up
and
using
fairly
extensively.
C
So
this
PR
is
definitely
not
ready
to
land
anytime
soon,
but
it
kind
of
is
something
we
can
base
a
discussion
around.
So
it
does
move
our
loader
hooks
into
a
separate
thread.
It
does
not
change
the
API
for
the
hooks,
except
for
removing
dynamic
and
stance
eight,
because
dynamic
and
stance
eight
simply
doesn't
work
off
a
different
realm
like
it
cannot
in
any
way,
so
we're
gonna
have
to
solve
some
issues
caused
by
that,
but
so
this
PR
is
a
way
for
us
to
discuss
basically
having
these
on
a
separate
thread.
C
C
C
So
we
will
need
to
do
that.
I,
don't
want
this
PR
to
expand
to
do
all
those
other
things.
I
want
this
PR
to
be
blocked
on
all
those
other
PRS
that
we
could
land.
So
I
want
to
keep
this
purely
as
a
PR
where
we
can
state
okay
in
order
to
land
this
PR.
We
have
to
get
this
feature,
such
as
the
ability
to
you
know
mutate
Global's,
and
then
we
go
make
a
separate
PR
for
that
hook
and
then
put
it
as
a
blocker
for
this
PR.
F
C
It's
possible:
we
could
do
that
I,
don't
see
a
large
benefit
of
doing
that
right
now.
So,
if
we
look
at
what
we
did
for
the
git
source
hook,
we
actually
tried
to
keep
that
incremental.
We
have
a
very
awkward
API
signature
right
now
to
keep
older
versions
of
loaders
working
with
it,
where
the
resolve
can
actually
still
return
a
format.
Even
though
there's
a
separate
gif
format
hook,
I
feel
like
we
can
mark
it
as
going
to
go
away,
but
I
don't
see
removing
it
actually
helping
our
users
right
now.
F
C
E
Yeah
I
kind
of
agree
with
Cory
that
I
would
definitely
prefer
if
we
can
remove
dynamic
instead,
the
napkin
Senshi
age,
rather
sooner
than
later,
or
at
least
added
application
warning,
because
I'm
definitely
concerned
that
people
find
it
and
develop
a
whole
thing
on
top
of
it.
Assuming
that
something
like
it
will
come
and
I
think
we
should
tell
them
as
soon
as
possible.
Something
like
it
might
not
come
may
be
a
good
thing,
also
to
kind
of
figure
out
as
soon
as
possible
is
can
do.
E
We
have
quorum
on
doing
it
in
general,
like
moving
to
an
isolated
context,
because
if
we
do
have
quorum,
then
we
can
make
a
very
clear,
the
size
of
action
of
saying
yes,
that
I'm
against
yeah.
It
is
definitely
deprecated.
We
definitely
need
to
communicate
that
it
goes.
This
is
going
away
and
I
think
we
are
at
a
point
where
we
could
say
that
we
could
make
that
call.
I.
D
So
I
assume
we
can
still
like
putting
these
in
their
own
and
I
guess
each
loader
would
be
in
a
separate
thread.
I
assume
we're
still
able
to
like
see
we
realize
loader.
So
if
you
have
like
you
know
a
CoffeeScript
loader
and
a
Babel
loader,
then
one
can
output
into
the
other
that'll
still
be
possible
in
the
thread
version.
D
D
Yeah
I'm,
the
current
master,
doesn't
do
it
either,
but
it's
not
like
I'm
wondering
what
is
this
PR
preclude
like?
If,
if
going,
the
way
of
this
thread
thing
means
we
can't
have
dynamic
instantiate?
What
other
things
does
it
mean
that
we
won't
be
able
to
have,
and
are
there
any
of
those
other
things
like
concerning?
You
know
that
would
be
the
only
reason
I
feel
like
we
wouldn't
want
to
say:
yes,
go.
Let's
go
forward
with
this,
so.
C
The
big
things
are
the
isolation
and
what
that
means
so
right
now,
if
you
go
and
you
make
a
global
in
your
loader,
however,
you
want
to
using
global
this
or
the
global
variable,
whatever
you
can
see,
that
in
user
code
and
you
can
kind
of
interact
with
your
loader
by
doing
so
so
you
can
actually
do
some
hokey
things
where
you're
sharing
functions
that
are
coming
from
your
loader
with
user
code.
You
won't
be
able
to
do
that
anymore.
You.
C
You
will
need
to
do
some
sort
of
message,
passing
of
some
kind,
so
not
ideal,
but
theory.
You
could
make
stuff
work
for
that
in
general,
though,
sharing
executable
code
and
Global's
with
your
loader,
probably
not
the
best
idea,
especially
since
doing
so,
would
mean
that
we
have
to
spin
up
a
loader
instance
for
every
context,
which
is
what
we're
doing
right
now.
That
does
have
an
impact.
So
if
you
spin
up
five
threads
right
now
with
CoffeeScript
loaders,
you
spin
up
five
different
CoffeeScript
loaders,
so
each
CoffeeScript
loader.
D
C
Would
say
it
makes
them
minorly
worse
until
we
add
some
other
hooks,
so
those
Global's
that
they
add
don't
interact
directly
with
how
modules
are
evaluated
for
mocha
and
stuff,
so
she'll
be
fine.
The
bigger
problem
for
a
lot
of
those
utilities
is
going
to
be
the
module
cache.
We
don't
have
the
module
cache
exposed
in
any
former
yeah.
D
A
E
I
think
so,
just
to
clarify,
since
my
name
was
brought
up.
My
point
was
step.
One
is:
do
we
have
quorum
to
decide?
Yes,
we
want
to
have
loaders
be
isolated.
We
don't
want
to
run
them
in
the
same
global
scope
as
the
code
that
is
actually
running
the
the
user
in
user
lands
and
I.
Think
that
will
inform
a
lot
of
the
other
choices
like
for
example,
then
I
don't
think
we
need
to
vote
on
whether
we
want
to
deprecate.
E
C
C
C
It
passes
well,
it
creates
a
new
message,
channel
per
spawned
context
and
it
passes
that
to
the
internal
worker
and
they
all
communicate
over
there.
A
message
channel
to
the
same
internal
worker,
which
gets
a
client
ID,
which
I
believe
is
a
the
thread
ID
currently
in
the
PR,
so
it
can
differentiate,
which
thread
is
doing
something.
I've
they've
got
a
similar
concept
in
the
browser.
Nobody
really
differentiates
per
thread
currently
a.
B
E
E
Can
be
separate
between
Lotus
and
hooks,
so
every
single
factor
would
always
have
a
loader
its
own
instance
of
a
loader
with
its
own
module
map.
I.
Don't
think
that
anything
will
ever
change
that,
just
because
the
modules
have
to
be
attached
to
the
context.
So
there's
there's
no
sharing
of
that
part.
So
the
hooks
are
shared.
That's
the
that's!
The
big
difference.
E
E
A
A
Issue
number
four
1
2
from
the
modules
repo
is
chartering
the
modules
team
they're,
not
something
we've
managed
to
actually
discuss
in
a
meeting.
We
don't
have
time
to
like
extensively
go
through
it,
but
you
know
my
my
intuition
is
that
we
kind
of
have
everything
we
need
in
place
for
the
most
part
to
charter.
A
D
A
Me
groups
can
be
murdered,
yeah
I,
think,
like
my
gut
on
this,
is
mostly
along
the
lines
of
like
the
people
who
are
maintaining
this
source
in
core
is.
Are
all
in
this
group
we're
actively
meeting.
We
are
developing
strategy,
we
are
consulted
like
like
we
are
acting
as
if
we
are
chartered
already
in
all,
but
like
official
capacity,
which
is
generally
like
a
good
time
to
consider
it.
A
We
also
don't
need
to
like
it's
not
is
not
blocking
our
ability
to
do
anything,
but
maybe
you
know
we
don't
need
to
dig
too
much
into
it
today,
but
we
do
have
that
open
issue,
and
if
people
of
feelings
would
be
great,
if
you
could
chime
in
this
has
been
on
the
agenda.
One
two
three
four
is
the
fourth
time
it's
been
on
the
agenda.
We
haven't
really
discussed
it
yet
died.
A
B
B
A
Being
officially
recognized
as
as
owning
the
things
in
which
we
own
from
like
a
process
perspective
would
allow,
for
example,
you
know
members
of
this
team
to
block
things
upstream
theoretically,
could
stop
the
TSC
or
other
groups
from
unilaterally
making
changes.
Without
you
know
us
shining
in
I.
Think,
like
part
of
the
chartering
process,
is
also
kind
of
you
know,
outlining
what
the
expectations
are.
To
be
frank:
I,
don't
have
a
ton
of
experience,
chartering
a
group,
that's
responsible
for
a
part
of
the
codebase.
A
D
A
B
I
think
we're
honest
at
the
end
of
the
agenda
already
of
the
remaining
items
we
have
stabilizing
the
resolver
unflagging
in
12-point
ex
loader
hooks,
which
I
think
we
actually
haven't
discussed
and
patching
instrumenting
module.
Does
anyone
want
to
bring
anything
up
with
the
remaining
three
minutes.
D
So
I
did
a
lot
of
work
on
that
with
with
Brad
and
some
others,
and
there's
still
much
to
be
done
so
I
think
if
people
want
to
check
out
it's
still
just
on
master,
it
hasn't
been
released
on
the
point
release
yet,
but
if
you
check
out
the
latest
master
and
build
it,
I
guess
pull
down
the
nightly.
There
are
now
four
hooks
with
the
loaders.
Have
it
forget,
didn't
you
can
say?
D
I
did
for
now,
but
there's
resolved,
get
format,
gets
source
and
transform
source
and
they're
kind
of
sequential
we're
resolved
takes
in
your
takes,
a
specifier
gets
URL
get
format
takes
the
URL
in
terms
of
format.
Get
source
takes
URL
in
format,
returns
the
source
and
then
transforms
first
optionally.
It
does
something
with
that
source
I,
so
I
won.
I
haven't
really
gone
through
all
our
long
list
of
use.
Cases
for
loaders
to
see
like
which
ones
are
still
unsatisfied
with
this,
but
that
would
be
something
that
we
should
probably
do.
D
B
D
D
Actually,
I
have
a
question
for
you:
Brad
is
with
the
work
of
moving
it
to
threads.
Is
there
anything
that
we
shouldn't
do
like
in
master
related
to
loaders,
like,
obviously,
we
shouldn't
develop
dynamic,
instantiate
any
further
but
like
beyond
that?
Is
there
any
like
if
someone
wanted
to
make
a
new
hook,
you
know.
Is
there
a
problem
with
that?
If
someone
wanted
to
work
on
how
data
gets
passed
between
hooks
like?
Is
there
anything
we
should
be
concerned
about
or
avoid
doing
because
of
the
intention
to
move
this
stuff
into
threads
Oh.
C
D
C
F
Well,
yes,
I
just
wanted
to
comment
on
the
multiple
loaders
not
being
wanted.
I
do
think
that
somehow
there
needs
to
be
some
kind
of
way
to
accomplish
that
I
know.
Somebody
had
mentioned
doing
that
userspace,
but
ultimately
my
concern
with
userspace
is
that
essentially
requires
every
single
loader
to
essentially
share
whatever
it
has
combines
multiple
loaders
and
I'm
also
not
sure
how
the
multiple
loaders
would
be
added
to
that
shared
loader.
So
I'm
hoping
that
at
some
point
there
can
be
more
thought
or
discussion
on
that.
B
E
D
Jeffrey
yeah,
just
just
to
follow
up
with
that
I
think
it's
inevitable
that,
like
I'm
just
thinking
of
gulp
as
the
example
like
gulp
as
the
game
gulp
floor,
there's
gulp
shot
series
and
gulp
top
parallel.
Where
you
can
pass
it
astute
pass
it
a
bunch
of
functions
to
either
run
in
series
or
in
parallel,
and
it's
like
having
no
do
this
in
core
either
we're
gonna
do
some
kind
of
much
more
simplistic
version
or
like,
like
I,
think
it's
inevitable.
D
That's
that
usual
and
we'll
produce
something
like
gulp
that
groups
together
loaders
in
whatever
ways
they
need
to
be
orchestrated
kind
of
like
ganas,
saying
and
that's
gonna
happen,
no
matter
what
node
does,
even
if
node
offers
something
in
core
for
like
running
them
in
sequence
or
something
so
then
the
question
is
like:
if
node
is
to
offer
something
in
core,
what
should
it
be
and
how
sophisticated
should
it
be
because
yeah
then
it's
like
is
you
know?
Is
it
really
nodes
place
to
compete
with
things
like
gulp
or
yeah?
D
So
it's
a
it's
a
I'm
not
opposed
to
it.
I
think
node
should
probably
offer
something
simple
in
core,
but
we
kind
of
have
to
be
careful
in
designing
this
too,
making
it
not
too
simple.
It
doesn't
accomplish
anything
useful,
but
also
not
like
you
know
not
like
we're
competing
with
the
gulps
and
web
packs
of
the
world.