Support for yarn workspaces

[inxilpro]

Support for yarn workspaces

[sgronblo]

I figure out another workaround. You can use yarn's nohoist option to make sure that app-root-path doesn't get hosted to the top "project root" directory.

If you put this in your subproject/package.json and re-install packages (I usually do yarn install --force) you should end up with app-root-path in subproject/node_modules which then should cause a correct lookup and find your ormconfig.js:

{
  "workspaces": {
    "nohoist": [
      "typeorm/**",
      "typeorm"
    ]
  }
}

[jbreeden]

I just bumped into this as well. As a workaround, you can use the ConnectionOptionsReader directly to get options from any folder/file you like.

My connection stuff is still a bit messy, but I'll post it here as an example. Note that I apply the name "default" to my config so the connectionOptionsReader.get call will work.

import * as fs from 'fs';
import * as path from 'path';
import { createConnection, Connection, ConnectionOptionsReader } from "typeorm";

const connectionOptionsReader = new ConnectionOptionsReader({
    // TODO: Maybe look in every folder up from CWD
    root: process.cwd()
});

let connectionOptions;
let connection;

export default async function connect (): Promise<Connection> {
    if (!connection) {
        connectionOptions = {
            ...(await connectionOptionsReader.get(process.env.TYPEORM_CONNECTION || 'default')),
            entities: [__dirname + "/entity/**/*.js"],
            migrations: [__dirname + "/migration/**/*.js"],
            subscribers: [__dirname + "/subscriber/**/*.js"]
        };
        connection = createConnection(connectionOptions);
    }

    return connection;
}

Checking in process.cwd() seemed to mimic the behavior of the typeorm cli commands (like typeorm migration:generate), so it was convenient to have this behavior be consistent.

I also found it convenient to set the entities and other paths here so that I could consume this package from other repos, with their own ormconfig.js files, and not have to keep setting up these paths. Not sure if I'm doing all of this right, but at least I can load my configs in my monorepo now!

Hope that's helpful

[inxilpro]

Oof, that seems like a nightmare to resolve. I think the first step is to try to enumerate all the different cases that we need to account for and the expected behavior. Maybe you could start there and see if anyone has comments?

[nwittwer]

I recently ran into this issue with Typeorm specifically as well.

@sgronblo's solution was great for Yarn v1, but if you're using Yarn v2–v3, you will likely need a .yarnrc.yml (I added it to my workspace directory) with the following:

nodeLinker: node-modules
nmHoistingLimits: workspaces

Now run yarn and you should see the node_modules folder inside your workspace directory, with Typeorm in node_modules as well.

(You can now safely remove the deprecated nohoist code from your root package.json)

---

nohoist is deprecated in v2+ and replaced by nmHoistingLimits (Docs).

This article also explains more about Yarn's decision to change away from nohoist.

P.S. if you're switching from Yarn v1 to v2+, I recommend reading their step-by-step upgrade guide.

[inxilpro]

Does anyone have any recommendations on how to handle workspaces?

[inxilpro]

I suppose we could read the package.json file in the discovered root path, and look for a "workspaces" key, and adjust the behavior if that exists…

[Brianzchen]

@inxilpro This is my goto package and just realised it's not bulletproof under yarn workspaces! Would be keen to help with this.

regarding looking for workspaces. Child projects can also have workspaces such as for nohoist

"workspaces": {
  "nohoist": ["react-native", "react-native/**"]
}

Do you have any other ideas of how we could solve this?

[Brianzchen]

It should be safe to just check the package.json if there's workspaces that's Array.isArray() or workspaces.packages that's Array.isArray() we can safely assume this is the root package of the mono repo. Should work well for yarn which is what I'm familiar with.

And if not, we keep traversing up the tree until we find a package.json that fits the criteria