标签: lerna

我正在使用 lerna 创建一个 monorepo，其中我有一个这样的结构：

root 
  packages
    application - Our root application 
    components  - Just some react components, that are to be used by the application

这是一个工作 Github，其中包含一个简单的示例。

我遇到的问题是我正在使用 Material-UI 及其主题功能，在应用程序根目录中，我们将有一个 ThemeProvider：

import { ThemeProvider } from '@material-ui/styles';
//...

function App() {
  return (

  <ThemeProvider theme={theme}>
          <MyMaterialComponent/>
  </ThemeProvider>
  );
}

然后在库组件中，我们使用主题，在我们的例子中使用makeStyles钩子。

import React from 'react';
import { makeStyles } from '@material-ui/styles';
import Card from "@material-ui/core/Card";

const useStyles = makeStyles(theme => {
    console.log(theme); //When this component doesn't have …

我在某处听说可以为所有 Lerna 子存储库创建一个 ESlint 预设，但是当开始积极收集有关此的信息时并没有找到明确的信息。

为什么它很有吸引力

如果我想为所有子存储库更改 ESLint（或 TSLint）的设置，则需要一些时间.eslintrc在每个项目中进行编辑。

问题

当然，我们可以放在.eslintrcmonorepo的顶层（与 同级lerna.json）。但是当我们在 IDE 中打开子存储库之一时，它不会.eslintrc在项目外搜索。所以我想.eslintrc我必须在每个子存储库的根目录中。Lerna 能解决这个问题吗？

我有一个由lerna管理的monorepo，它依赖于 Yarn 工作区功能。它看起来像这样：

/repo
  |-- packages
  |   |-- pkg-a
  |   |   |-- package.json
  |   |-- pkg-b
  |   |   |-- package.json
  |   |-- pkg-c
  |   |   |-- package.json
  |-- package.json

我yarn upgrade-interactive用来更新我的软件包中的一系列依赖项，但出现此错误：

Invariant Violation: expected workspace package to exist for "@babel/plugin-transform-classes"

然而，这不是我的直接依赖。当我在所有package.json文件中搜索它时，我什么也没得到：

$ find . -name "package.json" -and -not -path "*/node_modules/*" | xargs grep "@babel/plugin-transform-classes"
$

虽然它存在于我的yarn.lock文件中：

$ grep "@babel/plugin-transform-classes" yarn.lock
"@babel/plugin-transform-classes@^7.10.4":
  resolved "https://registry.yarnpkg.com/@babel/plugin-transform-classes/-/plugin-transform-classes-7.10.4.tgz#405136af2b3e218bc4a1926228bc917ab1a0adc7"
"@babel/plugin-transform-classes@^7.4.0":
  resolved "https://registry.yarnpkg.com/@babel/plugin-transform-classes/-/plugin-transform-classes-7.4.0.tgz#e3428d3c8a3d01f33b10c529b998ba1707043d4d"
    "@babel/plugin-transform-classes" "^7.4.0"
    "@babel/plugin-transform-classes" "^7.10.4" …

我们正在迁移Monorepo以使用Lerna。

Lerna支持NPM和Yarn，并且还允许配置与Yarn工作区一起使用。对于我来说，尚不清楚带有纱线工作区的Lerna是否比带有NPM的Lerna有任何明显的优势。许多帖子声称Lerna开箱即用地做与Yarn工作区差不多的事情。

与带有NPM的Lerna相比，将Lerna与Yarn工作区一起使用是否有任何优势？

我有这样的标准Lerna存储库：

my-repo
 - package.json
 - packages
   - api
     - package.json
   - web-app 
     - package.json

如果我在两个包中都需要相同的依赖项（例如lodash），那么教程中的人建议将它安装到两个子模块中，然后使用lerna bootstrap --hoist标志引导项目。

由于--hoist标志lodash依赖将仅加载到根级别，node_modules但两个子模块都将其作为依赖包含在适当的位置package.json

但是 Node 的包解析算法会在文件树中搜索文件node_modules夹。

所以我的问题是为什么我不能只将公共依赖项安装到根级项目？然后lodash将位于 root 的node_modules. 并且子模块（包）会找到它，因为 Node 会node_module一直搜索直到到达文件系统的根目录。

至少它会帮助我避免使用 uncommon lerna bootstrap --hoist，并且lodash依赖项只会在顶层出现一次package.json（而不是两次：在package.json两个子模块中）

我们在Sentry上提供了所有Javascript相关SDK的monorepo。 https://github.com/getsentry/sentry-javascript

如果克隆该回购协议，以正确设置它 yarn install ，然后打开像任何文件packages/node/src/backend.ts，并尝试跳转到另一个包执行的功能等limitObjectDepthToSize，生活在该utils包。

首先，如果您之前未构建项目（已放置所有类型定义），则会弹出此错误：

但是，即使您之前CMD+Click已经构建了所有内容，现在函数上的内容始终会跳转到所构建的内容，object.d.ts而不是我真正想要的是，它跳转到可以在中找到的实现源文件， packages/utils/src/object.ts而不是/packages/utils/object.d.ts。

现在我的问题是，我们的设置是否错误，VSCode中是否有任何选项，或者可以tsconfig.json修复此代码导航？

还是这是目前在单存储环境中VSCode的已知限制？

感谢您的帮助，希望我没有错过任何真正明显的事情，谢谢！

我想为我们的前端应用程序使用 monorepo。我们希望将一些 React UI 组件划分到“/packages/ui-components”下的包文件夹中，并将应用程序保留在“/apps/app”文件夹中，然后让应用程序通过导入来使用 ui-components（简化设置） 。我们不打算很快将这些包发布到各个 npm 存储库，而只是让最终的应用程序运行。

我开始有点担心我们如何才能拥有最好的工作流程，由于某种原因，我在我的研究中找不到这个：

应用程序应该使用包中的 src 文件还是将每个包编译到 dist 文件夹并仅导入这些文件？

在工作流程方面，我们希望在不同的包中无缝工作，因此，如果有人在包中进行编辑，我们希望这些更改立即显示在应用程序中。

与使用 dist 输出相比，我看到使用源文件的一些优点和缺点。

直接使用 src 的优点：

• 更好的树摇动，因为依赖关系可以是对等依赖关系，并且可以组合多个包使用的库。
• 由于 webpack 可以更好地访问完整依赖树和常用函数等原始数据，因此最终包大小更小。
• 较小项目的开发迭代速度更快，因为只有一个构建，而智能 Webpack 可能只能重新编译一些更改的文件。

使用 dist 的优点：

• 更多独立的包，因为它们可以包含自己的构建管道。
• 由于对等依赖项较少并且需要特殊的 webpack-config，因此导入会更容易
• 准备作为公共 npm 包发布
• 可能更快的构建时间，因为只有更改的包和主应用程序需要在更改时重新编译（我假设 webpack 可以进行缓存，所以也许这并不重要）

我确信我遗漏了很多细节；如今，设置良好的开发流程非常复杂，我想让我的同事尽可能简单地使用它。

TL;博士;

mono-repo 中的包应该构建到他们的 dist 中供其他人使用，还是直接从 src 导入更好。

我有一个包含许多不同前端 React 项目的存储库，它们都有自己的 package.json 文件。

我有四个要求：

1. 我想让所有这些项目保持在同一个依赖轨道上。（即，我希望我的所有项目都使用每个 npm 包的相同版本）
2. 我希望能够使用一个“全局”命令将每个 package.json 更新到最新版本。
3. 理想情况下，我想使用某种经过验证的开源工具，例如 Yarn Workspaces 或 Lerna，而不是使用全局 package.json 文件自行管理这一切。
4. 我正在使用 Yarn 生态系统。

这些包不需要同时运行。并非每个项目都包含完全相同的依赖项，但所有项目都至少包含一些常见的依赖项（即 React、Webpack、Babel 等）。这些包也是完全私有的，不应在 npm 上发布，而只能在 GitHub 上发布。

我已经对工具进行了一些研究，但我很困惑是否仅使用 Yarn Workspaces 就能解决问题，或者是否有必要使用 Lerna。这是我迄今为止在 Yarn Workspaces 中所做的事情：

文件夹结构：

Repo-root
   Packages
      Project-1
      Project-2

回购根 package.json：

{
   "private": true,
   "name": "example-monorepo",
   "workspaces": ["packages/*"],
   "scripts": {}
}

据我所知，Yarn Workspaces 尝试将所有常见依赖项移至幕后的根 node_modules，但我对如何完成共享依赖项安装和更新到最新版本要求感到困惑。Yarn Workspaces 能否自行满足要求，或者 Lerna 是否需要此功能？在勒纳如何实现这一目标？我是否需要定义一个全局的 package.json“单一事实来源”，或者这些工具是否在幕后自行执行某些版本？Lerna 或 Yarn Workspaces 如何“知道”如何在没有全局版本范围集的情况下将所有单独的 package.json 文件更新到最新版本？（我希望所有项目都相同）

我正在使用下面的命令

lerna bootstrap --hoist

我希望 lerna 将包的所有 dev 和 prod 依赖项安装到主根 node_modules 中。 有些包是相互依赖的。

当我运行 bootstrap 命令时，它将所有依赖项安装到根节点模块。但在这个过程之后，它会将一些包相互符号链接。

我只想将所有依赖项安装到根节点模块，包括依赖包。我不需要任何符号链接依赖项。

如何避免符号链接过程？

我有/frontend（JS/Vue）和/backend（PHP）的存储库docker-compose.yml用于开发。但现在我需要添加另一个 JS 前端，该前端将共享一些组件、库等。我不想重复代码，所以我发现我可以使用许多工具来实现此目的，例如lerna、nx等turborepo，用于使用共享包管理 monorepo。

问题是我发现的所有教程和示例存储库都基于 100% JS 存储库，例如前面的 React + 后面的 Nest 等。

所以问题-用于前。nx在具有多种语言的存储库上有意义，只是为了在 JS 包上利用它？如果是，目录结构应该是什么样子？或者也许有更好的 monorepo 工具是为多种语言设计的，而不仅仅是 JS？