►
Description
A short conversation between Laura Duggan, Javier Garcia, and Tyler Williams about how the GitLab Digital Experience team has configured Webpack to work with the www-gitlab-com repository.
We go over some errors Laura encountered in development, and Tyler talks us through how he would approach debugging the issues. We discuss some broader topics about how and why Webpack is configured, and how it functions in order to include external packages in the final build output.
Call agenda: https://docs.google.com/document/d/1BeybC2Cv-RuLLI-ABuDY15BhDq_xZ2jYvMVoEavEBdw/edit?usp=sharing
Thread that inspired the call: https://gitlab.com/gitlab-com/marketing/inbound-marketing/slippers-ui/-/merge_requests/20#note_506605866
Cartoon Deep Dive into ES Modules: https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/
ES2015 vs CommonJS: https://youtu.be/8O_H2JgV7EQ
A
Excellent:
hey
thanks
for
joining
us.
This
is
just
going
to
be
a
quick
video.
We
were
talking
in
an
mr
and
some
code
review
about
questions
about
what
was
going
on
in
our
package,
manifest,
as
we
were
uploading
slippers
to
npm
and
javi,
had
some
good
questions
about
it
and
thought
that
we
should
like
record
a
conversation
answering
those
questions.
A
A
Stand-Up
comedy
tour,
love
it
okay.
So
here's
my
screen,
excellent
and
so
everything
changes
now
that
my
zoom
window
is
different.
So
looking
at
the
agenda,
lauren
posted
this
screen-
laura
sorry.
Apologies
posted
this
screenshot
of
these
errors.
Talking
saying
that
when
you
were
working
locally,
there
were
these
warnings
that
the
modules
can't
be
found
and
it
wasn't
a
problem
in
production.
Do
you
want
to
say
more
about
what
was
going
on
there
any
other
details
about
what
you
were
like?
What
were
you
trying
to
do?
A
Absolutely
that
makes
sense,
so
there's
a
quick
solution
or
a
quick
thing
for
people
to
note
if
they're
doing
local
development
on
about
doculab.com.
We
have
this
documented
in
our
webpack
docs.
There's
a
link
in
the
agenda
here,
there's
a
known
issue
with
webpack
dev
server,
where
the
dev
server
stays
attached
to
the
process
too
long,
and
so
sometimes
so,
if
you're
seeing
console
errors,
they
may
look
like
this.
A
Maybe
a
little
bit
different
but
you'll
see
like
wds
stands
for
webpack
dev
server,
if
it's
like,
if
it
can't
find
files,
it
may
just
be
that
you
have
an
old
process
running
that
has
not
found
new
files.
That
does
happen.
Usually
you'll
see
404s
for
that.
So
I
didn't
think
it
was
necessarily
that,
but
it
could
have
been
because
it
presents
differently.
A
So
there's
a
document
in
the
repo
about
how
to
resolve
that
you
just
have
to
kill
the
process
and
restart
it
so
and
that's
kind
of
out
of
scope
for
like
we
don't
control
that
that's
just
a
known
bug
with
dev
server,
but
here's
what
the
actual
solution
was
right.
Laura
is.
This
was
the
the
fix
here.
So
and
I'll
talk
about
how
I
got
there,
so
I'm
looking
at
this
error,
I
see
a
lot
of
like
module,
build
failed.
I
see
like
the
work,
module,
a
whole
bunch
and
then
here's.
A
What
really
like
got
me
thinking
that
this
is
what
it
was.
If
you
look
at
in
each
of
these
messages,
there's
a
file
path
at
the
top,
so
this
is
module
identifier
and
then
users
or
dug
in
www
all
the
way
down
to
like
this
there's
a
source
file,
but
then
there's
also
like
a
node
underscore
modules
path,
identifier
there
so
like,
and
this
gets
to
the
broader
point
of
like
what
all
is
going
on
with
modules.
Yes,
modules,
common
js,
all
these
imports
webpack,
I
would
almost
never
expect
not
never.
A
I
generally,
you
wouldn't
expect
to
see
node
underscore
modules
like
in
a
404
or
error
message
in
a
browser
console,
because
that
is
a
folder
that
typically
speaking,
bundlers
like
webpack,
they
know
about
it
and
they
provide
something
else
to
the
browser.
So
in
these
two
you
see
these
two
errors.
The
first
one
is
like
I'm
like:
okay
webpack
is
having
a
problem
with
something
because
node
underscore
modules
is
there
and
the
second
one
is
where
it
says
like
source
javascript
slippers,
like
that
kind
of
makes
me
think
that
it
is.
A
This
is
actually
also
a
webpack
one.
Here's
another
note
before
I
get
to
like
the
conclusion:
webpack
dev
server
will
inject
its
own
scripts
into
your
local
site
instance,
and
it
will
give
you
its
own
error
messages,
so
you
also
have
to
parse
out
like.
Is
this
coming
from
code
being
executed
in
the
browser
runtime
or
is
webpack
dev
server
telling
me
something
and
that's
why
they
have
these
like
notes
like
wds?
So
that's
a
thing
to
like
be
careful
of
so
looking
at
that
and
thinking
like.
A
Oh,
this
might
be
a
web
pack
issue.
I
was
like
this
to
me.
My
first
instinct
is,
and
even
if
I
didn't
have
all
that
detail-
and
someone
was
like
if
someone
just
said
to
me-
like
hey,
I'm
running
this
locally
and
it's
not
working
I'd,
be
like
cool
like
delete,
node
modules
and
then
type
yarn
like
that's.
Probably
that
would
fit
it's
just
the
classic,
like
turn
it
off
and
on
again,
but
for
webpack
or
for
javascript
or
like
places
where
node
meets
browser-based
javascript.
A
This
is
the
place
to
do
it
so
yeah
and
that
ended
up
working
and
and
like
it
really
was
basically
what's
happening.
Here
is
node
modules,
the
folder
isn't
version
controlled,
along
with
all
of
the
like
webpack
config
and
all
the
files
that
basically
there
are
a
bunch
of
files
that
expect
like
they
tell
webpack
hey,
go
find
this
other
stuff
in
node
modules
and
they
expect
it
to
be
there.
A
But
since
your
node
modules,
folder
is
not
version
controlled
along
with
those
changes,
if
you
have
not
like
kept
up
to
date,
if
you
switch
branches
like
you
said,
and
your
node
modules
is
out
of
date
between
them
or
it's
out
of
sync,
you
will
have
problems.
We
have.
We
had
a
community
contribution,
or
maybe
this
is
from
a
product
team
person
who
added
a
nice
warning
message
now.
A
So
if
you
try
and
like
run
a
yarn
command
in
about
doculab.com
or
in
the
repo
you'll
get
it
and
your
if
your
node
modules
don't
match
your
package
lock
file
or
your
yarn
lock
file,
you
should
get
an
error.
I
don't
know
if
it's
entirely
foolproof,
but
that
should
help
a
little
bit
with
some
of
this
and
catch
it
earlier
on.
So
that's
how
I
came
to
that
conclusion.
A
Unfortunately,
that
was
the
solution
which
is
cool
and
then,
if
we
can
talk
about
like
what's
happening,
we
got
a
couple
like
two
or
three
minutes
left.
If
we
want
to
walk
through
the
the
chain
of
what's
going
on,
do
either
of
you,
two
have
like
thoughts
on
that
questions
on
that
on
the
troubleshooting
side,
specific
questions
about
what's
going
on.
B
A
Awesome
so
I'll
try
and
keep
it
brief,
it's
hard
for
me,
but
we
should
be
good.
So
I
wanted
to
start
by
taking
a
look
at
webpack
config.
We're
gonna
make
some
assumptions
about
pre-existing
knowledge
here
about
like
kind
of
what
web
web
pack
is
and
why
you
might
use
it,
but
we
can
go
further
deeper
in
other
conversations,
so
we
also
have
this
documentation
in
the
like
hard-coded
doc
file,
which
is
generally
meant
for
developers.
A
But
if
you're
curious
about
this
stuff,
we
have
the
really
detailed
like
what's
going
on
with
webpack
under
doc,
webpack
md,
it's
linked
in
the
agenda,
which
I
will
link
here
and
so
there's
two
things
that
webpack
does
for
us
right
now.
We
either
run
it
in
production.
It
just
like
runs
as
a
command
and
takes
it
consumes
our
configuration
file
seeing
here
and
like
takes
input
files
and
turns
them
into
specific
output
files.
That
middleman
like
relies
on.
A
A
The
other
thing
it
does.
Is
it
acts
as
a
dev
server
and
at
the
bottom
of
the
webpack
config
file,
there
is
dev
server
configuration,
and
so
this
runs
differently
and
separately
from
the
webpack
process
itself.
This
is
what
we
use
in
local
development.
It
gives
us
like.
It
allows
us
to
see
our
changes
faster,
basically
without
having
to
rebuild
the
whole
thing,
but
it
does
present
a
handful
of
other
challenges,
like
we
said
like
like
there's
a
bug
with
dev
server,
where
it
doesn't
kill
the
process
appropriately.
A
A
So,
instead
of
like
writing
files
to
disk
it
does
it
in
the
ram,
which
also
means
that
it's
harder
to
inspect
the
actual
state
of
the
generated
output
there
are,
you
can
configure
dev
server
to
do
it,
but
it's
like
slower
and
like
finicky,
so
here's
a
tip
for
troubleshooting.
If
you
want
to
see
what's
hap,
if
you
want
to
see
what
webpack
is
going
to
do,
you
can
just
run
webpack
in
production
mode
from
your
local
command
line,
and
that's
in
the
package.
A
Json
there's
a
script
for
it
and
I'll
link
to
that,
because
we're
getting
close
to
time,
but
then
you'll
actually
see
the
output,
and
so
you
can
kind
of
test
like
what's
getting
output.
Dev
server
also
has
a
url
which
is
documented
in
this
dock.
Here
like
where
you
can
go
see
what
dev
server
thinks
is
being
compiled
out,
but
it's
kind
of
it's
a
little
tricky
to
get
to
it's,
not
always
where
you
think
it's
going
to
be
so
refer
back
to
this
doc.
A
For
that
config
basically
defines
the
behavior
of
how
we're
manipulating
these
files.
We
do
it
a
little
differently
than
most
than
a
traditional
webpack.
Config
is
for
backwards.
Compatibility
with
how
our
project
has
been
set
up.
Most
webpack
config
will
bundle
everything
together
in
one
file
or
maybe
a
couple
different
bundles.
We
do
not.
We
basically
do
like
a
copy
procedure
where
we
do
the
webpack
stuff
to
the
source
javascript,
which
is
in
here.
This
is
like
one
basically
source
javascripts
are
slippers.js.
A
Webpack
takes
this
and
it'll
turn
it
into
like,
basically,
a
copied
version
of
it,
but
it'll
transpile,
some
stuff
out
for
us,
so
yeah
we're
about
at
time.
The
final
thing
I
want
to
say
is
like
so
I
just
want
to
show
like
here's.
What
webpack?
Here's?
What
I
mean
when
I
say
that
thing
about
webpack,
here's,
our
slippers,
javascript.
We
have
a
css
file
as
well.
A
This
file
tells
webpack
how
to
interpret
lines
one
and
two
in
the
javascript
file
and
how
to
interpret
line
one
in
the
css
file.
It
also
tells
webpack
where
to
find
these
files.
That's
what
the
config
file
is
doing
and
then
webpack
looks
at
these
and
says
hey.
I
know
what
to
do
with
this,
because
you
have
configured
me
in
my
config
file
and
then
it
creates
a
thing
and
it
like
either
puts
it
on
the
dev
server
or
puts
it
in
the
dist
folder
and
more
details
to
come.