Ben 的笔记

最近在某个项目从 Angular 8 升级的时候，允许 npm install 的时候遇到如下报错：

 
npm ERR! code EINVALIDPACKAGENAME
npm ERR! Invalid package name "__ngcc_entry_points__.json": name cannot start with an underscore

网上搜索到的方法主要是讲通过如下操作解决：

rm -rf node_modules
npm install

估计有的人行，但我这里仍然报错。实际上还应该删除 package-lock.json 文件才行。

rm -f package-lock.json

我主要是各种包的版本升级折腾遇到的，估计也是小概率吧。

Angular 项目的升级说起来也简单，也复杂，也有踩坑的地方。

简单的方面就是，官方提供了升级的指导，访问 https://update.angular.io/ 选择项目的当前版本号和想要升级的版本号，就会出来相关的步骤作为指导。

复杂的地方就是，ng update 工具其实只能完成一部分工作，通常我们升级的过程中，会需要手工处理不少冲突与不兼容的地方，踩坑的地方也主要就在这里。

具体来说，有如下经验供参考：

1，不建议一次性从6 升级到 10，而建议逐个版本依次升级。因为每个版本迭代都可能有很多地方调整修改，涉及对应的依赖包版本的调整或者应用代码的修改。若一次跨多个版本升级，对于遇到问题时候的定位会造成困难。

有一点小细节需要注意：执行 ng update 升级成功并不代表代码一定能正常编译运行。因此，建议对于每个版本升级，都把代码启动起来测试，以验证升级是否成功。

2，注意各个依赖包的版本兼容问题

基本上每次升级，都伴随着对应的很多依赖库需要相应升级。ng update 能自动升级一部分，但不是全部。尤其是当你用了很多三方包的时候。一般 ng update 失败的话，常见的原因就是提示某某库依赖于另外某个库的某个版本，而你将要安装又是某个版本。这时候就需要对相关的包进行升级。

主要注意点是，对于版本的选择并非是最新版就最好，譬如当我们从 Angular 6 升级到 7 的时候，其实应选择的是最兼容当时 Angular 版本的包版本。譬如 Angular 7 发布于 2018年10月，而 Angular 8 发布于2019年6月，那么就可以在 npm 官方站查找所要升级的依赖包的版本历史，选择发布时间介于 2018年10月和2019年6月的则基本就可以。若仍然提示版本问题，则可以尝试其它版本。

3，Angular 8 升级到 Angular 9 遇到 typings.d.ts 中的类型定义未生效的问题，这个主要是在 Angular 9 中有了 tsconfig.app.json 文件，在 ng update 的过程中，该文件的对应配置错误导致，一般应修改如下内容：

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
  "outDir": "../out-tsc/app",
  "baseUrl": "./",
  "types": []
  },
  "files": [
    "main.ts",
    "polyfills.ts"
  ],
  "include": [
    "**/*.d.ts",
    "typings.d.ts"
  ]
}

上面代码中最后那一项就是我们项目中丢失的，添加上去后，类型定义找不到的问题就解决了。

4，注意看官方提示，有些已经修改过的用法或者已经启用的用法就果断修改。这里主要涉及到两方面，一方面是 Angular 的变化，另一方面是 TypeScript 的变化。前者譬如 Angular 7  之后，废除了 @angular/http 而一律改用 @angular/common/http。又譬如 Angular 9 中，Module 定义中就去除了 entryComponent 的配置，所以删掉对应的语句即可。

5，有些三方库的写法发生了变化，有可能需要修改对应的代码。譬如我们项目中用到了 SweetAlert2 这个库。在升级到 Angular 10的时候，我们也将该库升级到了最新版本。这时候 ng update 升级整个项目虽然没遇到关于这个库的错误，但当运行项目的时候就遇到SweetAlert.fire()这个方法报错，具体来说，我们在这个方法的第一个参数里，有用 title 关键字来指定对话框的标题，但在新版本中，这个关键字改为了 icon。这是通过查找  SweetAlertOptions 的类型定义而知道的。所以依次修改掉即可。

总结下来，整个过程一要参考官方指导，二要认真研究出错信息，找到对应出处，其实问题都不难解决。

整个升级前后跨越了五天左右的时间，头三天花的时间较多，主要是各种踩坑及各种试错。由于有洁癖，后两天再花了一点点时间，用摸索出来的最合理的办法，将升级过程重新做了一遍。

最后，看一下漂亮的提交历史：（其实每个版本的升级都开了分支，每个升级其实并不止一次 commit，为了整洁，在 merge 回来的时候加了 –squash 参数）