SoFunction
Updated on 2025-04-10

Share solutions for angular sharing dependencies

webpack-ng-dll-plugin

  • The dll plugin available in the ng version is relatively wild

use

  • Improve packaging speed
  • Code reuse (micro front-end dependency sharing)

use

  • First, choose @angular-devkit/build-webpack,@angular-builders/custom-webpack,ngx-build-plus according to your personal familiarity

The first one is official, and the last two are third-party, but please do not choose the official one before confirming that you have practiced...

The author chose @angular-builders/custom-webpack when testing

  • First build the dll, it is recommended to use an empty project to create the dll, because the current development does not consider the implementation of some complex logic and the dependency saving of related third-party packages (the full mode should be implemented, theory)
  • Then reference it at build time

Quotation is a normal reference plugin for webpack, it's OK

Taste fresh

The following function filters the output of styles, polyfills, and License, and disables runtimeChunk

 setNgDllPlugin(
 config,
 {
  //Webpack's out-related configuration  output: {
  filename: '',
  },
  ngDllPluginOptions: {
   // DLL's resource list export configuration  path: (__dirname, 'dist', ''),
  name: 'TLIB',
  format: true,
  filter: {
   // Filter mode, full full amount, auto relative to the project, manual manually specify filter items (map needs to be set)   mode: 'auto',
  },
  },
 },
 options
 );

Customize

Related configurations need to be referenced (no documentation is written yet, you need to view the source code)

 (new NgDllPlugin());

Quote

// The context here can be understood as the code (application code) parsing relative to which folder (not packaged. If referenced correctly, you will find that deleting it will not affect the packaging). If you find that the packaged thing is not used, this configuration should be wrong (
 new ({
  context: (__dirname),
  manifest: require('./dist/'),
 })
 );

Demo address

/wszgrcy/ng-cli-plugin-demo

Possible technology to unlock

  • Split routing loading

Under normal circumstances, even dynamically loaded routes are packaged together with the project, but they are packaged into two files.

The main project is packaged first, and then the lazy loading routing module is developed separately

  • The usage rate of web-component increases

Although ng has implemented this, since each large package is equivalent to making a separate project, it is very large. After using the dll, it will shrink to a terrible level, and the side effects are close to 0

Current (possible) problems

  • The resource list outputs a full reference, but in fact, only mode: 'full' is equivalent

One of the unmodified ones is mainly due to the lack of impact, plus debugging needs

  • If there is a dynamic loading module in the project that generates the dll, it may have unknown effects

When designing the dll, it didn't consider dynamic modules or other things at all. It just puts a big package

Try to use empty projects to generate dlls

  • auto only means that the current generated project can reach full reference. If you modify the project, you must rebuild the project (Uh. It looks like a pattern that is more wasteful)

In fact, if the project code is sufficient (various types), modifying the code will not affect it. However, for example, some of the first time they are introduced, or some new things are used in the html template, they all need to be rebuilt.

Want to be improved

Actively exclude some exports that will never be used

Why is dll bigger than direct packaging

  • Even though DLL packaging now uses ng's Aot, tree shake and other related optimization technologies, there is still a fatal problem, that is, exporting names. When packaged by default, all names will be optimized (obfuscated), and DLL packaging must expose this name. When fully exposed, volume growth will occur.

Currently, the dll generated by empty projects (including rxjs, router, common, core) is 440k (that is, these files will be searched in the dll when other packages are used). The selective export minimizes the startup at 216k, and the final estimate is that it should be around 300k on average.

  • The technologies currently used can only be 1. Full export and 2. Select available export. This actually has a side effect. When exporting in full, not only some unused dependencies are exported, but some internal references (such as ɵangular_packages_core_core_h) are also forced to export, thereby increasing the package size

In the later stage, you can actually sort out a list that will never be exported and exclude it to reduce the volume

  • Traditional packaging is a module that uses multiple modules to package a module. Many dependencies in the middle belong to internal dependencies, so a lot of code is simplified. The packaging of dll belongs to multiple modules, so each module has an exit, and the references between modules are also used. Therefore, even if the dll is minimized, it will be about 40k more than the package.

Summarize

This is the end of this article about angular sharing dependency solutions. For more related angular sharing dependency solutions, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!