Turborepo now supports non-monorepos today!

Is this in progress? Currently remote and local caches gets diverged in non-monorepo project, even a basic one one from non-monorepo example.

I thought about this, too, and I basically miss two things, which turn out to be pretty much the same. (Because I think the configuration for those two could basically be the same)

1. work on non-monorepo projects
2. have package-level override

Imagine a ts app/project app that needs to generate code before it works, e.g. https://www.graphql-code-generator.com/ or https://www.prisma.io/.

Yes, it's definitely possible to pull these things out into their own package, but I think a separate package should be used for logical units and not be a work-around to enable caching.

Especially with graphql files I really like the colocation with the implementation, so it's a real pain to move all of them to a whole different folder/package just to have the code generation cached.

I think next to "pipelines", there could be a separate "package" config entry. This config is either taken into account for single package.json non-monorepo projects, or within the monorepo on the individual package's package.json. The parent turbo could then look at these individual overrides.

Codegen Example:

{
  "turbo": {
    "package": {
      "build": {
        "dependsOn": [
          "codegen"
        ]
      },
      "codegen": {
        "inputs": [
          "src/graphql/**.*graphql"
        ],
        "outputs": [
          "schema.graphql",
          "src/graphql/generated.ts"
        ]
      }
    }
  }
}

Prisma Example

{
  "turbo": {
    "package": {
      "build": {
        "dependsOn": [
          "prisma:generate"
        ]
      },
      "prisma:generate": {
        "inputs": [
          "prisma/prisma.schema"
        ],
        "outputs": [
          "node_modules/.prisma/client"
        ]
      }
    }
  }
}

Yep! Top-level commands are a must-have

+1 for the idea to support non-monorepo projects.

And there is another use case similar to this: support the scripts in the top-level package.json within a yarn workspace.

For example, some projects have top-level lint and start commands.

@rauchg and I were just taking about this the other day! It’s a great idea