在这篇文章中，我们将要讨论两个众所周知的困难的话题，这两个问题非常接近我的心，也很贴心：ngUpgrade和身份验证。首先，我们将介绍从AngularJS升级到AngularJS的基础。然后，我们将看一个将AngularJS身份验证策略升级到AngularJS的实例。我们将看一个使用Auth0进行机器对机器（M2M）身份验证的示例应用程序。"学习如何从AngularJS迁移到新的角度框架。"在推特上留言本文基于我在Auth0在线见面会上的一次演讲。你可以在这里观看演讲的录音和幻灯片。ngUpgrade基金会早在2016年末，我在尝试将我公司的应用程序从AngularJS升级到AngularJS时遇到了一些非常痛苦的问题。我完全不知所措，不知所措。我不想愤怒地翻翻办公桌，到山洞里去生活，而是决定把我的挫败感引导到学习所有关于升级过程的知识，并在升级过程中为社区记录下来。这就是我的视频课程升级AngularJS的来源，我自己的血，汗，和眼泪，搞清楚了这个过程。我希望能为别人节省我投入的几百个小时。这也是为什么我要写这篇文章来帮助你节省时间。ngUpgrade背景让我们从一点背景知识开始。AngularJS（1.x）于2018年7月1日进入一个长期稳定的时间表，将持续到2021年6月30日。最后一个稳定的版本是1.7版。那么，这会给我们留下什么呢？这给我们留下了新的角度（2+）。现在您有了这个桥接期来确定是否需要升级，如果需要，则使用ngUpgrade库完成升级。大多数时候，您应该升级，但也有少数例外。主要的例外是，如果您的应用程序从现在起将处于休眠状态。如果你再也不打算在它上面做更多的特性开发，你就不需要升级了。AngularJS包和cdn将永远存在。您不必担心遗留代码会蒸发为稀薄的空气，并且无法对此采取任何措施。也就是说，如果你在做特性开发，你应该帮自己一个忙，然后转到Angular。Angular更快，有很多更好的特性，有很多架构和数据流的最佳实践已经融入到框架中。不过，别担心。你不必一次完成所有的事情，你可以循序渐进地去做，并花时间去做正确的事情。我经常被问到的另一个问题是，"我是否应该重写所有的内容来进行React/Vue/whatever？"大多数时候，答案都是否定的，除非你已经有了具备这些专业知识的团队成员（或者你只是出于某种原因，真的想换一个不同的框架）。转移到另一个框架是不太可能的。ngUpgrade库是@AngularJS/upgrade/static包，它被明确地用来弥补AngularJS和AngularJS之间的差距。React或Vue没有类似的库。ngUpgrade过程让我们从高层次上了解一下升级过程是什么样子的。有两个不同的阶段。第一阶段：准备首先是准备阶段。AngularJS的优点之一是它非常灵活。您可以在许多不同的情况下使用AngularJS，从简单的数据绑定到复杂的单页应用程序。不过，这种灵活性也有缺点。很长一段时间以来，没有一个关于AngularJS的最佳实践的集合，直到johnpapa出现并将所有内容编入AngularJS风格指南。这真的很有帮助，因为有这么多构造应用程序的可能方法真是令人困惑。不过，并不是所有的应用程序都能立即符合样式指南。这意味着我们有很多可能的起点。没有"一刀切"的解决方案。因此，ngUpgrade过程的一部分就是让您的AngularJS代码符合最佳实践。准备阶段包括ngUpgrade过程的四个组成部分：你的文件结构。这里有两个关键的事情要与风格指南保持一致。首先，按功能组织文件，而不是按类型组织文件。第二，每个文件只有一个条目。你的依赖关系。在如何最好地管理依赖关系方面，我们一度意见分歧。现在，我们已经将npm（或yarn）作为管理包和依赖关系的最佳方法（不再是Bower！）。我们还需要使用AngularJS的最新版本（至少1.5，但最好是最新版本）。你的建筑。AngularJS 1.5引入了组件API，它支持组件架构。将应用程序移到组件体系结构是准备阶段的一部分。还介绍了AngularJS-1.hooks和life-cycle-one绑定。升级时，您需要用组件替换控制器，并删除所有这些$scope实例。在你开始使用ngUpgrade之前，你不一定要把所有东西都弄得井井有条，但你的最终结果将是组件架构，无论是AngularJS还是Angular。离组件越近，升级就越容易。您的构建过程。构建过程是我们想要做的工具，以便编译所有的应用程序，并为ngUpgrade库做好准备。实际上，这意味着使用Webpack进行模块绑定，并为代码使用Typescript。这意味着用ES6模块替换脚本标记或任务运行器，如Gulp和Grunt。我们的目标是使我们的工具与角度工具完全一致，以便在某些时候我们可以移动到角度CLI。说到CLI - 如果您可以立即在遗留应用程序中使用它，那么一定要这样做。但是，在某些情况下，您不能立即将CLI应用到升级项目中。您可能到处都有自己的代码结构，或者有一个非常定制的构建过程。在这些情况下，您需要等待至少清理完代码和体系结构，以便应用程序更好地适应CLI。CLI在如何组织您的代码方面非常固执己见，并且希望拥有您的构建过程。从长远来看，这是非常棒的，它解决了AngularJS早期的问题，但从短期来看，如果您使用的是一个使用旧模式的大型应用程序，则可能会令人沮丧。最后一个关于处理这四个构建块的注释。这不一定是一个线性过程。在你开始学习ngUpgrade之前，不是所有这些都需要完全完美。特别是，架构部分可以很慢地完成，也可以在升级过程中同时完成。这实际上取决于你的应用程序有多大，你有多大的能力来处理这些技术债务，同时你也在做功能开发和错误修复。除了更新依赖项之外，唯一真正重要的是构建过程，因为我们确实需要一个模块绑定器和TypeScript来使用ngUpgrade并开始移动我们的应用程序。阶段2：升级现在我们来谈谈升级阶段，它有三个不同的部分。第一个是安装和设置，您将安装Angular和ngUpgrade的所有包，然后引导两个框架并排运行。（我们不会在这里详细讨论，但我在上面写了一篇详尽的文章斯科蒂奥帮你解决这个问题。）第二部分是迁移过程。这是一个循环，将应用程序的各个部分逐渐移动到Angular，并使用ngUpgrade让AngularJS和AngularJS代码相互交谈。有不同的方法来实现这一点，但是大多数人选择一条路线，从底部或顶部开始，这取决于他们的应用程序的结构。通常情况下，从依赖项最少的项移到依赖项数最多的项。例如，我通常从一条线路上的服务开始，然后逐步向上通过组件。此迁移过程可能需要多长时间。我喜欢为ngUpgrade设置应用程序，然后在沙子上画一条线，所有的新特性都将是有角度的。然后，当我在Angular中添加一个新特性时，不可避免地会涉及代码库的其他部分。在我这样做的时候，我可以重写这些部分，然后按照我的方式进行处理，这样它就成为整个开发周期中的一个自然过程。最后，将路由保留到最后，因为路由是应用程序的大脑。把所有的东西都重写成AngularJS，然后用新的AngularJS路由器替换掉旧的AngularJS路由器。在这里的某个地方，如果你想继续赚钱的话，你必须将这些代码部署到生产中。你必须为生产设置你的代码。这意味着您需要利用Angular的静态编译过程，称为提前编译。Angular有两种运行模式。它可以在实时（JIT）编译模式下运行，也可以在提前（AOT）编译模式下运行。编译器占用了Angular库的一大块。当您在开发和使用JIT编译时，该编译器将被打包在您的包中，并随您一起进入浏览器。当您使用AOT编译过程时，所有东西都会提前编译，编译器代码本身不必放入您的包中。还有很多其他的原因，比如更好的安全性，但是底线是AOT比JIT更小、更快，所以它更适合生产。要了解更多关于如何为AOT设置Webpack的内容，可以查看我写的这篇文章。在我的课程中，我也有关于这个设置的一步一步的视频。我们现在有了不同的处理方法