►
From YouTube: Node.js Foundation Modules Team Meeting 2019-11-20
Description
A
We're
now
live
with
the
November
20th
meeting
of
the
node.js
modules
team,
I'm
joined
by
six
other
individuals,
five
of
whom
are
active
members,
meaning
that
we
currently
have
quorum
that
we
have
you
know
not
the
fullest
agenda,
but
I
think
enough
stuff
to
talk
about
kicking
it
off.
Before
we
start,
we
do
have
to
open
requests
to
add
new
observers.
A
A
Thinking
right
here,
cool
is
there
anyone
who's
on
the
call
right
now
who
is
not
an
observer
or
an
active
member
cool?
Then
I'm
gonna
go
ahead
and
I'm
gonna,
add
those
two
members,
I'll
close
the
PRS
and
whatnot
and
then
for
agenda.
We
have
four
things
on
the
agenda:
module,
attributes,
RFC
chartering
the
team
loader
hooks
and
get
a
package
type.
A
B
So
from
CoffeeScript
perspective,
it
was
brought
up
in
the
thread
that
CoffeeScript
wants
dot
coffee
files
to
essentially
match
whatever
the
file
format
of
a
dot.
Js
file
is
within
a
package
boundary,
so
they
want
to
be
able
to
determine
the
format
of
a
dot
JS
file.
If
it
should
exist
within
the
package
boundary,
it
could
be
a
hypothetical
and
be
able
to
compile
and
specify
that
dot
coffee
files
compile
to
that
format.
B
For
a
little
bit
of
history,
in
case
people
didn't
know
it
so
CoffeeScript
doesn't
actually
have
full
control
over
its
build
artifacts.
Those
are
controlled
by
different
asset
pipelines,
and
so
when
a
CoffeeScript
pipeline
is
generating
files,
it's
didn't
generating
dot,
J's
files
generally,
and
so
here
they
just
want
to
ensure
that
they
are
kind
of
staying.
True
to
that,
it
seems
there
are
some
considerations
here
and
API
design
wise
though
we
have
seen
some
comments
from
typescript
here
that
they
would
certainly
like
a
specific
API
design.
B
Perhaps
the
API
design
considerations
come
around
if
we
should
directly
exposed
the
typed
field
or
the
underlying
database
mappings
that
we
have
internally
in
nodes,
runtime
I've
personally
commented
on
this
I
think
either
is
potentially
able
to
fill
the
use
case.
I
have
concerns
about
misuse
and
for
its
compatibility
if
we
don't
expose
enough
information
or
enough
configurability
that
people
will
get
disparate
systems
in
place.
So
an
example
of
this
was
when
they
were
talking
about
a
use
case
in
the
issue
thread.
B
They
neglected
the
fact
that
the
dots,
ejs
extension
actually
doesn't
populate
the
way
they
thought
it
did
in
our
internal
database,
mappings
of
extension
to
file
format,
and
this
also
repeated
itself
a
little
later
on
in
the
thread
when
typescript
was
discussing
that
they
would
seek
to
add
a
plethora
of
file.
Extensions
specific
to
typescript
such
that
typescript
could
have
a
similar
user
experience
to
what
it
has
today
and
doing
so
would
mean
that
tools
would
need
to
coordinate
with
typescript.
Somehow
so
anytime.
B
We're
talking
about
these
tools,
we're
talking
not
just
about
a
single
tool,
but
a
potential
coordination
of
tools.
You
can
see
this
in
a
real-world
example
where
es
lint
didn't
have
access
to
this
API,
so
it
kind
of
does
workarounds
and
tries
to
load
files
and
slightly
odd
ways
in
order
to
get
es,
lint
RC
files
to
load
properly,
with
the
experimental,
well,
no
longer
experimental
modules,
well,
no
longer
flat,
but
still
experimental
modules.
B
So
we
do
have
some
real-world
examples
of
things
going
on.
They
could
use
this
and
we
have
some
kind
of
design
considerations
that
we
should
be
taking
a
look
at.
We
do
have
an
old
issue
in
this
working
group
about
exposing
the
ability
to
configure
these
file
format,
databases
within
package.json
files
themselves,
and
so
that's
been
cross-referenced
near
the
end
of
the
issue
thread
here.
B
It
doesn't
necessarily
have
to
be
within
package
JSON
or
something,
but
just
allowing
them
to
configure
it
themselves
and
then,
after
that,
we
can
take
into
consideration
how
they
configure
so
yeah.
Those
are
the
three
topics
I'd
like
to
bring
up
so
first
one.
Do
people
have
comments
or
concerns
about
exposing
this
mechanism
to
users,
and
if
so,
are
there
limitations
or
other
things
that
might
alleviate
those
concerns?
I.
A
Guess
I
have
a
clarifying
question
Brad
so
in
my
mind,
an
API
that
would
be
really
useful
and
apologies.
Cuz
I
haven't
had
a
chance
to
keep
up
on
the
entire
thread,
but
an
API
that
would
be
useful
would
be
an
API
that
you
could
pass
a
path
to
a
file
and
it
would
then
tell
you
you
know
how
node
is
how
node
will
interpret
that
file.
A
So
I
think
that's
a
little
bit
a
be
of
a
different
API
than
what
we've
talked
about
in
the
past,
which
was
you
know,
an
API
that
could
parse
a
file
and
let
you
know
what
like
definitively,
what
the
type
of
the
file
is.
So
to
me,
the
useful
API
would
be
like
hey.
How
is
node
planning
on
running
this
file,
not
necessarily
like
what
exact
format
is
this
file?
A
B
B
A
C
Right
so,
but
I
mean,
as
I
could
put
a
I
could
make
a
speculative
file
path
and
as
long
as
the
like,
it
pointed
to
a
directory
that
existed,
you
could
then
look
up
and
see
well
based
on
its
extension
and
on
the
package.json,
that's
nearest
to
it.
This
is
what
we
would
parse
it
as
if
it
existed.
That's.
C
But
I
guess
it
would
be
a
little
tricky
if
the
path
didn't
have
an
extension,
because
that
is
still
needed
to
be
supported
for
CJ.
Yes
right
like
if
I
did
/foo,
because
you
wouldn't
know
with
what
the
paths
were,
but
then
you
could
even
have
that
API
return
like
an
array
of
option
of
answers
like
based
on
what
the
priorities
it
would
pick
or
something
I
don't
know
that
might
be
more
complex.
A
D
D
E
C
C
The
weeds
here
but
I
guess
it's
more
like
there's
a
few
different
kind
of
overlapping
and
related
use
cases
that
might
we
could
possibly
meet
here
right.
One
is
like
which
loader
does
it
use,
and
in
that
case
you
don't
really
have
to
deal
with
a
real
file
and
you
don't
have
to
deal
with
the
extension
searching.
You
just
say
it's
either
this
loader
or
that
loader
right
and
the
common
Jas
loader.
Can
they
encompass
all
that
other
stuff.
C
To
do
file
extension,
searching
or
mandate
that
the
file
exists
like,
like
you
know
what
I
mean
like
either
have
those
two.
You
have
one
of
two
worlds
that
you
can
support.
One
is
we
can
take
a
speculative
path.
The
other
is
based
on
the
file
system
as
it
exists.
What
would
it
be,
but
then
that
second,
one
wouldn't
really
help
the
CoffeeScript
B's
case,
where
there
isn't
necessarily
a
file
I,
don't.
C
B
F
All
right,
I
think
the
more
important
thing
I
would
want
to
point
out
is
that
I
believe
guys.
Comment
in
the
thread
is
spot
on,
which
is
this
feels
like
something
that
really
really
should
be
a
user
level
imitation
and
not
as
exposing
this
API,
because
when
I
think
of
typescript
of
web
pack
or
anybody
else
who
wants
this
in
most
cases,
they
actually
aren't
interested
in
hitting
the
file
system.
F
So
my
gut
feeling
at
least,
is
that
we
could
expose
this
API
and
be
Bakst
into
supporting
a
very
specific
way
that
it's
implemented
and
that
is
exposed,
and
then
it
would
end
up
not
actually
being
helpful
to
any
one
of
these
people,
because
what
they
actually
want
is
a
more
generic
implementation
or
implementation
that
can
take
a
virtual
file
system.
Well,
it
takes
callbacks
for
making
the
process
of
interactions,
so
I
think
officially
supporting
an
NPM
package.
F
It
does
it
maybe,
but
it
feels
like
something
that
as
a
core
API
is
not
as
useful,
because
you
would
also,
then,
if
you
are
using
it
in
the
types
of
compiler
than
the
types
of
compiler
I
would
need
to
make
sure
that
it's
running
in
a
load
version
that
has
this
API.
Even
if
the
code
is
compiling,
doesn't
it
gets
really
really
weird
if
this
is
a
build,
an
API
used
by
tools.
F
C
I
was
just
asked
what,
if
I,
wanted
to
build
this
userland
library
right
now?
What
would
I
have
to
manually
replicate
the
resolution
logic
or
are
like
because
if
so,
then
my
next
question
would
be?
Are
there
components
that
node
could
could
support?
You
know
could
expose
that
would
make
it
easier
to
build
a
user
LAN
library
around
that
and
there's
the
question
of
backwards
compatibility
built-in
thing,
but.
F
Well,
my
assumption
is
that
this
has
nothing
to
do
with
the
resolution
that
you
would
always
have
a
file
path,
you're
interested
in
and
you
already
resolved,
because
the
resolution,
at
least
any
resolution
scheme
that
we
have
been
talking
about,
is
not
dependent
on
the
type
information.
So
anything
that
queries
the
system
would
already
have
a
fully
resolved
path.
That's
interested
in
whether
they're
finally
high
path
existence
different
question,
but
it
would
have
a
path
it
is
querying.
F
So
I
think
that
if
you
look
at
the
thread
and
guys
example,
implementation
like
it
is
literally
just
yes
encoding
the
logic
of
how
we
interpret
the
type
fields
or
how
we
interpret
the
package.
It
isn't
metadata,
but
I
mean
that
it's
literally
just
this
relatively
small
loop
of
going
up
the
directory
tree
to
look
for
publication
and
on
returning
a
relatively
small
bit
of
information.
F
Even
if
you
do
full
type
resolution,
so
I,
don't
I,
don't
give
him
the
complexity
that
this
problem
has
so
far
been
shown
to
half
I'm,
not
sure
that
there
is
a
meaningful
core
API.
That
would
actually
make
a
difference,
while
still
allowing
people
to
actually
write
the
packages
that
their
needs,
which
are
explicitly
not
dependent
on
notes,
notion
of
a
file
system.
All
that
stuff.
G
So
so
I
I,
don't
like
the
looseness
of
speculation.
When
we're
dealing
with
the
file
system,
you
can
speculate,
but
since
you're
a
tool
you
could
actually
influence
the
file
system
and
and
so
giving
you
a
cleaner
API
where
you
can
declare.
How
are
you
gonna
influence,
something
so
that
you
can
speculate
accurately
I,
don't
like
that
Luce
scenario,
honestly,
I
feel
that
it's
gonna
be.
It's
gonna
require
a
lot
of
coordination
and
it's
gonna
be
hard
to
make
it
appealing
to
everyone.
Equally,
it's
gonna
be
biased.
Basically,
so
so,
but
I
don't
mind.
G
G
They
only
require
the
precondition
that
if
you
need
to
modify
P
JSON
files,
you
do
that
before
calling
both
functions
and
that
condition
speculation
not
not
necessarily
too
much,
but
it
also
covers
I
believe
the
use
cases
that
most
tools-
I'm,
you
know
just
I-
think
it
covers
most
cases.
That
tools
would
be
interested
in
I'm,
not
sure
if
others
have
ones
they
want
to
race.
So.
A
D
Well,
so
looking
at
this
ticket
I'm
not
sure
this
is
the
API.
That
would
actually
be
useful
to
me,
I
think
and
I'm.
Sorry
if
this
is
unrelated
different
thing,
but
for
me
I'd
want
to
know
the
ultimate
result
of
the
result,
which
would
include
the
results
of
any
loader
hooks.
I
know
that
that's
still
experimental
but.
D
A
A
A
A
B
So
we've
been
talking
a
lot
about
if
we
should
expose
it,
it
seems
like
we
can
continue
debating
that
I
would
like
to
instead
try
I
to
shift
the
topic
to
if
we
should
allow
customizing
these
format-
databases
if
possible.
Just
since
we
have
a
limited
time,
we
do
have
an
open
issue
about
that.
It's
been
open
since
February,
and
this
seems
to
tie
into
that.
Oh
that's,
all.
E
E
E
So
when
we
talk
about
implementations,
drifting
or
having
those
sort
of
issues
in
the
wild,
in
those
discussions
with
people
and
and
with
other
tooling
and
any
discussions
we
have,
we
have
a
resolver
spec
and
the
spec
defines
exactly
how
these
bits
work
and
exactly
how
the
semantics
work.
And
if
they're
questions,
that's
that's.
When
we
can,
we
can
bring
that
back
to
the
spec,
and
maybe
we
need
to
highlight
the
spec
better
or
give
it
its
own
page
or
something,
because
it's
really
quite
important.
E
A
So,
guy
what
I,
what
I
think
is
maybe
missing,
then,
if
that's
the
direction
that
we
want
to
go
I
find
that
implementation
in
spec
are
great,
but
it
also
requires
tests,
and
so
when
you
think
about
what
happens
at
tc39,
it's
kind
of
the
marrying
of
all
three
you
have
the
spec.
Then
you
have
the
web
platform
tests.
Then
you
have
the
implementation
and
the
platform
tests
are
an
extremely
important
part
of
ensuring
that
various
implementations
are
all
compliant.
A
B
B
This
goes
beyond
this,
however,
if
we
ever
extend
the
format's
that
we
support,
we
also
will
be
breaking
that
and
we
will
be
forced
to
have
these
implementations
go
out
of
date.
Just
as
people
are
concerned,
they,
oh,
we
will
run
typescript
on
a
version
of
node.
Without
this
API,
you
could
be
running
typescript,
an
old
version
that
doesn't
support
the
level
of
module
formats
that
your
current
node
version
supports.
It's
a
two
directional
street
and
I.
B
Don't
feel
comfortable,
not
exposing
this,
because
we
are
seeing
pains
already
with
this,
like
people
can
implement
this
on
their
own,
yes,
but
they
can
also
implement
their
own
HTTP
server
off
the
net
API.
That
doesn't
mean
we
should
say
no
just
because
it
can
be
done,
and
it
doesn't
mean
we
should
say
no
just
because
they
spec
exists.
Http
exists
as
I
spec,
but
that
doesn't
mean
that
people
want
to
have
different
versions
of
things
running
without
coordination.
B
When
we
talk
about
loaders,
we
often
talk
about
supporting
new
formats
and
if
we
don't
provide
a
way
for
these
loaders
to
get
the
format's
in
the
first
place,
we
seem
to
have
counteracted
part
of
our
goals.
I,
don't
see
having
a
spec
is
a
means
of
saying
we
are
forwards
compatible
here.
We
need
to
provide
the
proper
hooks
such
that
our
forwards
path
is
supported
and
has
a
means
to
coordinate
with
the
ecosystem.
B
A
F
Yeah
I
I
partially
agree
with
that.
Lee.
Yes,
if
you
are
running
specifically
in
a
load
of
you,
would
want
to
have
some
sort
of
information
about
the
currently
active
extensions.
But
if
you
are
not,
if
you're
doing
precompilation
with
TSE,
you
still
need
this
map,
but
you
are
not
running
in
the
same
node
process
that
will
be
running
the
code
that
meets
the
extension
that
so
having
the
implementation.
F
Node
would
mean
that
you
would
then
need
to
start
node
with
the
flags
that
and
then
run
to
you
see
with
the
same
flags
that
the
final
application
would
run
with,
which
seems
really
weird
so
I.
Think
realistically,
TSE
would
have
to
have
this
information
as
a
separate
channel
if
it
wants
to
support
any
kind
of
precompilation,
so
it
could
not
use
the
API,
even
if
we
had
it
just
because
it
would
not
be
reliable
outside
off
a
loader.
G
F
B
F
A
Know
quick
interruption
is
this
something
that
can
now
be
taken
offline,
Joe,
ok,
sorry
for
interrupting,
but
we've
gone
over
by
quite
a
bit
and
we
still
have
a
few
agenda
items
so
I
think
that,
right
now
we
do
not
have
any
conclusion.
We'll
pick
kick
back
to
github
for
more
discussion.
Is
there
anything
else
that
we
should
add
there
right
now
or
no.
A
Ok,
so
then,
the
next
item
on
our
agenda
is
the
module
attributes.
Rfc
I
can
introduce
this
one
and
then
you
know
folks
may
have
some
content
that
they
want
to
want
to
add.
So
this
proposal
for
the
module
attributes
was.
It
was
brought
up
at
tc39
as
a
response
to
concerns
at
w3c
and
won't
work
group
regarding
JSON
modules.
So
for
a
bit
of
history,
JSON
modules,
respect
in
the
HTML
spec.
They
landed
then
@e
pack,
this
summer,
a
number
of
folks
from
different
vendors.
A
I
think
specifically
Mozilla
and
Apple
flagged
on
security
concerns
with
the
current
implementation,
with
the
way
that
they
were
initially
implemented,
which
is
what
we
support
with
experimental
JSON
modules.
If
you
import
a
JSON
file,
it
will
parse
gern
the
fetch
evaluate
during
the
fetch
phase,
export
only
a
default
object
and
be
a
leaf
node.
The
security
concerns
with
how
that
was
Specht
was
that
you
were
reliant
on
a
server
providing
the
appropriate
mind
type
and
and
source
over
the
wire
to
do
what
you
expected.
A
If
you
imported
thing
JSON,
but
a
server
responded
with
text,
slash,
JavaScript
and
a
module
that
in
turn
would
then
actually
just
execute
a
module
based
on
how
the
loaders
work
in
the
browser.
This
was
seen
as
a
security
concern
specifically
that
entry
points
that
are
expected
to
not
execute
could
execute.
A
A
C
D
C
A
C
Like
to
me,
if
you
import
something,
you
are
immediately
delegating
full
trust
to
it
and
like,
if
you
don't
trust
it,
you
shouldn't
import
from
it,
and
so,
if
it's
a
cross
domain
file-
and
you
know
that
you
don't
control,
don't
import
from
it.
Thank
you.
That's
kind
of
the
same
thing.
If
you
like,
pull
in
JavaScript
from
you
know,
another
domain
or
whatever
right
like
the
security
consideration
here
is
well
what,
if
some
you
know
the
it
changes
from
JSON
to
j/s
and
then
does
something
you
don't
like.
A
C
J
s
so
like
I,
just
don't
think
that
I
think
that,
no
matter
what
the
outcome
of
this
is
in
tc39
like
it,
you
know
the
if
there's
syntax
added,
of
course,
node.
We
have
to
support
it,
but
short
of
that.
I
think
that
any
canny
handling
of
this
should
stay
within
the
web
and
nodes
should
not
have
a
worse
UX
as
a
result
of
it.
B
Minor
correction:
this
isn't
specifying
the
type
that's
being
import,
it's
specifying
the
allowed
type
to
import.
So
it's
not
a
disambiguation
mechanism,
we're
still
using
mime
type
to
determine
the
format.
We're
just
having
an
assertion
added
I.
Think
the
big
problem
here
for
us
is
a
model
working
group
I'm
uncomfortable
stating
that
should
impose
specific
security
models
to
match
the
web
and
I'm
also
unclear
how
this
affects
node
and
why
we
should
do
it.
There's
the
concern.
That's
not
really
being
discussed
if
the
web
requires
these
attributes.
B
B
There
are
a
few
very
minor
edge
cases
which
I
can
believe
are
potential
gains
here,
where
you're
importing
one
level
deep
without
redirects
a
JSON
file
from
an
untrusted
origin,
but
importing
CSS
and
HTML
wasum.
All
these
other
things
have
complications,
including
things
like
the
templates
from
HTML
modules
being
able
to
expand
the
dependency
graph.
So
even
if
the
e.r
loaded,
they
can
produce
side
effects
later
on
blossom
same
sort
of
deal
CSS,
you
have
some
attachment
issues.
These
seem
to
be
an
odd
solution
to
a
problem
that
I,
don't
believe.
B
Note
has
and
I'm
not
sold
that
the
web
is
actually
solving
what
it
is
stating
to
solve.
I
think
bringing
this
here.
We
should
be
keen
on.
Can
we
implement
this
because
there's
an
interoperability
issue
for
us
and
should
we
implement
this
for
me,
I
think
we
can
implement
this
I,
absolutely
think
we
can
I,
absolutely
don't
think
we
should.
B
A
Thank
You
Brad
I
have
a
bit
to
add
and
then
I'll
hand
it
off
to
Yann
Jordan.
You
said,
like
you,
think
it's
premature
to
bring
to
this
group
I
disagree
with
that
sentiment,
primarily
because
I
believe
that
it
is
important
to
get
feedback
from
this
group
if
this
is
something
that
will
actually
move
forward
at
tc39
as
Brad
was
mentioning.
You
know
like
this
could
be
a
pivot
point
that
you
know
make
some
behavior
on
the
web
completely
incompatible
with
nodes.
A
So
if,
if
our
you
know,
if
our
conclusion
on
this
is
like
you
know,
we
don't
want
to
implement
it,
then
I
think
that
we
absolutely
should
be
coming
to
the
committee
with
that.
So
they
can
know
that,
while
making
decisions
here,
I
don't
know
that
I
entirely
agree
Brad
with
your
assessment
that
this
has
nothing
to
do
with
node.
You
know
we
have
discussed
the
possibility
of
loading
modules
over
HTTP
or
HTTPS.
A
More
specifically,
so
I
do
think
that
if
we
ever
found
ourselves
in
a
world
where
we're
loading
things
over
the
network,
we
very
much
are
in
the
same
place
from
a
security
perspective
and
I
understand
where
you're
coming
from
and
saying
that
you
don't
think
that
this
is
the
proper
or
potentially
full
solution
to
the
problem.
That's
been
identified.
A
I
do
think,
though,
that
if
we
want
to
see
JSON
modules
exist
on
the
web
platform,
we
do
need
to
come
up
with
a
solution
that
is
palpable
to
those
who
you
know
are
the
implementers
from
these
different
browsers.
So
if
node
wants
to
have
interoperable
JSON
modules,
we
have
to
find
a
way
to
come
up
with
something
whether
it's
in
band
or
out
of
band,
that
everyone
can
get
on
the
same
page
with.
If
we
can't
or
we
don't,
then
I
guess
either.
A
F
Yeah
I
definitely
concerned
about
the
current
direction
of
the
proposal,
which
seems
to
be
going
towards
the
full
type
assertions
which
I
think
is
bad
like
even
on
the
web
and
I.
Think
that
some
of
the
use
cases
outlined
in
the
wrapper
for
the
web
are
questionable,
like
protecting
for
every
single
kind
of
file
type
for
accidentally
serving
the
wrong
content.
Type
errors,
but
not
for
JavaScript
seems
really
weird.
F
F
Http
enforced,
it
hasn't
personally
make
it
more
valuable,
but
even
without
having
that
last
document
seems
very
nice
perfectly.
If
the
proposal
is
supposed
to
move
forward
with
the
current
scope
of
literally
documenting
what
kind
of
file
types
are
acceptable
on
a
very
fine-grained
level.
I
I,
don't
see
us
in
familiar,
you
know,
don't
see
anybody
realistically
using
it
like
nobody
using
webpack
will
annotate
every
single
import.
That
is
not
JavaScript
with
an
additional
two
or
three
or
four
tokens.
B
Brad
I
think
we
should
be
careful
about
talking
with
a
security
model
for
HTTP
in
node.
It
is
very
different
from
what
the
web
is
with
its
same
origin
policy,
because
node
can't
implement
that
actually
Dino
did,
but
Dino
has
a
different
kind
of
spun
up.
Runtime
and
sandboxing
features
that
node
doesn't
have.
D
F
Mean
in
this
context,
it's
just
about
the
fact
that
you
can
say:
hey
I,
want
to
read
this
Quantic
format
from
the
server
and
I
expect
it
to
be
just
data.
It's
not
about
origins
or
anything.
It's
just
about
being
able
to
document
that
I'm
not
expecting
this
remote
file
to
execute
code,
which
I
think
is
a
nice
thing
to
have
well.
B
F
But
in
in
the
note
case
that
we
are
currently
talking
about
it's
literally
on
a
per
URL
basis,
you
say
that
you
well
your
exam,
you
don't
trust
it.
It's
it's
definitely
also
different
from
the
web
and
that
this
proposal
says
you
need
to
annotate
the
ones
that
you
don't
trust
so
I,
don't
think
it's
even
using
the
web
security
model
as
its
currently
expect
in
the
proposal.
A
B
G
F
Think
the
place
where
I
would
see
it
being
problematic
is
the
kind
of
GS
bridge
which
would
because
we
don't
really.
We
didn't
actually
know
what
that
thing
will
be,
and
we
can't
really
forward
that
information
where
he
would
be
super
awkward
to
do
it
so
assume
that
we
would
treat
all
Commons
you
as
it
were
modules
because
from
the
module
loader
perspective,
it
technically
is
module.
I
think
that's
the
only
place
where
I
would
see
a
potential
witness.
In
the
note
implementation.
A
Okay,
so
it
seems
like-
and
you
can
correct
me
if
I'm
wrong,
where
we're
at
right
now
is
no
one-
seems
to
think
we
wouldn't
be
able
to
implement
it
from
a
technical
perspective.
But
there
are
questions
about
whether
or
not
we
should
implement
it.
From
a
philosophical
perspective,
would
people
say
that
that's
an
accurate
description,
I'm.
A
Okay,
some
of
us
are
heading
to
the
meeting
coming
up
soon
as
someone
who's
one
of
the
champions
of
this
proposal.
You
know
like
one
of
the
important
bits
to
this
would
be
like
we
have
to
figure
out.
If
this
has
legs
Jordan,
you
know
the
way
in
which
you
framed
it
makes
it
sound
like
you
do
not
believe
that
it
has
legs.
A
C
Clarify
I
do
not
expect
in
any
way
I
will
be
the
lone
objector
on,
or
you
know,
I
don't
even
think
I
will
need
to
object
for
this
thing
not
to
have
legs.
I
think
that
that
the
entire
design
of
the
module
system
and
the
import
syntax
and
as
Bradley
has
talked
about
the
actual
security
model
of
the
web
and
the
lack
of
that
security
model
on
other
implementations
is
just
not
gonna
fit
together.
Here.
C
A
And
I
think
with
that
in
mind,
what
might
be
useful
for
us
to
think
of
as
a
group
independent
of
whether
or
not
it's
how
we
implement
it
in
node
would
be
like
what
could
potential
out
of
band
solutions
be,
but
for
the
sake
of
time,
four
minutes
left
I
think
I
think
maybe
we
need
to
wrap
this
up.
There's
two
more
things
on
on
the
agenda,
which
is
one
is
chartering
and
the
other
is
hooks
I.
Don't
think
we
really
have
time
to
deal
with
either
of
those.
What
do
people
think?