►
From YouTube: How to publish and use changes to Slippers UI
Description
Laura Duggan and Tyler Williams step through the process of updating a component in Slippers UI, pushing that new package to npm, updating the package in the www-gitlab-com repo, and then updating the component integration. The steps are roughly:
1. Make changes/merge changes (already done in this case)
2. Check out the master branch
3. Double check things are looking good in Storybook
4. Run build command, increment version number
5. Push changes to repository
6. Push changes to npm
7. As needed, bump version in Middleman and make any required adjustments to existing Slippers integrations.
A
A
Let
me
this
is
actually
the
npm
package,
but
we
want
to
do
take
a
look
at
this
first,
so
laura
you
rece,
you
renamed
breadcrumbs
to
tags
right,
so
you
recently
merged
in
this
merge
request.
Yes
here,
so
you
can
see
it
here.
That
stuff
is
all
up
in
the
master
branch,
and
so,
like
typically
part
of
this
workflow
would
be
like
doing
that.
Work
first,
like
I
need
to
make
a
change
like
doing
the
change,
work
and
and
verifying
it
right.
B
A
B
A
I
had
named
them
breadcrumbs
erroneously,
so
you
see
they're
here
and
you
can
also
see
they're
still
like
rendering
here
in
sort
of
like
the
templates
and
stuff
and
I'm
like
hand
waving
this,
because
that's
not
the
point
in
the
video,
but
typically
you
would
like
to
make
your
changes
and,
like
first
verify,
your
changes
are
good.
You
know
get
the
review.
The
other
thing,
though,
and
like
the
reason
that
storybook
is
good,
like
here's
like
here's,
why?
All
of
this?
A
Because
we're
gonna
go
through
this
process
and
there's
a
reasonable
question
of
like
why
do
all
this
song
and
dance?
The
reason
is
that
storybook
gives
us,
like
a
very
clear,
like
place
to
test
our
changes
in
the
design
system
against
other
stuff,
so
I
hand
waved
before
but
like
tags
are
like
the
component
or
like
the
molecule
right,
we
have
these
different
iterations.
A
You
know
this
would
go
down
to
two
rows.
If
I
go
to
the
mobile
view
right
all
that
stuff
and
so
not
only
though
like
looking
at
the
component
but
being
like
okay,
like
I
know
that
I
have
these
tags-
and
I
know
they
also
appear
in
the
blog
template
so
like
now,
I
can
go
see
this
without
having
to
go
through
like
about.gitlab.com
and
be
like
what
page
is
this
used
on
right?
You
can
see
like
it's
in
this
template,
so
now
I
can
verify.
A
Not
only
do
my
changes
look
good
in
isolation,
but
they
also
look
good
like
when
we
bring
them
together
in
the
templates.
That's
that's
why
all
this
is
that's.
Why
we're
doing
this
so
we
verified.
This
is
my
local
copy
as
well,
but
it
should
be
the
same
because
it's
master
so
you've
done
all
your
work.
You've
verified
you've
made
your
merge
request
and
you've
merged
it
all
in
and
then
now
you
want
to
like
make
it
available
for
use
elsewhere.
So
we
have
a
couple
things
to
do
here.
A
The
first
is
so.
If
you
go
to,
I
think
we've
got
this
in
our
readme.
If
we
do
yeah,
we
do
there's
some
steps
about
like
instructions
about
yarn,
build
about
like
how
to
build
the
library
and
build
storybook.
You
can
also
check
in
the
package
json
look
at
our
scripts
and
see
like
specifically
what
each
one
does.
A
So.
The
first
thing
to
do
is
you're,
like
okay
cool,
I'm
really
happy
with
everything,
so
you
build
it.
It's
just
yarn.
Build
yarn.
Build
will
do
the
production
build
of
the
view
library,
it
will
also
do
the
production
build
of
the
tailwind
like
css
generated
output
and
we'll
bundle
it
all
together
right,
and
so
you
can
see
in
my
right
hand,
terminal
down
here.
These
are
the
files
it
created
and
it
like
deleted.
The
other
ones-
and
you
see,
there's
really
just
changes
to
our
css,
which
is
probably
the
changes
in
the
class
name.
B
A
Here
right,
so,
oh,
that's
an
error.
Okay,
those
aren't
my
changes
but
run
build.
You
can
see
what
actually
changed
again
if
everything's
been
reviewed,
you
should
be
pre
you're
in
good
shape
here.
So
so
you
run
the
build
step
and
then
here's
how
we
publish
it
again
in
the
package.json
here's
the
version
we're
on
zero,
seven
zero.
A
I
released
this
last
wednesday,
which
was
the
end
of
last
iteration,
and
so
now
all
we
have
to
do
is
increment,
so
we
increment
in
the
current
state
we're
in
because
we're
in
v0
and
nothing
is
stable.
We
increment
the
minor
version
at
the
end
of
each
iteration,
so
like
right
now
we're
on
it's
monday.
We
just
started
this
iteration.
A
No
one
should
be
bumping
this
eight
right.
There's
no
reason
to
do
that.
That's
just
that's
just
time!
There's
nothing
about
the
changes
you
make
that
will
ever
bump
it
to
eight
it
literally
just
end
of
each
iteration.
We
just
get
a
clean
slate
on
the
next
minor
version,
the
patch
versions.
What
is
usually
a
patch
version,
is
what
we
use
for
like
changes
during
the
iteration.
A
So
since
it's
monday
and
we're
not
releasing
zero,
eight
I'll
release
zero,
seven
one
right,
and
so
that's
because,
like
we're
making
this
change,
this
should
go
out.
So
we
can
use
it
inside
this
inside
the
iteration,
but
like
we
don't
need
to
increment
the
minor
version
right.
The
other
thing
we
could
do
if
you
wanted
to
test
it
is
you
could
use
alpha
tags
so,
and
this
is
documented
in
stories
releases.
A
They
should
not
be
like
following
the
alpha.
The
beta
like
you
know
anyway,
and
you
can
increment
alphas
dot
one.
I
think
it
is
so
like
you
can
also
like
as
you're.
You
can
build
and
build
and
build.
I
think
I
got
up
to
like
an
alpha.4
last
week
so
like
this
is
how
you
kind
of
like
continuously
like
build
and
like.
A
B
A
Think
I
I'd
actually
have
to
check
how
npm
behaves.
I
don't
think
that
it'll
do
pre-releases.
I
think
it'll
do
every
patch
and
I
would
recommend
that
nobody
pins
to
the
latest
version
we'll
go
over
that
and
again.
This
is
like
part
of
being
on
v0
we're
on
v0.
No
one
should
be
consuming
this,
but
like
right
now,
I'd
only
expect
us
to
be
consuming
it.
If
other
people
are.
A
I
really
hope
that
they
do
not
like
set
it
to
pin
to
the
latest
version,
because
things
will
break
frequently,
even
for
us
like
we
need
when
we
and
I'll
show
this
step,
but
we
should
be
very
considerate
about
like
when
we
do
this
and
like
when
we
increment
and
why
and
I've
said
it
to
be
hard
coded
to
a
specific
version
in
the
middleman
integration,
but
we
have
a
variety
of
tools.
Here's
the
other
cool
thing
about
this.
A
Oh
here,
let
me
even
show
you
so
I'm
on
the
master
branch
right
now
right
this,
like
you,
don't
need
to
version
control
it
or
like
it
doesn't
matter
it
sort
of
matters,
but
like
it's
not
a
huge
deal.
If
the
version
that
you're
working
on
like
locally
diverges
from
what's
in
your
version,
control
so
like
right
now,
I
can
push
up
this
alpha.
So
I'll
do
npm
publish
access
public.
A
This
is
one
dash
alpha
that
I
just
pushed
I'm
not
going
to
commit
this
to
to
our
source
control
at
all.
I'm
just
I'm
actually
gonna
like
get
stash,
get
stash
clear.
So
we're
back
here
that
just
released
though
so.
If
we
go
here,
we'll
probably
see
in
the
versions-
and
this
is
totally
cool
like
like,
I
did
that
to
demonstrate
that,
like
don't
worry
like
it's
fine,
it's
so
it's
it's
somewhere
it'll
go
up
but,
like
you
know,
it's
cool.
A
These
are
two
like
parallel
processes
that
should
have
some
like
they
have
some
dependencies
between
one
another,
but
they
don't
have
to
be
exactly
the
same
and
as
we
go
forward,
we'll
also
do
some
automation
around
this,
so
that,
like
people,
don't
have
to
like
make
choices,
but
I
don't
know
yet
what
the
answers
are
for
those
choices.
So
I
think
it's
good
if
we
all
just
make
choices
for
a
little
bit
and
like
converge
on
what
the
best
choice
is
for
some
of
these
automations
right.
A
So
back
to
this
last
week
I
released
zero
seven
zero.
This
is
a
change
to
zero
seven
zero,
so
I'm
gonna
bump
it
to
zero
seven
one,
and
for
now
and
again,
this
is
just
like
a
choice
that
I'm
making.
We
could
do
this
differently
and
like
set
it
up,
but
like
I
like
to
run
the
build
step
and
to
remind
everyone
we
got
here,
everything
was
reviewed.
I
ran
yarn,
build
which
I
could
do
infinitely
many
times
here,
because
it'll
be
the
same
output.
A
Whatever
ran
yarn,
build
bump
the
version
number
and
I'm
just
on
the
master
branch
and,
like
I
don't
hate
that
for
this
right
now,
because
eventually
what'll
probably
happen
is
we'll
have
like
a
ci
thing
that
like
does
those
two
things
on
its
own
and
like
humans.
Don't
do
it
so
like
it's
cool
that
it's
just
like
on
master
like
it
doesn't
need
to
be
his
own,
mr
and
then
like
I
do
like
git,
add
a
and
like
you'll
you'll,
see
this.
A
Yeah
we're
fine
cool,
okay
and
I
just
I
just
push
it
so
this
is
now
now
the
most
current
master
like
has
this
version?
The
reason
that
it's
like
useful
to
do
this
is
that,
like
so
when
I
go
to
like
make
my
next
set
of
changes
and
if,
when
I
pull
it
into
master
and
say
oh
we're
on
zero,
seven
one
like
I'll
increment
it
to
zero
seven
two,
the
nice
thing
is
you
can't
overwrite
versions
in
npm
or
like?
If
you
can
you
can't
to
do
it
easily
so
like?
A
If
you
made
a
mistake
and
like
push
to
a
version
that,
like
had
already
been
released,
npm
will
just
yell
at
you,
I
think,
okay,
which
will
be
good,
I'm
not
going
to
demo
that,
because
I
don't
know,
if
that's
actually
what
will
happen
but
they're
like
there
are
some
guardrails
in
place
here.
So
again
we
did
the
build,
we
did
the
bump.
We
pushed
the
changes
to
the
repository
so
the
next
time,
someone
like
pulls
it
or
like
tries
to
do
the
same
thing.
A
They'll
see
that,
like
we
are
saying
to
the
team
right
now
in
the
repository,
hey
we're
on
zero
seven
one
right.
That's
that's
just
an
indicator
to
other
people
who
pull
this
and
then
I
will
do
npm,
publish
access
public
which
again,
in
the
right
hand,
corner
we're
going
to
write
this
down
as
part
of
the
the
issue
here,
but
I
thought
that
the
live
video
would
be
useful
I'll
do
that.
A
This
is
the
part
we
need
to
get
people
access.
That's
all
I
think,
like
I
think
I
can
give
you
access
we'll
have
to
see
you'll
have
to
make
an
mpm
account,
but
you
can
just
tie
that
to
like
your
gitlab
stuff,
but
as
you'll
see
here
like
it
did
whatever
it
has
to
do
it
like
compressed
it
all
the
tarball
here's
the
details
and
then
it
like
released
this
and
you
can
see
like
the
version
number
071
right,
so
that
should
be
up
there.
Let's
refresh
the
versions
here,
interesting.
A
B
A
A
Okay,
cool!
Well,
I
will
trust
you
and
we'll
see,
and
you
know
we'll
see
it
work
here
shortly,
so
that
was
all
in
the
slippers
repository.
I
have
an
alias
in
my
command
line.
That
brings
me
to
the
gitlab
location.
So
that's
what
I
just
did
in
both
these
terminals
here,
so
I'm
gonna
check
out
master.
A
A
So
if
we
had
like,
in
fact
I
don't
know
what's
going
on,
this
must
be
like
my
internet.
Like
is
not
loving
me
right
now,
so
if
we
had
in
fact
like
had
these
in
use
like
in
middleman
anywhere,
where
it
showed
up
in
man
like-
and
this
is
like
in
my
opinion,
this
is
like
the
responsibility
of
the
person
incrementing.
The
version
is
like
to
then
go
and
like
make
these
changes
and
I'll
show
you
what
I
mean
so
like.
A
A
Yeah,
you
know,
I'm
just
gonna,
stop
that
and
I'm
just
gonna,
I'm
gonna
do
a
git
checkout,
I'm
gonna
call
this
I'm
just
gonna
spike.
It
demo
slippers
upgrade
so
here's
all
you
gotta
do
so
a
short
couple
steps
here.
So
this
is
the
gatelab.com
repo
up,
in
my
left
hand,
corner
package.json
towards
the
bottom.
I
just
control
f
for
slippers,
slippers,
ui
and
you
can
see
again.
I
have
specified
a
very
exact
version
right
right,
so
here
so
this
is
on.
This
was
on
master.
A
A
This
is
also
should
be
a
strong
driver
for
us
to
like
really
practice
like
incremental
changes
in
a
big
way,
because
what
you
don't
want
to
do
is
like
change,
a
whole
ton
of
stuff
and
release
and
like
bump
a
patch
version
number
that
then
makes
you
have
to
go
and
do
a
ton
of
reintegration.
Work
like
this.
This
will
like
this
is.
The
trade-off
like
there
is.
There
is
overhead
and
in
many
ways
it
is
like
unnecessary,
like
we
don't
have
to
do
it
this
way
there
are.
A
We
make
it
really
clear
what
depends
on
what
we
literally
have
a
dependency
in
our
in
our
package
manifest
and
like
when
you
do
these
small
changes.
So
when
I
like
increment
this
right,
so
I
increment
this
and
like
gives
you
like
yarn
install
for
now,
while
we're
on
version
zero,
I
would
recommend
against
doing
yarn
upgrade
because
I
think
yarn
upgrade
will
like
do
the
like
match
this
minor
version
or
whatever,
like
that's.
Probably
it's,
probably
okay,
but
again.
A
I
ran
yarn,
install
so
it'll
like
blow
away
the
old
package
and
then
add
this
and
then
what
I
would
do
like
honestly.
Here's
like
the
next,
so
this
is
like
it'll,
be
different
depending
on
what
you
changed
right
but,
like
you
changed
the
breadcrumbs
so
like
I
would
like
literally
just
search
for
slp
breadcrumbs
and
you'll,
see,
there's
nothing
in
there
because
we
haven't
yet
used
them,
but,
like
I
would
just
search
the
directory
for
all
the
instances
of
the
thing
that
you
changed
and
go
like
make.
It
work
right
and
they're
like
okay.
A
Well,
now,
they're,
not
breadcrumbs
they're
labels,
so
they
should
like
they
should
look
like
this
instead
right
or
like
whatever
the
signature
of
the
thing
was,
is
what
it
should
look
like.
There's
like
what
you
should
search
for
and
then
change
that
as
needed,
and
I
think
that,
like
again,
it's
a
little
bit
of
a
song
and
dance,
but
hopefully
your
changes
are
incremental
enough
that
it's
not
a
huge
amount
of
work.
A
A
A
A
The
cool
thing
here
is
like
if
I'm
working
on
about.getlab.com-
and
I
want
to
say
like
oh,
I
wonder
what
like
like.
If
I
want
to
use
your
alpha
branch,
I
can
check
out
a
branch
on
about
talking,
lab.com
bump.
My
version
to
an
alpha
tag
use
your
work
right,
like
your
local
work.
If
you've
published
it-
or
I
can
ask
you
like
hey
like
whatever
you're
working
on,
can
you
like
push
an
alpha
release
to
it?
So
I
can
see
it
and
like
help
you
like
troubleshoot
this
thing
on
the
integration.
A
I
can
do
that
all
separately
in
a
branch
and
then
like-
and
I
know
very
specifically
like
laura
and
I
were
working
on
zero.
Eight
five
alpha
two
and
that's
where
I
ran
into
this
problem,
but
fortunately
we
won't.
We
don't
have
to
like
revert
any
mrs
in
the
main
thing,
because
we
never
like
we
never
pushed
merced
into
maine
and,
like
we
have
this
all
like
semantically
versioned.
So
that
is
like,
like
that's
the
power
of
this
and
like
that's,
why
it's
worth
it.
So
that's.
B
That's
awesome,
yeah.
I
feel,
like
you
answer
one
of
my
questions
by
default.
Just
that,
like,
oh,
I
have
you
know
a
couple
of
mrs
that
are
ready
to
be
merged
in.
Can
I
just
release
them
as
one
version,
but
it's
it's
better
to
do
this
like
incrementally,
make
the
changes
in
about
document.com
to
make
sure
that
everything
works
and
keep
keep
the
get
history
kind
of
sanitized,
yeah
yeah.
A
I
also
did
that
rebase
because,
like
I
rebased
myself
locally,
and
it
took
me
like
30
minutes
to
rebase,
which
is
just
like
ugly,
really
hard
and
so
like
yeah
like
like.
Hopefully
this
like
pushes
us,
hopefully
like
lessons
like
that,
push
us
towards
like
the
smaller
changes
but
yeah.
I
think
it's
just
a
judgment
call
and
like
if
you've
got
three
or
four
mrs,
but
it
is
really
just
like
10
10
lines
of
code
different.
You.