►
From YouTube: Node.js Tooling Group Meeting
Description
A
A
You
know,
we
know
that
people
have
done
stuff
like
this,
and
so
site
is
a
company
that
had
at
least
one
one
or
two
different
tools
to
to
do
this
sort
of
thing,
and
one
of
those
I
think
correct
me
if
I'm
wrong,
it's
the
pkg
package,
I
assume
yeah
is
the
one
that
does
this
in
particular.
Is
that
correct
correct?
A
B
Have
PKG
which
bundles
into
a
single
binary
NCC,
which
tries
to
bundle
into
a
single
file
and
now
node
file
trace,
which
traces
dependencies
of
a
project
by
traces?
What
do
you
mean
I'm
so
across
the
file
system
and
tries
to
determine
all
the
files
that
will
be
required
at
runtime
and
drops
everything
that
won't
be
used
just
to
create
like
a
mini
moles
of
pile
or
something
like.
B
B
B
A
A
And
so,
but
I
mean
I,
I
haven't
looked
at
the
source
of
that
or
anything,
but
I
can
only
imagine
that
you
know
it's.
What
you
end
up
with
with
is
is
a
very
large
standalone
binary,
which
basically
contains
all
of
node.
It
contains
all
your
files
right,
you
know,
it's
are
you
using
anything
I
mean
you
said
you're,
maybe
not
the
right
person
to
ask,
but
I
guess
I'm
curious,
like
are
you,
you
know
like
changing
nodes,
bootstrap
or
anything.
B
A
Mean
yeah
I
mean
I,
suppose
I
could
I
could
dig
into
it
too,
since
the
source
is
up
there,
but
I
think
it
seemed
like
doing
that.
Sort
of
thing
is
kind
of
I'm
going
to
guess
that
was
kind
of
a
pain
in
the
butt
to
implement
and
what
you
get
the
result
is.
Yes,
it's
self-contained,
but
it's
not
really.
D
A
Because
there's
just
so
much
cruft
right,
I,
don't
know
if
you
went
and
you
started
disabling
modules
and
node
or
anything
like
that,
but
but
the
other
there's
Darcy,
so
the
other
part,
of
course,
is
you
know
you
you
have
to
have
this.
You
have
to
compile
node
right.
You
have
to
like
do
he'll
of
complement
compilation
to
make
this
work
so
for
once
worth,
I
think
it.
E
Does
think
it
skips
some
of
this
stuff,
if
I
understand
correctly
so
I
think
my
understanding
so
I've
dug
through
the
source
code,
but
it
was
like
a
while
ago
now.
So
this
is
totally
for
memory
and
I
could
be
totally
wrong.
But
if
I
remember
correctly,
it
uses
the
VM
module
and
then
just
uses
a
precompiled
node
for
the
Platt
target
platform
and
then
just
bundles
a
little
wrapper
around
it.
C
F
C
F
So
there
was
an
approach
suggested
by
Bradley
a
number
of
years
ago.
I
can't
remember
exactly
when,
but
it
was
basically
having
it.
So
you
could
have
a
tarball
or
maybe
some
other
kind
of
package
like
with
a
package
or
something
like
that
that
could
be
appended
to
the
nude
binary
and
their
node
binary
would
detect.
Okay
I've
got
something
a
pendant
to
me.
I'm
gonna
go
ahead
and
load
that
rather
than
an
indexed
address
or
whatever
else.
So
that
was
an
interesting
approach,
but
I'm
not
sure
that
would
anywhere
beyond
just
a
suggestion.
C
G
D
A
E
So
that
might
be
fine,
though,
depending
on
your
requirements.
So
one
other
use
case
here
that
is
a
you
know,
I
think
an
interesting
one
is
shipping
a
pre
compiled
version
to
a
production
web
server
right
so
think
about
you
know
the
stuff.
The
demo
is
doing
to
try
to
make
and
actually
secure
platform
right
and
they're
saying
you
have
to
opt
in
to
everything.
E
If
we
wanted
to
have,
you
know
some
some
extra
security
layers,
you
know,
as
somebody
you
know
who
has
heavy
investment
in
shipping
node
to
production,
web
servers,
it'd
be
pretty
nice
to
you'll,
say
like
no.
We
know
this
application
shouldn't
have
file
system
access
because
we've
bundled
all
the
JavaScript
together
right
and
so
now
it's
all
in
one
thing:
we
don't
even
need
file
system
anymore
right.
E
We
don't
need
all
these
other
things
that
could
possibly
have
security
vulnerabilities,
that
we'd
be
able
to
compile
out
and
that
doesn't
necessarily
matter
for
the
you
know,
maybe
an
open
source,
CLI
or
something
but
I.
Think
for
you
know
a
company
like
right
work.
It
would
probably
be
something
we'd
be
interested
in
doing
that.
A
C
That's
maybe
actually
like
a
separate
topic
is
being
able
to
limit
things
like
file
system
access
or
network
access.
I
thought
I
remembered,
like
maybe
a
year
or
more
ago,
someone
creating
like
a
third
party
package
that
would
let
you
somehow
specify
that
in
your
code,
I
think
you
could
sort
of
like
opt
in
and
say
like.
These
are
the
the
things
that
my
my
package
requires
and
then
I
think
just
like
throw
an
exception
or
something.
If
you
tried
to
use
something
outside
of
that
I.
Don't
remember.
C
F
Basically,
it
would
doing
so
through
what
you're
suggesting
we
could
set
up
a
set
of
policies
over
core
node
api's,
not
just
well
now
you
could
use
them,
but
also
like
what
you
could
do
with
them.
That
kind
of
thing,
that's
a
huge,
huge
security
topic,
perhaps
beyond
the
scope
of
what
we're
talking
about
here.
C
Yeah
I
do
think
that's
an
interesting
topic,
though
maybe
gap
for
future
meetings
or
something
like
that.
I
think
it's
sort
of
like
adjacent
to
this
issue
of
compiling
binaries
but
I,
know
that's
something
my
company
would
be
very
interested
in
as
well
like
to
be
able
to
say
for
compliance
reasons
like
this
code
can't
write
to
the
file
system.
This
code,
you
know,
can't
make
outbound
network
requests.
It
can
only
respond
to
requests
things
like
that,
so
I
don't
yeah.
Maybe
that
becomes.
E
A
Know
like
not
to
derail
too
much
here
but
like
the
the
what
I,
I
guess,
I'm
personally
interested
in
with
with
the
surface.
How
can
we?
How
can
we
make
this?
So
we
know
that
you
can
use
pkg
and
just
do
this
in
ship
a
thing
and
I.
Don't
know
if
there's
limitations
on
what
it
can
do,
but
you
know
let's,
let's
pretend
it
just
works
right,
so
we
know
you
could
do
that.
We
know
you
can
grab
an
entire.
A
You
know
no
package
or
whatever
and
just
like
stuff
everything
in
this,
like
maybe
a
self-extracting
executive.
All
that
knows,
but
you
can
do
that
right,
but
I
mean
I
guess.
What
I
would
like
to
know
is
is
what
can
node
core
do
to
to
make
this?
Like
a
can?
Can
we
make
this
easier
for
somebody
to
go
in
and.
A
Create
kind
of
change
change
the
way
node
node
executes.
Okay,
so
maybe
that's
changing
its
bootstrap
and
I
know
there's
there's
ways
to
do
this
now
and
the
other
thing
is,
you
know:
how
can
we
make
it
perform
it?
How
can
we
make
it
smaller?
You
know
instead
of
shipping
the
whole
bucket
of
stuff,
we
don't
we
don't
ship
all
of
it
or
you
know.
A
How
can
we
reduce
the
startup
time
if
we
know
that
all
we
need
to
do
is
start
the
VM
and
start
running
code
and
then
and
then,
of
course,
the
the
third
you
know:
I
guess:
okay,
I
guess
this
is
the
first
part
again
to,
but
it's
like.
How
can
we
make
this
easier?
How
can
we
make
it
so
people
don't
don't
have
if
they
want
to
distribute
this
way,
they
don't
have
to
like
install
all
this
crap
to
to
build
node
from
from
scratch.
Like
is
there
a
way
we
could?
A
We
could
maybe
even
create
a
distributable
of
node
that
you
could
use
for
this
purpose.
I
don't
know,
but
that's
kind
of
what
I
wanted
to
do.
What
do
you
want
to
get
in
and
what
I
wanted
to
understand
about?
Pkg
was
like
what
problems
did
you
run
into
when
you
were
building
this
thing
and
what
could
have?
What
could
have
been
easier
for
you
to
do
this
in
in
you
know
in
core,
because
that's
I
think
a
lot
of
what
this
group
is
about.
A
E
D
C
Yeah
sorry,
if
I
derail
things
there,
a
little
bit
I
do
think
that
should
be
a
separate
issue.
I
think
one
of
the
things
that
started
I
think
the
first
time
we
ever
had
this
topic
on
the
tooling
agenda
was
because
someone
there
was
a
new
API.
It
was
like
the
v8
like
snapshotting
API
or
something
so
that's
sort
of
on
the
topic
of
bootstrap
like
speed.
I,
think
that
was
the
the
thing
that
started.
C
Into
a
binary
that
you
can
start
very
quickly,
that's
I
mean
that's
one
of
the
best
things
about
ncc
is,
if
you,
if
you're
from
another
package
with
NP
acts,
and
you
haven't,
bundled
it
with
NCC
like
I,
guess
the
example
like
Joe
and
I
were
talking
about.
There's
a
recom
when
you,
if
you
do
NP
x,
create
react
app.
C
It
takes
like
I,
don't
know
six
seconds
or
something
before
the
command
runs,
whereas
for
create
next
app,
they
bundle
they
built
it
with
MCC,
and
it
starts
in
like
under
half
a
second
like
a
very
dramatic
difference
and
for
CLI
tool
like
running
a
command
and
then
waiting
six
seconds
is
not
ideal.
Do.
B
Me
guys
largest
wins
most.
The
winds
come
from
eliminating
the
whole
file
system,
traversal
stuff
on
boot-up,
so
everything's
going
to
be
a
single
file,
so
download
size
is
ultra
minimal
because
this
even
improves
over
the
wire
speed
and
then
obviously
you're
only
reading
in
a
single
javascript
file.
So
yeah.
E
Which
is
great,
I
think
there's
other
ways
we
can
help
solve
that
as
well.
So
I
I
have
an
issue
open
on
the
modules
working
group
right
now
to
look
at
doing
import
Maps,
which
would
at
least
get
rid
of
a
ton
of
the
tree
traversal
parts
of
the
file
system.
Reading
it
still
doesn't
turn
it
into
a
single
file,
which
is
obviously
ultimately
the
best,
but
anyway
I
just
thought.
It'd
be
interesting
to
know
if
it
was
just
being
a
single
file.
C
At
least
I
mean
the
single
file
makes
I
think
the
biggest
difference,
at
least
on
the
bootstrap
side
of
things
right,
but
then
there's
still
the
the
file
size
issue
and
I
mean
NCC,
doesn't
ship
with
node
it
just
bundles
your
JavaScript.
So
it
doesn't
have
that
problem.
It
also
didn't
have
that
advantage
of
like
someone
has
to
have
node
installed
in
order
to
run
your
tool,
so
I
think
yeah
I
think
they
dropping
the
core.
Api's
is
more
related
to
just
slimming
down
the
binary
size.
A
And
so
I
mean
this.
This
is
makes
sense
to
me
as
far
as
just
kind
of
common
sense,
but
if
you're
using
NCC
and
you
publish
so
essentially
all
of
those
versions
of
dependencies
are
locked
because
they're
embedded
in
their
bundle,
essentially
it's-,
and
so
if
there
was
like
a
security
concern
or
something
with
one
of
them.
It's
on
the
maintainer
z'
of
whoever
is
shipping
the
bundled
javascript
file
to
make
sure
they
upgrade
right
away.
Users
won't
automatically
get
those
based
on
some
sort
of
December
range
right,
correct.
B
F
Mean
the
other
thing
is
it's
kind
of
congruent
while
making
your
own
work
but
similar
to
how
in
note
itself,
when
there
are
issues
with
the
dependencies.
In
note
itself,
you
know
that's
a
compiled
thing.
It's
got
all
of
its
dependencies
like
open,
SSL
and
and
in
various
other
things
built
in
it's
the
same
sort
of
story
right.
B
A
A
E
Think
if
you
think
about
CL
eyes
as
standalone
applications,
it
just
makes
sense
to
ship
them
as
a
locked-in
version.
I
mean
you,
you
know,
that's
why
we
have
packs
lock
and
you
don't
ship,
you
don't
rebuild
a
lease
in
your
production.
You
know
environment
for
your
web
servers
either
right,
you
lock
down
and
you
have
predictable
builds
and
when
you're
on
a
version
that
is
a
locked-in
you
know
set
of
dependencies.
I
think
thing
about
your
CLI
is
in
the
same
way
is:
is
perfectly
reasonable
and
I
don't
think
we
should
seek
to
change.
A
C
C
B
B
C
D
B
A
B
B
C
E
E
The
NCC
part,
not
the
the
pkg
part
right,
not
the
node,
bundling
node,
and
there
was
some
library
that
used
like
this
thing
called
additions,
which
was
like
some
weird
way
to
do
fad
packages
right
so
ones
that
had
like
source
written
in
new,
yes,
six
stuff,
but
then
would
also
ship
bundle
down
bs5
and
then,
like
some
other
random
version.
I
can't
make
a
whether
what's
the
precursor
to
the
requirejs
UMD
style
definitions,
and
it
did
like
this
dynamic
thing,
and
so
there
was
no
normal
entry
point.
E
It
ended
up
getting
like
trying
to
read
the
file
and
that
just
flat
totally
broke
with
this
kind
of
methodology,
because
it
was
doing
more
complicated
stuff
than
even
the
like
webpack
style
bundle
and
everything.
It
think
it
could
that
even
didn't
work,
so
there
are
edge
cases
there,
but
it
did
work
for
things
like
expresses
views
again
for
the
same
kind
of
reason.
It
did
bundle
everything
in
the
views
directory
so.
A
A
E
E
What
could
we
read
with
FS
dot,
read
file
right
and
that's
what
a
lot
of
these
modules
are
doing
so
I'm,
not
sure,
that's
like
necessarily
a
goal
that
we
should
try
to
solve.
I,
think
a
more
reasonable
goal
would
be
the.
How
do
we
bundle
a
bunch
of
JavaScript
into
a
node
app
like
that
like
we
were?
We
were
tight.
E
C
Yeah,
even
even
as
a
starting
point,
I
think
that
would
be
good
you
could
you
could
bundle
your
app
even
with
something
like
NCC
and
then
append
that
blob
of
JavaScript
to
binary
and
that's
changed.
That's
the
entry
point,
even
as
that
would
be
a
good
first
step
that,
after
that,
we
could
maybe
consider
things
like
how
do
we
slim
down
the
node
binary
in
this
case,
and
things
like
that.
E
C
G
For
this
bundling,
how
would
you
deal
with
the
special
location
variables?
The
double
underscore
file
named
ur
name,
import,
meta
URL,
like
I,
know,
for
a
rollup
I,
basically
have
a
babel
plugin
that
rewrites
the
import
meta
URL
to
kind
of
remap
it
to
the
original
location
or
my
web
deployment.
Basically,
I
install
a
copy
of
the
node
modules
that
were
used.
That
way,
for
example,
if
something
uses
important
meta,
URL
to
reference,
say
a
PNG
file
that
can
still
get
the
appropriate
URL.
E
I'm
not
sure
what
we
just
proposed
with
those
three
points
would
necessarily
have
to
cover
that
that
would
still
fall
into
the
NCC
or
roll-up
or
whatever.
You
know,
tooling,
you're
doing
to
bundle
the
JavaScript,
whereas,
like
I,
think
what
we
proposed
just
a
second
ago
was
only
the
once.
You
have
a
bundle
appending
it
to
and
turning
it
into
the
entered
point
for
a
binary.
Oh.
F
E
F
It
this
loader
hooks
I
mean
the
the
promise
loader
hooks
is
that
doesn't
necessarily
apply
to
like
arbitrary
file
system
access,
so,
for
example,
like
any
of
the
loading
of
images
or
other
assets
like
that
that
wouldn't
necessarily
be
covered
by
loader
hooks
right,
so
far,
system
hooks
would
be
sort
of
another
thing
in
sort
of
there
are
toolkit
of
hooks.
That
would
allow
us
to
kind
of
pretend
that
things
are
in
certain
places
when
they're
not
interesting.
C
A
F
A
F
Not
not
only
that
right,
because
if
it
were
only
about
require
or
import,
then
we
could
rely
mostly
on
the
loader
hooks
or
at
least
since
my
understanding,
I
haven't
looked
probably
closely
enough
at
loader
hooks
to
definitely
say
but
I'm
pretty
sure
those
would
handle
those
cases.
The
more
interesting
bit,
though,
is
assets
that
aren't
JavaScript
files
right,
think
things
like
it
see
a
lot
of
no,
no,
that's
good
things
like
your
images
or
whatever
else.
Maybe
your
your
public
or
your
static
folder.
F
F
C
C
A
A
D
D
So
we
can
already
have
a
sort
of
stretch
goal
of
supporting
running
some
of
these
sub
commands
across
all
the
workspaces.
That's
already
a
kind
of
a
stretch
goal
so
but
yeah,
maybe
to
the
tooling
group
yeah
and
it's
a
good
question
for
all
of
you
to
have
in
mind
like
what
what
can
we
maybe
do
to
better
improve
tooling
around
this,
like?
Maybe
it's
going
to
be
in
the
further
RFC
release
or
maybe
can
makes
its
way
into
this
original
one
I
don't
know,
maybe
just
something
to
keep
in
mind.
D
E
F
Yeah
I'm
wondering
if
it
has
any
impact
from
an
APM
perspective,
because
that
is
my
current
employer,
an
APM
company
in
in
terms
of
how
it
installs
things
in
sin,
if
it
ends
up
being
any
significant
difference
like,
for
example,
you're
in
PNP,
is
the
having
not
looked
to
the
RC
at
myself'.
So
maybe
this
isn't
an
issue.
F
So
oftentimes
in
a
p.m.
land
with
we're
concerned
with
where
things
are
installed
in
order
to
make
sure
that
we
are
properly
dealing
with
the
sort
of
shims
and
trace
and
kind
of
things
we
need
to
do
so.
It's
just
a
question
whether
workspaces
in
NPM
will
change
whether
or
not
well,
not
whether
will
change
the
where
these
paths
end
up
being
and
how
much
extra
work
we
have
to
do
in
order
to
deal
with
that,
it
might
be
nothing
I,
don't
know,
I
haven't,
read
the
RFC,
so
yeah.
A
D
A
D
D
E
I
agree,
I
think
it
probably
is
it's
it's
well,
it's
very
similar
in
proposal
right
now,
what
yarn
b1
workspaces
are,
which
shouldn't
have
any
problems,
because
it's
just
using
the
module
resolution
stuff
so
I've,
given
a
little
bit
of
my
feedback
over
there,
but
I'd
be
interested
to
hear
y'all's
opinions
on
this.
One
of
the
things
that
I'm
trying
to
push
them
toward
is
stopping
thinking
about.
This
is
only
a
mono
repo
concern,
so
almost
everything
I
work
on
is
multi.
E
Repo
I
have
a
ton
of
modules
that
I
work
on,
where
I'm
working
on
them
together
and
I
want
a
workspace.
But
the
fact
that
all
of
the
existing
workspace
tooling
features
are
around
a
very
specific
file
hierarchy
which
lends
itself
to
a
mono
repo,
doesn't
really
suit
any
of
my
workflow.
So
if
I'm
working
on
something
like,
let's
do
a
concrete
example,
Express
and
then
the
router
for
v5
right
I
have
a
file
structure
where
Express
is
in
just
a
general
directory
called
I.
E
It's
the
shared
across
all
these
other
random
projects
that
I
might
be
working
on
at
any
given
time
right,
so
I'm
interested
in
hopefully
pushing
the
NPM
workspaces
implementation
to
think
about
these
kind
of
use.
Cases
where
you
know
the
file
structure
is
less
what
defines
a
workspace
and
what
you're
working
on
defines.
You
know
you,
as
a
user
could
mix
and
match
things.
I
say
arbitrarily
and
maybe
there's
limits
to
the
arbitrariness
of
it,
but
like
at
least
saying,
like
adjacent
directories,
should
be
able
to
be
in
a
workspace
like
if
I
so
choose.
A
E
D
Yeah,
the
workspaces
has
much
better
one
to
worry
about.
The
stack
is
together
right.
Managing
this
mess
yeah,
but
yeah
I
was
particular
careful
to
not
write
down
the
word
mana
repo
into
the
RFC.
E
C
Wes
I
have
a
question
for
you
in
the
use
case
that
you
were
just
describing.
Do
you
only
want
a
better
way
to
share
like
your
your
modules
that
you're
working
on
that
you
have
locally
or
with
those
two
projects
that
you're
describing
also
share
like
their
node
modules,
that
they
pulled
from
NPM?
So.
E
I
I
think
they
should
be
fine,
sharing
their
node
modules,
so
I
actually
like
to
move
to
a
world
where
we're
more
like
PNP
em,
and
it's
just
a
flat
global
cache
of
modules,
with
a
bunch
of
pointers
to
tell
you
where
to
get
them.
That
said,
I
understand
why
that's
definitely
not
the
world
were
in
today
and
I.
E
C
That
is
an
interesting
idea
like
yeah,
we
I
have
like
20
different
micro-services
at
work
and
they
probably
share
like
80%
of
their
of
their
modules.
However,
I
would
still
want
a
way
to
like
build
and
test
where
their
modules
are
maybe
self-contained,
because
that's
that's,
what's
going
to
actually
be
getting
built
and
run
on
the
server?
C
E
The
way
I
see,
that
is
that
workspaces
is
a
local
edition
that
shouldn't,
and
this
is
where
I
go
a
little
bit
further
from
what
yarn
is
doing
today
and
and
do
I,
don't
like
it,
because
that
makes
the
build
time
for
the
application
dependent
on
the
workspace
right.
So
the
way
I
see
it
working
if
I
got
my
full
dream
way
would
be
that
if
it's
in
a
workspace,
I
I've
defined
that
and
then
it
runs
in
context
of
the
workspace.
C
D
E
And
that's
one
of
the
things
I!
That's
why
I
I,
don't
like
that
part
of
it
as
it
stands
today,
because
again,
if
like
this,
is
all
fluid
stuff
like
developers,
workflow
is
fluid.
You
might
be
working
with
three
packages
together
right
now
and
then
in
an
hour's
time,
be
only
working
in
one
of
them
right
and
like
this
is
my
day
today
is
transitioning
between
us
and
the
tools
today
make
that
just
a
big
pain
right
like
I,
linked
and
then
I
unlink
and
then
oh
now
that
I
installed
a
random
package.
E
E
So
if
I
went
in
to
so
okay,
so
the
hypothetical
here
is
I
have
package
a
which
references
package,
B
right,
I've
done
a
workspace
that
includes
both
of
them
and
then
being
installed
in
there.
So
it's
set
up
a
link
between
package,
a
and
package
B.
Yes,
I
then
go
into
package
B
and
I
type
NPM
install.
Should
it
destroy
the
link
and
replace
it
with
what
I
got
from
the
remote
or
should
it
keep
the
link
and
I?
Think
that's
a
great
question
so.
D
In
the
current
proposal
in
the
current
proposal,
it
will
put
a
package
lock
within
package
B.
It
will
have
a
reference
to
the
same,
linking
to
the
highest
package
right
to
the
Express,
and
it
will
just
like
same
link
again
right
so
that
that
is
pretty
much
the
direction
we're
heading
with
the
RC.
Personally,
that's.
E
D
Yes
right
now:
yes,
that's
a
great
discussion
for
the
group.
That's
one
of
the
points
that
I
brought
to
Isaac.
We
should
probably
have
a
better
story
around
that,
like
people
might
want
to
eject
a
package
that
is
part
of
a
workspace
right
like
the
way
you
want,
like
that's
pretty
much
what
you
described
right.
So
we
should
probably
have
some,
maybe
not
totally
necessarily
but
like
some
story,
some
feature
something
within
the
the
NPM
Court
will
allow
for
a
better
experience.
I
mean.
A
It
seems
to
me
like,
unless
NPM
was
doing
something
where
it
crawled
up
to
parent
directories
and
started
looking
for
workspaces.
It
should
just
work
right,
because
if
that
lock
is
missing,
you
don't
know
anything
about
the
link
and
you
have
a
package
jason
in
there.
It
doesn't
say
anything
about
workspaces
and
you
have
no
no
modules.
It
should
just
work.
Yeah.
E
E
It's
a
router
right,
so
router
will
actually
be
expressed.
So
express
has
a
dependency
on
router
I,
then
do
a
workspace,
and
you
now
put
a
workspace
relative
path
in
my
lock
and
I
push
it.
That
would
break
in
CI
right.
So
it
definitely
should
not
do
that
because
it
won't
exist
in
CI
right,
like
in
my
CI.
What
install
from
the
register.
E
A
I
think
we're
about
at
a
time
so
actually
well
I
see
we
have
two
minutes,
but
we
should
wrap
it
up.
What
sorry.
G
E
First,
absolutely
so,
this
is
my
primary
concern
right
now
and
I'm
happy
to
talk
on
slack
anytime.
We
should
probably
do
it
in
one
of
the
channels,
though,
so
that
it's
because
I
think,
like
Rory
and
and
other
folks,
would
probably
love
to
see
the
outcomes
of
this
so
anyway,
yeah.
Let's,
let's
continue
the
conversation
for
sure.