NPM 7已经出来了，它支持工作空间。他们还将在即将发布的版本中继续开发这个领域，
也就是说，lerna拥有比npm7或yarn工作区更多的高级特性，而且，yarn声明他们永远不会试图取代lerna这样的工具，相反，他们打算实现处理工作区的核心逻辑，如安装子包依赖项和包符号链接。
一个很好的例子是命令：lerna changed，它为您提供了自上一个标记版本以来已更改的软件包列表，这可能对CI/CD非常有帮助。欢迎您探索lerna提供的额外命令。
到目前为止，npm7支持的与工作空间相关的唯一命令实际上是npm i/npm ci，这不是新命令，但它确实处理了嵌套的包和符号链接。
我写了一篇文章，如果你想在move to a monorepo上运行npm 7的话，它会更深入地分析配置，所以不使用lerna绝对是一个选择，与lerna相比，你可能需要在CI/CD方面做更多的工作，并添加一些会影响嵌套包的开发脚本。

答案是肯定的，你仍然需要Lerna或其他工具来补充npm@7工作区的特性。这些是npm@7工作区不能处理的事情（在写这个答案时）：

了解monorepo拓扑

npm工作区在一定程度上了解monorepo包的拓扑结构，例如，工作区知道package-c使用package-a和package-b作为它的依赖项，但有一点需要记住：

$ npm run build --workspaces

此命令将对所有monorepo包运行npm run build。
假设package-a依赖于package-b，package-c同时依赖于package-a和package-b，那么命令的执行顺序取决于package.json中的workspaces数组。

{
  "workspaces": ["package-a", "package-b", "package-c"]
}

则构建顺序为：

• Package -a
• Package -b
• Package -c

但正确的顺序应该是：

• Package -b
• Package -a
• Package -c

为了按照正确的顺序构建，您应该确保在package.json中按照正确的顺序列出它们：

{
  "workspaces": ["package-b", "package-a", "package-c"]
}

变革管理

Lerna可以检测monorepo中的变化，并为您提供一个已更改的软件包列表。如果您只想对已更改的软件包进行测试，这将非常方便。npm@7工作空间还没有这样的功能（2021年10月5日）。

出版业

Lerna可以管理软件包的版本控制和发布，它有两种不同的版本管理策略：固定的和独立的。它生成修改日志，并且只发布修改过的包到npm。
当然还有更多的东西，但这些都是你在npm@7工作区上仍然需要的主要东西。如果你使用Lerna或其他工具，那就取决于你了。
我已经在一篇文章中记录了所有的things I have learned while maintaining JavaScript monorepo with Lerna，它描述了在引入npm@7之后，monorepo管理过程是如何显著简化的，但是为什么我们仍然需要使用Lerna或其他工具。

从管理的Angular 来看是的，因为它可以处理变更报告之类的事情。
然而，如果你只是想拥有一个monorepos，并且你知道依赖构建的顺序而不是依赖packages/*，那么就没有必要这样做。在大多数情况下，你可以简单地使用下面的序列来进行构建，并且在你真正需要它之前，不要使用lerna和依赖。

yarn install --frozen-lockfile
yarn workspaces run prepare
yarn workspaces run test