Security News
JSR Working Group Kicks Off with Ambitious Roadmap and Plans for Open Governance
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
@angular-builders/custom-webpack
Advanced tools
Custom webpack builders for Angular build facade. Allow to modify Angular build configuration without ejecting it
@angular-builders/custom-webpack is an npm package that allows you to customize the Webpack configuration in Angular projects. It provides a way to extend or override the default Angular build process with custom Webpack configurations.
Custom Webpack Configuration
This feature allows you to specify a custom Webpack configuration file (extra-webpack.config.js) that extends or overrides the default Angular build configuration. The custom configuration can be applied to both build and serve commands.
{"angular.json":{"projects":{"your-project-name":{"architect":{"build":{"builder":"@angular-builders/custom-webpack:browser","options":{"customWebpackConfig":{"path":"./extra-webpack.config.js"}}},"serve":{"builder":"@angular-builders/custom-webpack:dev-server","options":{"customWebpackConfig":{"path":"./extra-webpack.config.js"}}}}}}},"extra-webpack.config.js":{"module":{"rules":[{"test":"\\.js$","exclude":"/node_modules/","use":{"loader":"babel-loader","options":{"presets":["@babel/preset-env"]}}}]}}}
Merge Strategies
This feature allows you to define merge strategies for the custom Webpack configuration. In this example, the 'module.rules' array from the custom configuration is prepended to the default configuration.
{"extra-webpack.config.js":{"module":{"rules":[{"test":"\\.js$","exclude":"/node_modules/","use":{"loader":"babel-loader","options":{"presets":["@babel/preset-env"]}}}]}},"angular.json":{"projects":{"your-project-name":{"architect":{"build":{"builder":"@angular-builders/custom-webpack:browser","options":{"customWebpackConfig":{"path":"./extra-webpack.config.js","mergeStrategies":{"module.rules":"prepend"}}}}}}}}}
Custom Webpack Configuration for Different Environments
This feature allows you to specify different custom Webpack configurations for different environments (e.g., production and development). Each environment can have its own configuration file.
{"angular.json":{"projects":{"your-project-name":{"architect":{"build":{"builder":"@angular-builders/custom-webpack:browser","configurations":{"production":{"customWebpackConfig":{"path":"./webpack.prod.config.js"}},"development":{"customWebpackConfig":{"path":"./webpack.dev.config.js"}}}}}}}},"webpack.prod.config.js":{"mode":"production","optimization":{"minimize":true}},"webpack.dev.config.js":{"mode":"development","devtool":"source-map"}}
ngx-build-plus is another package that allows you to extend the Angular CLI's build process with custom Webpack configurations. It provides similar functionality to @angular-builders/custom-webpack, including the ability to merge custom configurations and support for different environments.
angular-cli-customizer is a package that enables customization of the Angular CLI build process. It allows you to modify the Webpack configuration and provides hooks for various stages of the build process. It is similar to @angular-builders/custom-webpack but offers a different approach to customization.
Allow customizing build configuration without ejecting webpack configuration (ng eject
)
npm i -D @angular-builders/custom-webpack
angular.json
:
"projects": {
...
"[project]": {
...
"architect": {
...
"[architect-target]": {
"builder": "@angular-builders/custom-webpack:[browser|server|karma|dev-server|extract-i18n]"
"options": {
...
}
Where:
[architect-target]
is not one of the predefined targets (like build, serve, test etc.) then run it like this:ng run [project]:[architect-target]
ng [architect-target]
"projects": {
...
"example-app": {
...
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser"
"options": {
...
}
ng build
browser
Extended @angular-devkit/build-angular:browser
builder that allows to specify additional webpack configuration (on top of the existing under the hood) and index.html
transformations.
The builder will run the same build as @angular-devkit/build-angular:browser
does with extra parameters that are specified in the provided webpack configuration. It will also run transformation on index.html
if specified.
Builder options:
@angular-devkit/build-angular:browser
optionscustomWebpackConfig
: see belowindexTransform
: see belowangular.json
Example:
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser"
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js",
"mergeRules": {
"externals": "replace"
}
},
"indexTransform": "./index-html-transform.js",
"outputPath": "dist/my-cool-client",
"index": "src/index.html",
"main": "src/main.ts",
"polyfills": "src/polyfills.ts",
"tsConfig": "src/tsconfig.app.json"
}
In this example externals
entry from extra-webpack.config.js
will replace externals
entry from Angular CLI underlying webpack config while all the rest will be appended. In addition index.html
will be modified by the function exported from ./index-html-transform.js
.
dev-server
Enhanced @angular-devkit/build-angular:dev-server
builder that leverages the custom webpack builder to get webpack configuration.
Unlike the default @angular-devkit/build-angular:dev-server
it doesn't use @angular-devkit/build-angular:browser
configuration to run the dev server. Instead it uses customWebpackConfiguration
from browserTarget
and runs custom webpack dev server build.
Thus, if you use @angular-builders/custom-webpack:dev-server
along with @angular-builders/custom-webpack:browser
, ng serve
will run with custom configuration provided in the latter.
angular.json
:
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser",
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js"
},
...
}
},
"serve": {
"builder": "@angular-builders/custom-webpack:dev-server",
"options": {
"browserTarget": "my-project:build"
}
}
In this example dev-server
will use custom-webpack:browser
builder, hence modified webpack config, when invoking the serve target.
server
Extended @angular-devkit/build-angular:server
builder that allows to specify additional webpack configuration (on top of the existing under the hood) and index.html
transformations.
The builder will run the same build as @angular-devkit/build-angular:server
does with extra parameters that are specified in the provided webpack configuration.
Builder options:
@angular-devkit/build-angular:server
optionscustomWebpackConfig
: see belowangular.json
Example:
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:server"
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js",
"mergeRules": {
"module": {
"rules": "prepend"
}
},
"replaceDuplicatePlugins": true
},
"outputPath": "dist/my-cool-server",
"main": "src/main.server.ts",
"tsConfig": "src/tsconfig.server.json"
}
In this example module.rules
entry from extra-webpack.config.js
will be prepended to module.rules
entry from Angular CLI underlying webpack config while all the rest will be appended.
Since loaders are evaluated from right to left this will effectively mean that the loaders you define in your custom configuration will be applied after the loaders defined by Angular CLI.
karma
Extended @angular-devkit/build-angular:karma
builder that allows to specify additional webpack configuration (on top of the existing under the hood) and index.html
transformations.
The builder will run the same build as @angular-devkit/build-angular:karma
does with extra parameters that are specified in the provided webpack configuration.
Builder options:
@angular-devkit/build-angular:karma
optionscustomWebpackConfig
: see belowangular.json
Example:
"architect": {
...
"test": {
"builder": "@angular-builders/custom-webpack:karma"
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js"
},
"main": "src/test.ts",
"polyfills": "src/polyfills.ts",
"tsConfig": "src/tsconfig.spec.json",
"karmaConfig": "src/karma.conf.js",
}
extract-i18n
Enhanced @angular-devkit/build-angular:extract-i18n
builder that leverages the custom webpack builder to get webpack configuration.
The builder uses customWebpackConfiguration
from browserTarget
to run the extraction process while taking into account changes in your custom webpack config.
Thus, if you use @angular-builders/custom-webpack:extract-i18n
along with @angular-builders/custom-webpack:browser
, ng extract-i18n
will run with custom configuration provided in the latter.
angular.json
:
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser",
"options": {
"customWebpackConfig": {
"path": "./extra-webpack.config.js"
},
...
}
},
"extract-i18n": {
"builder": "@angular-builders/custom-webpack:extract-i18n",
"options": {
"browserTarget": "my-project:build"
}
}
In this example extract-i18n
will use custom-webpack:browser
builder, hence modified webpack config, when invoking the extract-i18n target.
This option defines your custom webpack configuration. If not specified at all, plain Angular build will run.
The following properties are available:
path
: path to the extra webpack configuration, defaults to webpack.config.js
.
The configuration file can export either an object or a function. If it is an object it shall contain only modifications and additions, you don't have to specify the whole webpack configuration.
Thus, if you'd like to add some options to style-loader
(which already there because of default Angular configuration), you only have to specify this part of the loader:
{
test: /\.css$/,
use: [
{
loader: 'style-loader',
options: {
// `style-loader` options here...
}
}
]
}
The builder will take care of merging the delta with the existing configuration provided by Angular.
In more complicated cases you'd probably want to use a function instead of an object.
mergeRules
: webpack config merge rules, as described here. Defaults to:
{
module: {
rules: {
test: "match",
use: {
loader: "match",
options: "merge",
},
},
},
};
replaceDuplicatePlugins
: Defaults to false
. If true
, the plugins in custom webpack config will replace the corresponding plugins in default Angular CLI webpack configuration. If false
, the default behavior will be applied.
Note that if true
, this option will override mergeRules
for plugins
field.
Webpack configuration can be also written in TypeScript. In this case, it is the appliaction's tsConfig
file which will be use by tsnode
for customWebpackConfig.ts
execution. Given the following example:
// extra-webpack.config.ts
import { Configuration } from 'webpack';
export default {
output: {
library: 'shop',
libraryTarget: 'umd',
},
} as Configuration;
Do not forget to specify the correct path to this file:
"customWebpackConfig": {
"path": "./extra-webpack.config.ts"
},
If in your custom configuration you specify a plugin that is already added by Angular CLI then by default the two instances will be merged.
In case of the conflicts your configuration will override the existing one.
Thus, if you'd like to modify an existing plugin configuration, all you have to do is specify the delta you want to change.
For example, if you'd like to allow cyclic dependencies that include dynamic imports you only have to specify this single entry:
module.exports = {
plugins: [
new CircularDependencyPlugin({
allowAsyncCycles: true,
}),
],
};
Keep in mind though that if there are default values in the plugin's constructor, they would override the corresponding values in the existing instance. So these you have to set explicitly to the same values Angular sets.
You can check out an example for plugins merge in the unit tests and in this issue.
Webpack config can also export a Promise
object that resolves custom config. Given the following example:
// extra-webpack.config.js
const fs = require('fs');
const util = require('util');
const webpack = require('webpack');
const readFile = util.promisify(fs.readFile);
module.exports = readFile('./LICENSE', {
encoding: 'utf-8',
}).then(license => ({
plugins: [new webpack.BannerPlugin(license)],
}));
In this case, the behavior will be the same as when exporting a plain object — the resolved configuration will be merged with the base one.
If customWebpackConfig.path
file exports a function, the behaviour of the builder changes : no more automatic merge is applied, instead the function
is called with the base Webpack configuration and must return the new configuration.
The function is called with the base config the builder options and the target options as parameters.
TargetOptions
follows target
definition from this schema
and can be used to manipulate your build based on the build target.
In this case, mergeRules
and replaceDuplicatePlugins
options have no effect.
custom-webpack.config.js
example :
const webpack = require('webpack');
const pkg = require('./package.json');
module.exports = (config, options, targetOptions) => {
config.plugins.push(
new webpack.DefinePlugin({
APP_VERSION: JSON.stringify(pkg.version),
})
);
return config;
};
Alternatively, using TypeScript:
import { CustomWebpackBrowserSchema, TargetOptions } from '@angular-builders/custom-webpack';
import * as webpack from 'webpack';
import * as pkg from './package.json';
export default (
config: webpack.Configuration,
options: CustomWebpackBrowserSchema,
targetOptions: TargetOptions
) => {
config.plugins.push(
new webpack.DefinePlugin({
APP_VERSION: JSON.stringify(pkg.version),
})
);
return config;
};
It's also possible to export an asynchronous factory (factory that returns a Promise
object). Let's look at the following example:
// extra-webpack.config.js
const axios = require('axios');
const webpack = require('webpack');
async function getPortalVersion() {
const response = await axios.get('http://portal.com/version');
return response.data.version;
}
module.exports = async config => {
const version = await getPortalVersion();
config.plugins.push(
new webpack.DefinePlugin({
APP_VERSION: JSON.stringify(version),
})
);
return config;
};
Since Angular 8 index.html
is not generated as part of the Webpack build. If you want to modify your index.html
you should use indexTransform
option.
indexTransform
is a path (relative to workspace root) to a .js
or .ts
file that exports transformation function for index.html
.
Function signature is as following:
If indexTransform
is writes in TypeScript, it is the application's tsConfig
file which will be use by tsnode
for indexTransform.ts
execution.
(options: TargetOptions, indexHtmlContent: string) => string|Promise<string>;
or, in other words, the function receives target options and original index.html
content (generated by Angular CLI) and returns a new content as string
or Promise
.
TargetOptions
follows target
definition from this schema and looks like this:
export interface Target {
configuration?: string;
project: string;
target: string;
}
It is useful when you want to transform your index.html
according to the build options.
angular.json
:
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser"
"options": {
"indexTransform": "./index-html-transform.js"
...
}
index-html-transform.js
:
module.exports = (targetOptions, indexHtml) => {
const i = indexHtml.indexOf('</body>');
const config = `<p>Configuration: ${targetOptions.configuration}</p>`;
return `${indexHtml.slice(0, i)}
${config}
${indexHtml.slice(i)}`;
};
Alternatively, using TypeScript:
import { TargetOptions } from '@angular-builders/custom-webpack';
export default (targetOptions: TargetOptions, indexHtml: string) => {
const i = indexHtml.indexOf('</body>');
const config = `<p>Configuration: ${targetOptions.configuration}</p>`;
return `${indexHtml.slice(0, i)}
${config}
${indexHtml.slice(i)}`;
};
In the example we add a paragraph with build configuration to your index.html
. It is a very simple example without any asynchronous code but you can also return a Promise
from this function.
Full example here.
FAQs
Custom webpack builders for Angular build facade. Allow to modify Angular build configuration without ejecting it
The npm package @angular-builders/custom-webpack receives a total of 244,309 weekly downloads. As such, @angular-builders/custom-webpack popularity was classified as popular.
We found that @angular-builders/custom-webpack demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.