►
From YouTube: Page specific CSS bundles
Description
We had a discussion on how we could realize page bundles.
A
I'm
just
sharing
you
know,
because
this
is
probably
a
one-off
discussion,
I'm
just
sharing
the
link
to
our
front-end
foundation
office,
our
stocks,
because
you
know
it's
easier
to
type
for
all
of
us
into
that
document,
and
then
we
can
maybe
get
a
summary
of
this
meeting
into
into
back
into
the
epic,
because
collaborating
on
a
comment
on
an
epic
seems
like
pretty
pretty
not
so
great
experience,
maybe
just
to
sum
it
up.
We
have
page
specific
css.
A
Those
this
is
currently
all
bundled
into
application.
Css
and
john
has
been
basically
tasked
to
take
care
of
it
and
that
we
only
load
this
page
specific
css
on
individual
files
on
the
individual
route
sites
and
the
there
is
a
work
in
progress,
merge
request
that
has
been
created
in
the
last
front-end
pairing
session
in
order
to
be
able
to
load
these
css
files
via
webpack
yeah.
I
hope
I
summed
it
up
correctly.
If
not,
there
are,
you
know,
speak
now
or
hold
your
peace
forever.
B
There's
also
an
alternative
where
we
already
have,
for
instance,
the
exome
styles
that
are
only
included
on
the
for
for
the
terminal
and,
and
so
it's
about
evaluating
these
two
options.
There
are
some
concerns
with
the
webpack
route,
and,
and
so
if,
for
instance,
the
the
approach
we're
taking
with
the
extern
page
bundle
is
is
appropriate.
B
That
might
be
enough
for
us
to
say
right.
This
is
the
approach
we
want
to
take.
My
goal
is
to
define
the
approach
and
then
create
issues
for
each
of
these
pages,
that
we
want
to
split
out
and
then
find
allies
in
the
front-end
group
to
to
help
execute
on
these
similar
to
how
the
jeffers
kind
of
like
conversion
happened
and
many
other
things
where
we
create
a
bunch
of
issues
and
we
farm
it
out
to
to
engineers
who
are
able
to
help
us
out
on
this.
So
essentially,
that's
that's.
B
Maybe
a
waypack
approach
is
the
the
one
we
want
to
take
in
the
future,
but
it
might
not
be
the
best
approach
for
right
now
and,
and
so
I'm
hoping
through
this
conversation
today,
we
can
evaluate
a
the
webpack
approach,
whether
there's
value
in
pursuing
that
further
or
whether
the
potential
challenges
we
might
have
is
is
too
significant
right
now
and
also
evaluating
the
the
other
approach
where
you
know
where
we
have,
for
instance,
the
extern
page
bundle
and
seeing
whether
that
is
sufficient
for
for
what
we
need
in.
As
a
first
iteration.
C
I
can
start,
I
think,
either
way.
We're
probably
gonna,
go
down
some
rabbit
trails
of
discussion,
a
couple
thoughts
that
I
don't
really
have
organized,
so
I'm
just
going
to
throw
them
out
there
right
now
we're
doing
the
import
pages,
slash
star,
star,
star
thing
from
application.sdss,
which
means
all
of
these
quote:
unquote:
page
specific
javascript,
sorry,
josh,
page
specific
css
are
currently
being
bundled
together,
which
means
they're.
Quite
there
could
very
possibly
be
a
lot
of
pages
that
are
relying
on
the
existence
of
css,
selectors
and
rules
from
unrelated
pages.
C
Without
you
know,
realizing
and
making
that
dependency
explicit.
So
we
can't
necessarily
just
split
all
these
out
and
expect
that
it'll
work
exactly
as
intended.
There
might
be
some
some
issues,
it's
the
same
problem
when
we
had
you
know
global
scope,
abuse
in
our
front-end
code,
because
you
know
there
were
a
lot
of
modules
that
might
rely
on
another
module
being
being
included
that
you
know,
there's
no
explicit
import.
So
it's
hard
to
tell
exactly
where,
but
just
one
concern.
So
it
is.
C
C
The
reason
we
didn't
jump
in
this
in
the
past
was
because
webpack
dev
server
specifically
has
a
notorious,
but
not
even
just
the
dev
server,
but
the
webpack
compile
process
in
general
has
had
always
been
butting
up
against
heap
overflow
memory
issues
and
that's
just
with
our
javascript
code.
I
imagine
if
we
added
a
lot
of
scss,
it
could
increase
the
memory
requirements
and,
possibly
you
know,
put
us
into
more
issues.
It's
worth.
C
B
A
Okay,
I
mean
to
be
perfectly
honest:
if
we
move
stuff
and
break
things,
we
have
an
easy
way
to
revert
right,
because
we
are
basically
just
moving
the
import
of
a
file,
so
in
case
we
really
really
break
something
either
we
we
should
analyze
whether
we
are
able
to
fix
it,
and
maybe
someone
else
can
be
typing.
Why
I
make
my
points
right.
A
Yeah
thanks,
so
regarding
the
point
of
of
the
side
effects,
I
mean.
Ultimately,
we
want
to
get
rid
of
the
side
effects
and
obviously
moving
it
out
of
the
moving
it
out
of
the
application
css
as
a
first
step,
because
in
case
something
breaks
or
maybe
sometimes
we're
even
correcting
side
effects
later
on
which
we
then
might
not
need
to
correct
anymore
or
over
correct
right.
Imagine
that,
like
one
of
the
imported
pages,
one
of
the
imported
pages
introduces
the
side
effect
and
then
follow-up
page.
A
You
know
fixes
that
side
effect.
So
it's
easily
revertable
and
we
should
do
it
anyhow,
and
I
mean
as
an
even
further
step.
Eventually
we
should
try
and
tackle
these
tackle,
but
try
to
reduce
the
page
specific
css
anyway
and
see
if
we
could,
you
know,
convert
some
of
the
stuff,
that's
in
there
right,
but
it's
obviously
a
second
step.
A
We
don't
introduce
like
a
new
way
to
compile
as
css,
that
is
its
own
rabbit
hole
because
it
might
handle
variables
differently.
There
are
actually
now
three
different
sas
implementations
right.
So
there
is
the
lib
ruby
sauce.
There
is
the
which
is
using
sar
c,
there's
note
stars,
which
is
also
using
the
c
version.
A
So
my
recommendation
would
be
to
go
with
that
assets
pre-compile,
because
whether
you
define
an
assets
pre-compile
or
whether
do
you
import
fscss,
doesn't
really
matter.
In
my
opinion,
right
yeah
because
yeah,
we
basically
don't
know
the
side
effects
of
the
webpack
stuff.
I
don't
I'm
not
saying
that
we
cannot
explore
it
in
parallel,
maybe,
but
if
we
decide
to
go
with
scss
here
on
webpack,
I
would
say
we
should
only
do
it
if
we
have
the
long
long-term
goal
of
ultimately
moving
everything
to
webpack
right,
yeah.
C
C
To
just
do
like
some
scss
in
webpack
and
some
with
sprockets
or
some
other
method,
you
kind
of
want
to
do
it
all
in
one
place,
just
to
keep
things
dry
and
and
having
the
configuration
do
the
same,
and
as
lucas
mentioned
there
might
be
some
implementation
details
of
the
scss
compiler
that
we're
using.
I
would
assume
that
they
should
all
be
pretty
standardized.
I
can't
imagine
that
there's
a
huge
deviation
between
them,
but,
but
I'm
not
sure
I
do
think
yeah.
We
can
totally
work
on
these
these
two
projects.
C
In
parallel,
I
think
it's
a
separate
question.
You
know
moving
scss
compilation,
webpack
and
splitting
our
sdss
into
page
specific
bundles
are
kind
of
two
separate
things.
The
only
thing
that's
a
cross-cutting
consideration
is
the
the
the
framework
that
we
build
to
to
govern
the
automatic
imports
of
page
specific
css
like
in
when,
when
the
views
are
rendered
by
rails,
is
it
going
to
be
some
magic
that
we
put
together
with
a
webpack
manifest
where
it's
going
to
notice
the
css
and
include
it
in
line,
or
is
it
going
to
be
handled?
C
C
So
there's
a
consideration
there.
I
guess
the
downside
to
implementing
it.
Splitting
out
the
css
into
page
specific
bundles
before
transitioning
to
webpack
is
we
might
have
to
duplicate
some
effort
there.
As
far
as
coming
up
with
a
solution
to
import
the
css
onto
the
page,
we
may
have
like
two
competing
solutions.
There
does
that
make
sense.
I'm
kind
of.
A
C
A
I
think
that
makes
sense,
but
to
be
honest,
like
it's
we're
not
currently
at
least
obviously,
if
we
could
get
a
win
and
suddenly
load
all
scss,
that's
page
specific
automatically.
We
would
be
happy
right,
but
this
at
least
the
plan
says:
hey
we're
going
to
create
individual
issues
because
we
might
need
to
do
some
manual
checking
and
obviously
looking
at
the
potential
side
effects
is
easier
if
you
just
go
file
by
file
by
file.
A
C
So
there's
there's
different
approaches.
We
could
do
the
yeah,
the
asset
config
assets,
pre-compile
line,
which
you
know
that's
going
to
balloon
in
size
pretty
quickly
if
we
start
doing
one
for
every
page,
specific
bundle
and
then
there's
also
the
matter
of.
Are
those
automatically
imported
on
the
the
correct
pages?
Or
do
you
have
to
add
something
in
the
hammel
to
make
sure
that
that's
the
style
page
is
added.
A
C
That's
that's
something
that's
going
to
be
automatic
where
we
have
this
thing
that
discovers
these
compiled
css
files
and
imports
them
based
on
file
name
schemas
like
we
do
with
javascript,
or
we
do
it
manually
where,
on
the
haml
page,
we
have
a
import
style
tag
or
or
even
in
the
javascript
page
specific
bundle.
We
have
an
import
whatever.scss
that
handles
it.
We
have
to
figure
out
exactly
how
we
want
that
to
work.
A
A
C
My
opinion-
and
this
is
without
having
tested
anything,
so
this
is
just
my
hunch,
but
I
like
the
idea
of
actually
importing
the
css
within
the
javascript
I
like
it.
We
could
almost
rather
than
calling
it
page
specific
css.
It
could
kind
of
be
like
component
specific
css,
like
you
know,
if
we
need
css
to
accompany
well,
I
mean
in
in
view
components.
This
is
explicit.
C
You
know
you
have
a
style
section
that
we
can
use
that
might
take
along
with
like
the
modal
functionality
or
something,
and
maybe
that's
modal
specific
css,
but
even
even
for
non-view
components.
We
can
have
a
css
import
statement
at
the
top,
and
you
know
maybe
it's
for,
like
I'm
trying
to
think
of
something.
That's
used
like
like
discussions,
css
or
something
like
that,
and
that
will
go
along
with,
like
our
discussions,
javascript
bundle
and
then
it
will
just
kind
of
go
along
to
every
page.
Where
that
discussions
javascript
is
loaded.
C
A
A
We
would
automatically
also
have
that
reconsideration
working
for
the
css
right
and
we
are
making
we're
having
the
benefit
if
we're
using
webpack
we're
having
the
benefit
of
of
utilizing
all
the
webpack
tools.
I
mean
there
are
a
few
considerations
that
we
are
having,
because
we
had
it
in
the
past
is,
like
you
know,
imports
and
stuff
of
other
static
assets.
C
C
Yes,
yeah
that'll
work
exactly
the
same
way,
we'll
have
to
make
sure
that
we,
you
know,
convert
it
correctly
when
we,
when
we
move
it
over,
I
think
the
syntax
might
be
a
little
bit
different
in
the
way
that
it
works,
but
yeah
it
basically
uses
the
same
loader
system
that
we
use
for.
If
you,
if
you
import
an
image
into
a
javascript
file,
it
will
use
the
same
loaders.
So
if
we
have
you
know,
we
have
it
a
little
odd.
C
The
way
we've
got
it
set
up,
because
some
some
file
types
like
svgs,
we
have
we
use
like
raw,
loader
and
it'll,
take
the
contents
of
the
file
and
put
it
into
a
variable,
whereas
other
other
file
extension
types.
We
use
file
loader,
which
turns
it
into
a
path
which
is
a
just
a
reference
to
like
it,
exports
it
as
another
asset
that
can
be
loaded
externally,
and
we
need
to
make
sure
that
those
are
kind
of
the
way
that
css
is
expecting
these
to
be
or
that
yeah.
C
C
A
A
So
I
think,
in
order
to
and
analyze
the
impact
using
one
page
that
uses
a
bit
more
of
the
features
like
hey,
it's
going
to
use
some
of
our
variables
hey
it's
going
to
to
be
like
the
real
deal.
It's
like,
maybe
one
of
those
20
kilobyte,
many,
maybe
one
of
those
you
know
divs
nodes
pipelines,
maybe
maybe
something
that's
not
as
broad
as
the
other
ones.
Here,
maybe
there's
one
a
good
one.
That's
like
a
bit
broader,
but
not
too
broad.
C
I'd
be
interested
to
just
try,
you
know
like
in
our
main.js
import,
application.scss
and
just
see
what
happens.
I'd
be
curious,
at
least
to
test
the
memory
constraints.
You
know
whether
the
compilation
process
can
handle
it
and
we
can
compare
the
output
there
to
what
sprockets
outputs.
Maybe
I
don't
know
that
would
be
a
lot
of
stuff
to
comb
through
at
once
to
make
sure
that
we
don't
have
any
regressions,
but
I'd
be
interested
just
to
see
if
it's
feasible
to
move
into
webpack
in
the
long
term.
B
The
preferred
long-term
solution,
if
we,
if
we
were
to
iterate
and
and
go
with
the
page
bundles
approach,
is
this
something
that
takes
us
away
from
where
we,
where
we
might
want
to
go
in
terms
like?
Are
we
iterating
in
a
direction
that
that
makes
it
definite
more
difficult
for
if
we
wanted
to
go
away
backwards
down
the
line
or
or
does
it
have
no
no
substantial
impact,
and
in
so
essentially
what
I'm
looking
at
is?
B
A
A
It
would
also
have
the
benefit
that
you
don't
have
any
other
sprockets
to
notes
are
specific
considerations
like
the
image
urls
and
stuff,
and
it
would
yeah
and
it
would
probably
be
have
the
benefit
if
you
look
at
it
that
you
know
just
by
converting
the
first
10
or
so
you're
already
at
a
at
a
really
like
a
benefit
of
removing
more
than
a
quarter
of
the
scss
right,
if
you're
already
tackling
the.
Why
am
I
with
tickling,
watching
too
much
much
soccer.
A
B
Yeah,
okay,
so
it
feels
like
the
safe
and
sensible
iteration
here
is.
It
is
going
with
the
page,
bundles
approach,
while
at
the
same
time,
not
forgetting
of
the
about
the
webpack
approach.
It
is
potentially
the
longer
term
solution
that
we
want
to
explore
and
we
and
and
might
be
the
the
ideal,
but
going
page
bundles
won't
restrict
that
in
fact,
it
might
have
the
benefit
of
helping
us
decouple
the
the
page,
specific
csa
so
long
from
each
other.
A
Yeah-
and
I
mean
mike-
and
I
have
just
been
discussing
a
bit
mike-
is
currently
working
in
this
situation:
working
on
source
maps,
improving
source
maps
and
he's
going
to
be
off
until
after
the
weekend,
so,
basically
from
tomorrow,
and
we
we
have
been
discussing
what
would
be
a
high
impact
project,
and
I
assume
that
the
css
thing
would
be
a
high
impact
project
that
we
also
can
look
at.
So
just
by
moving
ahead
with
the
iteration
on
the
page.
A
D
Gitlab
ui
does
have
visual
testing,
and,
while
I
wouldn't
suggest
adding
it
to
get
lab
proper
setting
it
up
locally
might
be
helpful
for
people
to
run
things
to
see
if,
when
they're
changing
files
to
do
verification,
if
big
things
are
like
totally
changed.
But
the
second
thing
that
I
really
did
want
to
say
is
that
is
to
spend
two
minutes
standing
for
my
personal
hobby
horse,
which
is
that
I
think
fundamentally
using
more
utility.
D
A
C
Yeah,
I
think,
breaking
out
things
from
the
monolithic
application.scss
bundle
into
smaller
bits
will
definitely
make
it
more
maintainable
in
the
future.
We
don't
have
to
suddenly
guess
like.
Where
is
this
selector
used
in
gitlab
when
we're
deciding
whether
we
remove
it
or
not?
We'll
know
if
it's
in
a
page
specific
bundle
that
it's
in
this
narrow
area
of
gitlab
it's
much
easier
to
figure
out.
C
I
imagine
we
have
a
lot
of
css
selectors
hidden
away
in
here
that
are
probably
irrelevant
and
used
nowhere
that
we
just
haven't
been
able
to
get
rid
of,
because
no
one
knows
if
it's
used
nowhere.
We
we
have
to
test
everything
and
everyone's
afraid,
because
we
don't
have
visual
regression
testing
in
gitlab,
and
that's
that's
that
really.
That
should
be
a
big
epic
that
we
should
all
be
working
on
as
well
as
just
doing
something
along
those
lines.
C
I
like
the
the
project
that
you
pointed
out
earlier
gene
I
hadn't
seen
that
before
the
gitlab
screener.
Is
that
something
that
we're
looking
to
start
doing
automated
visual
regression
testing
on
or
is
this
kind
of
just
a
proof
of
concept
that
tim
threw
together?
It
looks
like
the
latest
update
was
a
year
ago,
so.
B
Yeah,
my
my
understanding
is
that
it
was
there
was.
It
was
more
of
a
proof
concept
rather
than
a
specific
like
something
to
be
used
locally,
rather
rather
than
something
integrated
into
the
ci,
because
there's
some
challenges
with
running
visual
regression,
tests
in
in
the
ci
environment
itself
as
well.
B
B
I
think
for
for
this
specific
iteration,
just
being
able
to
run
something
locally
to
and
to
have
an
initial
feedback
and
and
some
confidence
that
you,
you
can
run
it
before.
You
make
the
change
and
then,
after
you
made
the
change
and
just
comparing
that
and
having
some
initial
kind
of
like
confirmation
that
you
haven't
drastically
changed.
Something
is
really
valuable
and
and
definitely
needed
as
part
of
this
process
of
breaking
out
the
page
specific
success.
C
I
feel
like
we're
really
close
to
being
able
to
do
something
like
that
in
gitlab
and
I'm
sorry.
This
is
kind
of
a
digression
off
the
the
main
purpose
of
this.
This
topic,
but
like
we
use
the
capybara
tests
in
our
spec
and
they
already
generate
image
snapshots
when
there's
like
a
test
failure,
the
only
thing
preventing
those
from
being
deterministic.
C
You
know
every
time
that
you
generate
a
snapshot.
Is
the
database
differences.
You
know
if
you
retry
a
test.
It'll,
maybe
generate
a
random
slug
for
the
project
that
you're
on
or
it
might
generate
some
lorem
ipsum
text
that
might
be
different
in
each
iteration.
So
that
would
trip
up
things
when
trying
to
do
a
visual
regression
test,
because
it
might
look
like
something
changed
when
it
really
didn't.
But
I
think
that's
a
solvable
problem.
A
What
one
one
quick
question,
because
the
css
is,
we
don't
have
as
much
css
files
and
dynamic
loading
and
whatnot.
Would
it
be
feasible
to
generate
the
css
in
sprockets.
Twice
like
once
include
like
basically
have
a
feature
flag
for
hey
use.
The
css
and
hey
use
the
css
that
has
already
like
five
page
bundles
removed.
A
Not
necessarily
a
test,
but
then
we
could
also
just
turn
it
on
on
production.
Once
it's
deployed
to
production,
be
like
hey
this
feature
flag
and
if
we
don't
get
any
weird
issues
in
the
is
this
known
channel
within
a
week
we
can
be
like
I
mean
to
be
honest
like
if
we
have
side
effects
there
and
other
pages
are
relying
on
the
side
effects
that
those
pages
have
been
broken
from
the
start
kind
of
right.
C
C
I
imagine
this
is
going
to
be
similar
but
yeah.
I
like
the
idea
of
just
having
it
be
a
feature
flag.
You
know
it
can
just
be
like
you
know,
get
lab
next.
You
can
toggle
between
the
two
and
see
if
something
breaks
pretty
easily
and
it
would
only
be
visible
to
you
know,
get
live
employees
or
something
so.
A
I
mean
we
should
at
least
explore
it,
because
that
that
thing
of
hey
you
decide
like
which,
because
this
I
I
think
the
sprockets
compilation
is
not
that
bad,
like
it's
not
like
compiling
all
of
our
javascript
with
all
the
optimizations
twice.
It's
just
like.
Hey
that's
compiled
this,
this
little
tiny
bit
of
not
tiny
bit,
but
let's,
let's
compile
the
css
twice,
which
is
probably
not
that
expensive
right.
We
should.
D
D
The
advantage
of
using
a
feature
flag,
too,
is
that
it
solves
the
problem
of
getting
things
to
render
that
a
lot
of
times,
especially
depending
on
what
stage
you're
working
on
like
even
getting
the
data
to
test
it.
If
you
want
people
to
visually
test,
it
can
be
a
pain.
So
I
think
that's
like
another
good
reason
to
like
let
everybody's
eyes
find
the
broken,
css
and
sort
of
run
it.
That
way
seems
like
a
really
good
approach.
D
A
C
C
A
C
A
D
A
C
C
D
C
A
C
C
Right
and
of
course,
there
are
going
to
be
lots
of
edge
cases
and
it
could
be,
it
could
be
that,
like
the
page,
is
not
even
in
the
the
state
that
uses
this
selector,
maybe
there's
a
pop-up
that
comes
up
that
then
that
selector's
utilized,
but
it's
not
right
now
there
could
be
a
lot
of
false
positives,
but
I
mean
it
would
give
us
a
basis
to
start
with.
I
think
at
least
I
wouldn't
rely
on
it
exclusively,
but.
A
C
A
A
B
So
so,
for
me,
a
couple
of
things
that
came
out
was
we
want
to
explore
the
webpack
route,
but
it's
a
it's.
It's
not
our.
It's
not
our
best.
Next
iteration
step,
the
next
iteration
step
should
be
to
to
go
down
the
page
bundle
through
there's
benefits
of
doing
that
already.
That
will
help
with
the
webpack
route
down
the
line,
so
that
that,
for
me,
is
first
decision
made
is
we're
going
to
go
with
page
bundles?
The
second
thing
is
is
having
you
know:
how
do
we?
B
How
do
we
check
for
for
for
the
regressions?
So
instead,
so
one
thing
is:
we
can
rely
on
the
1
300,
the
pairs
of
eyes
at
gitlab
to
pick
things
up
and
shout
loudly,
and
we
can
be
responsive
to
that.
The
other
part
is
is
to
potentially
utilize
the
gitlab
screener
project,
for
instance,
that
can
started
to
at
least
in
a
development
environment.
Give
the
whoever's
trying
to
separate
that
page
out
give
them
some
confidence,
so
so
that
that's
a
consideration
that
that,
I
think
is
fun.
B
I
think
for
me,
then
the
is
there
any
concerns
with
you
know.
If
we
look
at
how
epster-
and
I
think
the
web
ide
h,
bundle
was
was
done
and
included,
is
there
any
concerns
with
just
mimicking
that
approach
and
and
taking
another
page
and
and
trying
it?
That
way?
Is
this
something
we
need
to
be
aware
of
that
we,
apart
from
copying,
you
know,
like
simplistically,
in
my
mind,
copy
the
approach
that
was
done
there
and
and
tried
on
one
of
these
pages,
like
projects
or
whatever
and
and
see
what
happens?
C
D
A
Yeah,
I
don't
know
what
one
crazy
idea.
Again
we
have
on
each
data
tag.
We
have
the
rails
route
right.
We
have
this
projects,
issues
blah
blah
blah
yeah.
What
if
we
start
wrapping
the
page
specific
css
in
like
data
like
you
know,
in
these
selectors,
like
data
equals
like
body
data,
equals
projects
foobar
issues
whatever
right.
If
we
start
wrapping
them
in
those
before
we
split
them
out,
I'm
I
don't
know.
I
I've
seen
that
we
actually
done
this
in
few
of
interview
places
already,
but
that
would
and
and.
C
What
I
yeah-
and
I
think
that
would
be
the
the
easiest
solution-
is
to
just
yeah
base
it
on
the
rails
route,
and
you
can
do
that
you
can.
You
can
model
that,
after
how
we're
doing
it
with
webpack
we're
reading
the
manifest
parsing
out
the
controller
and
the
action
that
we're
on
and
and
going
that
way
right
now.
I
then
that
would
mean
you
put
this
import
into.
C
A
A
There
is
exact
matches,
there's
also
contains
right.
There's
also
starts
with
end
ends
with
so
you
could
be
like
hey
every
sub
page
of
groups,
every
route
subroute
of
groups,
and
maybe
maybe
that
would
give
us
a
way
for
checking
the
side
effects,
but
I
think
john
doesn't
really
care
about
checking
the
side
effects.
First,
you
care
about
getting
it
out
of
the
page
bundle
as
quickly
as
possible,
right
right.
B
Yeah,
so
so
an
exact
getting
the
first
one
done
you
know
for
me
is
is,
is
the
is
an
important
thing,
because
that
unlocks
me
to
to
go
and
and
reach
out
and
get
help
from
people.
You
know
like
I'm,
I'm
cheekily,
looking
at
the
you
know
like
the
list
of
files,
and
you
know
I
see,
there's
a
pipeline.scss1
and
I
see
sarah
as
in
verify
and
I'm
like
I'm
wondering
sarah,
whether
you'd
be
keen
on
on
on
piloting
removal
of
of
the
pipelines,
one
into
into
its
own
bundle.
B
C
A
B
A
B
So,
anyway,
from
my
side,
thank
you
very
much.
This
has
really
been
helpful
in
giving
me
some
clear
direction
as
to
what
is
the
actionable
next
steps,
and
thank
you
for
for
volunteering,
sarah
and
lucas
to
to
helping
me
and
for
sam
in
your
absence.
I
appreciate
it
and
I
will
I
think
what
I'll
do
is
I'll
start
by
creating
an
issue
for
for
the
pipeline.
Css
sss,
one
I'll,
summarize
kind
of
like
our
top
level
thoughts
here
and
we
can
iterate
on
that.
B
We
can
work
on
it
and
it
takes
us
a
week
or
whatever
or
two
to
to
get
there.
That's
okay!
It's
you
know
like
we
should
get
this
right
before
we
kind
of
like
go
out
and
and
farm
out
the
work
to
the
rest
of
the
front-end
group
and
do
make
sure
that
we
while
well,
we
can
rely
on
those
1300
pairs.
They
it
can
get
quite
noisy
and
stressful
if
they
all
start
starting
at
you.
I
know
from
personal
experience
with
the
handbook
as
soon
as
something
is
not
right.