欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

使用ng-packagr打包Angular的方法示例

程序员文章站 2023-11-19 12:43:46
写在前面 为了让 angular 类库应用范围更*,angular 提出一套打包格式建议名曰:angular package format,包括 fesm2015、fe...

写在前面

为了让 angular 类库应用范围更*,angular 提出一套打包格式建议名曰:angular package format,包括 fesm2015、fesm5、umd、esm2015、esm5、es2015 格式,不同格式可以在不同的环境(angular cli、webpack、systemjs等)中使用。

传统方式需要对这些格式逐一打包,一个打包脚本写法。这种写法只能针对不同项目的配置,而且除非你了解这些格式的本质否则很难维护;后来社区根据 apf 规范实现了类库 ng-packagr,通过简单的配置可以将你的类库打包成 apf 规范格式。

至 v6 以后 angular cli 也基于 ng-packagr 实现了另一个 应用构建器。

如何使用

既然 ng-packagr 被 angular cli 内置,这让我们进一步简化了生产一个 apf 规范格式的类库的成本。在 angualr cli 里使用 ng g library 来创建一个类库模板,例如在一个新的 angular 应用里执行:

ng g library <library name>

而打包,则:

ng build <library name>

最终,将生成的 dist/<libary name> 目录下文件上传相应包管理服务器(例如:npm)提供给其他 人使用。

配置说明

由 angular cli 生成的类库模板大部分内容同 angular 应用一样,只是多了一个 ng-package.json 的配置文件(对于生产环境是 ng-package.prod.json),它是专门针对 ng-packagr 的一个配置文件,如同 angular.json 一般也是基于 json schema 格式,因此可以通过访问了解所有细节,以下描述一些重点项。

whitelistednonpeerdependencies

ng-packagr 默认会根据 package.json 的 peerdependencies 节点清单来决定类库所需要第三方依赖包,这些依赖包是不会被打包至类库。

然而,所依赖包不存在 peerdependencies 节点里时(当然建议需要依赖的项应该在里面),就需要该属性的配置。

lib/entryfile

指定入口文件。

lib/umdmoduleids

umd 格式采用 rollup 打包,当类库需要引用一些无法猜出正确 umd 标识符时,就需要你手动映射这些类库的标识。

"umdmoduleids": {
  "lodash": "_"
}

angular.json

angular cli 配置文件 angular.json 内会增加一个以 <libary name> 命名的构建配置,绝大多数配置性同普通 angular 应用如出一辙,唯一不同的是 builder 节点为:

"builder": "@angular-devkit/build-ng-packagr:build"

次级入口

有时候一个类库可能会包含着多个二次入口,就像 @angular/core 类库包含着一个 @angular/core/testing 模块,它只是运用于测试,因此并不希望在项目中引入 @angular/core 时也包含测试代码,但同时二者又是同一个功能性时,这种次级导入显得非常重要。

另一种像 ngx-bootstrap、@angular/cdk/ally 等都提供次级模块的导入,可以更好的优化体积。

不论出于何种目的,都可以通过 angular cli 简单的文件组织进一步打包出主、次级分明的类库。

ng g library 生成的结构大概如下:

<libary name>
├── src
|  ├── public_api.ts
|  └── lib/*.ts
├── ng-package.json
├── ng-package.prod.json
├── package.json
├── tsconfig.lib.json
└── tsconfig.spec.json
当根目录下包含 readme.mdlicense 时会自动被复制到 dist 目录中,npm 规定必须包含 readme.md 文件,否则访问已发布类库页时会有未找到描述文件错误提示。

若想创建一个 <libary name>/testing 的次级入口,只需要在 <libary name> 根目录下创建一个 testing 目录:

<libary name>
├── src
|  ├── public_api.ts
|  └── lib/*.ts
├── ng-package.json
├── ng-package.prod.json
├── package.json
├── tsconfig.lib.json
├── tsconfig.spec.json
└── testing
  ├── src
  |  ├── public_api.ts
  |  └── *.ts
  └── package.json

核心是需要提供一个 package.json 文件,而且内容简单到姥姥家。

{
  "ngpackage": {}
}

最后,依然使用 ng build <libary name>,会产生一个次级导入模块。

小结

至此,基本上利用 angular cli 可以快速的构建一个可发布于 npm angular 类库,更复杂的可以构建像 ngx-bootstrap、@angular/cdk/* 类库。

自定义构建

angular cli 虽然提供非常便利的环境,但是对于一些复杂环境像 delon 类库(基建系列类库)包含着多个类库、类库又包含多个次级导入时,angular cli 会显得有点啰嗦,特别是对每个类库的 angular.json 配置。其实 @angular-devkit/build-ng-packagr 非常简单,如果将取进一步简化,整个实现差不多相当于:

const path = require('path');
const ngpackage = require('ng-packagr');

const target = path.resolve(__dirname, './projects/<libary name>');

ngpackage
 .ngpackagr()
 .forproject(path.resolve(target, `ng-package.prod.json`))
 .withtsconfig(path.resolve(target, 'tsconfig.lib.json'))
 .build()
 .then(() => {
   // 构建完成后干点事
 });

将上面的代码放到 ./build.js,执行:

node scripts/build.js

其结果完成是等价。

build() 返回的是一个 promise 对象,意味着可以确保构建开始前和结束后做一点额外的事。

总结

ng-packagr 极大简化 angular 类库被打包出一个 apf 规范建议,虽然它以 ng- 开头,但本质上并不一定非要在 angular 中运用,也可以使用在 react、vue。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。