My approach to share Typescript code between CRA and Backend: Am I missing anything?

Question

I have a single repository with the following directory structure. The described code below can be found here

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

Since I wanted the engine code to be reused by both the frontend and backend I decided to have it in a separate shared directory. To get everything working I did the following changes:

API

1. Added @engine alias to tsconfig.json paths like so:

    "paths": {
      "@engine/*": ["../shared/engine/*"],
    },

2. Updated the package.json start script to resolve the aliasing and file watching like so:

ts-node-dev -r tsconfig-paths/register --respawn --pretty --transpile-only --watch ../shared/engine src/server.ts

With these changes, I could import engine classes in my API code using @engine, and also have real-time file watching for the shared code.

Client

1. I used react-app-rewired to override the config restrictions and updated the tsconfig.json with the above aliasing (via a base file) so that I can use the @engine annotation for my engine imports. This approach is described here.
2. To enable file watching on my shared code, I added the following to the tsconfig.json file:

   "rootDirs": [
     "./src",
     "../shared/engine"
   ],

With these changes, the frontend imports worked as expected as well.

Many of the solutions (here, here) that I have come across for this type of problem seems to be based on monorepo architecture patterns and tools like project references, yarn workspaces, lerna etc. These solutions also seem to consider the shared directory as a separate project which is built and used in the dependent projects.

My approach does not do any of that, but on the surface it seems to be doing what I want it to do (ie: aliased imports, auto reloading on code changes, and including the shared code in the respective build folders (for deployment)).

My question is, am I missing something with this approach? What sort of a scenario would require me to consider an actual monorepo architecture based on things like project references, yarn workspaces etc? What advantages would I get over my current approach?