Angualr-Library笔记

基本用法

创建library

• 创建一个名为my-workspace【名字自取】的工作区

  # --create-application=false 表示创建的不是一个应用程序
  ng new my-workspace --create-application=false
  1
  2

• 进入到my-workspce工作区下，向工作区中增加一个 my-lib【名字自取】的库

  ng generate library my-lib
  1

library本地测试

• 要在本地使用我们创建的库，还需要创建一个angualr项目

  ng new my-project
  1

• 打包创建的my-lib库

  # 在·my-workspace·根目录下执行
  npm run build
  1
  2

• 打包完成后，会在dist目录下看到打包后的my-lib

• 进入到 dist/my-lib下，执行：

  npm link
  
  # 执行完成后，会提示我们：
  # C:\Program Files\nodejs\node_modules\my-lib -> xxxx\my-workspace\dist\my-lib
  
  # 此时我们去到 C:\Program Files\nodejs\node_modules 下，就可以看到我们的打包的 my-lib 已经被连接了这里。
  1
  2
  3
  4
  5
  6

• 此时，在回到我们生成的 my-project 根目录下

  npm link my-lib
  
  # 取消连接，执行：npm unlink my-lib
  
  # 执行完毕后，会展示：
  # xxx\my-project\node_modules\my-lib -> C:\Program Files\nodejs\node_modules\my-lib -> xxx\my-workspace\dist\my-lib
  
  # 这其实就是展示了我们 link 进来的 my-lib 的源在哪里。
  1
  2
  3
  4
  5
  6
  7
  8

• 到此为止，我们就可以使用我们的 my-lib 库了,例如：

  // 在 my-project 的 app.modules.ts 文件中，引入我们的 MyLibModule
  import { MyLibModule } from 'my-lib';
  // 导入一下
  imports: [
      MyLibModule
  ]
  
  // 在 app.component.html 下
  <lib-my-lib> </lib-my-lib>
  1
  2
  3
  4
  5
  6
  7
  8
  9

• 运行my-project项目，我们就可以看到效果：

  页面上多了一行 my-lib works

watch实时监听 library 变化

注意：下面的 watch 执行，是建立在 npm link 之后，即，我们必须要手动的把我们打的包 npm link 之后，再去执行下面的步骤。

毕竟，watch 只是监听代码改动并重新打包，并不会帮我们 npm link。所以这点一定要注意。

watch的作用就是营造热加载的效果，不然我们每次改变library就需要重新打包，重新 link，着实麻烦。

接下就说一下如何使用这个 watch

创建library的方法是不变的。变的是library的打包：

# 在 my-worksapce 目录下，就不执行 npm run build 了，执行：
npm run watch

# 执行完我们就会发现， library 提示我们：
# Compilation complete. Watching for file changes...
1
2
3
4
5

然后下面，就直接可以去我们创建的my-project项目下，执行：npm link my-lib即可。

此时再去改动我们的library，就会发现，library自动帮我们重新打包，并且，my-project也会自动应用最新的 my-lib的改变。

常见错误

TypeError: Cannot read property ‘bindingStartIndex’ of null

错误原因：

• 当@NgModule()从不同node_modules位置解析时会发生这种情况。
• 错误表明不知道什么原因出现了连个ivy副本。 这是由于 TypeScript 的模块解析方法 - 它node_modules通过遍历正在编译的文件目录来查找。

解决方案：

在angular.json中添加以下代码：preserveSymlinks:false。

// 具体位置如下：
project: {
	projectName: {
		architect: {
			build: {
				options: {
					"preserveSymlinks":false
				}
			}
		}
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

发布到NPM

在自己本地测试所写的没问题之后，就可进入打包发布流程。

默认已存在一个注册的 npm 账号，若无，则去注册一个。

发布

发布的流程大致分为以下几步：

1. 配置自己发布的信息，在package.json`中，例如下面这样：

   {
     "name": "syw-electron-titlebar",
     "version": "1.0.2",
     "description": "This is a angualrcli based custom electron titlebar.",
     "keywords": ["Angular", "Electron", "Titlebar"],
     "repository": {
       "type": "git",
       "url": "https://github.com/YouWillSun/syw-electron-titlebar"
     },
     "homepage": "https://github.com/YouWillSun/syw-electron-titlebar",
     "peerDependencies": {
       "@angular/common": "^12.2.0",
       "@angular/core": "^12.2.0",
     },
     "dependencies": {
       "tslib": "^2.3.0"
     }
   }
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18

   • name 这个将会是发布后的NPM包名，所以，要保证唯一性，即在NPM上不存在同样的名称。
     • 验证方法，可以去 npm搜索自己的包名，若无，则基本可以。
     • 上面的验证方法不是很稳妥，因为有些包废弃之后是搜索不到的，所以，还可以从URL来验证，比如直接输入URL：https://www.npmjs.com/package/ 后面拼接上自己的包名。
   • version 版本号，注意版本号最好别搞个 0.0.0，这是不好的
     • 有一个很奇怪的点，Angualr-library 有两个 package.json ,一个存在于项目根目录下，一个存在于projects库下面。
     • 发布时的版本号，竟然不是根据库下的版本号来的，即projects/xxx/package.json 配置的版本号没用，直接是根据项目根目录下的package.json 的版本号里来的，所以这里要注意一下。
   • description 包的描述
   • keywords关键词，配置关键词，发布后会在NPM上展示。
   • repository仓库，上面配置的是 git 仓库。
   • homepage主页面，一把是官网地址等等，如果有的话。

   还有就是注意修改库目录下的README文件，此文件将会是包发布后对外展示用法或版本或依赖的说明文件，要搞好，不然别人下了你的库，也不知道咋用。

2. 在项目根目录下[不是库目录，是项目根目录]，执行打包命令。

   npm run build
   1

   默认情况下，打包后输出的位置都是在dist/xxxx下。

3. 进入到dist/xxxx执行npm打包命令。

   npm pack
   1

   这个命令是将打包后的程序打包成一个.tgz的压缩包，而第二步的打包时打包我们的应用程序，两者不可混淆。

4. 命令行登录NPM

   npm login
   # 根据提示输入自己的信息
   1
   2

   验证自己是否登录成功，可使用命令

   npm whoami
   1

   退出登录，则使用

   npm logout
   1

5. 登录成功后，执行发布命令，发布的是我们刚才第三步执行生成的.tgz包

   npm publish xxxxx.tgz
   1

   要注意一下自己此时所在的位置，若此时在打包后的dist项目录下，当然可以直接写文件名

   若是不在，则可以将名称替换为路径，如：

   npm publish ./dist/xxxxx.tgz
   1

到此位置，我们就可以在NPM上看到自己发布的包了。

更新

对于已发布的NPM包的更新，其实流程和发布差不多，项目打包 --> npm打包 —> 发布。

要注意的最大的问题就是 **版本号 **问题，因为新发布版本的版本号不能和线上的一样。

• 版本号可以自己定义，这个没啥说的，改package.json就行。

• 也可以使用 npm 官方提供的版本控制,而且更具语义化：

  npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
  1

  啥意思呢：

  • major：主版本号（大版本）
  • minor：次版本号（小更新）
  • patch：补丁号（补丁）
  • premajor：预备主版本
  • preminor: 预备次版本
  • prepatch：预备补丁版本
  • prerelease：预发布版本

  比如你的初始版本是 1.0.0，你修改了一些bug，发布新版本时，你就可以执行：

  npm version patch
  # 此时，你的版本号就会改为 1.0.1
  1
  2

  再比如，你加了一些功能，你就可以执行：

  npm version minor
  # 此时你的版本号就会改为 1.1.0
  1
  2

其他的不变，进行正常的发布即可。

OK，说了重要发发布和更新，还有其他一些知识点，比如：撤销发布，推荐大家看两遍文章，写的挺好：

NPM包（模块）发布、更新、撤销发布

Angular Library 系列之 发布

npm version minor
# 此时你的版本号就会改为 1.1.0
1
2

其他的不变，进行正常的发布即可。

OK，说了重要发发布和更新，还有其他一些知识点，比如：撤销发布，推荐大家看两遍文章，写的挺好：

NPM包（模块）发布、更新、撤销发布

Angular Library 系列之 发布