►
From YouTube: 2022-07-28-Next 10 years of Node.js
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
I
will
push
the
button
again,
so
welcome
to
the
node.js
next10
mini
summit
on
typescript
support,
we'll
follow
the
agenda.
Well,
we'll
start
out
by
discussing
the
agenda
that
we
had
in
the
issue
which
I'll
I'll
paste
again
for
anybody
who
joined
afterwards.
They
can
add
themselves
to
the
agenda
or
say
the
attendee
list.
A
That
would
be
great,
so
I
think
we
wanted
to
start
with
a
little
bit
of
an
intro,
so
I
I'll
ask
people
to
jump
in
and
sort
of
give
a
brief
description
of
who
they
are
and
why
they're
interested
in
in
the
topic
that
we're
going
to
talk
about
today.
C
Okay,
I
don't
know
who
it
was,
but
I
can't
start
I'm
jacob,
I'm
on
the
node.js
core
team
work,
primarily
on
esm
and
loaders.
B
B
A
Yeah
I'll
go
michael
dawson
on
on
the
you
know,
one
of
the
collaborators
on
the
technical
steering
committee
as
well,
and
just
interested
in
you
know
and
helping
to
lead
the
next
10
effort
to
say,
like
let's
identify
the
things
we
think
are
important
document.
What
we
should
do
and
then
hopefully
you
know,
lay
the
groundwork
for
for
what
we
need
to
move
forward
on.
B
I'm
guilty:
I
think
that
I
was
the
one
that
was
quite
earlier.
Probably
my
mic
isn't
working,
so
I'm
using
my
phone
mic.
Can
you
hear
me
now
yep?
No,
okay,
I'm
I'm
mostly
a
node.js
user,
but
I
am
one
of
the
authors
of
the
tc39
proposal
for
incorporating
types
of
javascript.
So
that's
what
that's
my
interest.
E
Because
I
can
go
next
andrew
bradley,
the
ts,
node
maintainer,
so
all
of
the
work
that
typescript
or
that
node
does
to
support
the
work
that
I
do
is
super
important.
So
I
talk
a
ton
to
the
loaders
team
as
well.
So
if
you
might
see
me
on
those
issues,
I'll
have
to
be
silent
for
this,
but
thanks
for
hosting.
B
F
Sure
I'm
ethan
I'm
working
at
burcell
on
a
bunch
of
stuff
but
participate
in
a
lot
of
node
community
things,
part
of
opengs
world.
G
And
I
am
jake
I'm
from
microsoft
on
the
typescript
team.
I
think
that
there's
more
than
just
me
here,
but
everyone
else
I
think,
is
either
asleep
or
sick.
So.
C
Yeah,
I'm
stephen.
I
work
at
purcell
and
I've
been
a
long
time
user
of
typescript
and
node.js,
and
I
work
on
all
kinds
of
things,
but
one
of
them
relevant
here
would
be
purcell
cli
and
in
particular,
for
cell
dev,
which
supports
typescript.
B
H
B
From
some
of
the
early
days
on
on
the
modules,
work
and
node,
and
also
some
of
the
original
kind
of
loader
designs,
that
became
the
loader
flag
and
just
hoping
to
bridge
some
of
these
discussions
in
terms
of
where,
where
things
were
and
where
they're
going
and
whatever
input,
I
cannot
provide.
B
A
Okay,
it
sounds
like
we've
probably
covered
everybody
that
wants
to
introduce
themselves.
So
why
don't
we
dive
into
the
agenda?
So
what
I
I
put
on
the
draft
agenda
is,
you
know,
I
think,
from
the
earlier
discussions
and-
and
my
goal
here
is
to
like,
let's
discuss
the
agenda
and
figure
out
what
we
think
should
be
on,
but
I
started
with
you
know
a
proposal
say
we'll
start
about
the
requirements
and
desired
ux.
A
A
A
Okay,
so,
okay,
so
we
will
start
out
with
requirements
and
desired
ux
brainstorm.
A
I
don't
know
if
anybody
has
some,
you
know
you
know
somebody
wants
to
give
start
out
by
sharing
their
view
on
like
what
do.
We
think
it
should
look
like
and
then
actually
there's
a
few
more
one
more
person
to
promote
so
like
is
there?
Somebody
want
to
share
their
view
of
what
we
think
we
should
work
work
towards
in
in
node
in
terms
of
the
the
sort
of
high
level
ux,
not
the
implementation,
necessarily.
C
Well,
I
can
go
over
at
the
very
least
what
has
been
discussed
so
far
to
give
us
a
starting
off
point
and
sort
of
the
current
state
of
things.
A
C
Okay,
so
currently
adding
typescript
or
supporting
typescript
within
node
itself
is
possible
using
an
esm
loader,
and
it
requires
basically
just
a
command
line
argument
and
something
like
a
ts,
ts,
node,
a
ts.
Node
specifically
has
a
loader
that
facilitates
this,
so
you
add
it
and
it
kind
of
just
does
its
thing.
If.
C
Let
me
make
it
bigger:
yes,
yes,
yes,
yes,
exactly
so,
currently
the
the
level
of
effort
on
the
user's
side
is
basically
non-existent.
There
is
some,
but
not
not
very
much.
The
the
current
request
is
how
to
eliminate
the
the
current
level
of
effort
so
that
it
sort
of
just
works.
F
B
A
I
think
I
think
it's
like,
without
any
extra
steps,
necessarily
or
being
prompted
for
the
simple
step
which
is
like
not
necessarily
that,
like
we'd,
install
or
bundle
all
the
pieces,
but
that,
if
you
tried
to
say
no
dot,
node
ts
test.ts,
it
would
say
please
install
ts,
node
or
whatever
else,
and
I
thought
it
would
just
work.
It
was.
F
Yeah
so
you'd
still
be
able
to
run
nodescript.ts
like
assuming
you
had
the
things
installed
already.
It
would
just
work
right.
C
Are
you
saying
that
if
you,
for
instance,
already
had
ts
node
installed
that
node
would
somehow
know
to
use
it
without.
B
F
I
believe
I
mean
that's,
I
believe
that
was
part
of
the
original
issue.
That
was
the
one
before
that
this
issue
came
out
of
which
was
the
the
the
the
hooks
entry
point
hooks
proposal
and
my
my
understanding
of
and
again
you
know
we
have.
We
have
kind
of
moved
on
from
that
concept
into
you
know
accepting
that
loaders
will
be
this
way,
but
my
understanding
of
what
the
concept
was
there
is
node
will
go.
Look
for
the
global
tsc.
A
I,
I
think,
is
the
first
step.
We
wanted
to
kind
of
stay
away
from
the.
How
necessarily,
but
I
understand
it's
kind
of
like
if
it's
not
possible,
then
it
doesn't
make
sense,
but
like
just
to
say
we
don't
want
to
predefine
the
solution,
but
the
goal
is
like.
Does
that
make
any
sense
so
as
it
relates
to
that
makes
sense.
B
We
don't
want
to
like
predefine
the
solution,
but
we
should
try
and
capture
like
some
of
the
weaknesses
of
like
the
ideas
that
we've
so
far
like
that.
This
current
way
of
like
stuffing
in
node
options,
isn't
going
to
work
in
a
lot
of
environments
like
you
can't
do
that
on
lambda,
you,
like
there's
lots
of
places
that
this
just
would
not
work
at
all.
C
Sorry
when
I
said
how
I
meant
like,
if
you're
planning
to
use
ts
node
to
facilitate
this
or
on
or
swc
or
es
build,
or
what
have
you
if
there
is
no
command
line
argument?
How
is
node
supposed
to
know
what
you
want
to
use?
Is
it
supposed
to
just
keep?
Are
people
thinking
that
node
will
keep
some
kind
of
registry
of
all
of
the
available
options
and
prompt
you,
or
will
it
just
pick
one
or
is
there
actually
some
configuration
somewhere
that
tells.
I
F
To
answer
that,
my
understanding
at
the
time
when
you
know
we
were
initially
having
these
discussions
was
that
it
was
node
would
have
an
internal
thing
of
like
if
it's
a
ts
extension.
F
This
is
what
we
do
and
so,
like
I,
my
my
guess
would
be
the
you
know.
The
whatever
is
coming
from.
Typescript
is
the
one
that
we
do.
Yeah.
H
I
mean
I
thought
the
assumption
was
that,
like
there'd,
be
a
built-in
prompt
to
say
hey,
it
looks
like
you're
trying
to
do
something
that
isn't
supported
like
by
default,
but
then,
whatever
is
implemented
is
general
enough
to
do
whatever.
H
With
that
input
to
like
make
it
build,
and
specifically
there
might
be
multiple
options
for
that
whatever,
because
if
there's
one
thing
I
know
as
a
typescript
maintainer,
there
are
actually
many
different
flavors
of
typescript
and
the
one
that
runs
the
node
is
just
one
of
them
and
well,
there
are
actually
multiple
flavors
that
just
run
in
node.
Unfortunately,.
D
Yeah,
that
was
what
I
was
going
to
say.
It's
like
you
know.
Let's
not
forget
the
other
big
part
of
matteo's
request
was,
like
you
know
the
specific
desire
not
to
bundle
typescript
with
node
like
the
way
that,
like
dino,
does,
for
example.
D
I
think
that
would
if,
if
someone
were
to
try
to
propose
that,
I
think
that
would
probably
encounter
a
lot
of
headwinds
from
a
lot
of
people
that
are
part
of
the
node
project
like
I
know
it's
popular
with
dino
and
bun,
but
I
think
historically,
node
has
like
seen
itself
as
like
more
of
a
server-side
equivalent
to
browsers.
D
So
it's
like
you
know
if
a
browser
is
not
going
to
bundle,
typescript
or
support
for
it,
I
mean
unless
skills
you
know,
proposal
gets
through,
but
you
know
short
of
that,
we're
more
akin
to
being
able
to
run
what
browsers
could
run,
but
even
then
we're
we
do
beyond
that.
So
maybe
that's
not
such
a
purest
statement.
F
And
I
also
just
want
to
clarify:
I
wasn't
saying
that
we
should
bundle
typescript
with
node.
I
was
still
under
the
assumption
that
we're
we're
going
to
do
the
node
has
an
internal
kind
of
like
registry
is
a
bad
word,
but
it's
the
closest
word.
I
have
that
like
does
a
mapping
from
okay.
If
this
is
a
ts
file,
we
do
this
thing.
Whatever
this
thing
is.
D
Yeah,
so
just
to
summarize
what
was
in
this
discussion,
I
think,
like
you
know
something
that
we
certainly
could
do,
is
something
along
the
lines
of
print
some
kind
of
informative
error.
Message
of
like.
Oh,
you
tried
to
run
a
ts
file,
go
to
node.js
org,
slash
how
to
type
script,
or
you
know
whatever,
and
then
that
page
could
like
give
you
lots
of
options,
and
you
know
these
are
the
various
things
you
can
use
for
typescript
or
whatever
else
I
feel
like.
D
B
Very
quick
question
for
wes:
if
you
mentioned
how
there's
many
different
flavors
of
typescript,
if
you,
if
there
was
like
a
list
somewhere
that
those
flavors
I'm
just
just
very
quick
question
of
curiosity,.
H
H
What
I
wanted
to
point
out
is,
I
feel,
like
there's
just
like
two
core
parts
here.
I
guess
the
first
is
just
you
know,
printing
something
when
you
try
and
execute
something
with
a
ts
extension,
because
node
by
default
does
not
support
a
ts
extension-
and
you
know
whatever
thing
is
printed-
should
be
helpful
and
generally
indicate
what
you
can
do
to
make
that
work
more
right
and
the
other
thing
is,
you
know
whatever,
that
is
that
works
more?
H
It
would
be
nice
if
it
was
lower
configuration
than
you
know
like
requiring
node
options
and
using
a
loader,
for
example,
like
the
node
options
and
loader
method
for
ts
node
esm
it
doesn't
actually
even
let
you
use
a
typescript
repo,
for
example,
because
there's
no
loader
hook
for
a
repo
right
so
like
maybe
there
are
other
like
more
complete,
endpoints
or,
like
you
know,
end
points
that
wrap
node
more
completely.
That
could
also
be
useful
right.
E
J
E
F
I
I
would
also
say
I'll
sorry,
I'm
interrupting
in
front
of
the
line.
I'll
raise
my
hand.
G
G
Wanted
to
also
put
out
is
just
that.
You
know
if,
if
I
don't
want
to
get
too
caught
up
on
stuff,
like
does
node
have
a
hard-coded
list
of
like
oh
ts,
node
can
handle
the
ts
extension.
But
what
about
these
other
things
when
you
know
this
issue
at
the
very
bottom
and
in
my
brain
also
talks
about
the
fact
that
you
know
it
may
be
quite
sufficient
to
just
have
package.json
to
find
that,
like
if
you'd
like
to
run
a
ts
file,
you
can
do
it
by
running
this
motor
right.
G
A
J
Hi
everybody,
sorry,
I
kick
started
all
this
mess
and
then
I
was
super
late
at
something.
Some
other
meeting
was
running
around
super
late,
I'm
so
sorry,
so
the
fundamental.
So
there
are
a
few
fundamental
parts
that
are
that
are
problematic.
With
this
specific
snippet
that
is
being
shared.
Okay,
the
first
one
is:
it's
implies
modules,
I'm
I'm
very
I'm
stating
the
obvious,
but
probably
it
implies
that
you're
using
esm
and
you're
transpiring
as
esm.
J
Not
necessarily
the
word
is
way
bigger
than
that.
Unfortunately,
at
the
minute
and
the
vast
majority
of
the
of
typescript
stuff
is
transpiled
to
command.js,
and
I
want
something
that's
useful
for
them
right
now
and
not
something
that
useful
for
10
years.
So
I
need
that.
Okay,
I
think
that's
one
of
the
problems
and
second
or
it
is
something
that
works
for
both
okay.
It's
not
you
know
something
that
needs
to
to
work
for
both.
Second,
the
use
of
node
options
is
pretty
bad.
Like
I
I'm.
J
This
is
not
it's
most
people
will
it's
not
very
familiar
for
newbies
to
use
and
specify
an
expert
and
and
stuff
like
that
on
windows
and
so
on,
which
is
very
popular
unfortunately
still
doing.
All
of
that
is
not
super
easy,
so
and
so
loading
it
up
from
the
package.json
is
totally
valid.
Originally
I
thought
it
was.
We
were
searching
automatically
or
not
modules,
but
in
fact,
looking
at
some
config
on
packet
json
is
it's
great.
Okay,
it's
having
a
section
saying:
oh,
you
want
to
run
this
extension.
J
This
is
the
hook
that
is
being
is
going
to
be
used
easy.
Well,
it's
not
easy
to
implement
but
easy
to
to
do
easy
for
people
to
say:
okay,
so
I'm
just
going
there
and
and
configure
it
and
then
it
will
run.
I
think
that
would
be
phenomenally
good
from
from
our
developer
perspective
and
I
think
that's
the
best
we
can
achieve
more
or
less
so
yeah.
That
would
be
my
my
two
cents
tierney
you
had
your.
F
Yeah,
I
I
guess
to
one
of
the
points
that
was
made
earlier.
I
I
I
would
like
to,
and
I
and
I
think
configuring
through
packet
jason
is
fine.
F
I
would
like
to
be
able
to
download
node
from
you
know,
nodejs.org
and
be
able
to
run
nodescript.ts
happy
to
do
like
npm
install
whatever
loader
like
basically
I'm
happy
to
do
configuration
and
installation
the
steps
that
everyone
always
does
with
every
project,
but
yeah
I
I
that
is
kind
of
the
bar
of
I
don't
want
to
have
to
like
do
more
than
that,
or
I
don't
think.
Well,
I
don't
it's
not
that
I
don't
want
to.
F
I
don't
think
users
should
have
to
do
more
than
that
to
get
to
get
this
running.
E
Oh
yeah,
there
was
a
mention
of
this
snippet
implying
esm
and
I
think
it
actually
does
it
works
for
cjs
as
well
due
to
hacks.
The
loader
api
doesn't
support
that.
But,
as
I
thought
about
bringing
this
up,
maybe
it
just
means
we
shouldn't
be
looking
at
this
example,
because
I
understand
the
loader's
team
desire
to
say
yes,
we're
making
great
progress
towards
this
stuff,
but
also
looking
at
a
loader
specific
snippet
is
perhaps
distracting
from
the
higher
level
goals
that
we
really
should
be
focusing
on.
E
D
D
So
this
is
not
the
proposal
of
like
hey
the
problem
is
solved.
Let's
not
do
anything
it's
more
of
like
you
know,
we
have
a
fallback
of
plan
b,
plan,
z
and
it's
this,
so
it's
like
whatever
we
build
shouldn't
get
worse
than
this,
so
it's
sort
of
a
question
of
like
okay.
So
how
would
you
want
to
make
the
experience
better
than
what's
here?
That
was
the
point
of
this.
J
So
I
have
two
two
things:
one
is
back
from
journey.
The
reason
why
it's
not
possible
to
do
well,
it's
not
recommended
to
do
what
you
re.
What
you
said
that
somebody
can
just
download
node
run
an
npm
install
and
just
do
node
script.yes.
J
J
B
J
Well,
it's
not
the
is
down
to
our
to
the
loader
that
we're
going
to
use
okay.
What
I
mean
is,
if
you,
if
we
download
it
and
run
it
whatever
the
hook,
that's
going
to
be,
there
should
guide
people
in
creating
a
tsconfig
file,
or
something
like
that,
so
that
it's
important
now
note
that
dino.
What
dino
does
is
that
it
standardizes
the
rts
config
like
dino,
does
not
support
the
multiverse
of
typescript.
It
support
one
set
of
one
language.
J
J
You
know
it's,
I
know,
because
some
of
my
modules
need
to
support
all
of
them
so
and
it's
actually
quite
a
wild
ride
between
to
support
them
all.
There
are
a
few
competing
options
which
the
bar
used
to
do
certain
things
in
your
in
your
types.
Anyway,
that's
the
that's
my
my
point
on
on
that.
So.
F
Yeah,
I
just
have
a
quick
response
to
that
in
in
saying,
like
I
want
to
do
an
npm
install.
I
I
guess
that
it's
confusing
to
me
that
that
is
like
the
npm
install
is
the
installing.
Whatever
the
ts
thing
I
want
is
right.
So,
like
that's
installing
the
you
know
the
example
that's
on
the
screen
right
now,
ts
node,
slash
esm,
loader,
or
at
least
that's
I
mean
I
assume,
that's
how
you
get
that
loader.
F
I
hope
it
is
yeah
and
so
like
that,
theoretically
shouldn't-
and
perhaps
this
creates
more
complexity
for
node,
but
you
know
I
I
could
maybe
use
swc
slash,
loader
or
whatever,
and
maybe
we
have
a
way
to
register
that,
like
you
know,
adding
adding
the
you
know,
load,
loader
property
and
packet
json
and
then
having
typescript
colon
swc,
slash
loader
as
the
the
value
and
that
being
like
how
you
tell
node,
you
go
look
at
this
loader
for
this
extension
or
maybe
ts
just
to
make
it
clear
but
yeah
I
I
I
I
don't
think
what
you
said
is
mutually
exclusive.
F
B
J
Out
there
in
the
future-
yes,
I
I
I
can
I
can-
I
can
take
it.
This
is
complete,
whatever
happens
at
the
run
time
level
at
the
language
level.
It
doesn't
matter
at
this
point
if
you
know
the
the
way
that
the
way
the
comments
type
thing
has
been
is
being
specified
as
being
it's
completely
neutral.
Okay,
it's
still
a
javascript
file
so
and
we
are
not
I'm
not
specifically
talking
about
type
tracking
it.
Okay,
like
this
is
very
important.
I'm
not
this
one.
J
B
F
This
is,
these
are
also
orthogonal
issues
to
use
a
tc39
word.
The
the
this
is
about
supporting
typescript
usage
from
node,
which
is
type
we
see
massive
amounts
of
typescript
usage
in
the
ecosystem.
This
is
not
necessarily
about
getting
type
support
in
node.
A
Yeah,
I
think
I
should
let
roy.
C
B
Supporting
different
versions-
and
I
know
there's
a
parallel
discussion
going
on-
we
continue
the
discussion
of
rendering
packages
in
the
tooling
working
group
were
discussed
in
that
and
maybe
rendering
the
loaders,
and
I
know
it
might
be
a
lot
because
there's
a
lot
of
a
lot
that
goes
along
with
that,
but
might
be
a
kind
of
a
solution
to
to
the
multiple
versions.
Then
we
can
say:
okay,
we
support
this
version
that
is
bundled
along
with
this
version
of
node.js,
so
just
like
to
bring
that
to
attention.
I
Hey
hi,
I'm
rob
I've
I've
joined
late,
so
I
apologize
if
this
is
going
back
over
anything,
but
I
I
implemented
typescript.
You
know
a
custom
runtime
that
we
have
so
similar
like
bringing
these
things
together
and
just
kind
of
responding
to
mateo.
With
on
the
point
of
ts,
config
and
the
diversification
there,
we
found
that
you
can
divide
ts
config
into
almost
half.
Well,
as
you
split
it
into
two
categories.
I
Some
of
the
controls
are
about
type
checking
and
at
that
point,
yeah
each
project
wants
different
levels
of
strictness.
Fine,
the
other
set
of
options
inside
ts
config
are
more
about
adapting
typescript
to
the
platform
to
the
runtime
conventions
and
so
on
there,
and
for
those
we
found
that
locking
them
down
and
kind
of
in
the
way
that
dino
does
is
is
actually
beneficial,
because
a
lot
of
these
don't
need
to
vary
for
a
given
runtime
platform.
I
I
There
are
a
core
set
of
ts,
config
options
that
you
cannot
override
because
they're
considered
to
be
inherent
to
the
platform,
and
so
you
wouldn't
want
them
to
vary
if
a
project
is
designed
for
the
platform,
but
they
do
also
provide
overriding
some
of
them
as
well,
so
that
concept
of
having
ones
that
that
don't
make
sense
to
vary
versus
the
ones
that
are
per
project
and
that
layering.
I
think
there
might
be
some
value
to
that.
A
E
Yeah
I
just
wanted
to
highlight
in
terms
of
what
do
we
do
when
the
user
doesn't
have
a
config
file
or
stuff,
like
that,
a
wesley
pointed
out
the
language
service
issue
and,
more
broadly,
the
the
editor
issue
when
you're
writing
typescript,
it's
not
just
about
what
your
command
line
does
it's
about
what
your
editor
does
and
if
your
editor
is
highlighting
errors
with
certain
expectations.
E
One
example
would
be
one
of
the
new
jsx
flags
where
it
imports
it
doesn't
import
from
react.
It
imports
from
react
dev.
I
think
so
just
an
example
of
your
conf.
Your
editor
is
going
to
make
certain
expectations
around
highlighting
and
stuff
based
on
that
and
node
should
probably
do
the
same
thing.
E
So
if
we
lock
down
options,
the
question
is:
what
does
the
editor
do
when
it
doesn't
understand
that
we're
using
a
lockdown
set
of
defaults?
It
just
sees
there's
no
config
file
in
the
file
system.
I'm
going
to
behave
the
way
you
know
the
way.
That's
supposed
to
be
so
tsc
sort
of
dictates
some
some
defaults
there
and
we
should
probably
play
along
with
that,
wherever
appropriate.
H
I
mean
like
fundamentally,
it
feels
like
all
that
we
really
want
here
is
the
ability
to
install
something
either
locally
or
globally.
That
has
the
opportunity
to
intercept
and
either
modify
or
override
node's
command
line
execution.
So
like
read
the
compiler
options
provided
to
node
and
then
either
add
more
and
execute
normally
or
just
outright
intercept
it.
In
the
case
of
wanting
to
provide
like
a
different
repo.
H
F
Yeah
and
extending
on
that
slightly,
I
think,
there's
like
the
the
you
know.
The
better
economics
come
to
is
perhaps
the
part
that
we
need
to
focus
on
most.
Like
you
know,
what
is
what
does
package.json
look
like
with
this?
I
assume
that
that
is
the
only
thing
I've
heard
like
consensus
on
in
how
we
do
this,
so
I
I
just
what
I'm
assuming
we're
gonna
try
to
look
at,
but
yeah
like
figuring
that
stuff
out,
I
think,
is,
is
and-
and
the
other
thing
too
is.
F
I
don't
think
we
want
to
do
this
everything
I
I
think
I
I
think
we
probably
wanted,
and
this
might
be
a
controversial
opinion.
I
don't
know.
I
think
we
probably
want
to
scope
it
down
to
a
limited
subset
that
we
choose
to
support
and
that
subset
can
change
over
time.
So,
like
probably
not
gonna,
choose
coffeescript
like
I'm.
Probably
not
gonna
choose
to
do
the
work
for
that,
but
you
know
when
you
know
I
don't
know.
F
Next
script
comes
out
or
something
in
three
years,
and
then
everyone
adopts
that
like
supporting
that
when
it
hits
a
certain
critical
mass
that
I
don't
think
we
need
to
define.
I
I
think
I
think
gut
feeling
everyone
agrees.
This
is
what
everyone's
using
is
a
fine
measure
but
yeah.
I
I
think
I
think
scoping
it
down
to
for
now.
Type
script
is
reasonable.
B
C
Jacob,
I
think
we
don't
necessarily
need
to
do
that.
I
think
that
should
be
if
we
can't
find
a
robust
solution,
and
I
don't
think
we
are
at
that
bridge
yet
like.
If
we
go
the
package
json
route,
I
don't
foresee
a
problem
supporting
any
language,
even
something
that
only
one
person
is
using
as
long
as
they
follow
whatever
the
mechanism.
That
is
that
we
provide
under
the
hood,
be
it
a
loader
and
we
just
do
the
hookup
for
them.
I
don't
see
why
we
would
need
to
shut
the
gate
on
them.
A
Yeah,
I
think
that's
a
valid
that
was.
That
was
what
I
was
thinking
as
well
like.
I
think
we
might
get
agreement
that
if
we
have
to
limiting
scope
is
okay,
but
we
should
ideally
the
solution.
Is
we
don't
even
care?
What's
running?
We
just
have
the
hooks
and
the
ergonomics
that
let
people
plug
in
and
achieve
with,
and
once
they
do
that,
hopefully
we
don't
know
whether
it's
typescript,
coffeescript
or
whatever
right.
D
D
You
know
let
let
me
make
the
experience
as
convenient
as
possible
for
users
to
essentially
load
a
plug-in.
You
know
on
startup
that
and
then
they
can
do
whatever
they
want.
Like
the
the
sky's
the
limit,
like
even
coffee,
script,
whatever
like
like,
then
we
just
like
wash
our
hands
a
bit.
We
don't
have
to
be
involved,
but
then
everything
is
possible
and
users
can
do
whatever
they
want.
D
I
mean,
I
think
the
downside
of
that
is
that
you,
you
don't
quite
get
the
experience
of
dino
where,
like
it's
like
download
dino,
you
know
dino
file.ts
and
it
just
runs
yeah.
We
wouldn't
be
able
to
provide
that,
but
I
guess
that's
the
maybe
that's
the
first
decision
to
make
of
like
is
that
okay,
I
mean
it
might
have
to
be
okay,
because
I
don't
know
if
you're
gonna
get
like
agreement
from
the
note
team
to
like
bundle,
type
script-
and
you
know
some
set
of
configuration.
That
is
the
approved,
bundled
version.
A
Yeah,
I
I
I
think
that,
and
now
those
could
be
two
separate
steps,
even
if
there
was
a
goal
to
get
there
like
letting
providing
the
infrastructure
that
lets
you
do
anything
would
be
an
easier.
I
think,
to
your
point
step
we
could
always,
and
then
you
could
go
another
step
that
says
okay
well,
given
that
generic
framework
we're
going
to
implement
something
on
top
of
it,
which
gives
you
a
default
right.
A
E
I
was
just
going
to
take
a
stab
at
enumerating
like
the
acceptance
criteria,
so
it's
like.
We
want
loaders
to
expand
to
be
customization
hooks,
that's
great,
so
you
can
customize
the
runtime
and
it's
not
vendored.
We
want
to
opt
in
on
a
project
local
basis,
probably
the
package
json
and
then
we
want
to
opt
in
on
a
global
basis,
basically
configure
the
node
executable
on
your
path
to
somehow
automatically.
E
D
You
go
to
node.js
loaders.
The
readme
has
a
basically
like
a
roadmap,
and
many
of
the
things
you're
talking
about
are
on
here.
So
just
want
to
make
sure
people
are
aware
of
this
and
like
yeah,
you
can
open
issues
on
this
repo,
open,
pr's
against
roadmap,
whatever,
but
a
lot
of
the
things
people
have
discussed
like
they're,
like
customizing,
the
grapple
and
so
on
is
mentioned
here
and
then
just
one
other
really
quick
thing.
D
There
is
a
a
pr
about
this
already
open
and
an
issue
related
issue
in
node.js
loaders
about
like
if
we
were
to
provide
config
via
package
jason.
What
would
that
look
like
that's
still
in
the
very
early
stages
of
like
being
sketched
out,
but
just
wanted
to?
Let
people
know
with
that
that
these
exist
yeah
totally.
E
F
To
I'm
sorry,
go
ahead.
Michael,
oh,
go.
F
To
to
kind
of
respond
to,
I
think
jeffrey's
point
from
two
points
like
what
before
andrew
talked,
I
or
I
made
this-
I
remember
who
was
I'm
I'm
plus
one
to
having
it
be
totally
configurable
and
like
generic
as
long
as
one,
we
have
the
time
and
energy
to
implement
that
which
in
node
I'm
always
concerned
about,
because
more
and
more
we
are,
we
are
not
having
people
who
are
able
to
do
this,
as
you
know,
part
of
their
full-time
job,
and
so
I
I
very
concerned
about
that.
F
As
time
goes
on
and
as
long
as
the
dx
isn't
awful
like
I
we
that
that
needs
to
be
the
primary
result
of
this.
I
think
it
needs
to
not
be
convoluted
and
extremely
extra
and
so
yeah.
F
That's
that
that's
kind
of
my
primary
concern
here
is
it's
my,
and
you
know
this
is
a
do
it
right
versus
get
it
done
situation
where,
like
doing
it
right
is,
I
I
agree
having
it
be
generic
and
it's
much
easier
to
have
better
dx
if
you
just
get
it
done
and
so
like.
I
just
want
to
make
sure
we
we're
we're
getting
the
dx
correct,
because
this
is.
F
This
is
a
feature
that
you
know
breeds
that
future
innervation
of,
like
you
know
whatever
you
know
next
next
types
or
whatever
comes
up
that,
ideally
that
would
use
this
and
like
we
wouldn't
have
this
kind
of
existing
problem.
But
one
of
the
other
things
I
wanted
to
say
is-
or
I
guess
ask
is
couldn't
like
in
this
discussion
about
a
default
configuration.
F
Couldn't
the
loader
just
provide
that
like
if
we're,
if
we're
loading
a
loader
or
if
we're
pulling
a
loader
from
npm
or
from
the
registry
or
whatever
from
your
artifactory
or
whatever,
couldn't
the
loader
provide
those
defaults.
I
feel
like
that's
a
much
better
way
than
because,
since
we're
having
people
reach
out
to.
F
F
And-
and
I
I
I
I
think,
the
path
we're
going
down
is:
do
not
bundle
this
into
node,
which
is
fine,
I'm
very
on
board.
With
that,
I
I
think,
having
the
loader
choose
the
defaults
and
then
also
allow
it
to
load
it
a
config
itself,
which
should
be
irrelevant
to
us
like
that.
That
should
be
invisible
to
node
as
a
project
is
totally
fine,
and
I
think
that
is
the
the
better
dx
path
that
we
should
go
down.
A
Right,
okay,
so
I'll,
let
I
guess
mateo
and
jake,
and
then
then
I
think
we
should
move
to
trying
to
see
if
we
can
sort
of
summarize
some
of
the
discussion
I'll
pass.
I'm
good.
G
I
guess
I
have
one
question
which
is
we're
busy
looking
at
this
snippet.
That
is
explicitly
like
do
something
to
package
json
and
then
we're
talking
about
putting
stuff
in
package
json,
and
we
got
to
put
it
somewhere
right,
but
I
do
know
that
the
original
issue
basically
didn't
involve
that
it
was
basically
I
do
some
stuff,
please
install
it
and
then
run
node.ts
so
are
we?
Are
we
saying
that
we
don't
really
care
about?
The
condition
of
I
don't
have
a
package
and
I
want
to
run
typescript
or
are
we
content
with?
J
You
nee
yeah,
sorry
yeah.
If
I
can't
say
it's,
you
need
to
have
a
packet
because
you
need
to
have
a
ts,
config
file.
J
D
Just
gonna
say
like
that:
you
could
argue
that
that
problem
is
solved
with
something
like
ts.
Node
like
if
you
just
have
a
loose
like
script.ts
floating
around
somewhere
on
your
file
system.
You
could
run
it
via
like
ts.spacescript.ts
or
put
a
hashbang
at
the
top
of
script.
Fts,
that's
like
whatever
user
bin
and
ts
node
and
treat
ts.
Node
is
the
binary.
D
You
know
if
it's
sort
of
like
this,
it's
like
is
that
enough
or
do
we
need
to
improve
the
dx
of
that?
If
so,
then
it's
sort
of
like
well.
How
would
you
want
to
be
better
than
that,
and
maybe-
and
maybe
we
do,
but
I
feel,
like
that's
almost
a
whole
separate
use
case
that,
like
we
could
kind
of
yeah,
I.
D
G
You
know
figure
out
where
what
where
the
line
was
being
drawn,
because
I
mean
one
could
make
the
same
argument
and
say
like
well:
okay,
someone's
writing
all
this
stuff
so
that
they
can
run
the
node
cli
to
do
this
when
they
could
get
effectively
exactly
what
they
want
now
by
running
ts,
node
and
then
their
script
right,
like
that's,
actually
a
thing
you
can
already
do.
But
if
we're
saying
that
that's
not
acceptable,
then
we
want
people
to
run
node
directly
and
not
have
to
think
about
it.
You
know
it's.
You
know.
G
F
One
thing
I
would
like
us
to
just
consider-
and
this
is
like
a
longer
term
thing,
but
one
thing
that
has
come
up
somewhat
like
you
know,
every
collaborative
summit
has
been
the
concept
of
a
node
rc
and
not
saying
that
we
should
do
that
here,
but
just
designing
this
so
we're
not
potentially
excluding
that
in
the
future
might
be
nice.
So,
like
being
able
to
say
you
know,
node
is
going
to
use
this
loader
in
the
node
rc
and
then
that
would
solve
that
problem.
D
If
I
could
just
ask
a
question
to
the
group,
and-
and
if
this
is
too
off
topic,
then
let
me
know,
but
that
was
kind
of
like
that's
what
I
have
right
here.
That
was,
like
my
main
feedback
about
the
idea
of
adding
a
lotus
field
to
package.json
was
like
well.
This
is
just
like
one
bit
of
you
know.
That's
like
one
flag,
you
know
a
node
has
like
100
something
flags.
D
You
know
we
should
probably
design.
If
we're
going
to
put
configuration
and
package.json,
it
should
probably
be
like
all.
You
know
if,
if
not
all
the
configuration
as
much
as
of
node's
configuration
as
is
feasible
to
support
through
a
config
file
or
at
the
very
least,
have
a
design
that
it
could
expand
like
beyond
one
and
also,
I
think
it's
a
very,
very
common
use
case
that
people
have
different
configurations
of
node
for
like
local
host
versus
hosted
environment
or
you
know,
dev
and
prod.
D
You
know
multiple,
either
environments
or
ways
of
running
it,
like
maybe
you
run
it
differently
in
a
lambda
versus
you
know,
docker
or
you
know
whatever,
and
so
we
would
need
to
define
potentially
multiple
configurations
that
get
attached
to
environments
or
conditions,
or
something
like
that
that
was
just
all
kind
of
my
opinion
on
this,
like
is:
is
that
generally,
how
other
people
feel
that
certainly
would
increase
the
scope
of
you
know
supporting
config
in
a
package
of
json,
even
if
we
do
it
piecemeal
and
add
only
one
or
two,
it's
options
at
start
and
expand
it
gradually,
just
having
a
design
that
could
potentially
expand.
D
Most
of
them
would
would
raise
the
bar
of
getting
the
first
one
in
so
there
is
that,
but
with
at
least
like
give
us
the
most
leeway
of
of
supporting
whatever
people
might
want
in
the
future,
but
I
wanna
I'm
curious
how
people
feel
about.
H
I
guess
the
only
weird
thing
about
node
options
in
a
package.json
file
versus
a
separate
file
is
that
options
in
a
package.json
file
seem
to
carry
this
implicit
idea
that
they
only
apply
for
the
execution
of
files
and
contents
within
the
scope
of
that
package.
So
like
underneath
that
package.json
file
until
you
encounter
another
package
json
file,
which
implies
that,
like
loaders,
you
load
would
be
scoped
node
options
that
were
specified
in
there
only
apply
to
code
within
that
folder.
So
on
and
so
forth,
which
is
like.
H
Maybe
not
necessarily
true
or
like,
rather
that's
really
hard
to
do
for
some
options,
and
so
maybe
not
necessarily
what
you
want,
and
so
maybe
you
do
just
want
a
hierarchical
rc
file
that
you
know
has
global
options.
That
way
you
can
have
system
options
in
your
router
or
you
know,
products
all
right.
Let
me
back.
Let
me.
D
F
The
way
I'd
look
at
it
is
like
consider
it
like
an
mpmrc
or
get
ignored
like
in
that
vein,
except
you
can
also
control
it
from
package.json
like
package.json
would
be
appear.
This
is
I
I'm
pre.
I
avoid
babel
as
much
as
I
can,
but
I'm
pretty
sure
babel
does
this
too,
like
you
could
do
battle
options
in
either
battle
rc
or
packages.
H
I
mean
that's,
that's
just
my
point,
though,
like
package.json
files
are
typically
things
that
describe
stuff
that
affect
the
package,
but,
like
note,
options
affect
like
everything
about
the
invocation.
That's
happening
with
node
in
a
given
folder
right
so
like,
if
I'm
in
a
folder
that
has
a
package
json
and
I
execute
script,
slash
a
dot
whatever
and
in
script.
Folder
there's
another
package
json.
H
That
means
there
are
one
of
two
package
jsons
you
think
might
apply
and
based
on
what
you're
describing
only
one
of
the
two
would,
whereas
with
like
most
rc
type
files,
it
would
be
hierarchical
all
the
way
up
and
they
would
all
be
combined
right.
So
you
would
start
in
the
script
folder.
If
there's
an
rc
file
there,
you
would
read
it
add
its
options.
Go
into
your
project
folder.
If
there's
an
rc
file,
there
read
it
at
its
options,
keep
working
your
way
out
and
up.
D
Well,
that
gets
to
the
question
of
like
how
do
we
design
this
but
like?
If
it
doesn't
have
to
be
packages
json,
it
could
be
a
separate
file,
it
could
have
this
behavior
being
combined.
I
mean
these
are
all
open
questions,
but
like
getting
back
to
my
question,
though
it's
like
it
does
sound
like
you,
wouldn't
want
some
field,
that's
only
for
loaders
like
you
would
potentially
want
to
be
like
controlling
all
of
node's
options
through
a
config
file
like
essentially
what
the
node
options
environment
variable
does
as
a
file
is.
A
That's
what
I
was
thinking
is
that
it
should
really
be
a
mapping
from
say,
extension
to
a
set
of
options
and
whatever
those
options
may
be
like
we
know
that
some
of
them
could
be
loader
options
which
would
enable
you
know
allow
us
to
hook
into
some
things,
but,
like
it,
shouldn't
necessarily
be
tied
down
to
any
subset.
It's
just.
A
D
A
Well,
I
know
I
that's
what
I
was
trying
to
say
like
it's
whatever,
like
you
can,
whatever
you
could
specify
in
node
options,
for
example,
anything
could
be
like
it
would
be
equivalent
to
saying
we're
going
to
set
a
node
options
for
you.
If
we
see
this
extension
so
any
node
option
that
can
be
set,
you
can
associate
with
an
extension.
A
B
Going
that
yeah
there's
like
some
discussions
of
like
it
like
if
there
is
no
t,
if
there's
no
ts
config
then
just
like,
like
it,
doesn't
know
what
to
do,
but
I'm
I'm
kind
of
questioning
whether
like
the
presence
of
ts,
config,
is
actually
like
in
scope
at
all.
Like
does
that
even
matter
like?
Can
that
not
just
be.
D
B
We
like
we
can
leave
it
up
to
whatever
loader
to
decide
what
it
wants
to
do.
All
node's
responsibility
needs
to
be
is
to
load
this
thing
and
it
can
do
whatever
it
wants.
If
it
needs
to
load
a
config
file
from
somewhere,
it
can
check
and
see.
Oh
there's
no
config
file,
I'm
going
to
crash
because
I
I
need
this
or
it
might
provide
sensible
defaults,
it's
up
to
whatever
loader
thing
has
been
like
added,
so
I
I
I
don't
think
ts
config,
actually
matters
at
all
really.
B
J
You
the
ts,
comes.
We
need
to
consider
the
fact
that
we
need
a
ts
config,
because
that's
the
best
way
to
run
typescript,
okay,
so
running
typescript.
Without
the
ies
config
file,
it's
a
subpar
experience
or
some
level
of
default.
Now
you
know
you
could
install
a
opinionated
typescript
loader
thingy
that
actually.
J
Is
configured
so
that
you
you,
you
only
run
you
only
set
it
up
and
it's
it
has
already
a
preset
of
typescript,
but
we
should
not
dictate
ourselves
what
like
it's
important
to
know
that
these
exist
needs
to
exist,
and
somebody
needs
to
make
that
decision.
It
might
not
be
that
we
don't
need
to
make
that
decision
on
us.
We
shouldn't
be
us
making
the
decision,
but
we
should
design
ours
our
our
systems
so
that
it
allow
that
decision
to
be
made
and
it
works
in
a
world
where
we
are
making.
J
B
Yeah,
just
let
the
loader
do
whatever
it
needs
to
do.
If,
if
it
needs
a
ts
config,
it
can
go
and
load
that,
if,
like
I
I
can,
I
can
see
like
a
lot
of
big
companies,
would
probably
make
their
own
custom
loader
thing
that,
like
google,
always
has
their
own
like
style
stuff.
That's
we're
gonna,
like
bake
all
of
this
into
like
our
own
linter
and
our
own.
Like
all
these
tools
so
like,
I
can
see
them
having
their
own
like
typescript
loader.
A
I'm
I'm
gonna
say
if,
if
rob
and
andrew
the
last
two,
then
we
should
little
talk
talk,
maybe
a
little
bit
about,
like
specifically
the
dx.
If
we
can,
because
we've
only
got
20
minutes
left
so
andrew,
if
you
want
to
go
ahead.
E
I
just
wanted
to
say
that
there
was
some
talk
of
mapping
from
file
extensions
and
I
think
there
are
cases
where
that
won't
necessarily
work
just
wanted
to
highlight
that
it's
a
callback.
So
I
don't
think
I
should
get
into
it
now,
but.
A
I
think
that
might
be
related
like
like
things
within
typescript,
but
that
wouldn't
work
or
just
more
generally.
E
E
Should
we
support
that
experience
like
you,
have
a
webpack
config
file
written
with
the
ts
extension.
The
entry
point
is
going
to
be
webpack
and
then,
depending
on
what
kind
of
resolvers
that
we
use.
Sometimes
your
import
specifier
is
not
gonna
not
have
an
extension
at
all,
or
perhaps
it's
gonna
point
to
a
package
json,
which
then
has
a
main
field,
which
then
points
to
something
that
doesn't
have
an
extension
so
there
it's.
E
The
case
of
the
resolver
is
not
even
going
to
know
to
to
find
a
ts
file
until
you've
got
those
hooks
installed.
So
sometimes
gating
these
or
triggering
these
things
based
on
extension,
might
not
work
in
some
of
those
cases.
G
Just
just
for
reference,
webpack
and
other
tools
already
do
this,
like
they
just
go:
hey
if
you'd
like
to
have
webpack.config.ts
install
psnode
and
then
it
does
it
exactly,
it
wouldn't
be
unexpected
to
to
want
to
do
anything
like
this.
I
wasn't
sure
if
you
were
saying
you
weren't
sure
if
it
existed
or
not
so.
E
No,
no
just
highlighting
it
as
a
use
case,
because
you're
right,
the
tools
do
that.
But
it's
a
lot
of
duplicated
effort.
Every
tool
decides
to
support
this
in
a
different
way
and
every
tool
is
inevitably
hitting
the
issue
where
they
want
to
support
esm
and
then
are
finding
that
they
cannot
get
these
hooks
installed
in
process.
They
have
to
spawn
out
to
a
child
process.
D
G
Largely
that's
documentation,
but
there
I
I'd
have
to
go.
Look
it
up.
Maybe
someone
remembers
faster
than
I
can,
but
I
believe
that
there's
a
popular
config
library
that,
like
you,
can
just
say
that
emulates
this
behavior
and
it
basically
says
that
if
you
use
this
config
library,
then
we're
automatically
going
to
support
your
config
files
for
your.
You
know
your
cool
dev
project
with
the
ts
file,
because
we've
already
implemented
that
support
for
you.
I
don't
know
that
webpack
uses
that
library,
but
I
know
that
other
tools
do.
I
think.
G
That
might
be
one
of
them,
but
I
don't
know
that
it
is
well
anyways.
D
A
Okay,
so
I
think
at
this
point
it
would
be
good
to
see
if
we
can
spend
the
some
of
the
remaining
time
to
sort
of
write
down
a
few
lines
of
what
the
dx
we
think
we
should
be
targeting
looks
like
I
did
write
very
short
just
from
you
know
some
of
the
discussion
we've
had,
which
is
probably
not
not
it,
but
as
a
starting
point
you
know
people
want
to
try.
I
don't
know
what
the
best
way
to
do
it
but
like.
If
we
want
to
try.
A
A
A
A
We
tell
people,
we
don't
know
how
to
run
it
now,
but
if
you
install
here's
a
link
to
go
to
that,
will
let
you
tell
you
how
to
install
everything,
yeah,
okay-
and
I
could
see
in
our
in
our
context
of
like
not
limiting
it,
but
not
trying
to
cover
everything.
We
could
make
a
generic
message.
That
says
you
know
we
don't
know
how
to
handle
that
particular
file.
Extension,
unknown
extension.
A
A
H
Right,
like
you,
could
easily
just
start
by
adding
a
message.
That's
just
like.
Oh
you've,
you've
included
this
file.
That
looks
like
it's
probably
a
ts
file.
Did
you
mean
to
npm
installed,
cs
node
and
that's
that's
that's
literally.
Just
all
it
suggests
all
most
people
would
need.
F
C
F
Yeah
and
that's
why
I
was
saying
we
should
do
a
link
like
you
know,
node.js.org,
like
for
a
eight
times.
D
D
A
But
I
I
think
I
think
this
is
where
we
can
easily
get
into
a
long
discussion,
and
so
maybe
the
you
know,
I
don't.
A
But
but
like
agreeing
that
at
very
least,
we
can
point
to
a
page
on
the
node.js
project
with
instruction
that's
neutral,
and
I
don't
I
don't
think
we'll
get
into
that
long
discussion
of
which
ones
have
to
be
there
or
not.
We
can
defer
that.
So
that's
why
I
propose
we
have
like
you
know.
A
A
Yeah
rob
you
have
your
hand
up.
I
Yeah
so
on
this
subject
of
kind
of
like
allowing
the
marketplace
uploaders
and
directing
people,
maybe
maybe
we
can
start
with
that
being
like
generic
and
you
know
and
fuzzy,
but
I
think
ultimately,
what
is
beneficial
for
the
ecosystem
is
and
and
what
people
really
really
want
is
really
for
it
just
to
work.
I
So,
ultimately,
I
think
if
we
can
be
opinionated
about
at
least
which
one
we
endorse
and
rally
around
around
one
that
is
kind
of
necessary
for
ecosystem
coherence,
because
these
packages
have
to
work
with
with
each
each
other.
For
the
typescript
at
least.
C
I
know
as
long
as
they
work
with
us.
That's
all
I
really
care
about,
and
I
don't
want
to
be
building
and
rebuilding
this
every
time
some
new
typescript
comes
along,
so
I'm
kind
of
on
the
build
it
and
they
will
come
kind
of
front
like
this
is
what
it
looks
like:
here's
how
it
works.
If
you
want
it
here,
it
is.
F
A
I
think
we
could
get
in
a
really
long
discussion
about
this.
I
think
the
point
is
that
adding
an
opinion
can
be
valuable,
but
I
don't
think
we're
going
to
agree
on
on
whether
we
should
choose
an
opinion
or
not
or
what
that
opinion
would
be,
but
I
think
that
should
be
on
our
agenda
as
like
next
steps,
I
think
it's
it
can
hopefully
be
just
this.
A
This,
like
I
wouldn't
want
to
tie
that
to
like
doing
a
concrete
step,
which
is
jeffrey
said,
like
this
thing,
that's
written
down
here,
we
could
do
today
and
takes
a
step
in
the
right
direction.
If
that
later
is
changed
to
say
and
here's
our
opinion
at
the
very
top
of
the
one.
That's
that's
a
future
I
could
see,
but
I
think
we
should
defer
that
to
a
different
discussion.
If
people
agree
with
that.
D
F
H
F
A
Right,
okay,
so
again,
because
we're
we're
down
to
nine
minutes,
it
sounds
like.
We've
got
reasonable
consensus
around
like
the
what
happens
when
you
don't
have
something
plugged
in
so
now
we
want
to
if
we
want
to
go
to
the
next
step,
where
it's
like.
Okay,
we've,
given
your
message,
you
go
and
you
do
the
install
what
happens
and
what
I've
written
down-
and
I
know,
there's
there's
concerns
about
extension
but
like
somehow
we
need
to
map
what
you've
installed
to
what
you're
trying
to
run.
I
I
was
thinking
the
you
know.
A
A
D
H
The
question
is
more
like:
why
does
it
need
to
be
extension
based?
The
idea
is
generally.
If
you
install
something
in
the
right
place,
then
it
should
be
hooked
in
right,
like
that.
That
should
be
all
you
need
to
do.
I
would
assume,
like
there's,
no
need
to
configure
anything
on
a
per
extension
basis.
If
the
thing
you've
installed
handles
the
stuff
that
you
want
right.
Okay,.
A
F
Yes,
the
loader
loader
has
loader
can
hook
into
the
extensions
and
that
allows
like
mts
and
what
the
all
the
variants
that
yes
now
supports:
okay,
yeah!
No
that's
fair!.
D
I
think
I
can
describe
it
yeah.
I
think
it's
it's
what
it's!
What
antoine
has
in
that
pr?
Just
for
beyond
loader
like
here's,
the
anton's
pr,
it's
essentially
like
for
any
entry
point
run
in
this
folder
or
like
controlled
by
this
package.json,
where
the
nearest
parent
package.json
is
the
one.
With
this
configuration
when
you
run
an
entry
point
under
this
package
scope,
here's
the
configuration
that
node
should
run
for
that
entry
point.
F
In
talking
about
conf
in
dx,
though,
like
node
entry
point,
config
is
way
too
dense
of
a
name
for
that
like
that.
That
is
a
very
that's,
not
a
good
path.
Whatever
yeah
we.
D
Don't
need
to
worry
about
that
right
now,
but
the
the
that
would
be
the
the
ux.
I
guess
and
then
the
if
you
need
a
different
config
for
different
entry
points
like
you
have.
You
know
server
and
client
code
in
the
same
folder
or
something
like
that
that
you
would
just
have
to
you
would
have
to
like
split
them
into
subfolders
with
different
package
adjacent
files
or
use
node
flags
to
like
load.
This
configuration
versus
that
one
or
something
like
that.
D
Yeah,
well
I
mean
once
you're
attaching
a
loader,
then
it
can
do
whatever
it
wants
to
to
mix
the
match,
configuration
etc.
Well,
I
guess
well,
I
guess,
maybe
not
because
the
problem
is
that,
like
node's
already
running
by
that
point,
like
that's,
that's
what
makes
it
so
difficult.
Is
that,
like
it's,
you
know
it's
it
it's
stuff
that
needs
to
be
pulled
into
node
very
early
and
nodes
start
up
like
before
it
ever
can
like
parse
a
javascript
file.
A
D
Essentially
yeah,
and
maybe
if
you
want
the
non-default
like
if
you're
not
using,
if
you
want
like,
say
the
dev
config,
then
you'd
have
to
define
that
somehow,
maybe
a
flag,
I
don't
know,
but
we
would
need
to
figure
that
out.
J
I'm
not
convinced
of
that
flow,
but
yeah
we
can
probably
work
actually
there's
not
much
time,
so
we
can
probably
action
it
on
on
github,
because
they,
I
was
thinking
like
if
we
loaded
them
from
package.json
like
if
you
have
genetic
node
options,
okay,
and
we
always
need
to
look
for
a
package.json.
J
D
You're
only
looking
for
it
once
just
for
the
entry
point,
so
it's
like
you
know,
even
if
we
made
it
as
a
like
node
options.json
or
whatever
it's
a
very
minor
hit
to
you
know,
because
it's
only
just
the
entry
point.
It's
not
like
like
right
now
we're
looking
for
the
controlling
package.json
for
every
single
file.
You
load
across
your
entire
tree,
like
even
inside
their
modules
and
so
on.
A
D
A
Like
it
might
be,
an
argument
against
package.json
in
that
case,
right,
like
something
more
like
the
rc
file,
would
make
sense
more
like
that
seems
like
a
natural
fit
for
you.
You
have
an
rc
file
in
your
github
repo
and
you
might
have
a
different
one.
You
overlay
for
prod
or
for
tests
versus
overlaying
the
package
json
with
different
versions.
I'm
not
as
sure
as
I
don't
know,.
D
D
Well,
we
have
a
dash
conditions
flag
right
now,
that's
already
part
of
node,
so
I
was
kind
of
imagining
you'd
probably
tie
into
that.
Somehow,
where,
like
the
default
is
production,
if
it's
not
specified,
there
is
a
default
and
the
default
is
production
and
that's,
like
you
know,
what's
in
package
adjacent
or
something,
but
it's
like
if
you
run
with
dash
dash
conditions
or
condition
conditions
of
your,
if
it's
plural,
like
conditions,
equal
dev,
it
somehow
knows
to
load
a
different
config,
either
a
different
config
file
or
a
different
block
within
the
file
or
something.
A
A
Okay,
so
we're
actually
at
time
you
know
so
this
is
this
is
what
I've
written
down
in
terms
of
the
dx.
A
D
D
This
would
work
for
common
js
as
well
as
the
sm,
so
I
think
we've
I
think
we've
covered
all
of
the
use
cases
that
have
been
discussed
other
than
the
fact
that,
like
this
is
even
more
steps
than
the
exhibit
that
we
started
with
at
the
start
of
this,
but
even
that
can
be
automated.
Somehow,
like
you
can
you
know,
maybe
our
instructions
could
be
like
like
run
npx,
typescript,
init
or
whatever,
and
it
creates
the
config
block
or
something
like
that.
Well,
you
can
also.
F
D
Yeah,
like
I
don't
know,
if
do
we
want
to
include
this
in
the
list
of
like
you
know,
get
people's
well
or
maybe
that
could
just
be
a
future
improvement.
Once
we
give
the
instructions
automating,
the
instructions
could
be
a
later
improvement,
but
you
know
that
I
just
thought
it
was
worth
pointing
out
that
this
is.
This
is
an
even
longer
series
of
steps
than
than
what
people
have
now
so.
A
But
I
think
in
these
steps
are
all
meant
to
happen.
So
in
one
case,
if
you
start
it
and
it's
not
installed
you're
just
going
to
get
a
message
in
the
other
case,
you
start
it
and
if
you've
done
the
install,
it
just
runs
right.
So
you
don't.
D
A
question
of
like
yeah:
we
maybe
let's
just
build
the
feature
first
and
then
building
the
automation
for
making
it
faster
to
get
set
up,
could
be
a
later
improvement
and
there
could
be
lots
of
different
ways
to
do
that.
We
mdm
init
or
you
know
within
node,
who
knows
what,
but
we
can
write
it
in
the
leader.
A
D
Yeah,
like
I
could,
I
could
easily
imagine
like
npm,
init
typescript,
and
it
just
like
you
know
when
it's
creating
that
package
with
json.
It
just
includes
some
opinionated
config
block
for
like
what
would
be
an
opinionated
default.
You
know
config
for
typescript,
with
a
config,
with
a
typescript
over
etc.
H
So
like
this
is
all
well
and
good
for
like
scripts
and
applications
and
that
kind
of
stuff,
but,
like
a
philosophical
question
that
I
just
want
people
to
think
about,
is
like
how.
How
can
you
support
this
and
then,
at
the
same
time
discourage
people
from
shipping
libraries
that
only
contain
typescript
source
code.
D
H
Right,
it's
just
that
the
this
is
maybe
more
of
like
the
broader
and
broader
concern
about
like
how
publishing
traffic
with
the
npm
and
other
registries
works,
but
like
when
we're
talking
about
this
process,
we're
essentially
taking
someone's,
build
pipeline
and
running
it
for
them
when
they
run
their
application
right.
But
when
you
ship
a
library,
there's
no
blessed
or
like
taken
for
granted
build
step
when
you
ship
a
library
to
npm,
you
have
to
explicitly
build
something
right,
and
so
maybe
that's
another
thing
that
you
should
consider
when
you're.
Considering.
D
I
feel
like
that's.
We
could
let's
wait
to
see
if
that's
a
problem
before
we
because,
like
I
feel
like
a
lot
of
people,
would
complain
about
such
a
package
because
it's
like
not
just
that
it's
hard
to
run
the
code,
but
also
that
like
well,
you
just
ship
ts
files.
How
am
I
supposed
to
know
what
ts
can
take
to
use
with
them?
I
mean
like
it's
just
so
annoying
to
deal
with
that.
I
feel
like
they've
got
so
many
complaints
from
users
that
they
would
be.
H
I
mean
that's
why
I
bring
up.
We
already
get
complaints
with
users,
because
there
are
packages
that
do
this
by
mistake
already,
even
though
no
doesn't
support
executing
typescript
like
in
any
way,
except
through,
like
ts,
node
or
something
like
people
like,
do
it,
because
they
think
it'll
be
cool
or
a
good
idea.
H
And
when
you
like
ship
a
feature
like
this,
you
lead
people
to
believe
that
it'll
be
supported
like
more
by
the
run
time,
and
it
might
very
well
be
supported
by
whatever
loader
you're
using.
But
that
has
many
downsides.
And
so
that's
why
it's
one
of
those
things
that
you
probably
want
to
discourage
in
some
way
or
provide
like
a
good
alternative.
E
D
Like
maybe
there's
someone
out
there
who
really
wants
like
100
typescript,
even
you
know
even
including
their
node
modules,
and
you
know
I
mean
ideally,
I
think
at
least
like
packages
that
ship
typescript
should
ship
javascript
as
well.
But
you
know
that
feels
like
not
our
problem,
like
maybe
maybe
npm
could
do
some
kind
of
check
during
mkm
publish
that,
like
oh
you're,
not
publishing
any
javascript
files,
you
should
you
know,
did
you
mean
to
do
that
or
you
know
I
don't
know.
H
Right
like
what
I
just
wanted
to
prove
is
that
there's
a
certain
symmetry
between
like
this,
like
options,
loading
and
like
preparation
for
publishing
right
there
they're
both
things
that
describe
how
you
want
something
to
be
executed
in
the
case
of
publishing.
You
want
something
to
be
prepared
for
execution
later,
whereas
in
the
case
of
the
immediate
execution
of
node,
you
want
it
to
be
executed
right
now,
right,
and
so
there
are
parallels
between
the
two.
E
I
wonder
if
I
wonder
if
another
way
to
think
about
that
is
like
just
think
about
the
the
user
experience
of
someone
who
wants
to
run
their
ts
directly
in
dev
and
wants
to
pre-compile
for
publication,
and
what
does
that
developer?
Experience
look
like
for
them,
because
if
they
have
a
package.json
exports,
config
with
hard-coded
paths
that
end
in
dot
js,
that's
good,
that's
what
they
should
be
doing
for
node,
but
it
means
you've
got
a
module
specifier
that
ends
in
dot
js,
but
in
dev.
E
You
want
that
to
work
correctly.
So
you
want
that
to
map
to
the
ts
file.
What
does
that
mean
in
terms
of
draping
behavior
off
of
file
extension?
The
loader
has
to
be
eagerly
loaded
so
that
it
can
do
that.
Mapping
stuff
like
that.
So
I
think
similar
to
how
we
plan
for
users
to
be
using
a
language
service
that
is
outside
of
nodes
control.
We
can
also
plan
for
users
to
be
pre-compiling
and
that
can
help
drive
design
decisions.
B
C
A
Okay,
we
are
at
time,
so
I
guess
it's.
You
know
I
don't
have
a
hard
stop,
but
we
should
figure
out
like
okay.
So
if,
if
this
is
like
do
we
have
consensus
here?
The
next
step
is
like.
I
could
take
an
action
to
pr
that
into.
We
have
like
our
maintaining
types
support
like
basically
try
and
capture
it
somewhere,
where
we
can
have
broader
collaborator
input
as
well,
and
then
I
guess,
like
there's
also
as
jeffrey
mentioned,
some
existing
issues
and
stuff
where
the
discussions
can
continue.
A
C
Well,
should
we
start
actioning
any
of
these
things
like
that
error,
message
thing
and
creating
a
page
on
node
like
node.org,
nodejs.org
yeah,
we
can
do
right
now
and.
D
C
Who
who
handles
the
node.js
or
site?
I
know,
there's
two
now
right,
there's
that.
F
There's
a
repo,
the
dev
one
is
like
a
potential
work
in
progress,
one
that
may
or
may
not
ship
the
node.js.org
repo
in
the
node.org,
the
node.js
org,
that's
not
confusing
at
all
node.js
slash
nodejs.org
is
the
correct
place.
I
I
would
recommend
we
do.
Some
kind
of
this
is
a
problem.
F
I
see
a
lot
is
people
doing
a
link
that
is
embedded
forever
and
then
not
having
the
ability
to
can
change
that
link
later
so
having
some
kind
of
redirect
for
this,
like
a
simple
redirect,
would
be
very
smart,
I
think
but
yeah
that's
the
repo.
C
F
D
C
Do
we
need
to
give
a
team
a
heads
up?
Are
we
gonna
drop
a
pr
on
them
and
they'll
be
like
what
are
you
doing.
F
A
Do
is
figure
out
where
it
fits
with
the
node.js
site
and
when
the
pr
goes
in
point
back
to
the
minutes
for
this
meeting-
and
you
know
have
that
one
paragraph
that
says
like
here's,
what
we're
doing
and
that
should
provide
the
context
that
they
would
need
to
say:
okay,
yeah,
we
understand
this
is
meant
to
be
permanent.
Why
is
it
on
the
site
and
then
all
of
that.
D
There's
a
guide
section
on
the
side
too,
but
anyway
later
so
step
four
would
then
be,
I
think,
before
we
get
to
a
pr
we
have
to
like
do
like
a
I
could
open.
I
could
open
like
a
discussion
issue,
maybe
on
the
main,
node
repo,
that's
for
designing
the
config
file
or
file
based
configuration.
D
Yeah,
like
I
say,
file
based
config
because
it's
like
it
might
not
be
its
own
file.
It
might
be
packaged
that
json
or
something
else,
but
but
then
yeah
we'll
see
how
that
goes
because
there's
a
lot
of
you
know
that'll
require
a
lot
of
hashing
out
of
ideas
and
maybe
some
meetings
just
for
that
and
then
that
can
then
eventually
and
then
you
know,
whenever
we
nail
down
a
design,
we
can
open
vr
for
that.
D
And
then
but
the
design
there
would
have
to
fulfill
the
requirements
that
you
have
up
above
in
the
your
like
dx
section
yeah,
so
that
number
five
would
be
like
pr
to
implement.
You
know:
config
design.
A
D
C
D
Well,
I
think
step
one.
The
the
first
version
of
this
would
be
the
like.
We
would
just
put
the
config
to
do
it
in
the
instructions
like
in
the
whatever
doc
page.
We
create
with
instructions
once
once
file
based
configuration
exists,
we
could
update
the
doc
page
to
you
know
have
an
example
config
right,
okay,
you
know,
and
then,
if
we
want
to
automate
it
beyond
that,
we
could
you
know
we
could
do
so,
but
you
know
at
the
very
least
we
would
just
document
it.
B
A
A
Yeah
thanks
for
everybody's
time,
this
I
think,
was
very
productive
and
great
to
have
the
everybody's
insights
and
different
knowledge
and
all
that.
So
I
think
it
worked
very
well
and
I
guess
we'll
see
everybody
in
github
and,
as
jeffrey
said,
there
may
be
some
additional
sessions
and
stuff.
But
so
maybe
we'll
see
you
again
soon.