Integrate webpack for frontend asset compilation (duplicate MR)
This is a duplicate of !7288 (merged). I am opening this because the original is currently inaccessible due to some kind of database error.
This MR uses webpack to compile our frontend assets and replaces the Teaspoon test runner with Karma, a javascript based test runner.
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
-
Added for this feature/bug -
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