►
From YouTube: Node.js Foundation Modules Team Meeting 2019-08-14
Description
A
Now
live
with
the
August
14th
meeting
of
the
noches
modules
group.
We
have
eight
people
on
the
call
right
now.
I
think
we're
still
expecting
some
more
to
show
up
have
a
decently
full
agenda,
so
we'll
jump
right
into
it,
starting
with
number
twenty
eight
six
one.
Four
from
there
just
note.
Yes,
I'm
support
loading
data,
URLs
I
believe,
but
I
could
be
wrong.
That
Brad
is
one
of
the
leads
on
this.
Is
there
anyone
who
would
be
able
to
help
with
notes.
B
We
talked
about
this
last
meeting
with
data
uris
urls.
There
aren't
any
objections
to
it
on
the
PR
itself.
Currently
so
I
don't
know.
If
we're
wanting
to
wait
on
this
or
do
what
we
don't
have
quorum
here,
but
at
the
same
time
we
don't
have
a
moratorium.
I
am
just
trying
to
figure
out
if
we
can
go
ahead
with
this.
C
Yeah
we
talked
about
a
bit
last
week
in
a
bit
on
the
PR
I
guess:
I'm
I'm.
Still,
this
still
kind
of
feels
like
something
that
is
going
to
be
abused
more
than
it's
used,
and
that
is
being
added
like
like
the
the
benefits
of
adding
it
for
like
the
use
cases
that
can
only
be
achieved
with
this.
Our
minimal
they're
not
zero,
but
they
seem
minimal
to
me
and
the
justification
seems
to
be
well.
The
web
did
it.
So
let's
do
the
same
thing
and
there's
a
lot
of
decisions
on
the
web.
C
I
hope
no
doesn't
just
adopt
because
the
web
did
it
and
this
scene
kind
of
seems
to
be
one
of
them.
This
is
like,
like
Diddy,
your
eyes
were
originally
meant
for
assets
and
not
for
modules
and
they've,
been
they
work
in
modules
in
the
browser,
but
like
that
kind
of
seems,
to
have
fallen
out
of
the
way.
Daddy
Ora
is
work,
and
you
know
I
I,
guess
I
underst
I'm
not
clear
on
what
the
use
cases
are
when
you
have
a
file
system
like
in
the
browser.
C
A
F
Yeah
so
I
missed
last
meeting,
so
I'm
not
sure
if
we're
very
close
to
removing
the
flag
or
actually
decided
to
remove
it.
In
case
we
didn't,
it's
actually
helpful
to
see
the
uses
that
people
will
come
up
with
for
a
feature
like
this.
So
as
long
as
it's
flagged,
it's
good
to
actually
try
and
see
if
it's
gonna
be
abused
in
terms
of
interoperability.
F
If
you're
gonna
write
a
module
that
utilizes
theater
URLs
in
some
way
for
the
browsers,
it
helps
to
have
the
same
functionality
without
needing
to
circle
around
inconsistency
introduced
on
a
platform
basis,
because
that
will
force
you
to
avoid
static
specifiers,
which
would
actually
probably
result
into
in
an
overhead
that
you
don't
want
to.
You
know
introduce,
for
you
know
just
a
case
where
you
have
a
small
difference
between
how
you
have
like
sorry
and.
C
G
C
H
Yeah
I
was
also
just
gonna,
say,
like
the
word
security
stuck
in
my
head,
because
I
was
thinking
like
if
this
is
some.
If
the
code
you
want
to
run
is
sensitive
in
some
way
like
it
has
a
connection,
string
or
credentials
in
it
or
something
like
that,
you
might.
You
also
might
want
to
avoid
writing
such
code
to
the
file
system,
because
what,
if
your,
what
if
the
process
crashes
and
then
this
like
temp
file-
that's
not
supposed
to
be
permanent?
Is
there
sitting
on
the
file
system
for
other
processes
to
read?
H
H
A
So
actually.
D
C
G
It
is
because,
because
the
require
system
is
wide
open
to
all
kinds
of
hijinks,
you
can't
just
randomly
create
an
in
memory
module
and
link
it
into
the
module
grab.
As
you
want,
there's
no
no
boundaries
to
what
you
can
hack
into
it.
So
you
can
just
generate
a
module
from
string
because
nobody
stops
you
I'm
doing
it
sure.
C
But
then
you
don't
have
to
have
the
contacts
or
skoda,
then
you're,
not
availing
source
code
and
the
contents
of
the
source
code
aren't
the
key
like
the
specifier
for
your
module
so
that,
like
I,
don't
know
if
those
are
the
same
either
like
if
there
were,
we
were
just
talking
about
a
way
to
inject
a
runtime
like
module.
Namespace
object
under
a
specifier
I
think
that's
that's
a
different,
legitimate
thing,
but
like.
G
G
B
Require
is
file,
path,
based
file
paths
and
your
eyes
are
not
compatible
syntax
wise,
so
we
probably
can
never
get
required
to
have
absolute
URLs
in
it,
except
for
we
might
be
able
to
patch
in
like
what
we
do
with
the
file
system,
where
we
check,
if
it's
an
instance
of
a
URL,
but
that's
all
I
can
imagine,
I
mean.
A
C
For
what
it's
worth,
I'm
content
to
ship
it
behind
the
experimental
modules
flag
and
then
consider
in
the
future,
if
we
want
to
unflagged
the
whole
implementation
but
leave
certain
parts
of
it
behind
their
own
flags
as
long
as
that's
an
option
in
general
terms,
that
seems
that
I
don't
think
it
would
be.
I
mean
it
would
be
a
waste
of
effort
to
put
an
additional
like
data
URI
flag.
In
now,
for
example,
okay,.
B
C
A
I
will
just
say,
like
I:
don't
think
that
we
need
the
flag
independent
of
that,
though,
adding
the
flag
is
not
exorbitant
amount
of
effort.
Jordan
like
there's
a
whole
system
with
EndNote
core
to
handle
the
flags
and
I.
Personally.
Think
and
correct
me
if
I'm
wrong.
It
is
a
much
wieder
weirder
to
not
have
the
flag
right
now
and
then
introduce
the
flag
later
to
individuals,
so
my
preference
would
be
if
you
think
there
is
any
world
where
we
would
ever
add
the
flag
in
the
future.
A
C
I
mean
it's:
it's
more
that
I
as
an
on
collaborator
and
member
of
the
module's
group
I
have
no
ability
to
actually
stop
it
from
landing
and
sure
I
can
objective.
We
can
try
and
proceed
on
good
faith,
but
that
also
seems
silly
when,
like
I'm,
just
really
I'm
I
want
more
time
to
think
about
it
before
data
your
eyes,
land
in
the
unflagged
implementation,
but
like
so.
C
If
you
think
that
it
would
be
better
to
start
with
a
flag
now
and
then
to
ever
add
it
later,
then
maybe
we
should
start
with
the
flag
now,
but,
like
you
know,
but
you
know,
I
also
I
would
also
be
content
with
a
kind
of
good
faith
thing
of
like.
If
we
decide
we
don't
want
it
to
go
in
the
final
implementation,
then
we
can
remove
it
or
leave
it
behind
another
flag
or
something.
A
A
C
A
B
A
A
A
A
I
A
G
G
Domain
discussion
and
the
internal
remapping
or
imports
part
which
what
I
would
consider
the
tooth
pieces
that
I
want
to
have
consensus
on,
at
least
before
we
could
unflagged
exports,
which
also
means
that
is
realistic,
possible
to
inflect
exports
before
we
get
to
the
October
timeline
for
yes
modules.
So
we
could
actually
do
what
Jordan
at
some
point
suggested
that
we
could
I'm
flag
exports
earlier.
C
I
I
So
I
guessed
I
was
just
trying
to
clarify,
if
you
mean
removing
the
modules
flag
with
flag
exports
or
if
you
were
referring
directly
to
the
exports.
A
By
up
so
to
be
more
clear
if
we're
saying
that
exports
is
behind
a
flag,
it's
separate
from
modules
that
we
could
unflagging
land
exports
before
we've
unflagged
modules.
Would
it
can
be
considered
stable
or
experimental?
Because-
and
this
is
something
for
us
to
consider
with
ESM
as
well
and
I've-
talked
to
a
couple
members
of
the
TSC
and
there's
some
prior
art.
Here
we
can
remove
the
flag
before
LTS
for
ESM
without
actually
moving
ESM
itself
to
stable.
It
could
still
remain
experimental.
A
The
reason
why
this
ends
up
happening
and
historically
has
happened
with
like
http/2,
for
example,
was
that
even
though
it's
been
behind
a
flag,
it
has
not
had
tons
and
tons
of
usage,
so
we
very
well
may
find
edge
cases
or
things
that
are
problematic.
That
may
require
the
equivalent
of
assembler
major
change
that
we
may
be
required
to
land
well
in
LTS.
So
keeping
the
API
in
the
experimental
status,
by
like
kind
of
how
we
manage
December,
would
allow
us
to
make
those
changes
without
them
being
semver
major
Jordan.
You
of
your
hand
up.
C
Yeah
I
think
there's
a
huge
difference
between
functionality
that
only
affects
the
people
using
it
like
core
modules
and
ESM,
which
will
affect
the
entire
graph
and
I.
Don't
think
it
makes
any
any
if
we're
unflagging
it
it's
stable
like,
even
if
we
want
to
consider
it
experimental
like
like
that.
That's
just
that's
when
everyone's
gonna
start
using
it
and
so
I
think
that
the
the
bard
isn't
really
for
me.
F
Guess
the
clarification
about
like
exports
being
ready
for
CJ
s?
Are
we
saying
that
even
if
ESM
his
flag
we'll
be
able
to
just
use
a
flag
to
get
exports
working
with
CJ
s,
and
then
are
we
actually
saying
that
we're
gonna
remove
the
flag
and
then
it
can
be
used
with
CJ
s
without
ESM
flag
being
like
a
variable
at
all?
Yes,
okay,
thanks.
D
G
That,
after
I'm,
flagging
exports
should
be
experimental
is
because
exports
is
an
ecosystem
change
and,
if
note
is
the
only
runtime,
only
consumer
package,
Jason's
metadata,
that
has
infinite
export
support.
It
feels
like
jumping
the
gun
to
say
it's
stable,
because
we
might
get
very
important
implemented
feedback
from
bunless,
for
example,
which
might
change
some
elements
of
the
API
I
agree
with
Jordan
that
once
it's
out
there
and
people
start
publishing
packages
using
it.
G
A
Thing
to
add
also
Jordan.
We
can
still
have
the
experimental
warning
in
the
console
when
you
use
the
feature,
and
that
is
what
each
to
be
treated
right
now
you
have
like
FS
promises,
for
example,
is
still
experimental,
it's
not
behind
a
flag,
but
there
is
a
very,
very
clear
warning
when
people
use
it
I've
personally,.
A
With
calling
these
things
stable
before
they've
really
had
usage,
and
especially
with
the
way
that
our
LTS
works,
you
shame
to
lock
in
an
incompatible
version
of
a
new
ecosystem
feature
for
three
years.
If
the
changes
are
minor
from
an
inconvenience
perspective,
but
major
from
a
semantic
versioning
perspective.
So.
C
To
be
clear,
what
I
was
talking
about
was
unflagging.
Yes,
em
I
think
that
it's
I
don't
actually
care.
If
we
unflagged
exports
for
CJ
s
and
then
market
is
experimental,
because
what
what
I
want
is
to
be
eyes
wide
open
about
is
that
once
it
is
unflagged,
no
matter
whether
we
aspirationally
market
is
experimental
or
not,
we
may
find
ourselves
unable
to
suffer
the
breakage.
You
know
to
endure
the
breakage
of
making
many.
C
You
know
many
kinds
of
changes,
so
I'm
fine
with
calling
it
experimental,
but
we
should
all
kind
of
have
an
understanding
amongst
ourselves
that
were
risking
it
being
stable,
as
is
based
on
usage.
As
far
as
experimentation
with
bundlers
and
stuff
I
mean
we
all
have
the
we
either
have
the
expertise
or
the
direct
connections
to
get
that
those
changes
test
it
out.
I
can
implement
support
for
exports
in
resolve
in
like
less
than
a
day
and
like
I'm,
sure
webpack
will
add
it.
C
C
So
there's
like
there's
like
lots
of
ways
we
can
get
that
the
ecosystem
prepared
for
the
unflagging
as
long
as
we're
kind
of
saying
that,
pending
feedback
from
those
tools,
those
kinds
of
tools,
we're
gonna,
unclog
it
and
CJ
as
soon
I-
see
no
reason
why
those
tools,
some
of
which
I
maintain,
wouldn't
be
willing
to
adopt
it
again,
I'm
fine,
if
we
call
it
experimental,
we
just
need
to
accept
that
it
probably
is
stable.
You
know,
or
it's
frozen
because
of
usage.
Well.
A
And
that's
exactly
what
we're
committing
to,
in
my
personal
opinion,
by
removing
the
flag,
I
think
by
keeping
the
experimental
status
and
continuing
to
give
a
warning.
What
we
do
is
we
are
Ford
ourselves
as
a
flexibility
if
we
need
to
because
even
something
just
like
changing
an
error
like
not
the
technique
like
the
way
that
we
just
realize
that
hey
these
errors
are
inconsistent.
That
would
be
some
ver
major
if
we
weren't.
If
we
remove
the
flag
and
yeah.
A
C
The
other
thing
I
wanted
to
point
out
with
warnings
is
that,
with
all
the
other
things
you
mentioned,
you're
using
them,
and
so
you
get
a
warning
about
using
them
and
yeah.
Eventually,
your
downstream
consumers
maybe
get
the
warnings
too,
but
in
the
case
of
exports
you're
not
using
it.
So
you
might
never
see
the
warning
until
your
consumers
install
your
package,
so
I'm
not
sure
if
that's
like
that's
completely
in
actionable,
basically
so
I'm,
not
sure.
A
C
G
Okay,
yeah,
you
know
that
is
for
me
one
of
the
minor
issues
that
I
forgot
to
mention
I.
Think
it's
not!
Okay,
that
you
can't.
You
know,
taste
exports
in
the
package
itself,
so
I
think
it's
something
that
we
need
to
fix
that
you
would
see
that
warning,
because
you
would
actually
use
exports
new
unit
tests.
C
That's
a
really
good
separate
point.
Like
the
there's.
The
package
maintenance
group
has
talked
a
lot
about
how
they're,
just
there
simply
is
no
organ.
Amma
Quay
to
test
your
package
as
published
like
to
test
the
NPM
pack
out
put
or
to
like
you
know,
think
things
like
that.
Even
almost
nobody
runs
tests
against
their
build
output,
I've
done
it
in
a
few
packages
and
it's
a
huge
pain
in
the
ass.
So
like
it's
useful
to
think
about,
I
think
how
people
will
test
this
and
it's
a
really
good
point.
G
Is
actually
working
on
that
with
hustle?
Maybe
the
the
current
proposal
is
to
basically
say
you
use
the
specify
a
tilde.
It
refers
to
the
current
package,
know
the
slowing
that
would
go
through
exports
yeah
until
the
snapper
crack
expose
as
well.
So
you
would
have
a
way
to
require
yourself
or
import
yourself.
G
A
A
That
I'm
thinking
of
that
is
like
with
the
way
that
require
works
right
now,
like
if
you're
in
the
test
directory.
Sometimes
you
would
do
like
required
dot
dot,
slash
to
require
in
the
root
of
your
module
to
like
get
what
you
would
get
from
the
name,
but
like
in
theory,
should
you
only
then
be
able
to
get
the
things
that
are
in
the
exports
if
you're
requiring
yourself
yeah.
A
D
G
A
G
C
No,
no
people
think
it
does
and
then
their
stuff
doesn't
work,
and
then
they
stopped
doing
that
pattern.
So
actually
tilde
is
one
of
the
more
common
choices
for
a
Babel
or
web
pack
or
similar
alias
to
requiring
from
yourself
or
importing
from
yourself.
I.
Think.
That's
also
an
amazing
feature.
It's.
C
What
and
I
also
want
to
point
out
that,
if
we
specify
if
we
specify
that
the
semantics
of
tilde
is
that
it
goes
through
exports,
then
I
would
write
all
of
my
unit
tests
for
my
external
files,
with
tilled
importing
from
tilled
and
all
of
my
unit
tests
for
my
internal
files,
using
the
dot,
dots
and
then
I've
also
clearly
made
you
know
it
differentiated
my
tests
of
the
external
interface
from
my
tests
of
the
internals.
That
actually
sounds
really
cool.
C
Another
thing
that
we
might
want
to
consider
if
the
files
property
is
in
fact,
package.json
and
you
use
tilled,
and
that
file
is
not
in
the
list.
Maybe
we
could
also
make
that
fail,
because
one
of
the
the
reason
the
files
property
is
dangerous
and
terrible
and
like
even
though
npm
recommends
that
people
make
pause
bugs
all
the
time
with
it
is
because
they
forget
to
add
things
into
their
whitelist
or
their
include
lists
and
like
being
able
to
write
tests.
That
will
fail
on
yourself
when
you
forgot
to
add
something
to
the
files
list.
C
G
A
Kind
of
stepping
back
for
a
second
action
items
here
and
making
sure
were
on
the
same
page.
It
seems
like
people
are
okay
with
Pat,
with
exports
having
the
flag
removed,
while
maintaining
an
experimental
status
in
core
separate
from
the
es
modules
flag
is.
Does
anyone
object
to
that
great?
So
we
can
move
forward
with
that.
We
keep
it
with
the
experimental
flag.
We
could
separately
dig
into
what
we
want
to
do
for
ESM
itself.
Although
I
do
think
a
similar
approach
would
be
good,
but
that's
a
different
agenda
topic.
A
H
C
A
A
Okay,
I'm
hearing
no
objection,
so
we
can
update
that
and
then
maybe
update
it
from
saying
name
to
tilde
and
then
I'm
not
hearing
any
one
right
now
volunteer
to
help
with
the
implementation
on
that.
But
we
can
you
know
someone
volunteer,
will
figure
that
out
cool.
Did
we
miss
anything
within
that
discussion.
A
No
so
Darcy
just
posted
a
link
to
number
306,
which
is
guys
issue
about
it,
I'm
going
to
go
ahead
and
throw
the
modules
agenda
label
on
that.
We
can
revisit
this
in
two
weeks.
That
way,
you
know,
if
nothing's
moved,
we
can
figure
out
how
to
keep
it
going
Darcy
thanks
for
dropping
that
link.
Okay.
So
next
and
last
on
the
agenda,
we
have
loader
hooks,
which
is
issue
number
351,
Brad
guy
yan.
B
Can
I
won't
be
able
to
help
for
notes
as
much
though
well,
so
we
have
a
lot
of
comments
both
in
github
and
on
the
design
document
itself.
Not
too
much
has
changed
since
last
meeting
homeless,
but
we
have
started
adding
success
criteria
through
examples
for
API
designs
and
it
looks
like
we
need
to
sync
up
about
changing
the
hooks
in
general.
In
a
variety
of
ways,
there
have
been
a
lot
of
suggestions
and
different
directions
from
those
comments.
It
seems
like
there's
a
general
feeling
that
we
should
split
up
the
hooks
somewhat.
B
So
there's
a
few
ideas
on
what
the
actual
divide
should
be,
but
it
seems
at
least
there
is
a
fairly
consistent
overall
feeling
that,
having
resolved
return
and
location
and
having
a
separate
fetch,
look
that
can
convert
a
location
into
a
module
record
or
a
resource
for
a
module
record
is
an
approach
that
is
being
talked
about.
So
we
probably
want
to
figure
out
how
we
want
to
split
that
and
start
moving
on
it.
B
There
are
still
some
questions
about
how
loaders
should
define
their
format.
Currently,
the
design
document
has
a
mime
as
what
it's
using
to
determine
format.
Our
current
loaders
are
using
a
string,
enum
and
there's
some
contention
on
both
ends
on
which
should
be
used.
I
think
that
is
something
that
we're
probably
going
to
have
to
just
agree
upon
here
and
can
reach
consensus
on.
I
No
I
mean
I
know.
The
thread
on
the
latest
discussion
looks
did
but
actually
I
think
we
a
lot
of
agreement
on
things.
I,
don't
think
there
is
that
much
contention
here,
I
think
the
the
biggest
thing
I
just
wanted
from
a
usability
point
of
view.
For
for
this
composition,
models
was
was
separating
the
Herc's
and
I'm
really
happy
to
see
the
week,
and
we
can
look
at
those
designs
for
the
for
the
mime
stuff
faith.
I
It's
just
usability
concerns,
but
it
like
it
feels
like
it
is
stuff
at
some
level.
I
am
a
little
bit
concerned
that,
for
example,
we
don't
have
a
well-defined
mime
type
for
what
about
a
node
built
in
would
be
or
what
a
node
file
would
be.
We
sort
of
have
to
come
up
with
something
for
these
cases.
That
may
seem
somewhat
contrived
Gus.
Do
you
say
we
do
have
a
donate
mime
type.
B
B
Built-Ins,
basically
so
I
added
an
example
in
there
may.
This
may
not
cover
what
people
are
trying
to
do.
So
it
would
be
good
just
to
get
confirmation
that
this
doesn't
have
any
education
missing,
but
basically
the
contrived
example
is
adding
to
instrumentations
two
FS
read
file
sync
and
those
are
going
to
be
one
adding
a
console
that
time
and
that
time
end
around
invocation
of
it
and
the
other
adding
an
invocation
count
logged
whenever
read
file.
Sync,
it's
called.
If
you
have
two
loaders
doing
this,
it's
actually
fairly
hard
to
build
right.
B
There
are
some
ideas
thrown
around
guy
showed
me
an
interesting
idea
of
using
import
meta
to
kind
of
pre
inject
other
module
namespaces
so
that
they
can
be
used
without
a
bunch
of
redirection
or
source
code,
rewriting
I
I.
Think
we
just
kind
of
this
is
one
of
the
harder
solves
another
built
in
success
example.
We
have
is
basically
the
no
loader
which
is
basically
just
a
loader
that
prevents
loading,
something
and
the
example
you
need
to
prove
on
that.
One
is
preventing
loading.
Fs
HTTP
is
another
one.
You
can
imagine
how
that
works.
B
Synthetic
module,
loader
synthetic
modules
are
going
to
be
modules
created
from
stuff
in
memory
a
transpiler
loader,
a
transpiler
loader
is
different
from
a
synthetic
module
loader.
This
is
the
success
criteria.
Here
actually
includes
the
ability
to
have
a
custom
format
sent
through
the
loader
pipeline,
so
yep.
B
B
Yep,
are
there
specific
use
cases
that
we
need
to
add
for
the
success
criteria
that
people
are
wanting
to
see
for
specific
things?
They
need
shown
that
the
implementation
can
do
so.
Some
of
the
talks
have
been
about
concerns
of
either
isolation
or
head-of-line,
blocking
where
one
loader
can
essentially
block
all
loading
from
occurring
anywhere.
B
A
H
B
B
H
Is
I'm
just
thinking
of
like
NPM
start
scripts
running
things
through
other
environments
like
running
things
in
via
docker,
like
being
able
to
send
an
app
to
someone
else,
and
they
know
what
to
do
I
mean
yeah.
They
could
be
part
of
like
an
NPM
start
command
or
something
like
that,
but
I'm,
just
thinking
of
other
other
ways
to
start
apps
like
running
through
the
command
gest
running
through
the
command
meteor.
Like
you
know
you
you
don't
always
right,
you
don't
always
run
a
note
app,
starting
with
the
word
node
on
it.
H
A
So
I,
just
as
a
heads
up
I
just
wanted
to
say:
I
edited
the
original
post
in
the
loader
hooks
issue
and
just
added
a
link
to
the
design
dock.
To
make
it
easy
to
find
I
have
not
had
a
chance
to
extensively
review
it,
yet
so
I
won't
take
in
too
much
on
these,
but
just
in
case
they're
not
included,
like
some
examples.
That
I
think
would
be
really
good.
A
B
Yes,
but
that
would
not
help
them
with
the
SM
itself,
so
they're
using
the
fact
that
nodes,
common
jeaious
implementation
doesn't
have
a
robust,
a
file
system
call
and
so
they're
monkey
patching
internals
that
we
don't
guarantee
we'll
continue
working.
We
don't
have
any
example
of
providing
functionality.
They
would
allow
them
a
supported
path
in
the
future.
In
this,
so.
A
That's
one
that
I
would
love
to
see
like,
obviously
they
have
their
solution
to
this
base
right
now,
the
kind
of
hoop
we
went
back
to
first
first
principles
and
Darcy
says-
may
be
synthetic
loaders
could
help
with
that.
But
I
would
love
to
see
at
the
very
least,
one
of
them
aligned
explicitly
kind
of
solving
that
problem
space.
A
Whatever
the
solution
is
the
other
one,
and
you
can
tell
me
if,
if
you
have
something
there
is
the
APM
case
where
you
know
you
need
to
intercept
loading
of
built-ins
and
maybe
change
the
built-ins
themselves
or,
alternatively,
like
something
that
allows
like
programmatic
instrumentation.
It
sounds
like
the
timer
one
that
you
were
working
on
is
aligned
with
that,
but
I
just
wanted
to
make
sure
that
you
know
the
APM
case
is
explicitly
aligned
with
with
one
of
the
examples
we
have.
Yes,.
D
D
B
A
F
I
just
wanted
to
recap
on
the
splitting
resolve
just
making
it
two
separate
operations.
I've
been
thinking
of
that
and
I
believe
locating
and
resolution
resolution
could
be
scoped
to
package
scope
or
some
abstraction
of
scopes,
but
location
could
be
mapping
per
a
round
or
per
context.
A
particular
scope
to
a
particular
location
I
have
more
details
on
those
thoughts,
but
I
just
wanted
to
get
some
quick
insights.
I
It's
just
a
really
interesting
points
to
here
with
the
caching
stuff.
It
would
be
interesting
to
understand
what
what
models
of
proposals
might
be
able
to
capture
that
I
mean
there's
no
reason
not
to
kick
them
push
the
net
out
as
far
as
we
can
in
the
design
phase
here.
So
now,
it's
the
time
to
think
of
these
things,
and
and
similarly
with
the
FS
injection
stuff.
I
One
of
the
things
is
it's
a
little
bit
like
doing
keyhole
surgery
in
this
modal
model,
because
the
look
is
running
on
a
separate,
a
separate
room
or
a
separate
context.
So
we're
we're
dealing
with
the
fact
that
you,
the
only
way
that
you
can
run
code
to
instrument
FS,
is,
is
providing
source.
That's
going
to
execute
against
FS.
So
when
you
want
multiple
things
to
run
code,
that's
going
to
instrument
it's
it's
almost
just
like
yeah
loading,
a
polyfill,
jeaious
or
something
and
injecting
the
environment.