Describe the feature you'd like to request

Abstract internal tooling (half-ripped from esbuild) into formalize package for publishing JS-wrapped Go packages to NPM.

Describe the solution you'd like

• Break out makefile into shell scripts and js script (mostly are around publishing the 10 different golang packages)

Describe alternatives you've considered

• Wait until we do presets to tackle this

What version of Turbrepo are you using?

1.0.1

Describe the Bug

Package files recovered from cache does not preserve the permissions they were originally created with, but are all set to 755.

Expected Behavior

Expected behavior would be for turbo to preserve the permission bits from the files originally generated.

To Reproduce

Run build twice in your turbo project and all files in dist/, build/ or equivalent will have mode 755.

Describe the feature you'd like to request

It seems like the only supported scenario is to use turbo on monorepos. I'd imagine similar perf improvements through smart granular caching could be had on non-repo projects as well at the file-level, etc.

Feature request: enable turbo on non-monorepo projects

Describe the solution you'd like

Documented turbo configuration should work without any workspaces configured.

Describe alternatives you've considered

The alternative would be to put my Next.js website into a separate apps/web dir and configure it as a monorepo with a single app, but this feels like overkill and doesn't work "out of the box" with vercel CI builds.

Discussed in #213

Describe the feature you'd like to request

Add a starter repo using supabase, tailwindcss and python (maybe using poetry for managing dependencies)

Describe the solution you'd like

Similar to the current kitchen sink example. Preferebly just built on top.

Describe alternatives you've considered

I realize that turborepo is not built for python applications but it would still be cool to see the best possible solution currently. E.g. what to put in cache etc.

Describe the feature you'd like to request

Turborepo offers remote caching, allowing to share cached artifacts with team members.
Currently two remote caches are available:

• Remote cache hosted by Vercel
• Custom remote cache implemented by the end-user, which mimics the Vercel API

Some users might want to store their remote caches in other object-store-like services, like:

• AWS S3 (or any S3-compatible stored like MinIO)
• Google Cloud Storage
• Azure Blob Storage
• OpenStack Swift
• Anything else that can store files (HDFS, NFS, etc.)

This can be for several reasons. Here are three I can think about:

• I am not using Vercel with my team, and I don't plan to in the forseeable future. I don't want to use yet another cloud provider
• I do not want to share my build artifacts on a product that I can't control the security on (aka I want to manage my S3 security)
• I need to store my artifacts on-prem (aka I want to store this in my own datacenter)

Describe the solution you'd like

Turborepo would offer a configuration option to choose between supported remote cache stores. Users would need to configure access parameters and credentials in the configuration file of Turborepo in their monorepo.
In this case, Turborepo would write and reads its cache from the external cache host configured (S3 bucket for example).

Implicit login would need to be supported too: in the case of S3, Turborepo should be able to use the aws CLI to authenticate its calls directly, without needing an API token / secret key. This is usually supported by the Cloud provider's SDK.

Describe alternatives you've considered

The problem with this is that Turborepo will need to implement code for each supported caching provider. This can lead to a lot of code, and possibly go outside of the scope of the project.

Here are two other solutions I can think about:

A separate proxy for each wanted cache host

Since Turborepo already supports custom HTTP endpoints (that mimic the Vercel API), we could just develop a proxy that will act as the Vercel API, and will just forward operations to the end cache provider (S3, Google Cloud Storage, etc.)

This has the advantage of not bloating the Turborepo main codebase and binary, and allowing users with exotic requirements to push a PR to Turobrepo for a very specific use-case (or forking Turborepo as a last resort).

The downside is that the proxy will have to be hosted somewhere, and that each user will need to host their own version of the proxy.

A plugin-based approach

Another way of doing this would be to delegate the communication with the remote cache to a second binary that lives in the same machine as Turborepo. Turborepo would be configured to delegate all operations to this binary.

This is similar to what Docker does with authentication to alternative registries. Here are examples of documentation: AWS ECR, Google Cloud Container Registry (their standalone helper is the closest I could find to what I'm suggesting)

Turborepo would fork a process of the provider's plugin (aka adapter), and would forward the instructions to it directly.

Again, this has the advantage of not bloating Turborepo's code, and allow for custom implementations without PRing or forking Turborepo.

Terraform also has a plugin based approach, but I'm not sure how they handle it. The Docker model will probably be easier to implement.

What version of Turbrepo are you using?

0.8.5 - 1.0.1

Describe the Bug

Pipeline task runs while its dependsOn tasks stopped working from version 0.8.5 and higher.

Working as expected in 0.8.4

Expected Behavior

The defined dependsOn tasks list should run before the main pipeline task runs.

To Reproduce

Environment

• Linux
• Node 17.1.0
• NPM 8.1.3

Config

• NPM workspaces

  "workspaces": [
    "apps/*",
    "libs/*"
  ],

• Turbo

  "turbo": {
    "bashBranch": "origin/main",
    "pipeline": {
      "dev": {
        "cache": false
      },
      "lint": {},
      "test": {
        "dependsOn": [
          "lint"
        ]
      },
      "build": {
        "dependsOn": [
          "lint",
          "test"
        ],
        "outputs": [
          "build/**",
          "dist/**",
          ".next/**",
          "!.next/cache/**"
        ]
      }
    }
  },

Describe the feature you'd like to request

Add update check + message so people can be notified when new releases come out

Describe the solution you'd like

Should mostly grab the implementation from:

• updater in PlanetScale CLI https://github.com/planetscale/cli/tree/main/internal/update
• updater in GitHub CLI https://github.com/cli/cli/tree/trunk/internal/update

Describe alternatives you've considered

Rolling it ourselves seems like a bad idea, although, it could be nice to link to a CMS service to add context to releases perhaps. But for starters, we need this.

What version of Turborepo are you using?

1.0.7

Describe the Bug

Can't create a new package and import it, seems like an error reading a tsx file?

Expected Behavior

Should be able to create another package and import it easily?
Am I missing some steps? there is no documentation on how to create a new package in the monorepo so I expected it to be as simple as that.

To Reproduce

After using npx create-turbo@latest, to create a new monorepo, I simply try to create a new package.

1. I copied the "ui" package and named the copy "btn".
2. changed the component to have different text
3. changed the package name in the packages/btn/package.json to "btn".
4. added "btn" as a dependency in apps/docs/package.json
5. change the import of the button in apps/docs/pages/index.tsx from 'ui' to 'btn'.
6. run yarn again to link my module
7. run yarn dev/build and get this error

now webpack (which is hidden by turbo to next somewhere) cannot figure out how to import the file.

What version of Turborepo are you using?

1.0.6

Describe the Bug

Using the CLI to create a new fresh turborepo setup can't compile with the initial boilerplate.

Expected Behavior

It should build and run but looks like some steps are missing on the NPM setup, Yarn works like charm.

To Reproduce

Use the doc cli to create a new turborepo setup with NPM

npx create-turbo@latest

name:
my-turborepo

package manager:
Select NPM

Install with NPM

cd my-turborepo

(base) ➜  my-turborepo git:(main)   npm run build


> [email protected] build /Users/USERNAME/Documents/Projects/monorepos/my-turborepo
> turbo run build

• Running build in 5 packages
web:build: cache miss, executing abd4b87f623a255a
docs:build: cache miss, executing afd7dbb4538c1318

web:build: > [email protected] build /Users/USERNAME/Documents/Projects/monorepos/my-turborepo/apps/web
web:build: > next build


docs:build: > [email protected] build /Users/USERNAME/Documents/Projects/monorepos/my-turborepo/apps/docs
docs:build: > next build

web:build: sh: next: command not found
web:build: npm ERR! code ELIFECYCLE
web:build: npm ERR! syscall spawn
web:build: npm ERR! file sh
web:build: npm ERR! errno ENOENT
web:build: npm ERR! [email protected] build: `next build`
web:build: npm ERR! spawn ENOENT
web:build: npm ERR! 
web:build: npm ERR! Failed at the [email protected] build script.
web:build: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
web:build: npm WARN Local package.json exists, but node_modules missing, did you mean to install?

web:build: npm ERR! A complete log of this run can be found in:
web:build: npm ERR!     /Users/USERNAME/.npm/_logs/2021-12-11T08_04_02_825Z-debug.log
web:build: Error: command finished with error: exit status 1
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `turbo run build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/USERNAME/.npm/_logs/2021-12-11T08_04_02_873Z-debug.log

Log INFO

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/Users/USERNAME/.nvm/versions/node/v14.18.2/bin/node',
1 verbose cli   '/Users/USERNAME/.nvm/versions/node/v14.18.2/bin/npm',
1 verbose cli   'run',
1 verbose cli   'build'
1 verbose cli ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle [email protected]~prebuild: [email protected]
6 info lifecycle [email protected]~build: [email protected]
7 verbose lifecycle [email protected]~build: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~build: PATH: /Users/USERNAME/.nvm/versions/node/v14.18.2/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/USERNAME/Documents/Projects/monorepos/my-turborepo/node_modules/.bin:/Users/USERNAME/Library/pnpm:/opt/homebrew/Caskroom/miniforge/base/bin:/opt/homebrew/Caskroom/miniforge/base/condabin:/opt/homebrew/opt/icu4c/sbin:/opt/homebrew/opt/icu4c/bin:/Users/USERNAME/.nvm/versions/node/v14.18.2/bin:/Users/USERNAME/.local/share/solana/install/active_release/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
9 verbose lifecycle [email protected]~build: CWD: /Users/USERNAME/Documents/Projects/monorepos/my-turborepo
10 silly lifecycle [email protected]~build: Args: [ '-c', 'turbo run build' ]
11 silly lifecycle [email protected]~build: Returned: code: 1  signal: null
12 info lifecycle [email protected]~build: Failed to exec build script
13 verbose stack Error: [email protected] build: `turbo run build`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/Users/USERNAME/.nvm/versions/node/v14.18.2/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:400:28)
13 verbose stack     at ChildProcess.<anonymous> (/Users/USERNAME/.nvm/versions/node/v14.18.2/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:400:28)
13 verbose stack     at maybeClose (internal/child_process.js:1058:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:293:5)
14 verbose pkgid [email protected]
15 verbose cwd /Users/USERNAME/Documents/Projects/monorepos/my-turborepo
16 verbose Darwin 20.6.0
17 verbose argv "/Users/USERNAME/.nvm/versions/node/v14.18.2/bin/node" "/Users/USERNAME/.nvm/versions/node/v14.18.2/bin/npm" "run" "build"
18 verbose node v14.18.2
19 verbose npm  v6.14.15
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] build: `turbo run build`
22 error Exit status 1
23 error Failed at the [email protected] build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

`

What version of Turborepo are you using?

1.0.6

Describe the Bug

I there!
I'm trying Turborepo in a mono repository that works with Lerna. Currently, I'm getting a lot of these warnings in the console:

@my-org/icons:build: error fetching from cache: error moving artifact from cache into packages\icons: createtemp packages\next\.turbo\turbo-build.log: pattern contains path separator
@my-org/icons:build: cache miss, executing 496f71e70f091e41

Looks like the cache is not being used in the subsequent runs 🤔
At the end of the process I'm getting this output:

 Tasks:    30 successful, 30 total
 Cached:    0 cached, 30 total
 Time:    2m16.758s

As far I know, this warning comes from the io/iouti package. Maybe an extra validation is needed in windows 10?

Operating System: windows 10

Expected Behavior

The subsequent runs of a pipeline should use the cache from the .turbo folder.

To Reproduce

I'm getting the same warning in the basic example project https://github.com/vercel/turborepo/tree/main/examples/basic

Describe the feature you'd like to request

Add support for --plan flag that will output JSON that includes information about what is about to happen for a given command. This can be used with scripts such as Vercel's Ignore Build Command and also in Circle and GitLab for dynamic provisioning of CI/CD workflows.

Describe the solution you'd like

Collect up info through a traversal and print out to JSON

• Should this hit caches / wonder if we need an endpoint specifically to check without downloading which we don't yet support?

Describe alternatives you've considered

• Possibly need to do another full pass through the graph / topological sort in order to hash
• Split up scheduler so that the graph generation and execution occur in separate steps (so that it can be interrupted if --plan is passed)

What version of Turborepo are you using?

1.0.9

Describe the Bug

Our monorepo contains a few circular dependencies. We are actively working to remove them, but have some more work to do there.

When running for example yarn turbo run build with config "dependsOn": ["^build"], turborepo will just get stuck after printing • Running lint in 89 packages. I assume it's going into an endless loop as CPU usage goes up significantly.

Expected Behavior

It would be nice if turbo threw a warning and exited gracefully on this. Preferably including a description of the dependency circle (can sometimes be several packages long).

To Reproduce

• Init a new repo with turbo
• Point two packages at each other in respective package.json
• Make sure "build": { "dependsOn": ["^build"] } is set in the pipeline config
• run yarn turbo run build

Describe the feature you'd like to request

Hi, thank you for the great lib! But I wonder how about this?

turbo.config.js or turbo.config.ts

module.export = {
  baseBranch: 'origin/main',
  pipeline: {
    build: {
      dependsOn: ['^build'],
      outputs: ['.next/**'],
    },
    test: {
      dependsOn: ['^build'],
      outputs: [],
    },
    lint: {
      outputs: [],
    },
    dev: {
      cache: false,
    },
  },
};

Describe the solution you'd like

I don't know GO but in JS, we have one package to load the config file is joycon

Describe alternatives you've considered

I think this is a very useful feature, it can reduce a lot of clutter inside the package.json scripts field!

What version of Turborepo are you using?

1.0.4

Describe the Bug

I'm trying out turborepo in my existing monorepo that uses pnpm workspaces, and when I define a specific packages task, I get the following error:

~/development/raulmelo-studio(test-turbo-repo*) » npx turbo run build --scope=website
• Packages in scope: website
• Running build in 1 packages
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13fa6c8]

goroutine 114 [running]:
turbo/internal/run.(*RunCommand).Run.func3({0xc0000a9880, 0xa})
        /Users/jared/dev/vercel/turbo/cli/internal/run/run.go:375 +0x188
turbo/internal/core.(*scheduler).Execute.func1({0x1443e40, 0xc0006b0cd0})
        /Users/jared/dev/vercel/turbo/cli/internal/core/scheduler.go:107 +0x1bd
github.com/pyr-sh/dag.(*Walker).walkVertex(0xc00049fe60, {0x1443e40, 0xc0006b0cd0}, 0xc00068a300)
        /Users/jared/go/pkg/mod/github.com/pyr-sh/[email protected]/walk.go:377 +0x2ff
created by github.com/pyr-sh/dag.(*Walker).Update
        /Users/jared/go/pkg/mod/github.com/pyr-sh/[email protected]/walk.go:300 +0xf85

Config

I'm not sure if my config is correct though:

{
"turbo": {
    "baseBranch": "origin/main",
    "pipeline": {
      "lint": {},
      "build": {
        "outputs": [
          "dist/**",
          ".next",
          "functions/**",
          "build/**"
        ]
      },
      "test": {
        "outputs": [
          "coverage/**"
        ]
      },
      "website#build": {
        "dependsOn": [
          "core#build",
          "mdx-prism-2#build"
        ]
      }
    }
  }
}

What I want to accomplish

Since my website rely on packages/core and packages/mdx-prism-2, I want to test/build them first and only then build the website.

Expected Behavior

Running the pipeline or at least getting a handled error message.

To Reproduce

The PR I'm trying this is the following: raulfdm/raulmelo-studio#1141

If this is not only a matter of configure stuff, I can try to recreate a smaller version of my repository. Even though it's open source, building rely on .env files.

What version of Turborepo are you using?

1.0.6

Describe the Bug

Expected Behavior

Don't expected turbor need so much cpu

To Reproduce

npx create-turbo@latest
code my-turborepo
cd my-turborepo/
npm run build
npm run dev

node -v
v16.13.0
npm -v
8.1.4
npx turbo -v
1.0.6

neofetch

                    'c.          
                 ,xNMM.          ---------------------------
               .OMMMMo           OS: macOS Big Sur 10.16 x86_64
               OMMM0,            Host: MacBookPro15,1
     .;loddo:' loolloddol;.      Kernel: 21.1.0
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 13 days, 7 hours
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 449 (brew)
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: bash 5.0.17
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 1680x1050@2x, 1920x1080@2x, 1920x1080@2x
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Dark)
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: iTerm2
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   Terminal Font: Monaco 12
    kMMMMMMMMMMMMMMMMMMMMMMd     CPU: Intel i7-8750H (12) @ 2.20GHz
     ;KMMMMMMMWXXWMMMMMMMk.      GPU: Intel UHD Graphics 630, Radeon Pro 555X
       .cooc,.    .,coo:.        Memory: 18256MiB / 32768MiB

Describe the feature you'd like to request

Scenario:
Uninstall yarn completely from the system, and run

npx create-turbo@latest yourapp

It will fail at the second step where it should install the packages via yarn. Because yarn isn't there.

And it gives an unhelpful error:

Installing dependencies...
  Aborting installation.
    yarn install has failed.

Describe the solution you'd like

Instead of giving that error, there can be 3 approaches:

1. Tell the user exactly that yarn isn't found on their system, so either set up the project using npm. Just make it like: Press Y to setup with npm instead, or they can quit and restart with npm.
2. the Second approach would be to say: Command yarn not found. Press 1 to install it, or press 2 to set up with npm instead.
3. Third way would be to simply install yarn automatically. Just put a message saying Installing yarn...

Describe alternatives you've considered

The alternative is to understand why yarn install would fail, which could be because of many reasons I guess. Then figure out that you don't have yarn installed, so install it first, then go back to the Turborepo setup.

Describe the feature you'd like to request

I would like to be able to use this tool with yarn berry as my package manager. On the docs it says only yarn v1 is supported right now.

Describe the solution you'd like

Support for yarn berry.

Describe alternatives you've considered

Using another package manager.

Problem

User's are specifying workspaces declarations with double star glob directives which aren't support natively in Go. We need to use the other doublestar package and recursively search here, while also ignoring correct modules.

Solution

Copy PNPM's globbing from findPackages https://github.com/pnpm/pnpm/blob/917b95c01fd4e6b347dd6159506756693dc051ec/packages/find-packages/src/index.ts#L7

Customer impact: Lattice.com

What version of Turborepo are you using?

1.0.7

Describe the Bug

context: this repo

On my (windows) pc, all turbo commands work fine, but when i deploy it to vercel, i get the following error:

Running "turbo run build test lint deploy database"
20:15:34.159 | unmarshal
20:15:34.160 | ERROR  yarn.lock: yaml: line 6: mapping values are not allowed in this context
20:15:34.165 | Error: Command "turbo run build test lint deploy database" exited with 1

where line 6 is this

i assumed this isnt a problem with vercel and something weird going on with the windows to linux differences in yarns lockfile not being reflected in turborepos unmarshalling process

this happens with both v1 and berry lockfiles (slight difference in line number, v2 will fail on the version line under _metadata but follows a similar format to v1, i use v1 here because the docs say v1 is the only supported version and the error is also present there)

Expected Behavior

Turborepo should unmarshall the yarn lock fine and start building

To Reproduce

1. create a repo that has the scripts database, build, test, lint, deploy, dev (not sure if all of these are necessary)
2. deploy in production to vercel running all of these (obviously minus dev)
3. wait for yarn to install
4. see the error above

What version of Turborepo are you using?

1.0.6

Describe the Bug

For some reason Vercel is not detecting the .vercel_build_output content and generating the serverless functions/routes/static files accordingly.

I've set up 2 projects on Vercel using the same repository, one is building the frontend app with svelte-kit and the other one with turborepo. Check the screenshots:

Expected Behavior

To get Vercel detecting the build generated by turbo.

To Reproduce

Without turbo	With turbo
As you can see, vercel is detecting the .vercel_build_output content	The adapter is generating the folder but not detecting the content afterwards

Without turbo	With turbo
Website running fine

{
    "private": true,
    "name": "test",
    "workspaces": [
        "apps/*"
    ],
    "scripts": {
        "frontend:prod": "yarn workspace frontend build",
        "backend:prod": "yarn workspace backend build && yarn workspace backend start:prod",
        "bootstrap": "rimraf node_modules && yarn && yarn start"
    },
    "devDependencies": {
        "rimraf": "^3.0.2",
        "turbo": "^1.0.6"
    },
    "turbo": {
        "baseBranch": "origin/main",
        "pipeline": {
            "build": {
                "dependsOn": ["^build"],
                "outputs": [".vercel_build_output/**", ".svelte-kit/**"],
                "cache": false
            },
            "test": {
                "dependsOn": ["^build"],
                "outputs": []
            },
            "lint": {
                "outputs": []
            },
            "dev": {
                "cache": false
            },
            "frontend#deploy": {
                "dependsOn": ["frontend#build"]
            }
        }
    }   
}

Thank you!

What version of Turbrepo are you using?

Latest via npx

Describe the Bug

The template used by the turbo CLI does not respect the NPM choice when using npx create-turbo@latest. The commands in the package.json are yarn commands. This would work if you had Yarn installed but is unusable if you do not use Yarn. More so, if you choose NPM as your package manager, this file should respect that and also use NPM.

Here is a screenshot of the console and the package.json file it generated:

Expected Behavior

The package.json file should be using whatever package manager you choose during the prompts from the CLI.

To Reproduce

1. Create a new repo via npx create-turbo@latest
2. Select NPM as the package manager option
3. Wait for the project to be created and follow the prompts for development
4. You should see an error stating sh: yarn: command not found if you do not have yarn installed.

What version of Turborepo are you using?

1.0.6

Describe the Bug

The docs describe the --api option of the 'run' command, but the CLI errors with 'unknown flag'.

Expected Behavior

Expected behaviour is unknown, this is poorly documented and I was trying things out trying to make Turborepo run on a GH action.

To Reproduce

yarn turbo run build --api="any-value-here" on any turbo starter.

Describe the feature you'd like to request

Support for Yarn v2, at least in node_modules linker mode.

Describe the solution you'd like

Support yarn v2 like yarn v2 is supported

Describe alternatives you've considered

Switching to other package manager, but this can be costly, and Yarn v2 is actually the best in my opinion

Discussed in #172

npx create-turbo@latest

>>> TURBOREPO

>>> Welcome to Turborepo! Let's get you set up with a new codebase.

? Where would you like to create your turborepo? ./my-turborepo
? Which package manager do you want to use?
  Yarn
  Npm

## Setup

This repository is used in the `npx create-turbo@latest` command, and selected 
when choosing which package manager you wish to use with your monorepo (PNPM).

We nixed this in a rush for launch day but need to add it back. PNPM is fully supported just need to enable it. The wrinkle is that we need to add some code to loop through all of the package.json dependencies and devDependencies in all of the packages and replace "" with `"workspace:"

What version of Turborepo are you using?

1.0.6

Describe the Bug

I may be missing something here, but followed the getting started on website. I already had a yarn workspaces repo setup with the /apps/* and /packages/* workspaces. So continued on with setting up the pipelines.

Pipeline:

"turbo": {
    "baseBranch": "origin/main",
    "pipeline": {
      "build": {
        "dependsOn": [
          "^build" // prisma package is using dataproxy setup, so I have to make sure the correct bindings are created using the proxy engine and migrate the database.
        ]
      },
      "lint": {},
      "dev": {
        "dependsOn": [
          "^dev" // Since one of my packages is prisma, when I start dev I want to generate latest prisma typings and push the latest db schema.
        ],
        "cache": false
      }
    }
  }

In vercel I am using /apps/platform for the directory to be deployed and for custom build script I'm using

"scripts": {
   "vercel-deploy": "turbo run build",
}

Everything locally when I run yarn dev from root directory works great, I see cache miss and packages/prisma dev command is ran prior to apps/platform's dev command. Got it all committed and pushed up to main to kick of vercel deployment and run into the following. But if I go into /apps/platform and run the deploy command I get the following error

platform git:(main) ✗ yarn run vercel-deploy
yarn run v1.22.5
$ turbo run build
readfile
 ERROR  yarn.lock: yarn.lock: open yarn.lock: no such file or directory
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Similar error on Vercel deployment

[4/4] Building fresh packages...
--
13:36:24.790 | Done in 30.68s.
13:36:24.811 | Detected Next.js version: 12.0.4
13:36:25.003 | Running "yarn run vercel-deploy"
13:36:25.278 | yarn run v1.22.17
13:36:25.305 | $ turbo run build
13:36:25.319 | readfile
13:36:25.319 | ERROR  yarn.lock: yarn.lock: open yarn.lock: no such file or directory
13:36:25.332 | error Command failed with exit code 1.
13:36:25.333 | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
13:36:25.344 | Error: Command "yarn run vercel-deploy" exited with 1

Expected Behavior

I'm actually not quite sure. I'm not extremely experienced with monorepos since they've typically already been handled on the job by tooling teams. It appears there's only 1 yarn.lock file at the root of monorepo. When I delete that and run yarn install it's recreated. But if I yarn install inside any of the packages/* or apps/* no yarn.lock is generated. In Vercel I also have the Include source files outside of the Root Directory in the Build Step. checkbox checked (not sure if that is causing anything)

To Reproduce

Simply push main to origin and let Vercel run the custom build script turbo run build from within a monorepo directory.

Describe the feature you'd like to request

Actually use the pnpm template in npx create-turbo

Describe the solution you'd like

Need to be mindful that PNPM uses workspace:* instead of * for local dependencies. Would need to scan and replace accordingly

Describe alternatives you've considered

• Since PNPM store is getting merged into NPM, PNPM's future remains unclear
• Wait to do this until we parse the pnpm lockfile

Describe the feature you'd like to request

• cd app && turbo dev should build whatever is necessary

Describe the solution you'd like

• We may need to have a way to mark the "root" folder
• This also sets us up for esy-like environment variables and install commands, which we likely should be doing anyway.

Describe alternatives you've considered

• Running everything from the root is painful. Turbo should fix this.

Describe the feature you'd like to request

Add pass through commands like yarn

Describe the solution you'd like

Possibly need to move or fork mitchell/cli (the CLI abstraction library we use)

Describe alternatives you've considered

We might be able to get away with a few special commands like dev, test, and build, but that's 🗑️ imho

What version of Turborepo are you using?

1.0.9

Describe the Bug

Error when running npm install turbo -D.

npm ERR! path C:\Users\<username>\work\<project-name>\node_modules\zlib
npm ERR! command failed
npm ERR! command C:\WINDOWS\system32\cmd.exe /d /s /c node-waf clean || true; node-waf configure build
npm ERR! 'node-waf' is not recognized as an internal or external command,
npm ERR! operable program or batch file.
npm ERR! 'true' is not recognized as an internal or external command,
npm ERR! operable program or batch file.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\<username>\AppData\Local\npm-cache\_logs\2021-12-14T17_10_16_275Z-debug.log

I can reproduce this by just trying to install [email protected] directly via npm install [email protected].

zlib is now included in newer versions of Nodejs, but im guessing you are using it because of browserify?

Expected Behavior

No error.

To Reproduce

On windows (also seems to be the case using wsl) using [email protected] and [email protected] try to install [email protected].

From Lattice: Apologies if this has been asked a bunch of times (I’ve looked). Every time I run turbo I get 0 cached, 0 total. I’ve tried re-installing node, rim raffing node_modules etc to no avail. Other folks at my org have had this problem and others don’t.

Describe the feature you'd like to request

Output of steps are intermingled and can be a little hard to read

https://twitter.com/yangshunz/status/1470019087669489665

Describe the solution you'd like

• Add a --grouped flag that will not stream, but buffer and print all logs of a task once in a single group after a task is completed. This should be the default log behavior in non-interactive terminal processes. Our logstreamer abstraction already has an option for this, but need to make sure that prints to stdout/stderr are not intermingled. Ideally, writes should print First In, First Out, so a (new) queue/channel might be needed inside of run_state.go.
• Update documentation

Describe alternatives you've considered

• --buffered flag name

Describe the feature you'd like to request

I would like to release my packages under an npm scope - like @myorg/react and @myorg/lint-rules.

Right now, I can't figure out a way to do that with TurboRepo, because it can't resolve repos whenever I add a scope to the front of a package name.

I'm not sure if this is a feature or a bug request - kind of both, because I feel like this should be a pretty common use case for Turborepo users.

Describe the solution you'd like

I would like to specify the name of the package in its package.json - like @myorg/react - and that should make it available under that name in other parts of the monorepo.

I would prefer if the name of the package didn't have to be parroted to the folder name - so that my file structure would continue to be packages/react :)

Describe alternatives you've considered

I can't think of any other alternatives, other than not scoping our packages (not an option for us).

What version of Turborepo are you using?

1.0.6

Describe the Bug

create-turbo only accepts a sub-folder name, it can't initiate the project in the current folder, .:

Expected Behavior

It would be nice if user could initiate monorepo in the current folder, .

To Reproduce

npx create-turbo@latest

then pick . as the location.

Describe the feature you'd like to request

A starter example component library where each component is published as its own NPM package.

Describe the solution you'd like

• Turborepo
• SWC for compilation and test running (through Jest)
• Package publishing (could be Lerna or something else)
• ESLint
• TypeScript
• A way to view components

Describe alternatives you've considered

Maybe tsup is a better solution here? Open to suggestions.

Storybook doesn't seem like the right choice because it brings in webpack and Babel and ideally this solution avoids those entirely.

What version of Turborepo are you using?

1.0.9

Describe the Bug

../../packages/components/Loading.tsx
Module parse failed: Unexpected token (4:4)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|   // very simple spinner
|   return (
>     <section className="flex h-screen">
|       <img
|         className="m-auto my-auto"

This is the error and the code is here: https://github.com/samrathchadha/web/tree/unstable

Expected Behavior

The code should have run

To Reproduce

Clone the repository and install the dependencies(with pnpm)

Describe the feature you'd like to request

A starter example of basic usage of AWS lambdas + serverless framework.

Describe the solution you'd like

• Turborepo
• Few independent lambdas with serverless files
• Would be nice to use a Prisma in one of the lambdas
• ESLint
• TypeScript

Describe alternatives you've considered

Currently I use NX on my project and I’m not super happy with it.

Describe the feature you'd like to request

Some times the top level lockfile changes without a corresponding change in a package.json. One such example is when you run yarn-deduplicate (or yarn dedupe in v2/v3).

This should ultimately trigger cache invalidations for the workspaces that have had their dependencies changed in the lockfile. This is not the case currently, which can lead to the package upgrades not being deployed until later changes come in. If any dependency upgrade caused a bug this would be really hard to debug since it would be deployed with a different set of changes.

Describe the solution you'd like

Changes in for example yarn.lock should be parsed to determine which workspace packages to invalidate cache for.

Describe alternatives you've considered

Forcing complete cache eviction on every change to yarn.lock

What version of Turbrepo are you using?

1.0.0

Describe the Bug

Window x Yarn v1 deo-opts to full lockfile hashing due to a window bug in the yarn lockfile parsing code in ReadLockfile():

https://github.com/vercel/turborepo/blob/main/cli/internal/fs/lockfile.go#L45

This function's job is to transform Yarn v1 SYML into YAML and then read it into memory. This operation is rather expensive so turbo will cache this transformation in node_modules/.cache/turbo/[:hash]-turbo-lock.yaml. In order to ship v1.0 for launch, we hacked around this bug by adding isWin() throughout the codebase to avoid this. These should be removed when fixing this bug.

Expected Behavior

Lockfile marshalling should be the same across OS / Arch

To Reproduce

• Use turbo on win32 or win64 with yarn and see that its hashes will be different than those on darwin and linux with yarn.
• Or, ... remove isWin() booleans in the codebase, build from source, run on a windows machine.

What version of Turborepo are you using?

1.0.7

Describe the Bug

In a pnpm workspace using the following rules

packages:
  - "packages/**"

turbo sees the packages in node_modules as other workspace packages and attempts to run commands on them.

this can be worked around by explicitly setting the package name in the pnpm-workspace.yaml or by using a single level glob

packages:
  - "packages/*"

Expected Behavior

I would expect turbo to understand the pnpm workspace pattern matching and not include node_modules as packages

To Reproduce

Reproduction: https://github.com/qdozaq/turbo-pnpm-workspace-bug

What version of Turbrepo are you using?

1.0.4

Describe the Bug

Turbo crashes if private field is set to the string "true" in package.json:

 ERROR  error parsing packages/eslint-config/package.json: json: cannot unmarshal string into Go struct field PackageJSON.private of type bool

Expected Behavior

Turbo ignores the field?

To Reproduce

Add "private": "true" to package.json and build the package.

What version of Turborepo are you using?

1.x

Describe the Bug

We should never panic like #161, ever ever.

Expected Behavior

Turbo should gracefully fail with an error message and ideally never panic. We already validate the graph for cycles, but it seems like this may have to do with something in the scheduler.

To Reproduce

Needs more investigation

Describe the feature you'd like to request

Document all remaining hidden, internal flags

Describe the solution you'd like

Add the following to the CLI Reference docs

• --trace
• --heap
• --cpuprofile
• -v, -vv, -vvv

References:

https://github.com/vercel/turborepo/blob/main/cli/cmd/turbo/main.go#L27-L37

https://github.com/vercel/turborepo/blob/main/cli/internal/config/config.go#L126-L137

Describe alternatives you've considered

On might argue that --trace, --heap, and --cpuprofile should only go in Contributing.md (#214). However, given our commitment to observability, it seems like there shouldn't be any undocumented APIs

What version of Turborepo are you using?

1.0.4

Describe the Bug

Dependant projects hit a cache if only a dependency has changed. Changing something to packages/ui should result in a rebuild of the apps.

Expected Behavior

if I change something in packages/ui, I'd expect that the dependants (apps/docs | apps/web) would not hit a cache and rebuild.

To Reproduce

• Run npx create-turbo
• yarn build to build the cache
• Change something in packages/ui/Button.tsx
• Rerun yarn build -> Everything is outputted as already built.

Describe the feature you'd like to request

Have Dockerfile examples.

Describe the solution you'd like

It would be a good idea for the kitchen sink starter or others to add Dockerfile examples on how to do this cleanly.
To build only what needed etc.

Describe alternatives you've considered

There is no alternative?

What version of Turborepo are you using?

1.0.9

Describe the Bug

Changes to the yarn.lock file do not trigger cache invalidations in yarn v2/v3. Even when using classic node_modules mode

Expected Behavior

A package bump that only affects the yarn.lock file should trigger cache invalidations for the workspaces that depend.

To Reproduce

Repo: https://github.com/Jakst/turbo-yarn-v3-repro

Steps:

• Checkout the main branch and run yarn
• Run yarn turbo run build
• Checkout the modified-lockfile branch and run yarn
• Run yarn turbo run build
• Observe that the turbo build caches were not busted by the changes in the lockfile

Describe the feature you'd like to request

It would be great with examples of github actions that both uses remote caching and without

Describe the solution you'd like

Maybe the current kitchen sink example could be extended.

Describe alternatives you've considered

It doesn't need to be in .github folder as an actual action but just document how a yaml could look like that efficiently uses actions/cache@v2 and turborepo's caching.

This also becomes extra interesting to see with docker examples.

Describe the feature you'd like to request

Move turbo configuration into its own file turbo.json

Describe the solution you'd like

• Move config
• Add script to codemod
• Release a minor

Describe alternatives you've considered

• turbo.yaml
• Use HCLv2

Continues #183

Describe the feature you'd like to request

I tried both --help and searching the docs to find how to generate an image of the dependency graph, and couldn't find anything.

Describe the solution you'd like

Docs + command in --help

Describe alternatives you've considered

N/A

Describe the feature you'd like to request

Show original CLI colors in the output.

Describe the solution you'd like

I would like to be able to have a --colors flag when running turbo to enable colors of the CLI output, including the output from the sub packages/apps. turbo would likely set the environment variable FORCE_COLOR=1 before running commands.

Describe alternatives you've considered

Manually setting the monorepo's environment variable to FORCE_COLOR=1. This enables color when packages, like Next.js, use the npm package chalk