Integrate webpack for frontend asset compilation
What does this MR do?
Replaces rails asset pipeline (aka Sprockets) with webpack for javascript compilation, and replaces the Teaspoon rails gem with the Karma test runner.
This MR is a first pass and aims to be as simple as possible. No new features are added, no behavior should change. The messy global scope (#20983 (moved)) is maintained to emulate the sprockets environment in case there are any kludgy scripts which still rely on the old behavior. These things will all be addressed in future issues (see #27486 (moved)).
Why was this MR needed?
Sprockets is not keeping up with modern frontend development needs, and there are many things that a ruby-based javascript bundler simply isn't going to be able to handle. Webpack allows us to:
- leverage npm modules
- limit global scope pollution and have an explicit dependency tree with import/export and require
- generate source maps (for more useful stack traces)
- customize es2015 transpile settings and upgrade to babel 6
- implement hot module replacement in development
- fine tune all aspects of our asset compilation in ways that sprockets falls short
The number of changes here may seem daunting, but the majority of them are simply replacing //= require foo
with require('foo');
. Much of the other work necessary to make this work has been backported already or delegated to a separate MR (see #27486 (moved)).
Running this branch
Stop your GDK instance if it is running, then check out the gitlab-ce branch:
cd path/to/gitlab-development-kit/gitlab/
git pull
git checkout go-go-gadget-webpack
bundle install
npm install
The webpack branch must be accompanied by the corresponding GDK branch in order to function.
cd path/to/gitlab-development-kit/
git pull
git checkout webpack
gdk reconfigure # this will alter your Procfile and your gitlab.yml
gdk run
Major changes
Compiling frontend assets
bundle exec rake gitlab:assets:compile
This task replaces assets:precompile
for generating our frontend assets. The appropriate changes have already been made in the CI and omnibus packages to handle this change.
Running karma tests
bundle exec rake karma
This is an alias for rake karma:fixtures karma:tests
. After the fixtures have been generated once, you can simply run rake karma:tests
to save time, or call npm run karma
directly.
Using your own browser
bundle exec rake karma:fixtures # if the fixtures haven't already been generated
npm run karma-start
This will spin up karma on localhost:9876 so you can run the tests in a browser of your choice. Just open that url and tests will run automatically. Any time you save a javascript file, the bundles will be regenerated and the tests will run again so you get instant feedback.
Using webpack-dev-server
The GDK has been updated to configure gitlab to utilize webpack-dev-server in development. This is a deamonized webpack process which retains compiled assets in memory and serves them via HTTP, so when changes are made the entire bundle can be recompiled very quickly. This method preferred over webpack --watch
because when the bundle is being recompiled the server can block until the assets are ready again.
In order to minimize the number of ports that we use within the GDK, gitlab-rails has been configured to proxy requests to /assets/webpack/*
to the webpack dev-server in development, instead of accessing it directly.
See:
config/initializers/static_files.rb
and
lib/gitlab/middleware/webpack_proxy.rb
Does this MR meet the acceptance criteria?
-
CHANGELOG entry added -
Documentation created/updated - Tests
-
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master
(if it does - rebase it please) -
Squashed related commits together
What are the relevant issue numbers?
GitLab EE Port: gitlab-ee!1138
Related: #20983 (moved), #27486 (moved)
Closes #14634 (closed)