时间戳

首页 > 解决方案 > 我在 CRA 和后端之间共享 Typescript 代码的方法：我错过了什么吗？

reactjs - 我在 CRA 和后端之间共享 Typescript 代码的方法：我错过了什么吗？

问题描述

我有一个具有以下目录结构的存储库。下面描述的代码可以在这里找到

/my project/
    api/
        src/
        tsconfig.json
    client/
        src/
        tsconfig.json
    shared/
        engine/
            classes/
            types/

因为我希望engine前端和后端都可以重用代码，所以我决定将它放在一个单独的shared目录中。为了让一切正常，我做了以下更改：

API

  1. @engine为 tsconfig.json 路径添加了别名，如下所示：
    "paths": {
      "@engine/*": ["../shared/engine/*"],
    },
  1. 更新了 package.json 启动脚本以解决别名和文件监视，如下所示：
ts-node-dev -r tsconfig-paths/register --respawn --pretty --transpile-only --watch ../shared/engine src/server.ts

通过这些更改，我可以在我的 API 代码中使用 导入引擎类@engine，并且还可以实时监视共享代码的文件。

客户

  1. 我曾经react-app-rewired覆盖配置限制并tsconfig.json使用上述别名（通过基本文件）更新，以便我可以将 @engine 注释用于我的引擎导入。此处描述了此方法。
  2. 为了在我的共享代码上启用文件监视，我在 tsconfig.json 文件中添加了以下内容：
   "rootDirs": [
     "./src",
     "../shared/engine"
   ],

通过这些更改，前端导入也按预期工作。

我遇到的针对此类问题的许多解决方案（此处，此处）似乎基于 monorepo 架构模式和工具，例如项目引用、纱线工作区、lerna 等。这些解决方案似乎也将shared目录视为单独的在依赖项目中构建和使用的项目。

我的方法没有做任何事情，但从表面上看，它似乎在做我想做的事情（即：别名导入、代码更改时自动重新加载，以及在各自的构建文件夹中包含共享代码（用于部署） ）。

我的问题是，我是否错过了这种方法？什么样的场景需要我考虑基于项目引用、纱线工作区等的实际 monorepo 架构？与目前的方法相比，我将获得哪些优势？

标签： reactjstypescriptcreate-react-appmonorepo

解决方案

推荐阅读