►
From YouTube: Node.js Foundation Modules Team Meeting
Description
A
We're
now
live
with
the
May
8
2009
teen
meeting
of
the
modules
team,
I'm
gonna
go
ahead
and
immediately
hand
this
off
I'm
gonna
go
ahead
and
make
Geoffrey
the
host
for
right
now,
and
maybe
just
everyone
else,
co-hosts
I'm
about
to
drop.
Thank
you
everyone
for
joining
today
and
just
ping
me.
If
there's
any
emergencies,
have
a
good
meeting
Thanks.
B
B
Well,
figure
it
out
I'm
sure
so,
yeah
I
think
he
passed
out
to
me
because
I
think
I
had
the
first
item
on
the
agenda
so
which
was
well
I
mean
they
don't
need
to
share
my
screen,
but
basically
yeah.
So
apologies.
If
you
read
this
and
we're
a
little
confused
by
it,
because
I
kind
of
shared
my
thought
process
of
how
I
got
to
the
end
result,
which
was
perhaps
a
bit
confusing
because
it
was
my
thought
process
involved
dual
packages,
but
the
end
result
did
not
really
relate
to
packages.
B
So
my
apologies,
if
that
led
people
astray,
but
basically
I
was
thinking.
We
still
want
to
solve
named
exports
at
least
I
assume.
We
still
want
to
solve
it
because
we've
been
we
kind
of
keep
punting
it.
It's.
If
I
think
it's
still
on
our
list
for
phase
3,
so
named
exports
from
commonest
packages
into
an
ESS,
so
you
import.
So
in
other
words,
you
want
to
be
able
to
do
import,
brace,
shuffle
you
know,
brace
from
low
and
not
just
import
underscore
symbol
from
low
or
from
underscore
I.
B
B
So
what
I
was
going
to
suggest
was
you
know
if
that
gets
through
then
great,
like
obviously
that's
a
better
solution
than
what
I'm
proposing
here,
which
is
just
have
package
authors
to
find
they're
named
exports
somewhere
in
package,
a
Jason
with
the
format
of
such
a
such
a
field
like
to
be
determined,
and
if
dynamic
modules
comes
through
and
we've
already
implemented
the
package
adjacent
approach,
then
yeah.
We
should
get
rid
of
the
package
adjacent
approach
in
favor
of
the
dynamic
approach,
because
dynamic
approach
is
obviously
better.
So
this.
B
Let's
see
if
we
can
figure
out
a
solution
that,
like
the
last
stitch
option
for
if
we
can't
make
dynamic
models
or
some
other
dynamic
version
of
named
exports
work,
then
it's
just
in
package,
Oh,
Jason
and
then
we've
got
at
least
this
and
then,
if
a
dynamic
version
ends
up
happening,
we
can
replace
it
with
that.
So
Jordan
your
hand
up
yeah.
D
So
so
there
are
two
to
two
things:
I
want
to
say.
The
first
is
that
the
path
for
non
dynamic
modules,
I
think
is
removing
stuff
from
the
JavaScript
spec
and
delegating
more
to
the
hosts,
which
browsers
are
always
on
board
with,
as
where
least
in
this
case,
browsers
seem
to
always
be
on
board
with
and
would
permit
us
to
do
dynamic
modules.
The
the
fact
that
there
was
discomfort
in
the
tc39
meeting
doesn't
mean
that
that
we
don't
have
a
path
forward
there.
D
It
seems
like
it
seems
like
we
that
would
be
a
better
approach
to
me
than
a
package.json
field
to
allow
for
this,
because,
if,
if
underscore
wanted
to
make
this
happen,
they
would
just
like
if
they
had.
So
if,
if
the
package
author
needs
to
make
a
change
in
order
to
allow
named
M
imports
of
their
thing
of
their
CJ
s,
thing
such
as
adding.
E
D
To
their
package
JSON,
then
they
could
also
add,
for
whatever
their
entry
point
dot.
J
s
is,
they
could
add
an
entry
point,
MJ
s
that
pulls
in
the
common
j
s
one
and
explicitly
re-exports.
The
named
exports.
So
I
think
that
there's
that
to
me,
if
we
have
a
dual
module
solution
or
dual
mode
package
solution,
that
we've
kind
of
already
answered
a
lot
of
open
questions
in
that
it
becomes
very
each
trivial
for
people
to
make
their
package
consumable
in
both
module
systems
and
the.
D
Yeah
I
think
so
I
think
I
think
that's
the
path
I
would
rather
go
down.
Rather
than
trying
to
add
package
JSON
configuration
for
each
small
little
use
case
that
comes
up.
That's
important.
I
would
rather
solve
it
more
holistically
and
come
up
with
a
consensus
for
a
dual
module
solution
that
then
can
naturally
kind
of
obviate.
Most
of
the
other
concerns
that's
my
bit.
C
Yeah
I
was
unmuted,
actually
I
didn't
know
that
so
I
I
think
the
question
of
generating
named
exports
in
a
packaged
a
song
can
can
also
be
framed
as
in
differently
by
saying
the
amount
of
the
amount
of
diligence
you
need
to
put
that
information
in
JSON
format,
just
as
well
can
can
be
done
to
wrap
your
CJ
s,
module
with
with
an
echo
script,
module
export
created,
require
from
path
or
create
require.
C
Now
and
then
you
require
your
module
and
you
export
what
you
need
both
of
them
come
with
the
potential
circular
references
problem
that
dynamic
modules
is
trying
to.
Actually
you
know,
eliminate
duplicate
module
records
so
that
circularity
does
not.
You
know,
hit
that
I.
Think
sync
problem,
so
so
I
think
the
solution
theoretically
solves
the
problem,
but
it
does
not
necessarily
technically
solve
the
dilemma
of
how
do
you?
How
do
you
solve
the
circular
references
problem?
So
I
I
just
want
to
raise
that,
and
maybe
you
thought
about
that.
C
D
D
New,
a
circularity,
the
reason
we
don't
have
named
exports
is
because
cj's
doesn't
have
that
concept
and
it's
not
appropriate
to
just
always
take
all
the
object,
he's
and
treat
them
as
named
exports.
Circularity
is
something
that
can
be
done
in
CJ
s.
If
you
follow
certain
patterns
and
if
you
don't
follow
those
patterns,
then
obviously
you
wouldn't
be
able
to
have
circularity
there.
Now.
A
C
Can
I
breathe
what
you
just
so?
If,
if
you
know
your
module
keys,
you
don't
need
to
execute
the
module
before
before
you
expose
that
as
an
SM
named
export.
A
solution
to
do
that
at
this
point
in
time
is,
is
not
cleanly
available.
So
we
found
that
you
know
whatever
we
end
up
in
a
position
where
we
evaluate
the
module,
then
get
that
object.
That
has
its
keys.
C
E
D
C
D
C
D
What
you're
saying
that
you
don't
actually
disrupt
the
ability
to
have
circularity
if
the
CGS
module
mutates
its
exports
object,
which
is
what
is
necessary
in
order
to
allow
for
circularity
in
CJ
s,
then
the
ESM
rapper
would
be
a
live
binding
based
on
a
property.
Look
up
from
like
you,
you
could.
You
could
write
the
rapper
if
you
cared
about
the
circularity.
This
is
don't.
You
would
right
right
right,
okay,
that
it
used.
C
B
If
we
don't
go
forward
with
that,
then
I
guess
you
could
just
define,
rather
than
like
dynamic,
friendly
paths,
you
could
define,
like
literally
the
path
to
a
particular
file
to
be
like
okay
for
this
file
somewhere
down
on
my
package.
Here
are
the
named
exports
for
that
and
you,
and
it's
just
up
to
the
author,
to
define
as
many
or
as
few
named
exports
as
they
want
to
specify
for
whatever
paths
within
their
package.
B
Liberally
didn't
put
like
a
example
package
of
Jason
in
the
proposal
because
that's
kind
of
like
you
know
to
be
determined,
as
we
work
out
the
finer
details
of
all
of
this.
If
this
is
even
something
that
people
want
to
move
forward
on,
so
my
I
just
my
feeling
about
it
is
just
that.
Obviously,
this
is
the
the
least
desirable
solution.
I
guess
that
really
the
question
for
the
group
is
that
is
this:
is
it
more
desirable
to
do
nothing
than
this?
Assuming
that
everything
else
fails
in
terms
of
dynamic?
B
And
you
know
all
the
other
dual
package
approaches
that
we're
talking
about
like
say,
dual
package
doesn't
advance
beyond
where
it
is
now
and
say
you
know,
dynamic
models
doesn't
advance
beyond
where
it
is
now.
Would
we
rather
do
this
than
nothing
or
do
rather
do
nothing?
That's
I
think
the
question
well.
D
F
Yeah
I
just
wanted
to
mention
as
well
when
we
think
about
making
these
sort
of
decisions
that,
as
a
group,
we're
not
a
group,
that's
tied
to
one
path
and
I.
Think
a
lot
of
the
work
that
we've
been
doing
and
the
way
that
we've
been
operating
is
in
assuming
that,
to
some
degree
we're
exploring
problem
spaces
and
having
separate
proposals
that
are
mutually
exclusive,
is
not
a
problem
for
us.
G
No
we're
talking
about
it.
I
just
want
to
just
say
why
I
don't
think,
there's
really
a
need
for
it
like
well,
I
have
out
with
band
stuff
when
you
can
have
in
band
stuff
that
already
works
sort
of
by
I.
Don't
really
see
the
greatest
reason
for
it
like
if
you
like,
someone
might
pull
in
my
CJ
as
part
from
ESM,
and
then
they
might
not
get
named
exports.
B
G
B
Mean
that's
I
guess
the
broad
I
mean
that
goes
into
the
next
agenda.
Item
is
I
proposed
this
because
in
the
last
meeting
there
was
disagreement
about
dual
packages
like
even
in
principle
if
it
gets
something
we
should
be
supporting
I've
been
coming
at
this
from
the
perspective
that
it
seems
pretty
clear
that
users
want
them
and
that
it
greatly
helps
the
transition
path,
because
otherwise,
you
know
a
package
like
underscore
either
has
to
make
a
cember
major
change,
breaking
change
to
flip
everything
to
be
okay.
B
B
D
The
pushback
I've
heard
has
not
been
about
the
concept.
It's
been
more
about
the
risks
of
specific,
like
implementation.
Details
like
there
may
be
disagreement
that
that
solving
this
problem
is
worth
certain
trade-offs,
but
I
haven't
yet
that
I'm,
aware
of
heard
anyone
say
we
shouldn't
solve
this
problem.
C
C
C
F
G
Like
that
right
and
like
my
only
point
is
when
everything
is
asynchronous
right,
all
you're
doing
use
Express
Express
asynchronous
dependencies
between
your
co-routine
between
your
continuations
from
the
runtime.
That's
really
no
different
from
a
synchronous
set
of
dependencies
that
need
to
be
resolved,
and
so
we
are
the
runtime
when
we
do
if
they
the
power
to
see
those
as
equivalent.
C
It,
theoretically,
if
everything
is
they
think
everything
is
sync
kind
of,
because
you
know
everything
literally,
is
you
know
the
same
chronological
you
know
whatever
like
facade
or
so
a
question
would
be
wrapping
CJ
as
modules
in
generator
like
the
regenerator
approach
for
promises.
Would
that
be
something
feasible?
Has
this
been
explored?
I
mean
if
this
is
distracting
from
the
agenda
item,
please
somebody
just
you
know,
say
anything:
Bob
can.
G
Not
distraction
did
Miles
mentioned.
This
is
the
last
meeting
and
it's
probably
worth
looking
into,
but
he
was
saying
that,
like
we
put
a
lot
of
work
into
making
a
relatively
nice
C++
resolver
for
ESM,
that
is
separate
from
the
CJ
s
like
require
resolver,
that's
written
in
JavaScript
and
the
C++
resolver
is
like
it
has
some
promises
and
it
doesn't
asynchronous
stuff
it.
We
do
have
the
tool
to
do
the
signification
of
the
stuff
in
the
resolver
pipeline.
That
we
know
doesn't
depend
on
external
stuff.
G
It
might
be
worth
upgrading
the
entire
CJ
s
pipeline
to
also
be
in
C++
and
also
always
use
the
same
sort
of
async
resolution
stuff,
a
sync
resolutions,
because
they
can
be
sacrified
in
the
same
way
and
then
we
just
have
one
unified
resolver
in
C++.
They
always
does
async
stuff,
but
when
you
call
it
from
CJ
s,
it
all
resolve
synchronously
I.
G
G
B
B
F
B
B
The
older
of
the
two
dual
package
approaches,
which
was
basically
defining
a
new
field
to
specify
the
ESM
entry
point
for
the
pair
specifier.
So
that
way,
a
pair
specifier
like
underscore
could
point
to
index
taya,
J
s
index
and
MJ
s,
and
rather
than
those
both
being
defined
domain,
and
they
would
be
defined
through
two
separate
fields.
I
had
proposed
in
this
thread
that
this
doesn't
have
to
be
in
conflict
with
the
require
BSM.
B
That
wes
is
proposing
that
we
could
just
introduce
the
concept
of
a
field
that
points
to
the
SM
entry
point
and
then
require
VSM
can
happen
and
just
use
it.
You
know
like
that's,
it
doesn't
have
to
be
overloading
main
to
do
so,
and
that
way
we
can
kind
of
unblock
both
of
these
proposals.
And
then,
if
and
when
extensions
searching
happens,
we
can
decide
to
get
rid
of
this
second
field
and
overload
main
if
people
want
to
do
that.
B
But
I
think
like
there
are
various
people
who
would
want
to
keep
two
fields,
regardless
of
whether
extension
searching
happens.
So
I
guess
the
question
for
the
group
is:
can
we
move
forward
in
that
general
direction
on
this
to
start
like
getting
making
progress
on
this
or
do
people
objections
to
that.
D
B
D
May
end
up
and
I
agreed
with
West's
comment
just
now
in
the
chat,
so
I
think
that,
first
of
all,
it's
it's
weird
that
the
same
specifier
could
resolve
to
two
different
things,
depending
on
how
you
get
to
it
generally.
The
resolution
system
is
like
with
the
file
system
being
constant.
The
resolution
system
is
idempotent.
D
One
of
the
ways
we
can
provide
dual
packages
is
that
we'll
have
to
is
to
have
dual
entry
points
unless
we
have
some
kind
of
transparent
Interop.
So
if
we
have
multiple
entry
points,
then
we
need
a
way
to
differentiate
them.
Two
fields
is
one
way,
but
if
we
have
extension
searching,
we
don't
need
the
two
fields,
so
I'm
kind
of
I
feel
like
it
would
be.
Like
I'm,
not
clear
on
the
use
cases
for
having
two
fields,
if
we
have
alternative
ways
to
do
it
like
in
this,
because
I.
B
Think
you
don't,
we
don't
currently
have
alternative
ways
to
do
it
like
yeah,
like
if
extension
searching
happens,
then
we
could
be
about.
My
point
is,
if
extension
search
happens,
let's
reevaluate,
but
it's
not
happening
in
the
next
few
weeks,
so
rather
than
just
having
all
progress,
be
halted
and
blocked.
Waiting
on
that
to
someday,
maybe
change
I'm,
saying
like
let's
just
move
forward
and
solve
the
case,
we're
trying
to
solve
of
dual
packages
and
if
we
can,
if
it
gets
it
more
ergonomic
because
extension
searching
comes
later
on,
then
we
can.
D
Other
thing
is
that
the
the
module
field,
or
whatever
doesn't
solve
deep
imports,
dual
deep
imports
and
that
I
think
is
just
as
important
as
the
main,
so
like
a
package.json
field
approach
that
could
that
could
perhaps
solve
that
with
something
where
you
say
like
for
ESM
use
this
folder
as
the
rope
akka
Giroud
instead
of
the
package
root,
but
then
that
also
opens
up
different
questions
so,
like
I
think,
I
think
I
think
we
shouldn't
try
to
solve
this
at
all.
If
we're
gonna
solve
it
piecemeal
and
that
means
like
for
it.
D
You
know
to
point
to
different
indexes,
or
things
like
that
and
yeah.
So
I
think
that
I
appreciate
the
the
approach
of
like
how
can
we
provide
something
in
the
meantime
which
we'd
need,
if
the
other
things
failed
for
sure,
but
I'm
not
sure
that
this
really
does
it.
This
is
a
very
like
kind
of
shallow
approach
and.
D
Itself
is
not
a
very
complete
solution.
It's
just
the
one
we've
had
forever
I
would
have
vastly
preferred
some
sort
of
something
like
the
browser
field.
Where,
like
you
can
specify
you
know
you
can
overload
input,
specifiers
and
point
them
to
specific
files.
D
You
know
things
made
perhaps
ways
you
could
map
directories
to
directories,
things
like
that
but
like
since
we
don't
have
that
for
common
JSI,
like
I,
think
it's
tricky
to
propose
it
for
ESM,
so
I,
don't
know,
I
think
we're
just
kind
of
in
a
tough
place
where,
where
Maine
is
incomplete,
a
synth
us
what's
the
word
I'm
looking
for
a
similar-looking
solution
for
ESM
would
be
similarly
incomplete
and
so
I'm
just
not
sure.
If
that
solves
it
yet.
E
Yes,
one
of
the
things
that
I
wanted
am
I,
actually
missed,
audible.
Yes,
so
one
thing
I
wanted
to
react
to
on
under
set
is
I
think,
at
least
in
the
past
we
had
very
strong
as
agreement
on
the
fact
that
extension
searching
would
solve
this
problem
and
I
think
Jordan
also
touched
on
this
whole
thing,
whereas
like
packaged
foods,
in
fact,
many
foods
at
least
usually
in
packages
having
both
the
MJS
and
the
Jas
in
the
same
directory.
E
Just
different
extensions
would
be
a
highly
unusual
package
layout
and
a
very
in
many
cases
how
to
maintain
layout,
because
it
will
always
be
some
kind
of
weird
foreign
body,
so
I'm
not
convinced
the
convent
acceptance
searching
is
at
least
I
would
hope.
It's
not
a
solution,
because
it
will
always
be
a
little
bit
awkward,
at
least
in
editors
maintained
by
myself.
It
would
lead
to
just
to
junk
files
in
some
random
directory
and
the
rest
of
the
implementation
is
into
other
directories.
C
Yeah
so
so
I
think
the
question
of
extension
searching
being
a
solution
requires
convention
for
extensions,
which
was
something
people
entertained
before
there
was
to
JavaScript
things
trying
to
clean
the
jas
extension.
You
know
like,
let's
eliminate
talked
about,
which
you
know
will
claim
the
jas
extension,
but
not
having
constancy.
C
So
so
dual
packages
not
being
solved
by
convention
will
require
some
fields
and
we
seem
to
be
very
hesitant
for
good
reasons
to
actually
clean
one
of
those
fields
and
go
with
it.
We're
struggling
to
like
I'm,
just
trying
to
you
know,
observe
where
we
keep
looping
back.
Is
that
every
time
we
hesitate
and
then
eventually
put
a
field
in
package.json,
and
then
we
double
back,
and
if
the
problem
can
be
solved
without
a
package.json
field,
then
we
would
have
solved
it.
C
So
maybe
the
problem
is
that
we
have
to
agree
that
we
need
to
not
hesitate
and
explore
at
least
one
or
two
ways
to
use
package.json
and
and
try
to
actually,
you
know,
nurture
a
solution
up
until
it
proves
you
know
really
disastrous
before
we
give
up
on
it
type
is
just
the
one
example
of
you
know,
trying
so
hard
to
stick
to
a
plan
to
introduce
a
field
as
simple
as
like
it's
a
it's
a
string,
it
doesn't
really
do
much
and
the
amount
of
you
know
friction
and
the
amount
of
hesitation
we
we
have
to
agree.
C
If
the
problem
can
be
solved
without
a
package.json
field,
then
we
have
to
actually
clearly
clearly
state
that
or
we
have
to
commit
to
the
fact
that
we
need
a
field.
Try
two
or
three
different
incubator
solutions
can
then
pick
one
that
has
the
least
friction
and
tell
other
people
that
believe
us
it's
better
than
the
other
two
you
know
we
have
to.
We
have
to
agree
that
a
solution
is
in
a
particular
approach
and
then
stick
to
that
approach
and
not
hesitate.
B
Okay
and
jdd
did
you
have
something
welcome
yeah,
just
to
respond
to
Saleh
yeah
I
feel
like
we're
a
little
bit
in
the
realm
of
like
the
perfect.
Is
the
enemy
the
good,
but,
like
people
want
ideal
solutions
that
cover
all
these
cases
of
like
pretty-looking
specifiers
that
also
go
for
deep
imports,
and
you
know-
and
it's
like
it's
just
how
do
we
get
from
here
to
there?
B
You
know-
and
I
mean
like
if
you
want
to
propose
some
massive
PR
that
does
a
half-dozen
things,
that
it
adds
extension
searching
and
does
XY
&
z,
like
you
know,
you
can
do
so,
but
if
any
one
of
those
six
things
that
are
bundled
together
in
your
PR,
don't
have
consensus
and
the
whole
thing
falls.
So
I
was
trying
to
get
us
like.
If
there
is
there
a
iterative
approach
we
could
take
where
we
could
just
take
any
little
thing
that
has
consensus
and
build
on
that
and
yeah.
B
It's
not
going
to
be
what
you
prefer
if
you
get
extension
searching
or
if
you
get
required,
VSM,
etc.
But,
like
you
know,
here's
a
thought.
Could
we
take
the
same
approach
that
we
did
for
the
first
big
upstream
PR,
where
we
create
a
branch
on
the
atmospheric
models?
Repo
and
that's
where
we
just
kind
of
assemble
either
the
dual
package
solution
or
all
of
phase
3?
B
However
big
we
need
to
make
it,
and
you
know
that's
where
we
could
just
like
put
pieces
in
and
they're
not
going
to
core
and
it's
we
can
build
it.
Iteratively
like,
for
example,
we
add
this
main
module
field
and
then
maybe
we
add,
require
DSM
and
so
on
and
so
forth.
We
add
extension
searching
and
then
we
get
rid
of
the
main
module
field,
etc.
B
But
we
could
go
through
all
those
steps
of
development
in
this
kind
of
private
space
out
safe
from
node
core
safe
from
releases
on
node
12
and
then
we'll
get
to
the
end
of
that
and
we'll
see
like
at
some
point.
We
will
have
to
make
a
decision.
Okay,
we're
accepting
that.
You
know
extension
searching
is
or
isn't
going
to
happen
and
therefore
this
is
what
it
is
and
then
we
and
then
we
then
we
propose
at
the
upstream.
C
I
could
I
add
one
point
to
that
early
on
last
iteration
cycles
that
we
had
I
think
that
we
have
to
all
agree
that
this
is
you
know
the
chore
is
on
us
all
and
just
having
the
critic
perspective
on
a
solution
is
good,
it's
healthy,
but
being
involved
in
a
solution.
Even
if
you
don't
necessarily
back
the
idea
as
being
the
ultimate
solution
in
your
in
your
best.
You
know
all
right
nail
world
ideal
world.
C
It's
not
necessarily
the
only
reason
why
you
criticize
something
if
you,
if
you
get
involved
in
something
that
you
don't
necessarily
you
know
buy
into
you,
could
buy
into
by
by
making
it
better
along
the
way
to
and
in
the
sense
that
it
would
actually
align
better
with
you
would
like
in
an
ideal
world,
but
also
you
know.
That
gives
a
lot
more
credibility
to
when
you
criticize
something
that
this
criticize
ation
is
not
abstract
and
I'm.
Very
abstract,
I
know.
C
B
So
we
have
eight
people,
I
guess
I
could
propose
something
that
if
we
had
guys
consensus
but
on
the
eight
of
us,
then
we
just
need
to
get
one
more
like
say
miles
or
someone
else
after
this
meeting,
and
then
we
have
something
that
we
have
consensus.
So
let
me
just
throw
this
out
there:
the
export
proposal,
the
the
one
that
the
proposal
that
creates
a
new
field
to
package
adjacent-
maybe
we
call
it
X.
Fourth,
maybe
we
call
it
main
module
whatever
we
can
discuss
that
in
a
second
yeah
the
can
we
can.
B
Can
we
merge
in
a
PR
that
creates
a
new
field
for
the
ESM
entry
point
and
then
the
understanding
is
that
a
that
could
go
away
if
and
when
we
get
extension
searching
and
be
the
this
branch
that
we're
merging
into
won't
be
up
streamed
until
down
the
line
when
we're
done
with
everything
related
to
dual
packages
and
that
it's
the
up
streaming,
it
itself
will
be
subject
to
its
own
need
for
consensus,
and
then
so.
This
would
create
the
field
and
then
the
require
of
esm
could
follow.
D
B
I
mean
we
already
had
that
I'm
talking
about
like
this
would
be
similar
to
what
we
were
doing
before.
We
did
the
first
upstream
PR,
where
I
think
it
was
I
figure
out
which
branch
it
was
modules
all
kgr,
yeah
it'd
be
intended
to
be
merged
into
that
which
then
become
the
upstream
PR,
eventually
merging.
D
In
there,
despite
what
you
just
said,
where
oh,
we
can
remove
it
if
a
lot
in
the
past,
things
that
have
been
merged
into
in
that
sense
have
not
been
so
easy
to
remove.
People
have
not
wanted
to,
and
so
I
think
that
this
that
merging
those
things
is
actually
sending
a
signal
that
it's
going
to
land
so
and
to
Rob's
comment
in
the
chat.
Yes,
if
we
have
extension
searching.
E
D
We
have
other
means
all
the
other
things
that
we
would
prefer,
then
this
exports
things
should
be
like
I
would
be
to
it,
as
would
other
people,
as
they've
indicated
so
like
it
like
I,
don't
see
why
it.
It
gives
us
any
benefit
to
signal
that
this
is
a
thing
we
should
ship
if
it's
something
that
we
decidedly
aren't
going
to
ship
in
some
scenarios,
the.
B
D
This,
where,
if
there
is
somebody
who
doesn't
isn't
super
stoked
on
the
extension
searching
but
is
super
so
stoked
on
the
field
approach,
wants
to
make
sure
it
ships,
they
will
make
sure
extension
searching.
Never
ships
and
this
thing
will
have
already
been
set
up
to
go
for
it
and
III
guess
I.
Think
that
there's
no
downside
to
leaving
like
a
bunch
of
PR
proposals,
unmerged
and
open
for
months,
while
we
figure
this
out
and
just
kind
of
getting
them
all
ready
to
land,
but
not
any
of
them.
There's
no
actual
benefits
doing
that.
There.
B
Is
a
downside
and
that
it's
really
hard
to
maintain
these
PRS
as
like,
upstream
node,
constantly,
is
getting
rebased,
so
it's
like
it
needs
to
get
merged
in
soon,
or
else
it
just
like
becomes
like
you
have
to
do
all
the
work
over
again
and
we
have
to
make
progress
as
a
team
like
we
didn't,
we
weren't
able
to
get
to
phase
two
like
we
would
never
have
gotten
there
if
we
just
had
like
18
PRS
sitting
open
for
months.
You
know
we
have
to.
We
have
to
eventually
make
decisions
and
merge
things
in
well.
D
Right
but
then
I
think
the
things
we
should
be
making
decisions
on
are
those
contentious
things
and
I.
Think
like
I,
think
it's
better
that
we
do
in
fact
block
everything
on
some
of
the
really
important
decisions
that
that
define
future
paths
forward,
because
if
we
don't
do
that,
then,
like
we've
spent
I
mean
we
spent
how
long
in
this
modules
group
not
deciding
on
the
big
things
right.
B
Let
me
just
be
blunt:
we
had
several
meetings
on
extension,
searching
yeah.
We
had
a
out-of-band
meeting
specifically
on
it
and
the
only
consensus
we
were
able
to
breach
was
this
flag,
where
it's
you
have
to
enable
it
by
opt-in,
I'm,
assuming
that
that
nothing
has
changed
since
then,
there's
more
than
half
the
group
that
were
opposed
to
extension,
searching
enabled
by
default
and
I'm.
B
D
Jeffrey,
the
consensus
we
had
was
we're
gonna
we're
leaving
it
we're
putting
it
in
with
the
flag
to
gather
feedback
so
that
people
can
choose
one
of
the
other
and
tell
us
what
they
want.
We've
already
already
gathered
a
bit
of
feedback
that
says
that
people
really
want
it
and
I
have
not
yet
seen
any
evidence
that
having
it
causes
anyone
any
harm,
so
I
think
it's
very
likely
that
it
will
land
wit
like.
B
D
F
E
D
B
D
Want
to
say
that
I'm
just
gonna
block
block
block,
because
that
has
like
that-
has
felt
necessary
in
the
past
that
that
did
not
work
out
very
well
in
the
past,
but
I
think
that
we
should
not
have
anything
whatsoever
in
package.json
is
there's
a
better
way
to
do
it.
That
is
especially
if
it's
local
to
the
file
in
question
and
I
think
that
extension
searching
is
a
much
better
way
to
do.
Some
of
these
things
right.
E
Yeah
may
I
suggest
something
at
this
point.
Yes,
for
exemption.
Searching
we
put
the
bar
at.
We
are
fine
collecting
feedback
for
editor
flag
for
up
there.
Can
we
do
the
same
for
the
package.json
fields
to
collect
feedback,
have
an
opt-in
flag
by
default
we
have
the
dots
and
then
we
can
collect
fee
pet
on
both
sides
and
I.
Think.
Another
thing
that
we
are
missing
right
now
is
for
collecting
feedback.
E
We
don't
have
what
a
good
way
to
quantify
the
feedback,
for
example,
understand
why
Jordan
is
saying:
hey,
I'm
hearing
from
all
sides
that
they
really
want
to
speak
at
the
same
time,
I'm,
not
sure
we
have
a
good
way
to
quantify
that
when
the
default
behavior
that
will
not
make
people
reach
out
to
us.
You
know
we
won't
hear
from
people
who
likely
hawk
behavior.
D
D
E
Point
is
we.
We
said
that
we
wanted
to
gather
this
feedback,
but
we
haven't.
We
haven't
specified
what
that
means
like
how
we
actually
want
to
get
the
feedback,
whether
we
would
just
want
to
it's
fine,
if
we
say
github
issues
it
and
personal
discussions
that
we
have
as
members
of
the
group
is
our
mechanism,
but
I
think
we
should
be
somewhat
explicit
about
what
we
are
looking
for
when
it
comes
to
the
feedback
yang.
D
E
D
C
C
D
C
D
B
D
B
D
Just
a
general
thing:
I
model
thing
pointed
out
that
Wazza
modules
don't
support,
live
bindings
like
not
just
that
they
can't
export
them.
They
can't
import
them.
That
seems
super
weird
to
me
and
I'm
not
involved
in
waz
Amit.
Also,
like
maybe
I,
don't
know,
guy
or
someone
else
who
is
involved
could
either
help
me
explain,
help
me
understand
it
privately
or
it
could.
You
know,
try
and
correct
that,
because
that
seems
like
a
critical
feature
of
yes
modules
that
wizened
doesn't
have
as.
F
Far
as
I'm
aware,
there's
some
kind
of
I'm,
not
a
wise
in
my
expect,
by
any
means
in
terms
of
parts
implemented
in
in
v8,
but
as
far
as
I'm
aware,
there
is
some
kind
of
process
where
wise
values
are
turned
into
J's
valleys,
unknown
imports
and
it's
a
sort
of
an
unwrapping
or
unboxing
or
I,
don't
know
what
they
call
it,
and
basically,
when
they
doing
that.
Well,
zoom
is
a
static
format,
so
everything
is
referenced.
Statically
and
it's
it's
very.
F
D
Doesn't
seem
that
every
export
from
law
allows
is
a
constant
like
it
is
that
can.
D
B
B
G
G
As
they've
been
saying,
I
have
a
pair
that,
like
I,
have
a
branch
that
does
that
the
real
question
is:
how
far
do
I
go
in
merging
the
two
resolvers
after
that,
and
that's
where
I
couldn't
get
any?
What
can
actually
talk
about?
The
last
three
times
have
brought
it
up,
because
people
have
different
opinions
about
that.
Well,.