Routes in .blitz dir broken when using multiple apps in a monorepo

[nickluger]

What is the problem?

Multiple apps in monorepo write to the same .blitz directory which is hoisted into the monorepo's top-level node_modules. The issue is also described here: #92, including a temporary workaround.

Paste all your error logs here:

No logs

Paste all relevant code snippets here:

No snippets

What are detailed steps to reproduce this?

1. Create two blitz apps in a monorepo and yarn workspaces hoist your dependencies into a top-level node_modules.
2. Run blitz codegen, inspect /node_modules/.blitz in one of the apps.
3. Run in the other.

Run blitz -v and paste the output here:

macOS Big Sur | darwin-x64 | Node: v14.17.5

blitz: 0.41.1 (local)

  Package manager: npm
  System:
    OS: macOS 11.5.2
    CPU: (8) x64 Apple M1
    Memory: 154.82 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.5 - /var/folders/0t/qf92ltfx37jblv7t_3_7v8mh0000gn/T/yarn--1635001662121-0.45095447188894155/node
    Yarn: 1.22.17 - /var/folders/0t/qf92ltfx37jblv7t_3_7v8mh0000gn/T/yarn--1635001662121-0.45095447188894155/yarn
    npm: 6.14.15 - /var/folders/0t/qf92ltfx37jblv7t_3_7v8mh0000gn/T/fnm_multishells/46353_1634987771186/bin/npm
    Watchman: Not Found
  npmPackages:
    @prisma/client: Not Found
    blitz: 0.41.1 => 0.41.1
    prisma: Not Found
    react: Not Found
    react-dom: Not Found
    typescript: Not Found

Psst! the Not Found stuff happens when you use a monorepo, too.

Please include below any other applicable logs and screenshots that show your problem:

No response

[flybayer]

For working on this, here's the line that determines the .blitz location. https://github.com/blitz-js/blitz/blob/canary/nextjs/packages/next/build/routes.ts#L139 So the logic for determining this needs fixed.

[nickluger]

I would tackle this, but do not understand how location resolution would solve this, because findNodeModulesRoot is working correctly, as far as I can see, by finding the hoisted, top level node_modules, where both, Next and Blitz are installed.

The problem with multiple apps is, that Next uses the generated .blitz directory/module directly, e.g. here. So if Next is hoisted to the monorepo's top-level node_modules, Blitz has to be hoisted too, et vice versa.

Both, local and hoisted .blitz directories are failing with multiple Blitz apps, though:

1. Multiple local .blitz directories:
   We cannot use local, project-level .blitz directories to distinguish multiple Blitz apps, due to the fact that Next is hoisted and node does not search "down the tree" for dependencies. This only works with my workaround, which keeps both, Blitz and Next local.

2. One hoisted .blitz directory:
   We cannot use one hoisted .blitz directory, either. if we use more than one Blitz app, we have a naming conflict at the top level, as Next always just calls .blitz and will not be able to distinguish between the apps, even if we had different (sub-)directories for the apps.

This is not a Blitz-specific issue, would happen e.g. with the auto-generated .prisma directory, too, if you hoist it, but have different apps using different Prisma schemas. For me this version of the workaround is pretty reasonable though, because it does not include sub-dependencies of Blitz and Prisma, and keeps the project level node_modules directories pretty small:

 "nohoist": ["**/blitz","**/@blitzjs/*", "**/next"]

[flybayer]

@nickluger ok wow, thank you so much for the investigation. That makes total sense. So it sounds like the only thing to do at this point is add some docs on monorepo usage and include the nohoist option?

[nickluger]

I can add something to do docs, at least for yarn workspaces. (PNPM, Rush etc. i don't know, they might have similar features) I think the only other solution would be some kind of module resolution config in webpack that alias to a different dir on build, but seems a bit over the top for this use case.

[beerose]

hey @nickluger! Are you still up to adding it to the docs? I'm not sure what would be the best place, though. Maybe having some FAQ section or something would be good? We could document there some common questions, problems, workarounds etc.