►
From YouTube: Node.js Foundation Modules Team Meeting 2019-12-18
Description
A
We're
now
live
on
YouTube
with
the
December
18th
meeting
of
the
node.js
modules
team,
I'm
joined
by
seven
other
individuals
and
we
have
a
pretty
full
agenda.
So,
let's
jump
right
into
it.
The
first
item
we
have
on
the
agenda
is
conditional
exports
using
naming
usability
discussion
guy.
Do
you
want
to
pick
that
one
up
since
it's
your
pull
request.
B
A
very
brief
description
in
the
name
of
keeping
the
time
boxes
to
a
minimum
unit
today
as
well.
So
we've
had
a
lot
of
discussion
around
named
exports
and
the
conditional
exports
proposal
and
we've
been
ironing
out
the
usability
on
on
these
on
these
cases,
trying
to
get
as
much
feedback
as
possible
and
share
with
as
many
people
as
possible
and
through
various
discussions.
I
think
this.
B
A
B
B
Now
that
we
have
require
an
import
which
are
both
on
the
same
footing
from
a
priority
perspective
and
and
they're
perfectly
mutually
exclusive,
so
default
isn't
mutually
exclusive
with
require,
which
is
why
this
this
ordering
mattered
so
much
now
that
we
have
mutually
exclusive
items
when
we
look
at
the
scaling
of
exports
conditions.
So,
for
example,
if
you
want
to
add
a
production
condition
or
allow
users
to
add
their
own
conditions
or
if
build
tools
want
to
add
their
own
conditions.
B
As
this
list
of
names
grows
and
as
we
started
to
flesh
out
some
cases
around
that
it
becomes
clear
that
it
starts
to
get
a
little
bit
confusing
what
matches
in
what
order.
So,
if
I
have
like
browser
production,
electron,
node
years
2019
and
all
these
conditions
say
if
you're,
an
electron
and
you're
gonna
match
four
of
those
conditions,
you
have
no
idea
which
one
is
going
to
be
matched
because
they
all
correspond
to
your
environment
potentially
and
there's
this
invisible
priority
order
in
the
resolver
itself.
B
B
We
can
bring
that
control
the
records
of
the
users
by
using
the
well-defined
object
order
that
we
can
rely
on
now
in
JavaScript
as
of
years
2015
as
it
was.
So
if
something
comes
first
in
the
list,
it'll
match
it.
If
it,
if
it's
a
valid
condition
and
if
doesn't
it'll
move
on
to
the
next
item
in
the
list
and
the
other
thing
that
this
PR
does
is
it
allows
falling
back.
B
So
if
the
match
corresponds
to
an
invalid
target,
so
you
have
like
the
match
and
then
:
and
you
have
an
empty
array
or
something
it'll
then
try
the
next
match
in
the
list.
It
won't
just
fail
and
say:
I
match
this
thing
that
that's
invalid.
We're
now
going
to
throw
your
entire
resolution,
because
this
item
that
came
first
in
the
priority
order
is
not
a
valid
target
and
that
allows
some
nicer
chaining.
So
basically,
Tobias
had
a
very
very
nice
example
of
you
can
now
think
of
it
like
if
statements.
B
So
you
can
imagine
that
it's
like,
if
condition,
try
thing
and
if
it's,
if
the
thing
is
invalid,
it'll
it'll,
move
on
to
the
next
condition
and
there's
a
4-3
that
happens
now
as
well
and
as
as
a
programmer
he's
used
to
writing
lots
of
if
statements
I
mean.
Of
course,
we
don't
encourage
lots
of
if
statements
in
our
code
as
a
general
rule
but
as
as
this
kind
of
logic
is
naturally
branching
for
it
to
naturally
match
the
same
semantics
of
of
branch.
B
C
Sure
so
I
noted
on
the
issue
that
Jason
doesn't
actually
assert
a
specific
ordering
I've
been
trying
to
look
into
a
variety
of
potential
concerns.
We've
had
well
I've
had
in
the
past,
with
this
I'm
in
particularly
concerned
that
there
are
a
variety
of
packaged
utilities
out
there
that
sort
your
package.json
automatically
by
well.
Well,
they
sort
the
keys
alphabetically
basically,
and
so
that
is
something
we
need
to
be
aware
of
also
other
languages.
A
lot
of
the
very
popular.
C
D
C
A
So
I'll
go
quickly
in
the
neon.
The
big
thing
for
the
ordering
that
I
saw
in
the
thread
was
that
any
keys
that
have
numbers
could
significantly
cause
issues
with
ordering
so
I
think
one
of
the
things
that
was
discussed
there
was
just
you
know
not
allowing
he's
that
start
with
numbers
seems
like
a
reasonably
SH
condition,
but
just
want
to
like
throw
that
out
there
to
the
group
that
that
would
be
one
of
the
limitations
of
doing
this
form
of
ordering
yan
to
you.
Yeah.
E
A
C
D
Just
hand
on
this,
but
if
I
could
add
one
thing,
I
agree
with
Brad
on
that
I
feel
like
they're,
probably
not
gonna
sort
in
the
child
Keys.
That
would
be
what
I
would
be
curious
to
see.
If
anyone
does
that
research,
the
other
thing
I
was
just
thinking.
I
was
like
even
if
the
oddball
tool
here
there
or
library
does
reorder
them
or
whatever
I
guess.
D
The
question
is
whether
that
would
be
preferable
to
like
you
know
this
current
magic
order
that
is
defined
in
the
resolver
because,
like
you
know
like,
if
there
is
some
library
like
c-sharp
or
whatever,
where
it
doesn't
preserve
the
order,
then
it's
really
no
different
than
what
is
now
we're
in
that
c-sharp
environment.
You
have
to
like
reimplemented
of
the
of
whatever
order
our
resolver
wants
to
pull
them
in.
So
you
know
it's,
it's
not
really
any
like
I.
D
C
C
We
could
just
say
it's
alphabetically
sorted
if
it's
problematic
it
wouldn't
be
in
the
order
of
your
package.json
source
text,
but
at
least
it
would
be
a
reliable
order,
so
people
could
reliably
figure
out
things.
So
I
think
it
might
not
harm
other
environments.
This
current
behavior,
but
if
tools
are
relying
on
ordering
being
alphabetized
double,
we
could
have
problems.
That's.
A
G
Yeah
so
JSON,
the
nice
thing
is
it's
a
string.
So
if
you
want
to
implement
some
sort
of
a
small
patch
to
basically
run
the
string
and
determine
the
order
after
you
use
whatever
like
parsing
library,
you're
using
elsewhere,
so
I
think
there
are
easy
ways
to
rely
on
the
string
to
close
that
gap
in
these
tools.
That's
that's
my
things.
B
Okay,
so
yeah
I
mean
these
are
the
two
things
that
I
feel
are
kind
of.
The
outstanding
usability
changes
that
I
would
like
to
make
before
before
shipping
exports
and
self
resolved
the
outcomes
result.
Is
we
had
a
couple
of
bugs
it's
a
PR
to
fix
those
bugs?
This
is
three
one:
zero,
zero,
nine
and,
in
addition
to
fixing
the
two
bugs
it
also.
B
Hits
up
across
this
compatibility
concern
between
es
modules
and
common
Jess
when
it
comes
to
the
self
resolved
and-
and
the
argument
for
this
is
the
following.
If
we
add
a
khadeem
resolution
to
common
jeaious,
that
is
theoretically
a
breaking
change,
because
lots
of
packages
can
have
a
node
modules,
folder
or
lots
of
users
already
use
noted
a
can
have
a
modules
folder
with
the
name
of
their
package,
in
that
big
modules,
folder
and
maybe
they're
running,
like
the
current
stable
version
against
the
development
version.
That
way.
B
There's
various
patterns
like
that,
if
we
just
shift
the
self
resolve
that
then
intercepts
that
mode
modules
look
up
and
instead
says
no.
If
you're
importing
your
own
name,
you're
gonna
get
your
own
package,
then
we
could
potentially
that's
a
major
change
and
we
could
potentially
breaking
common
J's
resolver.
B
For
that
reason,
when
Yan
implemented
the
self
resolved
PR,
he
made
sure
that
this
applies
after
doing
the
node
modules.
Look
up
so
it'll
do
all
your
node
modules
checks
and
see
if
that
package
exists
in
those
modules
all
the
way
up
to
the
bottom,
and
only
when
it's
gonna
get
to
the
point
where
it'll
say
we
didn't
find
this.
It's
require
for
the
name
of
your
package.
Now
we're
gonna
use
that
name.
B
This
all
fits
all
and
my
concern
with
having
that
same
behavior
implemented
for
years
modules
is
it's
taking
a
legacy,
compatibility
concerning
and
pushing
it
forward
into
the
indefinite
future
and
I
think
it
would
be
nicer
to
have
a
better
encapsulation
for
sulfurs
all
where
you
can
know.
If
there's
a
name
required,
it
will
always
as
a
rule,
there's
no
exceptions.
B
It
will
always
load
a
local
package
and
for
that
to
be,
but
if
there's
something
in
node
module
somewhere
up
on
the
file
system
that
can
override
it,
I
feel
there's
a
weaker
feature
and
and
we'll
introduce
friction
into
tooling
we're
closed
so
that
this
PR
tries
to
make
them
work
differently,
and
it
says
common
gist
will
have
the
compatibility
behavior.
These
modules
will
have
the
guaranteed
encapsulated
behavior.
E
Quick
comment,
so
one
other
thing
that
we
had
in
the
past
as
a
problem
of
self
resolved
was
the
potential
import
map
import
map
load,
where
every
single
package
needs
to
offensively
declare
all
the
exports.
Also,
in
the
scope
of
the
package
itself,
we
have
discussed
having
some
sort
of
opt-in
in
the
text
racing,
whether
it's
the
exports
field
or
new
field
that
says
hey
I,
do
want
to
have
self
resolved,
which
would
enable
the
feature,
but
also
would
make
it
most
likely
save
to
for
both
come
ingest
and
ESM.
A
So
I
thought
that
I
have
on
this
personally,
like
we
did
do
a
bunch
of
work
to
make
the
resolving
algorithm
between
common
J
s
and
ESM
identical,
and
this
feels
not
in
line
with
that.
I
know
that
we
had
discussed
introducing
a
sigil
and
a
sigil
seems
like
a
good
shorthand
to
say:
hey
load
me
first,
especially
if
it's
a
sigil
that
can't
be
used
anywhere
else
essential
is
also
one
of
those
things
that
could
be
an
additive
change
in
the
future.
So
we
don't
even
really
need
to
land
on
consensus
around
them.
B
A
A
A
H
H
D
Geoffrey
so
I
liked
what
Yann
had
suggested
that
like
we
could
treat
something
in
the
package
of
Jason
as
a
way
to
opt
in
to
this
feature.
Like
say,
if
your
package
ace-
and
it
has
to
have
say,
the
exports
filled
with
something
defined
in
exports
to
enable
this,
and
then
that
I
think
I
hope
gets
us
out
of
the
backward
compatibility
concerns,
but
then
lets
this
feature
behave.
The
way
guy
wants
it
to
where
it
behaves
the
same
income
and
Jess
and
ESM
it's
at
that
point.
D
A
Let's
hear
from
guy,
and
then
we
can
see
if
we
can
reach
an
agreement
on
this.
Well,
let's,
let's
find
out
what
the
consensus
system
I
personally
feel
more
comfortable.
If
we
say
that
self
resolve
is
something
that
only
turns
on
when
you
use
exports,
and
if
we
did
that,
then
it
feels
less
like
a
cember,
major
change
and
more
like
a
feature,
although
I'd
probably
need
to
spend
a
little
bit
more
time.
A
A
B
There
is
still
further
stability
might
include
things
like
refining
error
messages,
validations
and
then
we
do
also
have
the
imports
feature
in
the
package.json,
which
is
in
Yuans
original
spec
for
exports
and
imports.
That
is
something
we
could
consider
as
well
or
it's
something
we
could
consider
adding
later
on.
As
part
of
the
future
result
of
features,
one
benefit
of
self
resolve.
B
It
does
allow
packages
to
self
resolve
additional
within
themselves,
because
if
you
can
resolve
your
own
exports
and
your
own
exports
out
conditions,
you
can
resolve
your
own
conditions
that
they
must
be
public
conditions,
so
imports
allows
us
to
have
private
conditions
in
which
maybe
that's
important.
Maybe
it's
not
I'm,
not
sure.
It's
not
right.
Now
we're
not
prioritizing
that.
A
A
A
Wes
is
asking
to
defer
a
few
minutes,
so
let's
talk
about
the
unflagging
stuff.
First
then,
and
we
can
get
back
to
this,
so
we
have
unflagging
experimental
self
and
unflagging
conditional
exports
and
unflagging
on
dsm
is
three
different
issues.
Maybe
we
can
get
through
some
of
these
pretty
quickly.
I'll
start
with
unflagging
on
12,
because
I
want
to
just
propose
something,
and
if
people
see
it
as
non-controversial,
we
can
just
kind
of
move
forward.
A
A
Alternatively,
we
can
change
this
plan
if
we
have
changes
to
release
schedule,
but
assuming
that
both
conditional
exports
in
named
exports
land
in
January,
the
plan
would
be
to
back
board
everything
in
January
and
I.
Think
we
could
back
board
everything
in
January
to
twelve
independent
of
what
decisions
we've
made.
The
main
thing
that's
been
blocking.
The
back
port
has
been
that
the
878
has
not
been
on
12
yet
so
we
would
have
to
unroll
a
bunch
of
the
refactoring
that
we
did
on
top
of
synthetic
modules.
A
A
D
A
A
But
in
general,
and
we
had
prior
art
with
HTTP
to
api's
that
are
marked
as
experimental
can
receive
semver
major
changes.
We
would
likely
for
LTS
back
Porthos
in
December
minor
rather
than
a
patch
other.
We
could
arguably
land
it
in
either
behind
a
flag.
It's
very
easy
to
land
all
these
things
when
it's
not
behind
a
flag.
It
requires
a
little
bit
more
discussion.
The
only
thing
that
we
would
not
be
able
to
do
in
a
back
port-
or
you
know
even
on
13-
would
be
semper
major
changes
to
stable
api's.
A
D
A
Cool
so
since
it
seems
like
we
have
general
consensus
on
that
I'm
willing
to
take
on
you
know
at
least
the
first
pass
of
getting
those
back
ports
together
and
then
I'll
pull
people
in
as
I
stumble.
The
next
two
that
we've
got
here
is
unfair.
Flagging
a
conditional
exports
and
unflagging
resolve
self
I
think
hey
Wes.
How
are
you
doing
for
time
right
now?
Are
you
able
to
talk
about
require
ESM
at
the
moment.
A
Not
seeing
a
response
yet
because
I
feel
he's
still
in
the
BA
bus
okay.
So
let's
talk
about
experimental
self
first,
because
I
feel
like
conditional
exports.
What
we
can
even
just
say,
like
I,
think
that
if
we
do
not
have
consensus
on
moving
forward
with
required
ESM
by
early
January,
which
was
around
the
time
that
we
talked
about
that,
we
you
know,
should
look
at
unflagging
conditional
exports.
A
Obviously
that
is
slightly
dependent
on
the
conversation
that
we're
about
to
have,
but
especially
with
the
dates
that
we're
looking
at
for
LTS
I
would
like
us
to
unflagging
a
week
or
two
before
the
LTS
ember
minor.
So
we
have
time
to
you,
know
back
port
it
there's
anyone
have
any
concerns
with
that.
As
a
timeline.
A
Okay,
I'm
not
seeing
it
concerns
and
I'd
say
similarly
for
resolve
self.
Obviously
we
have
a
couple
things
that
we
need
to
work
through
on
that
before
I
can
land
that
we're
identified
today,
but
you
know
I
think
a
similar
timeline,
but
potentially
earlier.
If
we
can
reach
stability
for
unflagging
resolved
self,
does
anybody
see
any
concerns
with
that
I.
D
A
D
A
If
I
look
at
the
schedule
right
now
me
one
second,
the
current
release
plan
for
12
was
expecting
12.30
know,
but
it
didn't
and
then
it
was
expecting
December
minor
to
go
out
on
the
21st.
So
that's
where
we
came
up
with
the
date
of
the
seventh.
My
guess
is
that
both
of
these
dates
are
going
to
be
pushed
out
a
week,
possibly
two,
and
so
you
know,
whichever
one
we
do.
D
Okay,
just
to
try
to
maybe
like
speak
for
Wes
a
little
bit
before
he
gets
on
I
was
thinking
that
this
is
why
I
was
asking
about
the
deadlines.
Was
that
like
so
we
sort
of
have
two
deadlines?
January
and
April
like
it
doesn't
I,
think
I
think
we'd
all
agree
that
require
require
BSM
doesn't
seem
likely
to
land
before
the
January
deadline.
I
guess,
there's,
there's
potentially
some
chance
that,
like
all
the
issues
could
get
worked
out
by
the
April
deadline.
D
A
A
Yes,
if
we're
hoping
to
get
things
back
ported
into
the
LTS
release,
it
seems
like
January.
8Th
is
a
prudent
date
for
us
to
maybe
meet
and
see
where
things
at
Wes
is
commenting
in
the
chat
right
now
saying
that
he's
working
on
a
simpler
variant
of
it
that
could
be
likely
to
land
before
January
I'm
sure
he'll
tell
us
a
little
bit
more
about
it
once
we're.
There
is
everybody
on
the
call
right
now
available
at
the
same
time
that
we
usually
meet
a
week
early
on
January,
8th.
A
C
Brad
sure
I
can
just
do
a
tiny
bit
of
an
update,
so
Jeff
introduced
a
new
couple
of
hooks
that
we
haven't
really
discussed
before
there's
a
PR
on
the
repo.
You
should
go.
Look
at
it
right
now.
This
is
so
far
being
framed
as
an
additive
change.
We
have
had
discussions
previously
of
doing
bigger
reef
actors.
I,
don't
think
we
are
aiming
to
do
those
currently,
but
so
look
at
this
PR
as
an
additive
thing
not
blocking
a
refactor
in
the
future.
A
I
Right
so
the
first
PR
that
I
put
up
was,
in
my
mind
what
is
the
most
maximal
implementation
that
could
be
produced,
one
that
effectively
had
the
highest
likely
compatibility
with
like
actual
code,
that
people
would
want
to
write
and
allow
the
all
ESM
code
to
execute
and
function
as
ESM
authoring.
So.
H
I
So
simply
saying
that
if
your
module
execution
is
async,
we
won't
allow.
It
is
very
acceptable
for
a
common
task.
Since
most
modules
don't
actually
need
top-level
await,
and
so
the
simpler
version
of
that
PR
that
I
plan
on
putting
up
is
one
where
I
simply
just
synchronously
unwrap
promises.
If
they're
resolved
and
that's
it
and
before
someone
says
that
breaks
the
promises,
spec
I'm
going
to
tell
you
that
top-level
await
in
modules
breaks
the
promise
spec.
So
it's
not
my
fault,
that's
actually
just
how
top-level
weight
is
defined
to
work.
I
Wait,
the
couple
of
await
specifically
doesn't
break
it.
So
the
way
modules
are
executed.
Bracelet.
If
you
expect
it
that
every
module
execution
was
a
promise
to
its
execution
and
then
joined
with
ends,
you
would
expect
that
you
would
have
event
loop
turns
between
the
execution
of
every
module.
You
do
not.
The
reason
you
do
not
is
because
the
promises
are
not
actually
executed.
They're
synchronously
unwrapped
up
until
the
point
where
you
finally
actually
hit
in
a
wait
at
which
point
the
graph
actually
becomes
async
and
you
actually
see
an
event
loop
turn.
I
D
B
I
can
respond
to
that.
If
so,
the
top-level
away
expect
execute
smuggles
in
a
synchronous
way.
There
is
nothing
about
the
actual
execution
that
is
promise
based,
correct
exactly
you
start
hitting
top-level
awaits,
and
then
it
turns
into
a
promise
execution
but
execution.
If
all
your
modules
new
graph
are
sync,
the
execution
is
async
execution.
There's
nothing
async
about
it
right.
H
B
If,
if
common
J's
were
to
load
an
async
module
only
no
during
the
execution
process,
as
we
start
to
process
the
tree
that
we've
hidden
a
sink
module,
so
you're
suggesting
that
you
would
like
to
allow
that
execution
to
complete
to
run
to
completion.
But
on
the
clip
resolve
aside
you,
you
immediately
return
an
exception.
There.
I
B
I
And
so
that's
that's
why,
if
we
give
you
through
you
wouldn't
like
cancel
the
execution
or
anything
you
still
executed
up
to
that
point,
you're
still
planning
to
continue
to
execute
it
in
the
async
part.
You
just
be
throwing
the
synchronous
execution
of
the
containing
common
J's
library
and
that's
why
I
said
the
other
option
is
to
actually
just
return
a
promise
from
require.
At
that
point,.
A
I
C
I
I
That's
mostly
just
because
for
API
like
ease
of
working
with
the
API,
we
probably
still
define
it
as
like
returning
a
promise
and
working
with
a
promise
that
way
it
has
a
consistent
API
shape
and
then
unwrap
that
which
then
makes
unwrapping
said
promise
easier
than
maintaining
dual
api's
for
a
synchronous
modes
that
then
fills
in
the
async
one.
If
it
starts
executing
async,
which
you
then
have
to
inspect
once
the
synchronous
mode
is
done,
I
mean
we
could
do
that
as
well.
It's
just
more
complicated.
C
I
Hey
and
as
I
said,
like
the
ideal
for
like
the
earliest
of
early
errors,
is
to,
as
I
said,
the
the
what
WG
people
have
a
modification
of
the
spec
that
they've
been
working
on,
that
just
enhances
the
async
flag,
which
currently
only
applies
to
a
single
module
to
have
an
equivalent
for
a
module
graph
that
Flags
it
as
whether
or
not
the
graph
itself
contains
the
module.
That's
a
zhing.
I
A
A
couple
questions
that
I
have
here
because
I
like
the
direction
where
this
is
going
Wes,
so
failing
I
like
the
idea
of
failing
early,
especially
I,
would
want
it
to
be
broadly
to
all
dynamic
modules
are
all
async
modules
so,
like
specifically,
this
would
also
preclude
requiring
webassembly
modules,
most
likely,
but
I
think
like
we
could
just
enumerate
what
what
the
limitations
of
this
would
be.
But
you
know
since
I,
don't
think
many
people
are.
A
I
A
A
A
I
One
that
I
posted
did
not
involve
more
than
one
event
loop,
as
I
said
that
one,
the
PR
that
I
opened
I
removed
the
inner
event
loop,
because
I
decided
to
go
for
the
most
maximal
implementation
that
made
an
es
module
and
any
a
single
weight.
Inside
of
that
at
the
top
level.
Behave
as
the
es
module
would
expect.
Technically
it
breaks
concerns
for
common
GS
callers,
which
is
why
just
not
handling
top-level
await
is
actually
much
better
for
common
data
consumers
and
so.
I
A
B
I
Related
I
was
Bradley
mentioned
this
in
the
thread.
The
design
space
that
we
wanted
to
move
loader
hooks
to
is
moving
them
off
of
the
main
realm,
because
there
are
a
bunch
of
security
concerns
with
loaders
executing
in
the
main
role,
and
so
the
way
that
we
wanted
to
consider
doing.
That
was
by
shuffling
objects
back
and
forth
between
loaders
in
a
shared
buffer
and
using
a
comic
stock
weight
to
wait
on
the
messages
between
them,
which
is,
of
course,
synchronous,
and
by
doing
that,
you
no
longer
need
an
async
resolver
API.
B
Right
is,
but
in
such
an
API,
every
single
resolve
and
source
and
translate
operation
must
be
fully
blocking
down
to
that
communication.
So
we
need
to
make
sure
that
the
performance
works
out.
Common
J's
is,
of
course,
synchronous
and
the
performance
is
what
it
is,
but
it's
something
to
bear
in
mind
that
if
we
wanted,
for
example,
HTTP
loaders,
the
the
entire
thread
would
be
blocked.
Wow
the
resource.
I
B
I
B
I
As
well
I'd
much
rather
try
and
make
it
so
that
custom
loaders
can
be
like
sync,
if
possible,
simply
because
running
them
like
off
thread
and
then
waiting
on
them,
like
the
idea
of
having
loaders
that
can
execute
interleaved
with
your
program
is
scary.
To
me
from,
like
add
just
figuring
out
what
the
order
of
operations
is.
I
A
Sorry
I
didn't
wrap
the
clear
the
border.
We've
got
one
minute
left
and
we've
got
to
wrap
this
up.
This
sounds
like
a
really
positive
development.
I
think
we
should
kick
back
to
the
issue
to
talk
through
technical
bits.
We
could
also
consider
running
another
out-of-band
meeting
to
discuss
this
particular
topic.
I'm
about
to
get
kicked
out
of
this
meeting
room,
so
we're
gonna
have
to
wrap
everything
up.
So
thank
you,
everyone
for
for
joining
today
and
Wes.
Thank
you
for
all
the
hard
work
on
this
I
know.