►
From YouTube: Node.js Foundation Modules Team Meeting 2020-03-25
Description
A
A
B
A
A
Can
do
so,
then
my
understanding,
and
then
you
know
anyone
who
defied
this
wrong.
Please
feel
free
to
interrupt
and
correct,
but
the
export
map
has
like
a
left-hand
sign,
which
is
a
specifier.
The
right
hand.
Side
is
the
file
that
that
specify,
specify
references
when
exports
themselves
were
specked
out
and
put
together.
It
was
done
with
kind
of
the
intention
and
philosophy
that
all
of
the
references
would
be
static.
A
It
is
viewed
by
you
know,
a
handful
of
folks
as
being
a
bug
not
being
a
you
know,
feature
of
this
and
in
general,
with
the
expert
Matt,
so
you've
been
trying
extremely
hard
to
make
sure
that
the
feature
works,
the
same
for
both
common
jsn
ESM.
So
a
guy
opened
a
pull
request
to
fix
the
extension
searching
to
ensure
that
the
experience
for
both
common
je
s
and
e
sm
module
consumers
would
be
the
same.
C
I
think
the
one
thing
I
would
add
is
the
impact,
so
it
means
that
people
who
are
currently
adding
exports
to
the
packages
and
primarily
testing
or
only
testing
those
values
with
require
will
ship
packages
that
unintentionally
don't
work
with
import,
because
import
will
try
to
resolve
the
export
and
will
not
work
so
they
those
packages
only
work
with
require
for
no
good
reason.
Basically,.
C
A
To
clarify
OS,
it's
not
turning
it
off
when
you
deep
search
into
that
folder.
It
would
be
that
like,
if
you
did
the
slash
it,
wouldn't
automatically
look
for
the
index
so
like
if
you,
if
you
did
I'll,
do
an
example
here,
require
my
module,
slash,
deep,
slash
thing
right
and
in
the
export
map
you
only
had
my
module
light.
You
had
deep
slash
defined
yeah
thing
would
still
get
all
of
the
common
J's
resolution
stuff
happening
it
just
you
wouldn't
want
my
module,
slash
deep
to
automatically
search
for
the
index.
I
think.
F
A
F
Type
out
the
export,
so
you
think
would
go
with
that,
because
I
think
we
get,
we
often
get
it
or
at
least
I'm
getting
confused
about
left-hand
side
versus
right-hand
side
like
I
cert.
If
you
put
deep
slash
in
the
left
hand
side
your.
That
means
something
in
exports,
but
if
you
put
it
in
the
right
hand,
side,
that's
well
that.
A
That's
that's
what
I'm,
what
I'm
saying
so
like
as
you
deeply
go
into
that
folder
I.
Don't
think
that
there's
any
debate
about
what
happens
as
you
go
deeply!
That's
the
common
j/s
resolution
algorithm!
It's
just
like
my
module.
Slash
deep,
should
not
automatically
get
the
index
or
my
module
with
no
slash
should
not
automatically
do
the
common
j/s
resolution.
Algorithm.
Oh
yeah,
because.
D
A
F
Agree
here
that,
if
you
try
to
require
or
import
deep
without
a
trailing
slash,
it
doesn't
exist,
it
should
air
out
and
if
you
try
to
import
or
require
so
the
question
is:
if
you
require
deep
slash,
then
the
current
behavior
saying
is
path
to
deep
slash
gets
dumped
into
the
CGS
resolver
and
the
behavior
you're
expecting
is.
That
is
what.
A
A
D
That's
that's
fine
I
just
want
to
like
be
sure
that
the
folder
exposing
case
still
actually
does
do
the
extension
searching
and
look
at
thing,
because
the
folder
case
exposing
the
whole
folder
in
there
by
implying
that
all
the
CGS
look
up
logic
still
happens
within
that.
Folder
makes
a
lot
of
sense
to
me.
So
my
understanding
with.
A
C
Go
for
it.
I
I
think
the
the
desired
behavior
within
PR,
at
least,
is
that
exports
resolves
completely
as
defined
using
the
exports
mapping,
and
it
will
never
pass
it
to
the
commonest
resolver,
because
if
we
do
it
for
directories,
we
are
back
to
square
one
on
the
problem
that
you
would
have
something
that
works
well,
require
sales
by
I.
D
Mean
so
the
directory
the
directory
mappings
like
don't
like
they're,
exposing
an
entire
directory,
they
aren't
like
what
you
do
with
the
fact
that
a
directory
is
exposed
like
you
can't
really
really
create
a
whole
path.
You
do
some
pros,
passing
whether
that's
concatenate
another
path
to
it
or
concatenating
another
path
and
then
doing
some
sort
of
lookup.
F
C
The
the
excellent
resolution
is
in
ASM
absolute,
like
aqua
export
is
resolved.
That
is
the
finding
there's
no
further
processing
at
all.
Exports
resolves
to
eighth
absolute
URL
like
after
expose
processing,
is
done.
That
is
the
final
URL
in
import.
There's
no
further
searching
or
post
processing
afterwards,
I.
A
C
D
Can't
I've
always
used
the
concatenation
as
like
the
implementation
of
where
the
actual
logic
is
I
want
to
say
these
are
the
resources
that
I
want
to
expose
at
some
end
point
the
concatenation
just
being
the
the
implementation
of
that
at
the
time.
I
don't
think
the
concatenation
is
like
the
be-all
and
the
end-all
and
the
actual
desired
end
goal.
Necessarily
in
any
cases,
it's
all
about
what
resources
you
actually
want
to
make
public.
C
D
Know
what
my
voice,
my
foot
is
quite
simply
for
the
ESM
resolver
like
it
still
is
just
concatenation,
because
it
doesn't
do
any
extension
searching
or
lookup
within
directories,
and
so,
if
you
end
with
a
directory,
you
know
if
the
directory
is
nothing
more,
it's
gonna
do
with
it,
but
procedure
as
needing
to
do
more
with
the
directory.
That
makes
sense
to
me.
C
If,
if
we
do
that,
if
we
say
hey
for
comment,
yes,
we
pass
it
forward
to
the
extension
to
the
expansion
expansion
logic
that
come
to
us
does
for
relative
requires
and
stuff.
If
we
do
that,
then
we
end
up
with
packages
where
the
readme
says:
hey
you
just
use
the
following:
specifier
and
those
instructions
will
work
for
program
for
require,
but
will
fail
when
you
try
to
use
the
same
instruction
to
import,
which
seems
incompatible
with
how
we
would
want
people
to
treat
exports.
C
D
I
want
to
I
want
to
I
want
to
rationalize
this
in
this
way
to
get
the
behavior,
where
you
have
the
commonjs
deep
exposure,
you
cannot
replicate
that
by
writing
out
a
like
explicit
map
easily.
However,
you
can
make
it
so
that
all
the
specifiers
do
work
in
both
the
ESM
and
the
CGS
was
Oliver
by
adding
a
couple.
More
explicit
entries
to
that.
F
So
I
have
a
question
why,
if
I,
if
I'm
using
ESM
and
I,
specify
a
path
to
a
directory
inside
a
package,
why
does
that
not
reference?
Its
package.json,
like
there's
already
a
chain
of
package.json
through
node
modules,
right
what's
wrong
with
a
chain
of
package.json,
is
relatively
like
within
the
project
like.
E
F
C
C
Nice
right
so
from
my
perspective,
it
is
working
as
intended,
because
my
my
goal
with
exports
was
to
have
a
data
structure
can
be
used
for
static
resolution
using
just
the
top-level
metadata
that
comes
from
thanks,
Jason.
You
know
in
a
package
so
that
in
theory,
if
you
just
get
the
metadata
about
the
packages
without
downloading
any
files
from
the
packages,
you
can
build
resolution
structure,
you
can
do
static
analysis
using
it.
I
see
like.
C
C
F
C
Basically,
if
you
use
a
loader
that
doesn't
maintain
this
guaranteed,
you
are
opting
into
losing
the
grantee
okay,
for
example,
a
random
third-party
package.
Couldn't
it
couldn't
assume,
generally
speaking,
that
a
certain
notice
being
used
by
an
application,
so
the
ecosystem
at
large
should
be
compatible
with
you.
C
B
F
F
F
C
F
F
A
F
Mean
so
that's
fine,
but
even
if,
if
tomorrow,
we
could
get
a
list
of
what
the
breakage
is,
today's
release
cause
so
that
we
could
reach
out
and
like
get
them
fixed.
That's
still,
I
think
valuable
and
a
good
mitigation.
I
I
certainly
hope
it
doesn't
break
anyone
and
and
I'm
pretty
confident.
None
of
my
packages
will
break
so
that's
good,
okay,
yeah,
well,
yeah.
F
E
E
A
Thing
that
we
would
be
able
to
do-
and
this
is
one
of
the
things
I
like
about
the
13
X
release-
is
like
we
can
do
a
bunch
of
research,
but
one
of
the
easiest
ways
to
tell
that
we
break
people
for
better
or
for
worse,
is
to
break
them
and
have
them
open
issues.
So,
like
one
thing
that
we
also
can
do
for
better
for
worse-
and
this
is
part
of
the
reason
why
it's
good-
that
this
stuff
is
still
experimental
with
a
clear
warning-
is
we
could
just
break
it,
break
it
on
13?
C
C
A
C
A
D
E
E
D
That
place
in
that
case,
if
we're
not
going
to
consider
the
ability
to
undo
this
change
because
we
think
that
it's
partial
or
incomplete
or
bad,
then
we
want
to
ship
it
correctly,
the
first
time
because
we're
not
going
to
change
it
again
right,
we
don't
want
to
ship
something.
That's
like
half
breaks,
a
lot
of
things
that
we
didn't
mean
to
well.
D
E
G
They're
currently
about
just
under
400
packages
on
NPM
in
the
exports
field,
and
it
seems
to
be
growing
at
about
three
packages
a
day
as
far
as
I
can
tell
just
from
some
hard
checks,
so
my
feeling
listed
is
that
the
longer
we
wait,
the
worse
that
break
is
getting
the
next
release
is
in
a
month,
I'm,
not
sure
what
the
exact
timing
is.
They
do
you
think
three
packages
a
day
times
30
days,
that's
potentially
another
hundred
packages
which
could
break.
G
G
Which
was
actually
a
mistake,
they
they've
got
past
exports
in
one
of
their
sub
packages
and
in
one
of
the
path
exports
they
left
out
the
extension
or
the
OD
extension.
They
didn't
realize
that
they
needed
to
include
the
extension,
so
it
was
working.
Fine
was
required,
but
then,
if
someone
were
to
use
imported
with
a
broken,
sir
I
send
PR
to
babble
on
that
already,
anticipating
the
semantic
change
but
yeah
those
kind
of
reaching
Zout
are
important
to
ensure
that
people
aren't
just
confused.
G
E
Would
just
say
like
if
there
any
that
like
scream,
you
know
leav
lo
is
at
the
top
of
the
list
or
like
anything
like
that,
that's
extremely
popular.
We
should
maybe
try
to
try
to
reach
out
to
them
before
we
land
this.
If
this
affects
them
did
I
assume
most
of
them
are
probably
using
exports.
The
way
Jordan
is
where
it's
like,
not
assuming
searching,
so
there
might
not
be
any
ones
that
we
need
to
say.
I,
don't
know
any
other
major.
A
The
pre-act
we
would
break
pre-act
in
the
example
that
michael
was
putting
here,
because
this
is
actually
an
interesting
one
to
consider
right.
People
who
are
who
are
using
exports
and
early,
and
they
want
to
land
it
in
a
cember
minor
pre-act
is
including
dot
slash
map
dot,
slash
to
ensure
that
any
people
who
are
deeply
searching
into
the
module
in
the
past
will
not
actually
have
that
break
on
them,
and
that
will
break
that
pattern,
because
in
common
just
prior
to
this
change,
deep
searching
would
have
the
full
resolution
algorithm.
D
A
E
D
A
D
The
thing
is
like
you
can
always
if
you
want
to
like
not
do
this
for
you.
Yes,
I'm
consumers
for
us,
I'm
consumers,
you
could
have
a
conditional
export
where
you
do
dot,
slash
dot
size
for
your
CJ
s,
consumers
and
then
only
expose
specific
things
for
yes,
M
consumers.
That
way,
only
your
ESM
consumers
have
a
break
and
change
which,
probably
when
you
do
this,
you
have
no
es
M
consumers
yet
so
like,
but
the
the
folder
exposure
case,
like
the
primary
use
for
the
folder
exposure,
is
for
backwards.
D
F
The
other
thing
is,
as
was
discussed
in
the
chat,
the
property
that
Yan
was
interested
in.
Preserving
already
doesn't
work
if
there's
conditional
exports
right,
which
is
that
could
like
you,
could
not
I
think
right,
which
is
that
you
can't
ensure
that
the
whole
graph
is
static
if
those
are
being
used.
Usually.
D
F
Can't
ensure
that
the
specifier
results
to
the
same
URL
and
es
m
and
CJ
s
right
so,
given
that
that
guarantee
is
already
not
there
and
that
there's
been
a
lot
of
desire
expressed
for
consistency
between
CJ
s
and
es
m
in
exports,
and
given
that
you
know
we
may
want
the
directory
resolution
or
the
audit,
the
lookup
stuff
to
apply
to
expose
directories.
Do
we
want
to
let
the
ESM
thing
also
check
package.json,
x'
and
folders,
and
then
just
say:
if
you
want
that
property
don't
expose,
folders
may.
C
E
C
C
Because
you
would
have
to
have
without
downloading
the
source
code,
okay,
so
the
property
is
currently
maintained,
business
from
all
but
I'm
aware,
and
there's
definitely
the
possibility
that
we
can
allow
this
for,
require
and
I.
Think
God
has
had
multiple
possible
workarounds
like,
for
example,
warning.
C
If
we
make
this
breaking
change
right
now,
the
work
is
on
the
other
side,
which
is
the
smallest
group
of
users,
so
I'd
much
rather
make
it
a
little
bit
harder
on
the
authors
that
they
would
have
to.
If
they
want
to
say,
hey,
I'm,
Ellen
exports,
I,
don't
want
it
to
be.
A
breaking
change,
then
export
all
the
possible
possible
paths.
If
you
really
want
to
be
sure
I,
don't
like
the
slash
export
was
a
way
to,
for
example,
expose
things
like
package
Jason,
which,
for
the
most
part,
then
kind
of
works.
C
A
Them
my
understanding
was
that
they
released.
The
export
map
was
unaware
that
they
broke
deep,
searching
and
broke
a
bunch
of
their
downstream
consumers
and
adding
the
dot
slash
as
kind
of
like
an
escape
hatch
was
the
way
in
which
they
resolved
to
not
just
completely
remove
the
feature
all
together
before
speaking.
C
F
Change
that
adding
the
ESM
version
doesn't
have
to
be
once
you
have
exports.
Yes,
yes,
so
part
of
our
discussion
through
the
process
was
that
it's
okay
to
first
have
to
have
a
breaking
change
in
order
to
position
your
API
such
that,
then
adding
ESM
are
converting
to
your
you
know.
Changing
DSM
is
not
a
breaking
change,
so
I
think
I
mean
the.
E
E
B
G
D
And
my
point
is
like,
if
you
don't
use
the
folder
export
I,
think
that
we
should
be
able
that
like,
if
you
want
to
expose
exactly
specific
end
points,
that's
what
we
should
be
doing
for
the
non
folder
exports.
But
the
folder
wildcard
re-export
is
for
exposing
the
entire
folder
as
a
resource
right
which
CGS
can
folder.
Consumers
expect
that
resource
to
do
the
frames.
G
F
G
F
Yeah
I'm,
sorry,
what
I
mean
is
if
I
currently
have
a
package
with
the
exports
field
that
exposes
a
folder
I
understand
that
later
so
yeah
like
and
then
my
question
is,
you
know:
I
can
require
CJ
s
style
things
inside
it,
but
I
can't
import
anything
inside
it
unless
it's
an
actual
file
in
the
file
system
and
I
include
the
full
path
to
it.
Is
that
right,
yeah.
F
This
goes
back
to
my
question,
then,
is
for
folder
imports
or
folder
exposing.
Is
there
a
reason
why,
if
that
folder
contains
a
package
JSON
for
ESM,
it
couldn't
use
the
exports
map
in
there
and
I
understand
that
that
takes
away
a
little
bit
of
yawns
desired
property
of
being
able
to
only
look
at
the
pack.
Events
but
like
it
seems
like
the
solution
is:
don't
use,
folder
exports,
if
that's
something
that
matters
so.
F
Suggesting
that
I
have
a
nested
folder
inside
a
package
that
contains
another
package
JSON
that
has
an
exports
mapping
and
at
the
top
level
I
expose
that
nested
folder
and
then
with
require.
Of
course
it
would.
It
already
follows
the
require
the
CJ
s
resolution
and
it
goes
through
the
package
JSON,
but
with
but
I'm
asking.
Could
we
also
make
it
so
that,
if
I
import
the
path
to
that
folder,
it
gives
me
and
I
can
then
next
the
only.
G
F
F
H
So
I
just
I
just
wanted
to
say
that
I
actually
agree
with
I
think
what
Wes
is
saying
if
I'm
exposing,
for
example,
dot
slash
to
dot
slash,
my
expectation
is
that
any
path
that
I
require
or
import
will
go
through
the
require
or
import
resolver,
so
I
would
expect
that
certain
paths
would
work
and
CJ
s,
but
would
not
work
in
the
SM
on
the
other
side
for
exports,
which
specify
an
explicit
destination.
I
kind
of
expect
that
that
should
be
the
full
path,
as
I
think
is
what's
being
recommended
in
this
PR.
H
E
D
F
E
Also
feel
like,
we
need
to
do
some
more
research
to
see
like
all
these
edge
cases
of
folders
and
deep
folders
like
we
need
to
have
like
a
full
list
of
like.
Maybe
let
me
starting
with
pre-act,
what
are
the
various
things
that
people
import
from
pre-act
and
what
would
break
if
we
change
how
dot
slash
dot,
slash
works
in
kind,
so.
A
I
guess
like
the
thing
that
I
think
is
really
important
for
us
to
consider
here,
is
like
we.
We
are
removing
that
escape
hatch,
and
this
is
the
one
thing
that
gives
me
hesitation
right
now
when
we
remove
this
from
the
directory,
like
I
I
know
that
that
some
platforms
are
pretty
good.
Just
like
hey,
you
know,
versions
are
cheap,
we'll
do
a
semi
major
whatever
we
want,
but
there's
also
like
you
know
there
are.
A
There
are
software's
that
are
very,
very
slow
at
landing
summer,
majors
and
I
I
am
concerned
that
this
could
significantly
hurt
adoption.
If
we
make
exports
have
to
be
a
sin
for
major
change
and
I'm
pretty
sure,
but
I
can
check
with
Jason
quickly
that
if
we
did
land
this
change,
it
will
break
pre-act.
I
would
have
to
dig
up
the
PR
where
they
landed
exports.
Initially
I
can't
recall
if
people
reported
actual
breakages
or,
if
I
flagged
on
the
fact
that
there
might
be
breakages.
A
So
I'd
want
to
double-check
that,
but
I
do
believe
that
after
they
released
exports,
they
broke
people
and
it
was
specifically
deeply
searching
for
the
package.json
and
in
this
example,
with
like
the
dot
slash.
If
people
are
still
requiring
things,
slash
package.json,
it
will
work,
but
if
they
were
requiring
pre-act
slash
package
like
we
will
break
that
resolution,
search
that
they
were
doing
now.
A
Maybe
adding
the
extension
there
is
not
the
end
of
the
world
is
like
a
response
that
like
something
that
they
can
come
up
with,
and
maybe
it's
fine
that
we
do
this,
but
I
just
want
to
like
be
explicit
about
the
fact
that
we
are
removing
the
ability
for
this
to
be
like
sever,
a
minor
Brad.
You
have
your
hand
up.
Yon
mentions
that
he
has
a
direct
response
to
what
I
said
about
pre-act.
Would
you
mind
if
he
goes?
First
sure?
Are
you
also
drink?
Go
ahead,
young.
C
Yeah,
just
the
strictly
I
my
memory
of
the
pre
acting
was
that
they,
edit
all
the
paths
they
knew
about
breaking
and
those
paths
are
all
still
explicitly
listed,
and
that
is
the
reason
why
I
was
thinking
that
they
might
not
be
broken
because
they
already
exposed
all
the
breakages
that
they
knew
about
before
the
head
of
the
dot.
C
C
A
That
is
literally
the
only
thing
I'm
worried
about.
If
we
took
the
like
the
mental
model
that
I've
always
had
for
the
folder
mapping
was
the
folder
mapping
was
being
used
to
concatenate
the
path
and
then
handing
the
path
off
to
the
resolver
and
letting
the
resolver
doing
do
its
thing
for
the
individual
files.
It
makes
sense.
It's
a
one-to-one
thing
and
I
could
see
how
both
mental
models
make
sense
here.
B
Sure
a
little
bit
outdated,
but
I
can
take
on
the
work
to
get
a
new
data
set
that
we
can
query
as
of
today.
It's
going
to
take
a
few
days
and
we
can
actually
get
numbers.
I
actually
have
a
very
neutral
feeling.
After
all
this
discussion,
it
seems
like
we
are
getting
some
guarantees
but,
as
was
stated
earlier
in
the
discussion,
any
guarantees
about
commonjs
are
kind
of
mute,
leutis.
Sorry,
so
for
me,
this
PR
doesn't
really
impact
import,
which
is
my
only
major
concern
for
reliability.
B
A
You
so
kind
of
I
guess
with
that
being
said,
we
have
two
different
paths
that
we
could
go
right
now
and
like
to
be
like
clear,
like
I'm,
okay
with
us,
going
either
I.
You
know
I'm
still
kind
of
digesting
the
result
like
what
it
would
mean
myself,
one
in
which
we
land
the
PR.
That's
open
right
now,
which
you
know,
keeps
it
consistent
between
both
and
another,
where
we
move
the
PR
to
only
remove
the
extension
resolution
for
files,
but
maintain
handing
it
off
to
the
resolver
in
the
case
of
directories.
D
A
G
I'd
be
happy
to
update
the
PR
to
still
provide
extension
searching
for
the
pot
exports
for
comment
yes
and
I
mean
we
can
always
come
back
around
on
that
and
add
you
know,
remove
that
in
future,
as
Jeffrey
said,
so
it's
still
a
step
towards
it.
So
if
we've
got
agreement-
and
everyone
agrees
on
that,
I'd
be
happy
to
fix
up
the
implementation
and
ensure
you
can
merge
that
as
soon
as
possible.
G
A
A
A
Research,
Brad,
I,
I,
don't
think
that
this
should
really
break
anything
and
the
breakages
that
it
would
maybe
have
would
be
fairly
obvious
and
fixable
with
like
a
couple
like
by
adding
the
extension,
whereas
breaking
it
in
the
folder
case
doesn't
really
have
an
alternative,
because
it's
removing,
like
a
whole
use
case,
so
happy
to
revisit
it
and
do
the
research
and
and
maybe
further
limit
things
in
the
future
Wes.
You
have.
D
D
F
F
D
G
The
base
level
of
each
package
once
you
have
to
go
into
deeper
levels-
it's
you
know,
isn't
in
complexity
to
something
that's
already
a
huge
complexity
on
top
of
the
existing
resolver,
which
is
already
a
hugely
complex
system
like
as
much
as
possible.
Resolver
simplicity
is
so
important
and
I
know
these
any
cases
don't
always
seem
like
do.
F
I
think
is,
is
perhaps
ask
npm
upon
publish
to
inline
all
of
the
nested
exports
in
the
top
level,
like
it's
all
statically
discoverable,
once
you
have
the
package
available,
so
that's
certainly
something
that
I
mean
I,
don't
know
how
well
it
willing
they
would
be
to
do
it,
but
if
they
did
it,
then
the
top-level
package
JSON
that
you
install
as
well,
you
know
in
the
pack.
You
meant
that
you
can
get
without
even
telling
the
tarball
would
all
contain
all
that
information.
Provided
your
package
doesn't
do
something
unique
like.
A
Know
I'm
sorry
to
interrupt,
but
we
are
in
time.
The
one
thing
I
will
mention
is
the
fact
that
the
pattern
that
you
shared
west
does
work,
but
for
internal
self
referential
modules,
so
it
actually
can
already
be
broken.
So
I
think
that
this
discussion
is
worth
having
anyways
to
decide
whether
or
not
we
want
to
limit
that
possibility
altogether.
H
A
A
G
D
Right
exactly
it's
like
this,
as
written
here,
I
don't
actually
need
the
sub
mod
reacts
forward
before
the
the
file
we
export
like
if
I
don't
include
exports
at
all.
This
actually
works
just
fine,
because
it
does
just
go
through
the
type
module
in
the
index
lookup.
So
the
point
is
well.
Why
aren't
we
looking
at
the
package.json
for
like
an
alternate
main
entry
point
for
that
folder
when
we
find
it
because,
like
we're
looking
there
for
the
type
module
anyway
right?
So
why
not
look
at
the
other
information?
Can.
A
H
B
I
got
requested
to
add
APR
to
the
agenda
in
nodes.
Build
scripts.
I
made
a
PR
to
let
you
change
the
default
package.
Type
people
keep
bringing
this
up
and
various
issues
I
would
like
to
land.
It.
I
just
wanted
to
be
sure:
it's
okay
to
land.
This
does
not
let
you
configure
this
at
run
time
and
for
the
most
part,
I
haven't
found
many
things
that
actually
run.