Gathering detailed insights and metrics for ngc-webpack
Gathering detailed insights and metrics for ngc-webpack
Gathering detailed insights and metrics for ngc-webpack
Gathering detailed insights and metrics for ngc-webpack
webpack
Packs ECMAScript/CommonJs/AMD modules for the browser. Allows you to split your codebase into multiple bundles, which can be loaded on demand. Supports loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
terser-webpack-plugin
Terser plugin for webpack
webpack-dev-middleware
A development middleware for webpack
schema-utils
webpack Validation Utils
npm install ngc-webpack
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
84 Stars
59 Commits
15 Forks
11 Watching
5 Branches
6 Contributors
Updated on 13 Mar 2024
TypeScript (87.29%)
JavaScript (10.67%)
HTML (1.17%)
CSS (0.48%)
Shell (0.4%)
Cumulative downloads
Total Downloads
Last day
-35.9%
186
Compared to previous day
Last week
-3.5%
1,199
Compared to previous week
Last month
-8.8%
4,879
Compared to previous month
Last year
-16.8%
53,774
Compared to previous year
9
2
49
@ngtools/webpack wrapper with hooks into the compilation process and library mode compilation support.
AOT compilation for an application.
AOT compilation for a library.
Library mode is the simple compile process we know from tsc
/ ngc
where each module (TS
file) is compiled into a matching JS
file.
The output files can then bundle up with RollUp to create various bundle formats for published libraries (FESM, FESM2015, UMD, etc.)
This process is fairly simple as is but with the angular AOT compiler in the middle things are a bit more complex.
@ngtools/webpack
does not support library compilation and it is (1.8.x)
designed for application bundling only.
The @angular/compiler-cli
does support library compilation through its
ngc
command line utility but it does not know about webpack,
resources will not go through the loader chain and so using formats not
supported by the angular cli will not work (SCSS, LESS etc).
Additionally, templareUrl
and stylesUrls
are left as is which is not
suitable for libraries, resources must get inlined into the sources code (JS)
and the AOT generated metadata.json
files.
ngc-webpack
library mode allows AOT compilation for libraries through
a CLI interface (ngc-w
) or directly using it via node API with
full support for inline and complete webpack loader chain compilation (for resources).
ngc-webpack
also support library compilation for @angular/cli
projects
by importing the configuration from the cli and using it to build libraries.
This works great with monorepos and setup's based on nrwl's Nx
.
Also available by CLI interface (ngc-w-cli
) or node API.
For more information see:
Library mode is experimental as it uses experimental API from angular packages.
ngc-webpack
started as a wrapper for @angular/compiler-cli
when angular
build tools were limited.
It offered non @angular/cli
users the ability to perform an AOT builds
with all the required operations while still using a dedicated typescript
loader (e.g. ts-loader
, awesome-typescript-loader
).
With version 5 of angular, the compiler-cli
introduces a dramatic
refactor in the compilation process, enabling watch mode for AOT and
moving to a (almost) native TS compilation process using transformers.
The support angular 5, a complete rewrite for ngc-webpack
was required.
Since @ngtools/webpack
is now a mature plugin with a rich feature set
and core team support it is not smart (IMHO) to try and re-implement it.
This is why, from version 4 of ngc-webpack
, the library will wrap
@ngtools/webpack
and only provide hooks into the compilation process.
The implications are:
ngc-webpack
is safe, at any point you can move to @ngtools/webpack
.@ngtools/webpack
will work since ngc-webpack
acts as a proxy.
This includes i18n support which was not included in ngc-webpack
3.x.x@ngtools/webpack
(for JIT see Using custom TypeScript loaders)Using ngc-webpack
as a proxy to @ngtools/webpack
is safe and allows
quick and transparent porting between the libraries.
In fact, if you use ngc-webpack
without using it's extensibility
features you probably better of using @ngtools/webpack
directly instead.
When using ngc-webpack
features, including library compilation mode,
you should be aware that ngc-webpack
is using experimental angular APIs
as well as internal implementation of angular code to allow extensibility.
1npm install ngc-webpack -D
webpack.config.js
1{ 2 module: { 3 rules: [ 4 { 5 test: /(?:\.ngfactory\.js|\.ngstyle\.js|\.ts)$/, 6 use: [ '@ngtools/webpack' ] 7 } 8 ] 9 }, 10 plugins: [ 11 new ngcWebpack.NgcWebpackPlugin({ 12 AOT: true, // alias for skipCodeGeneration: false 13 tsConfigPath: './tsconfig.json', 14 mainPath: 'src/main.ts' // will auto-detect the root NgModule. 15 }) 16 ] 17}
Production builds must be AOT compiled, this is clear, but we can optimize
the build even further, and the angular team has us covered using
'@angular-devkit/build-optimizer
:
webpack.config.js
1const PurifyPlugin = require('@angular-devkit/build-optimizer').PurifyPlugin; 2 3const AOT = true; 4 5const tsLoader = { 6 test: /(?:\.ngfactory\.js|\.ngstyle\.js|\.ts)$/, 7 use: [ '@ngtools/webpack' ] 8}; 9 10if (AOT) { 11 tsLoader.use.unshift({ 12 loader: '@angular-devkit/build-optimizer/webpack-loader', 13 // options: { sourceMap: true } 14 }); 15} 16 17return { 18 module: { 19 rules: [ 20 tsLoader 21 ] 22 }, 23 plugins: [ 24 new ngcWebpack.NgcWebpackPlugin({ 25 AOT, // alias for skipCodeGeneration: false 26 tsConfigPath: './tsconfig.json', 27 mainPath: 'src/main.ts' // will auto-detect the root NgModule. 28 }).concat(AOT ? [ new PurifyPlugin() ] : []), 29 ] 30}
The examples above are super simplified and describe the basic units for compilation, the
@angular/cli
uses them but with a lot more loaders/plugins/logic.
For more information about setting up the plugin see @ngtools/webpack
The plugin accepts an options object of type NgcWebpackPluginOptions
.
NgcWebpackPluginOptions
extends AngularCompilerPluginOptions so
all @ngtools/webpack
options apply.
NgcWebpackPluginOptions
adds the following options:
1export interface NgcWebpackPluginOptions extends AngularCompilerPluginOptions { 2 3 /** 4 * An alias for `AngularCompilerPluginOptions.skipCodeGeneration` simply to make it more readable. 5 * If `skipCodeGeneration` is set, this value is ignored. 6 * If this value is not set, the default value is taken from `skipCodeGeneration` 7 * (which means AOT = true) 8 */ 9 AOT?: boolean; 10 11 /** 12 * A hook that invokes before the plugin start the compilation process (compiler 'run' event). 13 * ( resourceCompiler: { get(filename: string): Promise<string> }) => Promise<void>; 14 * 15 * The hook accepts a resource compiler which able (using webpack) to perform compilation on 16 * files using webpack's loader chain and return the final content. 17 * @param resourceCompiler 18 */ 19 beforeRun?: BeforeRunHandler 20 21 /** 22 * Transform a source file (ts, js, metadata.json, summery.json). 23 * If `predicate` is true invokes `transform` 24 * 25 * > Run's in both AOT and JIT mode on all files, internal and external as well as resources. 26 * 27 * 28 * - Do not apply changes to resource files using this hook when in AOT mode, it will not commit. 29 * - Do not apply changes to resource files in watch mode. 30 * 31 * Note that source code transformation is sync, you can't return a promise (contrary to `resourcePathTransformer`). 32 * This means that you can not use webpack compilation (or any other async process) to alter source code context. 33 * If you know the files you need to transform, use the `beforeRun` hook. 34 */ 35 readFileTransformer?: ReadFileTransformer; 36 37 38 /** 39 * Transform the path of a resource (html, css, etc) 40 * (path: string) => string; 41 * 42 * > Run's in AOT mode only and on metadata resource files (templateUrl, styleUrls) 43 */ 44 resourcePathTransformer?: ResourcePathTransformer; 45 46 /** 47 * Transform a resource (html, css etc) 48 * (path: string, source: string) => string | Promise<string>; 49 * 50 * > Run's in AOT mode only and on metadata resource files (templateUrl, styleUrls) 51 */ 52 resourceTransformer?: ResourceTransformer; 53 54 /** 55 * Add custom TypeScript transformers to the compilation process. 56 * 57 * Transformers are applied after the transforms added by `@angular/compiler-cli` and 58 * `@ngtools/webpack`. 59 * 60 * > `after` transformers are currently not supported. 61 */ 62 tsTransformers?: ts.CustomTransformers; 63}
ngc-webpack
comes with optional patches to angular, these are workarounds
to existing issue that will probably get fixed in the future making the patch
obsolete. Patch's address specific use case so make sure you apply them only
if required.
disableExpressionLowering
fix (@angular/compiler-cli
):The compiler-cli
(version 5.0.1) comes with a new feature called
lowering expressions which basically means we can now use arrow
functions in decorator metadata (usually provider metadata)
This feature has bug the will throw when setting an arrow function:
1export function MyPropDecorator(value: () => any) { 2 return (target: Object, key: string) => { } 3} 4 5export class MyClass { 6 @MyPropDecorator(() => 15) // <- will throw because of this 7 prop: string; 8}
The compiler will lower the expression to:
1export const ɵ0 = function () { return 15; };
but in the TS compilation process will fail because of a TS bug.
This is an edge case which you probably don't care about, but if so there are 2 options to workaround:
disableExpressionLowering
to false in tsconfig.json
angularCompilerOptions
1 require('ngc-webpack/src/patch-angular-compiler-cli');
The issue should be fixed in next versions. See https://github.com/angular/angular/issues/20216
From ngc-webpack
4 using a custom ts loader is not supported for AOT
compilation and partially supported for JIT.
If you must use your own TS Loader for JIT, you can do so. This is not recommended mainly because of the mis alignment between the compilations.
To use a custom loader (JIT only), remove the @ngtools/webpack
loader
and set your own loader. To support lazy loaded modules, use a module
loader that can detect them (e.g. ng-router-loader)
The feature set within ngc-webpack
is getting more and more specific.
The target audience is small as most developers will not require hooking
into the compilation.
It is mostly suitable for library builds, where you can control the metadata output, inline code and more...
I personally use it to restyle material from the ground.
The plugin enables re-writing of the index.metadata.json
files on
the fly which allows sending custom styles to the compiler instead of
the ones that comes with material.
Because ngc-webpack
becomes a niche, I believe integrating the hooks
into @ngtools/webpack
makes sense and then deprecating the library while
easy porting to @ngtools/webpack
. If someone would like to help working
on it, please come forward :)
I believe it angular team is open to such idea since @ngtools/webpack
is separated from the cli.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 2/30 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
security policy file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
150 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More