@bloomreach/frontend-build

READ FIRST

This package, although published as a public package, is only meant to be used internally at Bloomreach. We offer no support whatsoever to anyone outside Bloomreach.

Frontend Build

Frontend build system for frontend apps at Bloomreach. Features:

• Linting, compiling and optimizing of ES2015+, TypeScript and Sass (scss) files
• Specific support for Angularjs apps.
• Run unit tests using the Karma Test Runner and Jasmine framework
• Provide text-summary and html coverage reports over original source code
• Loading of html, svg, images and fonts
• Provide sourcemaps to original source code

Changelog

Release notes are found in the changelog.

Frontend Build release steps

We use release-it to release to @bloomreach. A config file is included with preset configuration options.

Examples of commands:

• Release new minor version: `npm run release-it -- --increment=minor --src.commitMessage="[Relevant JIRA issue] Release %s"``
• Release new pre-release under a npm tag: npm run release-it -- --increment=prerelease --src.commitMessage="[Relevant JIRA issue] Release %s" --prereleaseId="[relevant prerelease] --npm.tag=["relevant npm tag"]"
• Non-interactive mode patch version publish: npm run release-it -- --non-interactive --src.commitMessage="[Relevant JIRA issue] Release %s"

Setup

All tools used (Webpack, Karma, Babel, TypeScript, ESLint, TSLint and Stylelint) will look for a configuration file in the folder where your package.json is stored. Frontend-build ships with default setup files for these tools and requires the project to extend these files.

Webpack

Create a file named webpack.config.js with the following contents:

const webpack = require('@bloomreach/frontend-build/conf/webpack');

module.exports = webpack;

Karma

Create a file named karma.conf.js with the following contents:

const karmaConf = require('@bloomreach/frontend-build/conf/karma.conf');

module.exports = karmaConf;

Babel

Create a file named .babelrc with the following contents:

{
  "extends": "./node_modules/@bloomreach/frontend-build/.babelrc"
}

TypeScript

Since 9.0.0 TypeScript code is compiled using Babel. This is faster (no type-checking) and simplifies the build pipeline. But, type-checking is why people use TypeScript, so to handle this a tsconfig.json file is provided that can be used together with the TypeScript compiler to only do the type-checking (it does not emit).

To use it, create a file named tsconfig.json with the following contents:

{
  "extends": "./node_modules/@bloomreach/frontend-build/tsconfig.json",
  "include": [
    "src"
  ],
}

Note: the project's source folder src has been configured as the entry point for the TypeScript compiler. By default it uses the project's root folder.

To execute the TypeScript compiler, add the following two NPM scripts entries:

  "lint:ts": "tsc",
  "lint:ts:watch": "npm run type-check -- --watch",

ESLint

Create a file named .eslintrc with the following contents:

{
  "root": true,
  "extends": "./node_modules/@bloomreach/frontend-build/.eslintrc"
}

To execute ESLint, add the following NPM scripts entries:

  "lint:js": "eslint src --format \"node_modules/eslint-formatter-friendly\"",
  "lint:js:watch": "esw src --watch --format \"node_modules/eslint-formatter-friendly\""

Note: It is also possible to enable caching for ESLint, which improves performance. It is recommended to only enable caching for development purposes. Caching is enabled by adding the --cache flag.

TSLint

Create a file named tslint.json with the following contents:

{
  "extends": "./node_modules/@bloomreach/frontend-build/tslint.json"
}

StyleLint

Create a file named .stylelintrc with the following contents:

{
  "extends": "./node_modules/@bloomreach/frontend-build/.stylelintrc"
}

To execute ESLint, add the following NPM scripts entries:

  "lint:css": "stylelint \"src/**/*.scss\" --custom-formatter=\"node_modules/stylelint-formatter-pretty\"",
  "lint:css:watch": "onchange -i \"src/**/*.scss\" -- npm -s run lint:css",

Note: It is also possible to enable caching for StyleLint, which improves performance. It is recommended to only enable caching for development purposes. Caching is enabled by adding the --cache flag.

Running frontend-build tasks

Frontend-build uses NPM scripts to execute it's tasks. The following scripts entries are recommended:

"scripts": {
  "build": "webpack --env.prod",
  "build:dev": "webpack --env.dev",
  "build:dll": "webpack --env.dll",
  "build:types": "tsc --emitDeclarationOnly",
  "clean": "node_modules/@bloomreach/frontend-build/bin/clean.js",
  "start": "webpack-serve --env.dev",
  "start:dist": "webpack-serve --env.prod",
  "test": "karma start --env.test",
  "test:debug": "karma start --env.test --debug",
  "test:once": "karma start --single-run --env.test",
  "type-check": "tsc",
  "type-check:watch": "npm run type-check -- --watch",
},

Options

You can use the following options as follows: npm run <task> -- --<option1> --<option2>

CLI option	Default value	Description
analyze	false	Visualize size of webpack output files with an interactive zoomable treemap. Uses webpack-bundle-analyzer.
cache	false	Provides an intermediate caching step for modules, speeds up subsequent builds. Uses HardSourceWebpackPlugin.
color	cliHasColorSupport	Enables or disables colored output. By default, colors are enabled when the terminal supports it.
debug	false	Show debug information.
dll	false	Enables Webpack's DLL-plugin to speed up rebuilds in watch mode. Note that prior to running with the -dll option you should generate the DLL files with npm run buildDll.
friendly	false	Clean webpack output using the @nuxtjs/friendly-errors-webpack-plugin. Clears the console in dev/test mode when recompiling.
profile	false	Add timing information to the build. Needs the --verbose option al well to print all relevant information.
progressbar	false	Webpack has a built-in option for showing a progress indicator, which is triggered with the --progress option. If you prefer the old progress indicator from frontend-build <= v7 you can use this option.
verbose	false	Detailed build output. When used in combination with the --debug option it will also output the aggregated frontend-build configuration and Webpack stats configuration.

Project configuration

A project can define a file build.conf.js which contains project specific configuration related to the build.

The available options are:

• entry: an object containing a mapping of all the entry files for the webpack build. Each entry will be packaged in a separate bundle. The default value is

{
  app: 'index',
}

This results in Webpack loading a module named "index" in the source folder and outputting a single bundle named "app".

Webpack DLL's

To improve the build speed for tests, we provide the possibility to use the Webpack DLL plugin. In short, this will ensure only our own sources are packaged, and external modules (like angular) will simply be included from node_modules.

To use the DLL setup, we first need to generate the DLL manifest(s): npm run buildDll This will generate a manifest JSON file with a related bundle javascript file. Now you can run the tests with DLL's: npm run test -- --dll

Note: by default, all dependencies in your package.json file are bundled into a single DLL. To have more finegrained control (change order, exclude modules, etc) you can specify a dlls property in your build.conf.js file, e.g.

dlls: {
    angularjs: [
      'angular',
      'angular-animate',
    ],
    angular: [
      'core-js',
      'hammerjs',
      'es6-shim'
    ]

Webpack special loader rules

• SVGs located in images/html/ are loaded as strings so they can be used inline
• Sass files in styles/string are loaded as strings so they can be used inline
• Sass files for Angular apps following the convention *.component.scss will be loaded as strings so they can be used inline

Testing

Loading HTML, CSS and JSON fixtures

The default Karma setup of frontend-build exposes the jasmine-jquery module for handling HTML, CSS and JSON fixtures, as well as provide a set of custom matchers that simplify validating DOM conditions, e.g. expect($('#id-name')[0]).toBeInDOM().

Fixture files should be defined adjacent to the spec files that use them, or at least as close as possible. They follow the same naming convention as the spec files and are named with a .fixture suffix, e.g. cms.login.fixture.html or cms.config.fixture.json. Karma can be instructed to serve fixture files over it's HTTP-server by adding a file pattern to the files array in the project's karma.conf.js. The default pattern is saved in cfg.src.fixtures and matches { pattern: cfg.srcDir + '**/*.fixture.+(js|html|css|json)', included: false}.

Frontend-build instructs Karma by default to proxy the path /spec/javascripts/fixtures/ (which is the default fixtures path of jasmine-jquery) to /base/src/app/. This is a combination of Karma's base path for serving files over HTTP and the root folder where frontend-build expects your Angular code to live.

When changing the karma options you can customize the proxy path with the following options:

• override cfg.srcDir in your build.conf.js which changes the default proxy path from /base/src/app to /base/[your src dir]/app

• override cfg.karmaFixtureProxyPath in your build.conf.js directly

• override options.proxies in your karma.conf.js, then you will have to replicate these two configuration values:

  proxies: {
  '/spec/javascripts/fixtures/': '[your proxy path]',
  '/spec/javascripts/fixtures/json/': '[your proxy path]',
  },
  

Example project setup and code

|- src
  |- app
    |- main.js
    |- main.spec.js
    |- main.fixture.html
    |- main.fixture.json
    |- dialogs
      |- dialog.fixture.html
      |- dialog.fixture.css
      ..

In main.spec.js you can then load your fixtures with:

// Load html fixture into the DOM
jasmine.getFixtures().load('main.fixture.html');
// from a subfolder
jasmine.getFixtures().load('dialogs/dialog.fixture.html');

// load css fixture into the DOM
jasmine.getStyleFixtures().load('dialogs/dialog.fixture.css');

// Load JSON fixture object
var jsonObject = jasmine.getJSONFixtures().load('main.fixture.json');

For more control over the paths you can use the following snippet in your spec files:

beforeEach(function () {
  jasmine.getFixtures().fixturesPath = 'base/spec/js/fixtures';
  jasmine.getStyleFixtures().fixturesPath = 'base/spec/css/fixtures';
  jasmine.getJSONFixtures().fixturesPath = 'base/spec/json/fixtures';
});