Nested workspace ignored after upgrading to 1.12.2 from 1.11.3

[edgarrroussille]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/edgarrroussille/turbo-1.12.2-ignored-workspaces/tree/main

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

turbo 1.12.3-canary.0

Describe the Bug

TLDR:

Using nested packages worked with turbo@1.11.3
Using same directory structure with turbo@1.12.0 doesn't work anymore

Consider this directory structure:

- apps
  - apps-a
    - package.json
    - apps-b
      - package.json

with thispnpm-workspace.yaml:

packages:
  - apps/**
  - packages/*

Running pnpm turbo build with turbo@1.11.3 would build apps-b
Runnin same command with turbo@1.12.0 and later would not build apps-b

Expected Behavior

Searching through past issues, #942 states that nested directory wasn't actually supposed to be supported... but it worked since we migrated to turborepo (summer '23) and from our point of view it's definitely a regression :(

As this folder structure worked in earlier versions, I'd love a way to keep it working as is...

To Reproduce

1. Clone repo
2. cd 1.11.3 && pnpm i && pnpm turbo build
3. See all 5 packages are built
   4 cd ../1.12.0 && pnpm i && pnpm turbo build
4. See only 4 packages are built: apps-b is missing

Additional context

Not an expert, but it's most probably coming from #7025

[Klaitos]

Same issue on our side, we have a package inside a package that is ignored now, the turbo prune command fails on 1.12. We are stuck to 1.11 from now until a package architecture refactor.

[chris-olszewski]

@edgarrroussille Can you update your example so that the 1.11.3 directory contains a nested workspace?

[edgarrroussille]

@edgarrroussille Can you update your example so that the 1.11.3 directory contains a nested workspace?

Sorry about that, just updated the repo :)

[gsoltis]

We're looking into this. While nested packages aren't technically supported, we did previously find them and allow scripts to run. I suspect, but haven't confirmed, that caching won't work very well in a nested scenario.

@edgarrroussille the team is interested in use cases for nested packages. If you don't mind, can you describe what you are aiming to accomplish with your setup?

[edgarrroussille]

Thank you @gsoltis

To be honest if I could avoid it I would. My use case is pretty specific, but maybe others would face similar issues with the serverless/reduced context part:

We're using a Backend As A Service (nhost.io) and the issue lays with their "build on push" logic (same as vercel) : as we're in a monorepo, I point nhost to a subdirectory. This subdirectory's structure is constrained, and their build system can't go up (out of the registered subdirectory) to use the whole monorepo as context... (no private packages either)

Here's the constrained structure:

...
- **apps**
  - **backend** (= nhost subdirectory)
    - package.json
    - nhost (= config/metadata/migrations)
    - functions (= file based routing serverless functions)
...

We faced a blocker when using their serverless functions (exposed through HTTP endpoints generated based on the contents of ./functions). As we needed to use some core/reusable business logic within these functions. Obviously I got other apps that also need access to this custom business logic code.

So we ended up with this structure:

- **apps**
  - [...other apps]
  - **backend**
    - package.json
    - nhost (config/metadata/migrations)
    - functions (file based routing serverless functions)
    - **core**
      - package.json

Within our serverless functions code, we'd import what we need using import { utilA, classB } from "../core"
And from all the other apps, we simply add it as a regular local dependency: "@monorepo/core":"workspace:*"

Again, if I had total control over the deployment process I would not use nested workspaces, pruning and --docker flag work just great in all our other apps.

[Jarrku]

We've also bumped into this issue, our use case for nested packages is the following:

We have an application, but ripped certain packages out that are used by 3rd parties to integrate the application (as an example, app-1 is codesandbox.io and pkg-a | pkg-b | pkg-c are packages used to integrate the application, but reusing certain constants (so for example one package can be the general embed logic, and another package a react wrapper)

- apps
	- app-1
		- app (src code for the actual hosted application, published privately)
		- packages
			- pkg-a (Core embedding logic, published publicly)
			- pkg-b (Constants reused in the application and pkg-a, published publicly)
			- pkg-c (React wrapper around pkg-a, published publicly)

We opted to colocate those packages under the app, as they're only relevant for that specific application. We can move these packages to the top level as well, but liked that we could nest these under the main application.

[gsoltis]

Thank you all for the use cases. We're continuing to look at what Turborepo should do in these situations.

Can you all verify that turbo@1.12.3 captures the packages you're expecting?

[lluiscab]

turbo@1.12.3 has solved a similar issue we found where it did not detect any packages in scope when running any tasks, I'd assume it could very well be the same issue discussed here

[nihitavr]

I am using turbo@1.13.0 and it sill has the same issue. Nested workspaces are getting ignored when running tasks.

[AndreaPontrandolfo]

@gsoltis at our company, nested workspaces are necessary because of Shopify.
Shopify Checkout extensions have a mandatory nested structure (a folder with as many Shopify apps as you want, and every shopify app can have as many Checkout Extensions as you want. Both apps and checkout extensions have a package.json.).
This feature is definitely needed for us and for any Shopify developer (checkout extensions became mandatory starting August 2024).