►
From YouTube: Node.js Foundation Modules Team Meeting 2019-02-12
Description
A
And
we're
now
live
on
YouTube,
with
the
February
12th
meeting
of
the
nodejs
modules
team,
we
have
a
fairly
full
agenda
and
potentially
a
shorter
meeting
than
normal,
so
I
think
we
should
get
right
to
business.
We
have
a
couple
upstream
issues:
I
think
that
we
should
get
started
with
the
we
have
one
for
disabled
exports,
encapsulation
for
CJ
s,
another
for
refine
and
unify
experts.
A
A
B
A
C
A
C
A
C
This
came
up
because
pre-act
shipped
exports
in
that
package.json
and
when
they
published
that
they
found
that
some
users
we're
doing
things
like
require
pre-act
forward,
slash,
package.json
and
those
then
broke
because
of
exports,
encapsulation
and
then
I
believe
Jason
and
miles
were
to
get
a
fix
into
pre-act,
which
includes
the
mapping
for
the
package,
so
JSON
file,
and
also
a
root
level
like
the
our
encapsulation
opt-out
of
dark
forward,
slash
maps
to
dark
forward,
slash
and
watching
this
happen.
I
was
just
thinking.
Is
this
something
that's
going
to
happen
regularly?
C
Our
other
package
is
going
to
experience
that
same
problem
where
the
upgrade
path
is
going
to
break
for
users
and
then
they're
opting
out
of
encapsulation.
The
opt-out
is
affecting
both
common
J's
and
ism
consumers
when
it's
just
the
CJS
consumers
who
are
potentially
going
to
have
issues
so
the
threw
together
the
PR,
and
it's
had
a
lot
of
negative
response.
So
it
doesn't
look
like
it's
something
that's
going
to
go
forward,
but
the
idea
was
that
we
could
just
disable
it
and
disable
encapsulation
for
commonjs.
C
I,
guess
that
the
problem
is
that
the
opt-out
is
opting
out
for
both
common
J's
and
the
earth
modules.
Maybe
we
could
encourage
an
opt-out
passing
like
that
that
only
works
for
require
I'm,
just
posting,
something
in
the
chat
here,
something
like
that
in
conditioner
exports.
If
we,
if
we
tell
people
how
to
use
conditioner
exports,
let
me
say
this:
is
your
opt
out
that
might
be
a
better
path,
because
the
worry
is
that
people,
then
on
getting
encapsulation,
are
they're
all
adding
this
this
opt-out,
and
then
we
lose
those
benefits
of
exports.
A
And
Wes
the
the
particular
case
that
came
up
was
that
pre-act
attempted
to
just
document
their
specific
exports,
but
then
forgot
to
include
package
JSON
which
broke
things
so
I
sent
a
PR
specifically
to
ad
pack,
which
JSON
and
after
a
discussion
with
Jason
Miller,
he
added
the
dot,
slash
binding
specifically
in
case
there
were
any
other
edge
cases
they
were
unaware
of.
So
is
meant
to
be
like
a
capture
all
with
the
intention
of
removing
it
in
assembler
major.
A
B
Yeah
I
think
one
of
my
concerns
with
scoping
to
require
is
that
that
works
as
long
as
none
of
the
existing
tools
at
support
for
importance.
Basically,
because
right
now
scoping
it
to
require
works,
because
we
assume
that
all
existing
consumers
are
using
require,
which
is,
to
some
degree
fair.
But
as
soon
as
webpack
and
others
adding
support
for
the
field.
Then
there
might
be
suddenly
plenty
of
consumer
dan
not
using
require
because
they're
using
input,
syntax
and
all
the
bundlers
are
still
looking
at
exports,
so
I
think
medium
term.
I.
B
A
E
A
C
A
I'm
happy
with
where
we
landed
on
the
warning
right
now
and
I
honestly,
like
this
particular
edge
case
of
exposing
a
dot
only
for
require
and
making
it
inconsistent
between
an
ESN
consumer
and
a
common
Jay
s
consumer
in
like
a
very
specific
weird
way,
like
it's
still
an
experimental
feature
like
I'm
personally
fine,
with
the
warning
being
the
way
it
is
right
now
and
I
personally,
don't
see
a
problem
with
folks
who
want
to
in
assembler
minor.
Have
this
escape
hatch
using
it
personally.
B
A
So
to
be
clear,
I
personally,
I'm,
potentially
even
thinking
that
just
doing
the
dot,
slash
export
broadly
for
both
PSN
and
common
jeaious,
should
potentially
be
the
preferred
pattern,
because
it
feels
weird
to
me
to
be
treating
one
of
the
consumers
differently
so
broadly
and
I
understand
that
it
could
be
a
way
of
like
adding
ESM
support
as
December
minor
and
like
keeping
it
more
restricted
for
ESM,
while
not
making
it
restrictive
for
common.
But
it
just.
It
seems
like
it's
a
really
easy
way
to
can
confuse
consumers
and
in
retrospect,
I'm
thinking.
A
Maybe
we
don't
even
want
to
document
that,
but
I
think
we
can
maybe
talk
about
that
offline
in
a
documentation
PR
if
people
feel
strongly
about
it
and
to
what
Wes
there
I
think
like
people
should
really
consider
that
adding
exports
can
be
breaking
unless
you
opt
out
of
some
of
this
stuff
and
that
last
bit
is
my
editorial.
Ization
Jeffrey,
you
of
your
handout,
yeah.
D
I
feel
like
I
kind
of
agree
with
Wes
like
I,
feel
like
pre-act
solved.
Their
media
problem
is
that
they
had
legacy
consumers
who
expect
non
capsulation,
and
so
they
disabled,
encapsulation
I'm,
not
sure
we
really
should
be
encouraging
them
to
like
be
a
to
throw
on
encapsulation,
but
only
for
import
consumers
like
whenever
they
adding
capsulation.
That
should
just
be
their
breaking
change
and
they
should
roll
with
it.
At
that
point,
like
I,
said
I'm,
not
sure
anything
needs
to
change.
You
know.
A
C
A
C
But
one
of
the
thing
is
I
know:
I've
heard
you
think
it
should
stay
in
an
experimental
status.
That
I
was
hoping
to
hear
from
some
other
members
as
well.
You
know
keeping
conditional
exports
in
self
result
in
experimental,
but
removing
those
warnings
to
to
allow
adoption
without
these
frictions.
What
people
think
about
that.
B
Should've
thought
about
this
before
I
started
writing.
So
what
do
people
think
about
removing
the
warning,
I
kind
of
come
back
early
about
and
I
think
it's
I'm
saying
the
same
thing
as
I
said
last
time
the
question
came
up,
which
is
I
I.
Think
the
warning
for
conditional
export
specifically
is
too
easy
to
get
wrong
by
accidents
that
you
accidentally
trigger
it.
B
So
I
think
it
would
be
a
much
nicer
experience
for
people
if
they
don't
have
the
warning
like,
for
example,
what
my
eyes
just
set
with
oh
yeah.
We
should
advise
them
that
they
need
to
use
a
specific
form
of
conditional
exports
so
that
they
can
trick
the
warning
system
to
not
warn,
even
though
technically
they
do
have
conditional
exports
in
there,
but
it's
just
not
triggering
them
it's.
It
seems
very
happy
to
suggest
people
to
do
that,
just
because
we
want
to
have
the
warning
for
what
seems
to
me,
like
intellectual
purity.
A
D
I
think
we
talked
about
this
at
a
previous
meeting
and
I
think
what
we
were
I
don't
know
if
we
reach
incentives,
but
I
think
a
suggestion
that
several
people
liked
was.
We
wanted
the
warning
to
somehow
only
be
shown
to
the
package
author,
but
not
the
package.
Consumer
and
I,
don't
know
where
we
went
with
that.
I
was
just
thinking
right
now
that,
like
we
could
I
mean
this
is
perhaps
a
little
too
hacky
I
don't
know,
but
like
there
are
those
extra
fields
that
the
NPM
registry
adds
on
to
package
a
Jason.
D
So
we
could
maybe
like
when
someone
does,
when
there's
a
require
import
of
a
package.
If
it
has
those
extra
automatically
added
fields,
don't
show
the
warning,
because
you're
assuming
at
that
point
that
it's
an
end
consumer,
but
if
there's
pack
that
those
fields
are
missing
then
show
the
warning
because
you're
assuming
it's
the
author
and
then
we
get
a
little
bit
of
the
best
of
both
worlds.
You
know.
A
So
kind
of
two
thoughts
here,
the
encapsulating
the
warnings
only
to
the
package.
Authors
is
definitely
an
avenue
that
we
can
go
by
I.
Think
I,
think
that
and
it
could
be
wrong.
You
know
like
we're,
seeing
even
just
in
our
back
port
212
like
this
stuff
is
still
experimental,
we're
still
finding
bugs
in
it.
It's
still
not
in
my
personal
opinion,
production-ready,
like
the
warnings,
albeit
annoying,
are
also
kind
of
like
doing
their
job,
like
people
are
seeing
them
they're
reporting
them.
A
Anyways
short
shorter
version
is
maybe
what
would
be
useful
would
be
for
us
to
sit
down
and
come
up
with
an
explicit
timing
of
where
were
okay
with
removing
the
warnings
and
that,
if
we
wanted
to
do
shorter
term
engineering
backflips
for
like
specific
encapsulation
in
the
meantime,
we
can,
but
it
might
be
reasonable
for
us
to
figure
out
how
much
longer
those
warnings
will
be
there.
First,
before
we
kind
of
do
some
engineering
effort
on
that.
A
D
A
Yeah
we
can
is,
we
have
other
things
on
the
agenda.
So,
okay,
like
how
about
this,
how
about
we
put
a
bookmark
in
this,
because
it's
taken
a
lot
of
our
time,
we're
aware
of
the
problem
space,
let's
try
to
blast
through
the
other
things
that
are
on
the
agenda,
so
that,
like
we're
good
and
then,
if
we
have
remaining
time,
spend
it
all
on
this
issue:
people!
Okay!
With
that
sure,
okay,
we
have
refined
and
unify
exports
resolution
error
handling.
Think
this
one
is
guy.
C
My
title
that
obvious
yes,
so
I,
of
course
I
should
have
actually
read
through
this
is
I
just
put
together
this
mammoth
block
of
text
for
the
pr3
165.
It's
very
simple,
I
promise.
C
So
the
main
thing
that
I
was
kind
of
tackling
with
this.
The
main
problem
was,
if
you,
if
you've,
got
the
PRF
and
you're
looking
at
it,
it's
in
the
middle
there's
the
number
one
and
two
and
it's
the
example
in
the
middle
of
the
paragraph
of
number
one,
which
is
this
fact
that
if
you've
got
because
we
we've
made
exports
conditions,
behave
logically,
like
if
statement
so
they
kind
of
pull
through
from
top
to
bottom,
and
if
you
have
a
nested
condition,
so
you
have
a
condition
inside
a
condition
and
in
the
nested
condition.
C
C
C
The
programming
principles
like
you
should
get
an
error
when
you've
made
a
mistake,
sort
of
thing
to
know
that
this
is
not
a
correct
mapping
and
not
just
sort
of
oh,
it
could
have
fooled
through
to
some
other
other
options
or
the
down
the
conditional.
So
the
the
gist
of
the
PR
is
splitting
up
the
resolution.
Errors
into
two
main
different
cases:
error,
'invalid
package
target
and
error;
'invalid
module
as
specifier.
C
Sorry,
error
package
part
not
exported
and
error
'invalid
package
target,
so
in
the
one
hand,
if,
if
the
package
target
is
invalid
in
immediately
throws,
whereas
if
there's
no
package
target
so
like
that
example
that
I
faced
it
earlier
in
in
the
in
the
chat
where,
where
there
was
just
a
require,
but
there
wasn't
anything
else,
so
it
would
not
match
anything,
but
it
was
still
a
conditional
object.
It
was
a
past
present,
but
it
doesn't
match
anything,
and
so
that
would
give
me
error
package
past
not
exported.
C
So
the
idea
was
just
try
to
like
reify.
Some
of
these
conditions
into
their
general
cases
and
I
really
went
through
quite
thoroughly
and
kind
of
sorted
through.
So
this
the
standard
module
not
found
this
error.
'invalid
packets,
are
error.
'invalid
package
target
error,
'invalid
module,
specifier
and
error
package
path,
not
exported,
which
are
the
encapsulation
errors
or
the
full-backs.
C
When
nothing
was
found
all
the
callbacks
and
then
the
logic
is
used
internally
to
make
sure
that
in
conditional
exports
we
always
we
fall
back
if,
if
the
path,
if
there
was
no
conditional
match,
it'll
act
like
a
callback,
but
if
there's
an
invalid
thing
on
the
right
hand,
side
and
it
matches
it'll,
sir,
it
won't
just
fall
on
and
go
through
to
the
next.
Unless
it's
an
array
fallback
sorry,
it's
quite
a
complicated
one.
So
explain,
but
that's
the
gist
of
it
or
maybe.
F
C
F
F
C
F
C
C
And
do
you
have
any
feedback
about
this
API
concepts
of
splitting
up
the
errors
from
this
sort
of
singular
module,
not
found
error
into
these
slightly
more
descriptive
errors,
I
think
it
I've
tried
to
do
the
best
classification
I
can
of
the
aerospace
kind
of
thinking
in
terms
of
you
know:
error
invalid
module
specifier.
If
it's,
if
it's
the
user,
importing
the
something
invalid
in
the
package
error
package
files
not
exported
when
it's
the
exports
configured
self,
that's
invalid
or
missing,
or
a
error
invalid
package
target.
If
it's,
if
the
exports
mapped
to
something
invalid.
F
I
mean
so,
like
my
personal
opinion,
is
that
people
shouldn't
take
a
dependency
on
the
exact
and
specific
errors
that
something
throws,
because
I
as
a
developer
would
very
much
like
to
have
the
Liberty
to
change
or
improve
those
errors
in
the
future.
Ergo
not
like
the
idea
of
including
my
error
surface
in
my
public
API
and
us
for
the
node
project
yeah
exactly,
and
so
this
is
one
of
those
things
where
like.
A
Ill
not
promote
the
API
to
being
considered
stable.
The
other
thing
we
can
also
do
is
like
the
error
codes,
and
the
error
message
are
also
super
flexible,
like
the
error
code
is
not
flexible,
but
the
message
is,
which
is
part
of
the
reasons
why
we
abstracted
those.
So
what
is
actually
more
important
than
even
the
messaging
is
ensuring
that
the
things
that
are
erroring
that
are
sharing
codes
share
the
same
semantics
like
high
level
semantics
like
they
are.
They
want
to
share
the
same
basic
error
because
we
can
actively
change
the
error
message.
C
So
another
thing
I
mean:
if
we
were
against
this
idea
of
separating
out
and
having
these
separate
codes,
we
could
try
and
still
keep
the
singular
mojo
northbound,
but
we
already
do
have
two
other
codes
happening.
I
think
they
are.
Where
is
it
I
can't
see
where
I've
written
it
out,
but
I
think
it's
error.
'invalid
specifier
I
think
we
have
added
four
invalid
package
names
because
it
simply
isn't
a
motion,
not
sound
error
and
it's
I
think
four
invalid
URLs
they
might
be
area
and
rather
than
euro,
or
something
like
that.
F
That
the
real
question
is
like:
do
you
expect
people
to
programmatically
switch
behaviors
based
on
the
different
error
code?
Right,
like
is
that
error
code
different
because,
like
that,
is
intentionally
something
that
you
want
people
to
switch
on
because
like,
if
you
think
people
want
to
do
it,
then
you
want
to
provide
a
different
error
code
for
them
to
switch
on.
If
you
don't
think
people
are
gonna,
do
it
well,
you
can
just
have
a
different
message,
because
the
message
is
all
they're.
Gonna
read
right.
C
So
there
is
another
thing
there,
which
is
in
no
jeaious
generally.
The
way
the
arrow
system
is
set
up
is
that
the
error
code
and
message
kind
of
goes
together.
So
if
we
we
could
still,
if
we
decided
to,
we
could
stick
with
a
single
module,
not
found
code
and
then
split
that
code
on
lots
of
different
messages.
It
just
wasn't
the
way
that
naturally
fell
into
it.
There
is
also
a
way
in
which
one
of
the
codes
is
being
used
internally
for
these
object
fallback.
C
So
it
was
the
natural
way
to
kind
of
do
it.
I've
kind
of
I've
tried
to
design
it
as
clearly
as
possible
to
indicate
the
different
classes
of
what
these
errors
are.
So
I
think
they
will
be
useful
to
users
and
I.
Don't
see
that
these
are
going
to
be
something
we're
going
to
be
having
problems
with
in
terms
of
as
they
expand
in
future.
Two
two
more
sets
of
resolution
cases,
but
I'm
open
to
suggestions,
I
think.
F
It's
a
mostly
a
matter
of
your
intent.
If
you
want
people
to
be
able,
if
you
want
people
programmatically
in
their
code
to
switch
on
different
errors,
these
different
error
classes,
then
you
want
to
have
different
error
classes.
If
you
think
that
people
really
shouldn't
be
like
doing
things
programmatically
based
on
these
error
codes,
then
maybe
having
only
one
error
code
is
the
way
to
go
to
try
and
discourage
people
from
switching
on
the
error
code.
B
May
I
get
in
here,
I,
I,
agree
and
I.
For
me,
one
of
the
reasons
for
having
this
yeah.
These
additional
error
codes
is
potentially
less
than
we
want
people
to
switch
on
these
error
codes
and
more
that,
given
that
people
are
already
switching
on
module
not
found,
we
don't
want
these
new
cases
to
hit
that,
because
the
usual
way
that
they're
using
it
is
they
catch
modular
not
found
as
a
proxy
for
this
optional
depends.
E
is
not
installed.
B
If
that
catches
I'm
trying
to
get
a
sub
path
of
the
dependency
I
have
a
programming
error.
Basically,
that
is
not
exported.
That,
in
my
opinion,
would
be
bad,
so
I
think
that
not
having
these
included
in
the
thing
that
is
already
used
to
be
a
proxy
of
optional
depends.
He
is
missing,
is
good
and
I.
Think
in
that
sense,
I
would
want
people
to
switch
on
it.
B
Just
like,
for
example,
switching
being
able
to
distinguish
another
kit,
in
other
words,
being
able
to
prevent
people
from
catching
accidentally,
something
that
is
a
miss
configuration
in
their
dependency
as
hey.
This
path
is
not
supported
by
this
version
of
my
dependency.
I
think
it
makes
it
a
lot
clearer
and
it
breaks
the
code
that
should
be
breaking
to
have
different
error
codes
in
these.
These
cases.
A
D
Wanted
to
say,
I
feel,
like
error.
Messages
should
just
be
designed
to
function
to
to
achieve
their
intended
function,
which
is
to
inform
the
developer
what's
wrong
and
as
clear
and
concise
away
as
possible,
so
that
they
know
what
to
fix
like
I.
The
idea
that
we
wouldn't
want
more
informative
error
messages,
because
we
don't
want
to
let
people
switch
on
them.
Let's
just
I
mean
I,
see
where
you're
coming
from,
but
I
feel
like
it's
kind
of
crazy,
like.
F
C
C
Things
things
that
are
unrelated
to
you
know
if
it
was
an
actual
error
that
that
has
to
do
with
the
resolution
of
the
package
itself
as
opposed
to
it
just
not
being
installed
and-
and
this
does
also
open
up
the
door
to
detecting
encapsulation
errors.
So,
for
example,
if
I
wanted
to
do
a
lot
of
this
stuff
is
also
thinking
about
how
import
metadata
solve
behaves,
because
these
errors
also
come
out
of
that
function
and
if
you're,
using
import
that
meta
don't
resolve
to
resolve
an
expose.
That
doesn't
that's
not
it.
C
That's
not
exported,
say
like
say
in
that
pre-act
case,
where
you
want
to
check
the
package.json,
you
could
catch
the
resolved
error
and
see
that
it's
error
package
pass
not
exported
and
know
that
that
error
code
is
always
means
that
you've
hidden
encapsulation
error,
and
then
you
have
a
fullback
in
that
encapsulation
case
that
you
can
say.
Okay
I
need
to
resolve
the
pass
to
the
package
first
and
then
resolve
the
file
from
there
inside
the
package
and
the
news
FS
or
whatever
so
I
yeah
I.
Think
it's
the
idea
of
having
an
encapsulation
area.
A
A
A
C
C
A
A
So
next
one
we
have
on
here
is
number
four
75,
which
is
Doc's
review
of
various
effects
of
tight
field.
This
is
another
one
from
Brad.
There
hasn't
been
a
comment
in
there
in
like
26
days,
I,
don't
know
if
there's
really
any
specific
discussion
I
have
about
this
one.
Does
anyone
have
any
specific
anything
specific
that
they'd
like
to
discuss
on
this
I?
D
A
Okay,
yeah
I,
put
the
Help
Wanted
tab
and
removing
the
modules
agenda
and
I'll
document
it.
So
the
next
one
that
we've
got
on
here
is
the
unflagging
12
and
LTS
thread.
We
we
updated
the
we
back,
ordered
all
the
steps
of
12
that
X
that
went
up
this
week.
We
broke
some
stuff.
We
discussed
that.
Well,
maybe
you
have
time
to
discuss
some
stuff.
Some
more
later,
I
think
we
can
for
now
drop
this
from
the
agenda
and
bring
it
back
to
the
agenda
in
April
or
close
to
April
when
we're
getting
ready.
D
D
How
would
how
would
that
correspond
to
unflagging
stuff
like?
Are
we
gonna
want
to
have
everything
on
flagged
in
14,
or
do
we
specially
want
to
have
things
flagged
in
14
things
are
unflagged
in
13
we
wouldn't
be
reflashing
them
for
14.
No
I
mean
that
things
that
are
sorry.
The
things
are
still
experiment
are
the
things
that
are
doing.
The
warnings,
yeah.
A
I
mean
I
think
that
that's
a
separate
topic,
though,
about
whether
I
wore
names
in
14
and
I,
think
that
was
the
topic
we
were
talking
talking
about.
Bringing
up
I
think
14
might
be
a
reasonable
time
to
remove
the
warnings.
We
can
also
remove
the
warnings
before
LT
s
and
we
can
also
remove
the
warnings
during
LTS.
So
these
are
all
things
that
are.
D
A
A
D
A
Okay,
so
I
guess
we
can
do
because
I
don't
know
if
we
have
quorum
on
the
call
right
now,
don't
think
maybe
we
do
1
2
3
4,
it's
close
I
think
we
need
one
more
for
quorum,
but
I
can't
remember
exactly
how
many
members
we
have
thanks
to
us
I
think
that
maybe
we
just
put
something
in
the
issue,
and
you
know
if
no
one
objects
and
the
next
week
we
can
make
a
request
to
the
TOC
to
charter
the
group.
How
do
people
feel
about
that.
D
D
So
I
shipped,
where
I
need
it
I
know
both
guy
and
Bradley,
had
designs
or
had
ideas
of
doing
a
redesign,
but
I
haven't
really
heard
anything
since
so
I
wonder
I
know
the
most
specific
thing
I
remember
hearing
was
wanting
to
make
these.
What's
the
phrase
not
recursive
but
where,
where
you
register
like,
if
you
read
register
multiple
like
resolve,
hooks
one
runs
and
then
like
returns,
its
result
to
your
other
registered
hoof,
which
returns
to
the
next
register
trip
and
so
on.
D
But
I
don't
know
if
that's,
if
anyone's
working
on
that
or
plans
to
work
on
that
I,
don't
know
what
any
other
you
know
intended:
design
changes
or
redesigns
that
anybody
wanted,
but
I
feel
like.
If
we're
gonna
do
kind
of
dramatic
changes
to
this,
we
should
kind
of
do
it
sooner
than
later
so
or
at
least
put
a
tissues
up
that
says
like
yeah.
D
C
Yeah
I
mean
it's
worth
considering
we
should.
If
we
want
to
think
along
those
lines,
maybe
we
should
consider
if,
if
the
API
was
the
one
would
be
breaking
or
anything
like
that
or
you
know
what
design
space
we
want
to
keep
open,
I'm,
not
sure
actually
I
mean
if
someone's
interested
in
driving
it.
It
sounds
like
it
could
be
done.
C
Yeah
I
suppose
we
should
maybe
go
back
to
use
cases
and
think
about
where,
where
did
where
the
need
is,
and
if
this
is
something
that
I
mean.
Ideally,
we
would
have
users
asking
us
for
these
features
and
then
it
could
be
sort
of
driven
by
by
user
interest.
I,
don't
know
how
much
feedback
we've
had
from
from
the
user
line
loaded.
So
far,
do
we
do
we
know
what
how
that's
going
and
how
much
people
are
wanting
loaded
composition.
At
this
point.
D
D
The
the
whole
wasm
thing
and
the
extension
this
files
we
were
talking
about,
maybe
not
inside
node
core,
but
if
we
wanted
to
provide
a
way
to
do
source
detection
in
order
to
get
the
type
right
now,
the
hooks
are
kind
of
in
a
set
order
where
you
have
to
define
the
format
before
you
get
the
source
or
you're
getting
source
twice
like
once
inside.
They
get
format,
hope
and
then
again
and
they
get
source
so
and
so
it
kind
of
works
against,
like
figuring
out
the
format
from
the
source.
D
But
it's
not
I,
don't
know
if
it's
something
we
necessarily
want
to
encourage.
So
there's
like
lots
of
little
things
like
that,
where
we
need
to
like
broaden
our
scope
of
what
are
the
other
use
cases
that
people
going
to
use
things
these
things
for
and
our
is.
It
is
the
current
design
painful
in
those,
and
we
need
to
make
changes
so.
B
B
It's
just
not
an
API
that
is
compatible
with
running
the
loader
another
threat.
Another
isolate,
and
the
second
thing
is
that
speaking
of
getting
format
and
then
loading
the
sauce
HTTP
loader
is
another
example
where
that
is
very
unfortunate,
because
you
have
to
respond
to
a
first
function,
call
to
get
the
content
type,
but
then
you
get
a
completely
different
API
call.
B
It
has
no
apparent
connection
to
the
first
one
to
get
the
contents
of
the
HTTP
resource,
so
you
need
to
either
make
the
HTTP
request
twice
once
for
the
headers
once
for
the
body
or
you
need
to
somehow
in
a
safe
manner
that
doesn't
leak.
Memory.
Keep
the
HTTP
response
around
between
two
separate
calls
to
two
different
sub
functions,
so
I
think
combining
get
format
and
get
source
would
be.
Something
would
make
a
lot
of
loaders
less
painful,
to
write.
In
my
opinion,.
D
Yeah
or
maybe
combining
them
some
of
the
time
or
something
like
that
like
have
it
be
optional,
whether
they're,
combined
or
not,
another
thing
would
be
like.
Could
it
be
where,
if
dynamic
instance,
if
there's
a
if
the
user
registers
a
hook
for
dynamic
instantiate,
then
you
know
it
all
happens
in
the
main
thread.
But
if
they
don't,
then
we
do
this.
You
know
split
out
into
worker
threads
stuff,
I.
B
B
D
Alright,
so
maybe
one
or
maybe
when
we
start
a
thread
with
the
specific
use
cases
that
are
painful
currently
and
then
we
can
talk
about
ways
to
improve
it.
The
only
thing
I
would
add
to
what
you
just
said
is
that
the
the
reason,
they're
split
into
more
atomic
bits
is
specifically
so
that
you
don't
need
to
like
re-implement
a
whole
lot
of
boilerplate,
like
that
was
the
problem
I
had
with
the
old
resolve,
so
I
just
want
to
override
little
bits
and
not
huge
swathes,
so
yeah.
D
B
I
think
the
one
thing
I
would
add
is
dynamic.
Instantiate
also
means
that
we
might
need
a
new
hook
and
somebody
would
have
to
drive
that
so
far.
We
only
know
that
people
would
not
like
us
to
remove
that.
Never
consent
she
ate
unless
there
is
something
that
you
can
run
in
the
normal
threads
in
the
main
threads
to
set
up
the
Global's.
B
B
A
D
A
A
D
Likely
really
I
think
that
that
issue
was
just
opened
like
a
year
or
two
ago,
long
before
we
had
the
hooks
kind
of
flushed
out
and
so
now
that
the
hooks
are
kind
of
closer
to
being
able
to
achieve
it.
We
can
kind
of
talk
about
it
in
the
context
of
the
hooks,
but
I
don't
think
it's
a
whole
separate
like
feature
and
stuff.
Is
it.
C
When
it
comes
to
patching
core
modules
and
having
custom
ways
of
doing
stuff
like
this,
from
for
the
SM
representations
of
these
modules
and
there's
and
exports
I
guess
actually
didn't
we
do
it.
We
pretty
definitely
but
but
patching
modules
is
something
that
has
to
be
considered
from
a
later
perspective
as
well.
I.
B
A
A
F
They're
a
little
different
insofar
as
when
we're
talking
about
loader
hooks,
we
have
like
a
concrete
design
and
goals
that
we're
looking
forward
to.
But
when
we
talk
about
like
B,
patching
and
instrumenting
and
module
use
cases,
we
don't
have
any
concrete
proposals
for
what
we're
gonna
do
to
enable
it
like.
We
don't
have
anything.
It's
like.
We
don't
have
a
proposal,
yet
we've
got
nothing.
A
A
Point
of
order,
sorry
we're
at
time
Wes.
Would
you
like
me
to
keep
the
agenda
label
on
there
for
now,
then
I
mean
probably
I
mean
okay,
distinct
enough.
Then,
then,
that's
all
that
matters
for
today
and
we
can
revisit
that
the
next
time
that
we
talk
about
it's
right
for
you
interrupting
everyone.
Do
we
have
a
pretty
hard
cut
so
with
that
we
did
not
get
time
to
get
to
discussing
removing
of
warnings.
Does
anyone
want
to
take
the
action
item
of
kicking
off
an
issue
to
discuss
that.