Skip to content

Integrate webpack for frontend asset compilation

Mike Greiling requested to merge go-go-gadget-webpack into master

webpack-logo

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 (closed)) 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?

What are the relevant issue numbers?

GitLab EE Port: gitlab-ee!1138

Related: #20983 (closed), #27486 (moved)

Closes #14634 (closed)

Merge request reports