简体   繁体   English

Bazel 与 lerna 和 yarn 工作区一起使用

[英]Bazel using with lerna and yarn workspace

Many people are using lerna and/or yarn workspace.许多人正在使用 lerna 和/或 yarn 工作区。

I guess either migrating from them to Bazel, or just using them with Bazel together is good to be guided with an example project.我想无论是从它们迁移到 Bazel,还是将它们与 Bazel 一起使用都可以通过示例项目进行指导。

For example, currently, I have a directory structure like this, where foo is an express server and bar is a library consumed by foo, both based on typescript.例如,目前,我有一个这样的目录结构,其中 foo 是一个快速服务器, bar 是 foo 使用的库,两者都基于打字稿。

<project root>
├── jest.config.js
├── lerna.json
├── package.json
├── packages
│   ├── bar
│   │   ├── jest.config.js
│   │   ├── package.json
│   │   ├── src
│   │   │   └── index.ts
│   │   ├── test
│   │   │   └── unit
│   │   │       └── index.test.ts
│   │   ├── tsconfig.build.json
│   │   └── tsconfig.json
│   └── foo
│       ├── jest.config.js
│       ├── package.json
│       ├── src
│       │   ├── hello.ts
│       │   └── index.ts
│       ├── test
│       │   ├── integration
│       │   │   └── index.test.ts
│       │   └── unit
│       │       └── index.test.ts
│       ├── tsconfig.build.json
│       └── tsconfig.json
├── tsconfig.build.json
├── tsconfig.json
└── yarn.lock

How should I align it with Bazel, like you know, WORKSPACE, BUILD, and their contents?我应该如何将它与 Bazel、WORKSPACE、BUILD 及其内容对齐?

Any tips or examples?任何提示或示例?

Thanks!谢谢!

There are some examples of repo structures somewhat similar to this in the rules_nodejs examples directory .rules_nodejs 示例目录中有一些与此有些类似的 repo 结构示例 This shows (in this case an Angular app) having shared libs and consuming them, but the principle is the same here.这表明(在这种情况下是一个 Angular 应用程序)共享库并使用它们,但这里的原理是相同的。

Generally, you'd only have one WORKSPACE file in the root of your project.通常,您的项目根目录中只有一个 WORKSPACE 文件。 While it's possible to have multiple package.json files for different apps and libs, it adds some extra complexity to the ts_library rules which, for getting started, may be best avoided.虽然可能有多个package.json文件用于不同的应用程序和库,但它为ts_library规则增加了一些额外的复杂性,对于入门来说,最好避免。 This example repo shows multiple package.json files, but without Typescript.此示例存储库显示了多个package.json文件,但没有 Typescript。

For BUILD (or BUILD.bazel ) files, the minimum you'll need here is one in foo and one in bar (and one at the root).对于BUILD (或BUILD.bazel )文件,此处至少需要一个在foo ,一个在bar (以及一个在根中)。 The more BUILD files you have, the more you split up the compilation units for your source, therefore increasing incrementality.您拥有的 BUILD 文件越多,您为源代码拆分的编译单元就越多,从而增加增量。

Then add ts_library rules to those BUILD files, docs for which can be found here , they also show the differences between using tsc directly and ts_library .然后将ts_library规则添加到那些BUILD文件中,可以在此处找到其文档,它们还显示了直接使用tscts_library之间的区别。 You can then define source dependencies between foo and bar , a quick example shown below:然后,您可以定义foobar之间的源依赖项,如下所示的快速示例:

packages/foo/BUILD : packages/foo/BUILD

ts_libaray(
  name = "foo",
  srcs = glob(["src/**/*.ts"]),
  deps = [
    "//packages/bar", <-- this is the source dep for bar
    "@npm//some-package",
  ],
)

packages/bar/BUILD : packages/bar/BUILD

ts_libaray(
  name = "bar",
  srcs = glob(["src/**/*.ts"]),
  deps = [
    "@npm//some-other-package",
  ],
)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM