Turborepo Release Notes

Changelog

• docs(security): Update Next.js by @anthonyshew in #11208
• docs: Remove flags code by @anthonyshew in #11209
• docs: Cleanup Sentry from gitignore by @anthonyshew in #11210
• docs: Comment out Tinybird by @anthonyshew in #11211
• docs(fix): Sitemap by @anthonyshew in #11207
• docs: Revert "Comment out Tinybird" by @anthonyshew in #11223
• docs: Move search to built-in by @anthonyshew in #11224
• fix(cli): Preserve exit codes in notifyUpdate functions by @pyrytakala in #11153
• examples(dev-deps): bump turbo from 2.6.1 to 2.6.3 in /examples/with-shell-commands by @dependabot [bot] in #11217
• examples(dev-deps): bump the basic group in /examples/basic with 2 updates by @dependabot [bot] in #11218
• examples(dev-deps): bump the with-svelte group in /examples/with-svelte with 3 updates by @dependabot [bot] in #11219
• fix(turbo-utils): Add test for conflicting configs and remove stale TODO by @deepakpathik in #11201
• feat: Yarn 4 catalogs by @anthonyshew in #11115

New Contributors

@deepakpathik made their first contribution in #11201

Full Changelog

v2.6.3...v2.6.4-canary.0

Original source Report a problem

One of Turborepo's most important features is Remote Caching, a distributed caching layer that ensures your developers and CI never do the same work twice.

As of today, Vercel Remote Cache is now a free, zero-configuration option for any Turborepo linked to Vercel, joining the open-source Remote Caches created by the community as free options for speeding up your development.

Linking a repository to Vercel Remote Cache

On Vercel

Commands using turbo on Vercel are automatically configured to use Vercel Remote Cache. Your builds will benefit from Remote Caching with zero-configuration.

On other Continuous Integration providers

Create the TURBO_TOKEN and TURBO_TEAM environment variables to authenticate to Vercel Remote Cache with their respective values. Visit our CI provider documentation to learn how to connect to:

• GitHub Actions
• GitLab CI
• CircleCI
• GitLab CI
• Travis CI
• Any other CI provider

On your local machine

To get started locally, run:

npx turbo login
npx turbo link

More information

To learn more, visit Vercel's changelog announcement or Vercel Remote Cache documentation.

Original source Report a problem

Turborepo 2.6 includes a number of improvements to developer experience for your repository:

• Microfrontends: Develop many applications on one localhost port
• Bun package manager to stable: Granular lockfile analysis and pruning for bun.lock
• Task list search in terminal UI: Use / to focus tasks faster

Upgrade today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Microfrontends

Vertical microfrontends are an architecture where multiple applications are served on one production domain, split into "zones". Each path for the domain is handled by one of the applications.
This strategy gives teams at scale the ability to ship more independently. Release cycles become decoupled, build times can be brought down, and CI pipelines can get more focused, among other benefits.
While this does help production deployments, it can create difficulty for local development since you’ll have to run many applications instead of just one. Each application ends up needing its own development command and port to use.
Today, we’re releasing a microfrontend proxy for local development, so that all of your applications can run on one port, with one command. Add a microfrontends.json file to your parent application and Turborepo will automatically proxy localhost:3024 to the ports for your other applications.
Just run turbo dev. In this configuration, your docs app runs its development server on localhost:3001 and will handle requests for /docs and all nested paths in /docs. The web app runs on localhost:3000 and handles all other requests.
Visit the documentation to learn more.

Integrating with production infrastructure

While Turborepo’s native microfrontend proxy is meant for working locally, we’re deeply integrating with infrastructure providers to help you bring your microfrontends architecture to production.
For example, we’ve designed the Turborepo-native microfrontends proxy to work with Vercel’s microfrontends product, which is also releasing to GA today. In fact, Vercel’s microfrontends feature provided the research for Turborepo-native microfrontends. We explored how to build microfrontends, locally and in production, with some of the largest customers at Vercel, and are now extracting those learnings from closed-source to open-source.
When you install @vercel/microfrontends into your repository, Turborepo will dynamically adjust your local environment to use the proxy provided by the package, deeply integrating with your production infrastructure.
Visit the Vercel microfrontends documentation to learn more.
We look forward to working with more providers to integrate seamless microfrontends across your stack. If you are an infrastructure provider looking to integrate, please reach out.

Bun package manager to stable

Bun is a fast, incrementally adoptable all-in-one JavaScript, TypeScript & JSX toolkit. Today, Bun as a package manager is now stable in Turborepo.
This means that, when you use Bun as your package manager, Turborepo will only miss cache for packages that have changes in their dependencies. If you update a dependency for your web application, your docs application’s tasks will still hit cache.
Since September 2023, Turborepo has had Beta support for Bun’s package manager capabilities. Our first iteration worked with the original bun.lockb lockfile, though it didn’t have granular change detection, so any change to your dependencies would result in cache misses for your whole repository. Since then, Bun’s lockfiles have undergone several changes:

• In December 2024, Bun introduced the text-based bun.lock, with a v0 version. Because this file is text-based, Turborepo could parse it to intelligently cache tasks for your packages based on dependency changes.
• In January 2025, bun.lock's format changed from a v0 to v1, breaking the parser we created for v0. A package manager’s lockfile isn’t part of its public API, and Bun got much faster because of this change, so we were excited to see the improvement. But we didn't know if we were going to need to rewrite a new parser every month...
  After a few months of stability and an inspiring blog post about the new lockfile format by the Bun team, Turborepo now handles the latest v1 lockfile format for Bun.
  We’ve updated our Support Policy and the rest of our documentation to reflect this update. We also want to thank the Bun team for sending robobun to help us with the first draft of the PR.

Task list search in terminal UI

The terminal UI in Turborepo was early to today’s trend of TUI-based experiences that we’re seeing in many AI-based workflows. Turborepo’s terminal UI brings many benefits compared to streamed logs, including improved readability for task logs, easy copy-paste for a specific task, interactive tasks, and more.
But in large repositories, it can be slow to scroll through a large list of tens or hundreds of tasks, one-by-one.
Today, we’re improving on our task search to make it one of the fundamental ways that you interact with a large Turborepo. When using the terminal UI, press / to filter to only the tasks that you’re interested in.
Only the tasks that match your search query will be selected.
Visit the terminal UI documentation to learn more.

Other changes

Acknowledgments and community

Turborepo is the result of the combined work of all of its contributors, including our core team: Anthony and Tom.
Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice. To learn how to get involved, visit the Community page.
We also thank everyone who contributed to this release of Turborepo: @0ri0nexe, @0xmuon, @ahlimanhuseynov, @Alvi24, @andrewjdimola, @ashishkumar901336, @aviramha, @brunoapaulino, @chris-olszewski, @d0lwl0b, @DiegoDev2, @dstewart1911, @emilbjorklund, @eric-hjh, @esauri, @eug-vs, @evsasse, @felipetau, @Franck-Fernandez-pro, @grgsh, @haklee, @hijuliancode, @hugomassing, @JacksonSL, @JamesHenry, @jeonghwan-park, @jferrettiboke, @jihwan1211, @JoeyKamsteeg, @kade-robertson, @kenfdev, @kitfoster, @leopardracer, @mamuso, @mcky, @melroy, @MendyLanda, @mischnic, @mknichel, @mrr11k, @namidapoo, @NathanM2000, @neonerdy, @nivekithan, @ognevny, @oliveirabalsa, @pawbor, @pzion, @Redddy, @richardhuf84, @robbym, @robobun, @safaiyeh, @sahyl, @Satheeshsk369, @schwenkm, @sdavids, @shinjith-dev, @sitek94, @tedw, @tetzng, @vikhyathdevadiga, @xcfio, @yam-codes, and @yamadayutaka

Original source Report a problem

Turborepo 2.5 includes a number of improvements to enhance your repository:

• Sidecar tasks: Use with to ensure persistent tasks always run together
• Flexibility for --continue: Only continue running tasks when dependencies are successful
• turbo.jsonc: Write comments directly in your configuration file
• prune for Bun: You can now use turbo prune in Bun repositories
• $TURBO_ROOT$: Reference the Workspace root in turbo.json
• OpenAPI viewer: Human-readable OpenAPI spec for self-hosted Remote Caches

Upgrade today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Sidecar tasks

In some cases, you want to ensure two long-running tasks are always running at the same time. For example, you may have a web application that makes requests to another application in your monorepo. Running the web application by itself may not be useful, since the backend API application won’t be available to serve its requests.
You may have tried to use dependsOn to create this relationship - but quickly discovered that depending on a long-running task isn’t allowed. A long-running task never exits, so the dependent task would never run. This meant you’d have to carefully craft a --filter to ensure those resources are available—and make sure everyone in the repo knows to use it.
Instead, we’re introducing the with key so you can guarantee that a dependent long-running task always runs with the long-running tasks that it depends on at runtime.
Using this Package Configuration, anytime that the web application’s dev task is started, the api's start task will also run using the package#task microsyntax.
Visit the documentation to learn more.

Improved control for --continue behavior

By default, Turborepo stops running tasks when it encounters a task that has failed. You can alter this behavior using the --continue flag, instructing Turborepo to continue running tasks, even when one or more tasks have failed.
While the --continue flag is useful, there are times when running tasks whose dependencies have failed will only result in more failures. For these situations, we’ve added a new value to the --continue flag in this release: --continue=dependencies-successful.
When using this value, all dependencies for a task must be successful for the dependent task to run.
Learn more in the documentation.
The Turborepo core team would like to thank @jenseng for contributing this feature.

Add comments to your Turborepo configuration files

You can now use JSONC (turbo.jsonc) for your configuration files, allowing you to add useful comments to your configuration.

Pruned monorepos for Bun repositories

turbo prune creates a partial monorepo for a target package, and is especially useful for creating lightweight Docker images from monorepos. This command has been available for pnpm, npm, and Yarn repositories in previous versions of Turborepo.
In this release, turbo prune is now available for Bun v1.2+, which has introduced a text-based lockfile that we can now read and analyze.
To learn more about turbo prune, visit the documentation.
The Turborepo core team would like to thank @camero2734 for contributing this feature.

Reference your workspace root with the $TURBO_ROOT$ microsyntax

In some situations, you’re forced to break out of package boundaries in a monorepo. This could be due to a number of constraints, like tooling that doesn’t conform to modern package manager workspaces or incremental migration workflows that take you out of ideal conditions.
In the past, you’d need to write paths in turbo.json that traverse to the workspace root, since globs are anchored to the root of packages:
While this pattern does work, it can lead to inconsistencies in some cases:

• Some packages may need ../ while others need ../../
• A developer could potentially move a package to a different location so that the path isn’t correct
  Instead, you can now use the $TURBO_ROOT$ microsyntax:
  Now, this file glob is guaranteed to always start at the root of your workspace.
  Visit the documentation to learn more.

OpenAPI specification viewer for self-hosting

Turborepo is proudly open-source with a public specification for its Remote Caching protocol. While Vercel Remote Cache is a free-to-use managed option, the OpenAPI spec allows the community to create implementations for Remote Caching of their own.
We’ve published the Remote Cache spec as JSON to the web for some time, and have recently added a human-friendly version of the spec at https://turborepo.com/docs/openapi.
Visit the Remote Caching documentation to learn more.

Other changes

Acknowledgments and community

Turborepo is the result of the combined work of all of its contributors, including our core team: Anthony, Chris, Dimitri, Nicholas, and Tom.
Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice. To learn how to get involved, visit the Community page.
We also thank everyone who contributed to this release of Turborepo: @beaussan, @bohongu, @camero2734, @cprussin, @dinglindong, @jenseng, @jimmycathy, @kevincatty, @mm-webx, @ognevny, @pi0, @pudongair, @rootdiae, @shinjith-dev, @sicarius97, @ssshashank, @Tigatok, @todaymoon, @Tyoneb, @victorlagerfors, @vinayaksodar, @wmjae, @x-N0, and @xiaobei0715.

Original source Report a problem

Turborepo 2.4 includes a number of improvements to enhance your repository:

• Boundaries Experimental: A first look at Boundaries in Turborepo
• Terminal UI improvements: Persistent preferences and new features
• Watch Mode caching Experimental: Develop faster in Watch Mode
• Circular dependency recommendations: Adopt Turborepo in large repos more easily
• schema.json in node_modules: Versioned configuration validation from within your repository
• ESLint Flat Config support: eslint-config-turbo and eslint-plugin-turbo updated for ESLint v9

Upgrade today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Boundaries Experimental

Turborepo is built on top of package manager Workspaces, leaning on ecosystem conventions as a part of determining your repository's task caching. However, this requires that all developers in the repository know and adhere to those conventions.
We're introducing Boundaries, an experimental feature to catch places in the repository where these best practices aren't being followed. This makes caching safer, and ensures your repository is prepared to use future Turborepo features safely.
Try it today using:

turbo boundaries

This early iteration of Boundaries includes finding two types of monorepo mistakes:

• Importing a file outside of the package's directory
• Importing a package that is not specified in dependencies

Boundaries RFC

We look forward to hearing your feedback on the Boundaries RFC, which includes proposals for these built-in diagnostics as well as custom-built Boundaries.
To learn more, visit the documentation.

Terminal UI improvements

We've continued iterating on the terminal UI, originally released in Turborepo 2.0.

Persistent preferences

In previous versions of Turborepo, you would need to reset the terminal UI to your desired state every time you would run turbo. In Turborepo 2.4, we'll persist several of the UI selections that you've made, including:

• The task that you had previously selected will be pre-selected the next time you run turbo. Give your up and down arrow keys a rest.
• Task list visibility, as described below
• Task selection pinning, as described below
  Together, persisting these preferences creates a more seamless experience across turbo invocations, restoring the UI to the state from the previous run of turbo.

New keybinds

We've added more functionality to the terminal UI to make it easier to work with your tasks and logs.

• h to toggle task list: You're often focused on one of your tasks, so you don't need to see your task list, all the time. Press the h key to show and hide the task list. This feature is a persistent preference, as described above.
• c to copy logs: Once you've highlighted a set of logs with your mouse, press c to copy the logs to your system clipboard.
• j and k to select tasks: You can now use j and k in addition to ↑ and ↓ to cycle through the task list. Vim users rejoice.
• p to pin the selected task: Selecting a task sets a "pin", meaning it will continue to be selected as your tasks change states. You can release the pin (or pin the task you're hovering) by pressing p. This feature is a persistent preference, as described above.
• u and d to scroll logs: You can now press u to scroll your logs up and d to scroll your logs down.
• m to learn more: Pressing m will show a popup listing all of the available keybinds.

Visit the documentation to learn more.

Watch Mode caching Experimental

Watch Mode is a monorepo-aware watcher that re-runs tasks according to your Task Graph. This opens up brand new ways to work in monorepos by leveraging a single, global, dependency-aware watcher, rather than many smaller, less powerful watcher scripts.
In this release, we're adding caching as an experimental feature in Watch Mode. To activate it, use the --experimental-write-cache flag:

turbo watch dev --experimental-write-cache

To learn more about Watch Mode, visit the documentation.

Circular dependency recommendations

Circular dependencies are loops in your package graph that create non-deterministic cycles in Turborepo's Task Graph. However, if there is a loop in your task graph, Turborepo is unable to determine which task comes before which, since they both depend on each other.
While adopting Turborepo in your monorepo, you may find circular dependencies as Turborepo create a more sophisticated, faster Task Graph than your previous task runner. Previously, Turborepo would naively list all of the packages involved in the cycle or cycles that exist in the repository's Package Graph. Now, Turborepo will include the dependency relationships that need to be broken up to get rid of the cycles in your graph.
Compare the before and after of the terminal printouts below:

schema.json in node_modules

A schema.json file provides auto-complete and validation in your editor for JSON files. We have a web-accessible version of the schema.json for turbo.json hosted at https://turborepo.com/schema.json, but some developers prefer to get the file from node_modules to stay synced with the installed version of turbo.
Starting in this release, schema.json is available in node_modules once you've run your package manager's install command:

{
  "$schema": "./node_modules/turbo/schema.json"
}

node_modules location

We recommend installing turbo at the root of your repository, so the path for the schema should point to node_modules at the root of your repository. In Package Configurations, you may need to use a path like ../../node_modules/turbo/schema.json.
Visit the documentation for more information.

ESLint Flat Config support

Turborepo 2.4 introduces support for ESLint v9 in eslint-config-turbo and eslint-plugin-turbo, following the end-of life for ESLint v8 on October 5, 2024.
The configuration and plugin remain backward compatible for those still using ESLint v8 to ensure a smooth transition.
For more information, visit the documentation.

Other changes

• Features (5)
• Fixes (29)
• Documentation (42)

Acknowledgments and community

Turborepo is the result of the combined work of all of its contributors, including our core team: Anthony, Chris, Dimitri, Nicholas, and Tom.
Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice. To learn how to get involved, visit the Community page.
We also thank everyone who contributed to this release of Turborepo: @aaronccasanova, @AlvaroParker, @ankur-arch, @arosequist, @atimmer, @bgw, @bitttttten, @chaficnajjar, @codexshell, @eps1lon, @gianelli99, @glitched-w0rld, @JasonnnW3000, @jbrocksfellas, @jeremy-code, @jonathandsouza, @Juneezee, @kayumuzzaman, @krlvi, @maciej-ka, @ognevny, @olets, @pkerschbaum, @romanofski, @shivam-pawar, @takaebato, @tevem1207, @thebrubaker, @Tofandel, @trivikr, @yamz8, and @zsh77.

Original source Report a problem

Turborepo 2.3 introduces several ergonomics improvements:

• Boundaries RFC: Enforce constraints to maintain developer experience
• Package task shortcuts: Execute tasks with turbo run package#task
• Simplified cache control: Easier management of cache sources using a single flag
  Update today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Boundaries RFC

Monorepos unlock greater iteration speed and incredible flexibility, but also introduce new challenges:

• How do we make sure the public API of a package is respected?
• How do we communicate where code can and cannot be used to all of our developers?
• How can we ensure packages are only used in the right context?
  These are only a few examples of a key question when building in monorepos: How do we communicate and enforce the structural integrity of the Workspace?
  At the time of publishing this post, the Boundaries RFC is only an initial draft. The implementation described below is subject to change. Please see the RFC itself for the most up to date information.
  The Boundaries RFC is our initial proposal for this problem. In our current approach, we want you to be able to incrementally adopt Boundaries in one line of code:
  {
  "boundaries": true
  }
  Additionally, we want to create a tagging system so you can mark domains, concerns, contexts, and other useful metadata with custom Boundaries.
  {
  "extends": ["//"],
  "boundaries": {
  "tags": ["library", "ui", "frontend", "beta"],
  "allowDependencyOn": ["library", "frontend"],
  "denyDependencyFrom": ["backend", "stable"]
  }
  }
  We also plan for you to be able to allowlist existing diagnostics with a flag:
  turbo boundaries --exclude-errors
  This way, you can enforce Boundaries for new code and gradually fix existing issues.
  We're looking forward to hearing your ideas and feedback on the Boundaries RFC.

Package task shortcuts

You can now run tasks using the fully qualified task identifier:
turbo run web#build
This is more convenient than the equivalent command using --filter (turbo run build --filter=web) and allows for more precision if you have multiple tasks that you'd like to target:
turbo run web#build docs#lint
Learn more in the documentation.

Simplified cache control

Previously, the --remote-only and --no-cache flags were used to manage the sources and caching for your output artifacts. However, we've seen how they can cause confusion, and there are gaps in control as far as reading and writing to local and Remote Caches.
To refine this, we've introduced a new --cache flag that brings these flags together - and provides more power.
turbo run build --cache=local:rw,remote:r
Using local and remote, you can control the reading and writing behavior of the turbo invocation. Learn more in the documentation.

Continued improvements for turbo query

In 2.2, we introduced turbo query, a feature built for examining your repository using Turborepo's knowledge of your package and task graphs. We've iterated further on this feature to provide you with even more powerful queries:

• Implemented reverse file tracing to find which files depend on a specific file
• Filters for file tracing to find type-only dependencies
• Package names that you provide are now validated to ensure that they exist

Community

Since releasing Turborepo 2.2, we've seen great adoption and community growth:

• 26.3+ GitHub Stars
• 3.4M+ weekly NPM downloads
• 496 years of compute time saved using Vercel Remote Cache
  Turborepo is the result of the combined work of all of its contributors, including our core team: Anthony, Chris, Nicholas, and Tom.
  Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice.

Original source Report a problem

Turborepo 2.2 brings a new repository query command, along with other improvements, including:

• Repository queries Experimental: Explore your repository like never before with turbo query
• Improved cache safety: Easily diagnose and fix missing environment variable dependencies, and incorrect cache configurations
• Zero-configuration comparisons for affected packages: Automatically target packages with changes in GitHub workflows

Update today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Query your repository Experimental

In Turborepo 2.2, we're introducing turbo query —a new command that allows running GraphQL queries against Turborepo's repository data. Turborepo computes lots of data about your repository in order to execute your tasks with maximum efficiency. This includes your package dependency graph, changed packages, task dependencies, log output from your tasks, and more. This data can be useful for scripting, refactoring, determine what to run in CI, and discovering other insights into your codebase.

To get started, run turbo query to open GraphiQL—a local IDE for writing GraphQL queries that supports interactive schema exploration, documentation, and sending queries.

You can also pass queries directly as a string or file path:

Examples

• Get the name and path for all affected packages that have a test task.
• Get a specific package and its direct dependencies.
• Find all packages with more than 10 immediate dependents.

Turborepo has added APIs for structured data in the past, such as run summaries, dry run, and ls. However, these APIs have some limitations. First, they're centered around a single run, not general repository info. Second, as we added more fields, the output quickly became very large. We needed a way to query repository data in a run-agnostic fashion, and make the returned data more customizable.

We would like to thank @maschwenk, @rafaeltab, and @weyert for their early feedback on this feature.

To learn more, visit the documentation, and leave feedback for this new experimental command on the turbo query RFC.

Improved cache safety

Caching tasks is one of the most powerful features of Turborepo, speeding up builds and other tasks by only re-running what has changed. With Turborepo 2.2, we're releasing some improvements to help configure cache inputs and outputs, and warn you when things don't look quite correct.

Platform environment variables

When deploying your applications, you likely already have environment variables configured in your production environment. Now, for supported platforms, Turborepo will automatically check these environment variables against your turbo.json configuration to ensure that you've correctly accounted for them, and will warn you about any missing environment variables.

Any platform can support this feature by implementing the TURBO_PLATFORM_ENV environment variable in to the build environment.

Vercel is supported today, and we will update documentation as more platforms become available.

Learn more about platform environment variables.

Warnings for empty cache configurations

When running tasks, Turborepo will now warn you if a task is configured to cache an empty directory. This can be a common mistake, and can lead to accidental broken builds. This is enabled by default in 2.2.

Learn more about configuring outputs.

Improvements to eslint-config-turbo

Turborepo automatically adds prefix wildcards to your env key for common frameworks. If you're using one of the supported frameworks, you don't need to specify environment variables that begin with the framework's prefix.

Now in Turborepo 2.2, eslint-config-turbo supports this feature as well, ensuring the warnings from the plugin are accurate and actionable.

Learn more about eslint-config-turbo.

Zero-configuration comparisons with --affected

In Turborepo 2.1, we released the --affected flag which can be used with turbo run and turbo ls to automatically target changed packages. In 2.2, we're taking it a step further by introducing automatic comparisons when running --affected in a GitHub workflow—making common use cases even smarter.

• For workflows running in response to a pull request, the base of the comparison is automatically set to the base of the pull request. This ensures turbo considers any files changed in the pull request when determining the affected packages.
• For workflows running in response to a push, the base of the comparison is automatically set to commit before your latest push.

Learn more about --affected.

Community

Since releasing Turborepo 2.1 we've seen incredible adoption and community growth:

• 26.2k+ GitHub Stars
• 3.2M+ weekly NPM downloads
• 477 years of compute time saved through Remote Caching on Vercel

Turborepo is the result of the combined work of all of its contributors, including our core team.

View the full changelog.

Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice.

Original source Report a problem

Turborepo 2.1 improves integration with your repository, with features like:

• Affected package graph detection: Only run tasks with changes using --affected
• Repository exploration tools: Find packages and tasks faster with turbo ls and turbo run
• Terminal UI improvements: Log selection, task search, resizing, and more
• Expanded configuration options: More flexibility for defaults using turbo.json

Update today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.

Run tasks for changed packages with --affected

Turborepo’s Remote Caching shares a single cache across all of your machines, so you never have to do the same work twice. But, what if you could ignore unchanged packages altogether?
You can now use the --affected flag with turbo run to automatically target packages with changes between the latest commit of your current branch, and the default branch of your repository (usually main or master). turbo will use your Package Graph to ensure tasks are run for packages with direct changes or changes to internal dependencies.

You'll want to use this flag in situations like:

• You're running many tasks across packages in your monorepo, and only want to run those tasks in packages with code changes.
• You’re not using a Remote Cache, but still want to do as little work as possible in CI.
• You are using a Remote Cache, and you’re in a large repository. By minimizing the amount of tasks that will be restored from cache, there will be less data to send across the network, resulting in faster cache restoration.
• You’re already using advanced filtering techniques or turbo-ignore to create the same or similar behavior as --affected. You likely have the opportunity to simplify your scripting using this new flag.

To learn more, visit the documentation.

Repository exploration tools

As a repository grows and changes, it can be difficult to quickly find what you’re looking for. We want to quickly surface your tasks, packages, and their relationships to make understanding your repository faster and easier.

Use turbo run (with no task arguments) to get a list of the available tasks in your repository. This command also works with filters and Automatic Package Scoping.

Use turbo ls to get a list of all the packages in your repository with their locations, or filter to a specific package to see a summary of its internal dependencies and tasks. turbo ls also supports --filter, and --affected, making it easy to gather a list of changed packages.

turbo ls supports an experimental --output flag that can be used to return results in a specific format. For example, --output=json can be used to more easily create inputs for other tools or custom scripts. If you were previously using turbo build --dry=json only to retrieve a list of changed packages, give turbo ls --affected --output=json a try. Visit the docs for more information and leave feedback on output format on the turbo ls RFC.

To learn more, visit the documentation.

Terminal UI Improvements

In Turborepo 2.0, we released a new terminal UI to improve clarity for logs and allow for interactive tasks in local development. We heard your feedback, and prioritized polishing this UI, releasing improvements in patches to 2.0 and in this 2.1 release:

• Highlighting of logs for copying to clipboard (PR)
• Search through task list (PR)
• Cleaner layout resizing when your terminal changes size (PR)
• New icon for cache hits in task list (PR)
• Task status indicators updated when Watch Mode triggers a restart (PR)
• Output logs are respected after the terminal UI exits (PR)

Building a great terminal UI experience has unique challenges, and we’re continuing to iterate on this experience. We appreciate your continued feedback as we keep up our work on creating great UI for monorepos.

Expanded configuration options

In this release, we’re adding more keys to turbo.json to give you more flexibility for your repository’s defaults. The following keys are new in this release:

{
  "envMode": "loose",
  "daemon": false,
  "cacheDir": "./my-custom-directory/"
}

You may have been using the flag equivalents for these configurations on many or all of your turbo invocations, littering your codebase with commands like:
turbo run build --env-mode=loose --no-daemon --cache-dir=./my-custom-directory
These can now be simplified with a centralized configuration in turbo.json using Turborepo’s existing configuration model:

• turbo.json sets the defaults for your repository.
• System environment variables customize behavior in a specific environment.
• Flags customize behavior for specific invocations of turbo.

To learn more about available options and configurations, visit the documentation.

Other improvements

• We’d like to especially thank Shaharking for their contribution in #9023 to make the colors for task names in streamed UIs deterministic, closing #2564. This makes it easier to compare tasks across turbo run invocations.

View the full changelog at vercel/turborepo.

Community

Since releasing Turborepo 2.0 we've seen incredible adoption and community growth:

• 25.9k+ GitHub Stars
• 2.9M+ weekly NPM downloads
• 428 years of compute time saved through Remote Caching on Vercel

Turborepo is the result of the combined work of all of its contributors, including our core team.
Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice.

Original source Report a problem

Progress with Turbopack, current priorities, and a move to a different repository.

Turbopack is a new JavaScript/TypeScript bundler we’ve been cooking at Vercel. Building on 10+ years of learnings from webpack, we want to build a bundler that can be used with many frameworks.

We’re moving the Turbopack codebase into the Next.js repository—and wanted to share an update on our progress with Turbopack so far, as well as where we’re headed.

Project updates

• You can try out Turbopack with Next.js today. If you're using the supported webpack loaders or have no custom webpack configuration, you can run the Next.js development server with next dev --turbo to speed up your development workflow. To get all the latest fixes, we recommend using it with the Next.js Canary channel. We'll have an updated Next.js 15.0 Release Candidate soon with the latest version of Turbopack.

• Turbopack is passing 100% of the Next.js development test suite and all Next.js examples work with Turbopack. We’re rapidly working through our backlog of user-reported issues not surfaced by existing tests.

• We’ve verified the top 300 npm packages used in Next.js applications can compile with Turbopack.

• We use Turbopack every day to develop vercel.com. It’s been much faster than webpack for our team, both for initial server startup as well as code updates.

We have also begun work on production builds. To follow along with this, visit https://areweturboyet.com/build.

Moving homes

In the coming weeks, we will move the source code for the Turbopack bundler out of the vercel/turbo repository and into the vercel/next.js monorepo. We believe that co-locating the source code will enable us to iterate faster and get Turbopack to a stable release with support for production builds sooner, both in Next.js and as a standalone bundler for the rest of the JavaScript ecosystem.

We have not begun moving the code yet, as we felt it was important to inform the community of these changes before they are made.

There will be no change to the Turborepo build system project, which will remain where it is in the vercel/turbo repository. There will also be no change to how you interact with Turbopack, Turborepo, or Next.js.

Why are we moving?

Initially, we believed that putting Turbopack (the bundler) and Turborepo (the build system) into the same repository would assist with sharing code between both projects, especially as Turborepo has recently migrated from Go to Rust.

However, as Next.js is Turbopack’s primary user during this phase of development, we found that internal changes in Turbopack affect Next.js more often than Turborepo. Since Next.js is in a separate repository, we often have to spend time synchronizing dependencies or coordinating changes between these two repositories.

An example of how we must cross repository boundaries to make breaking changes today.

Over time, we developed hacks to work around some of these problems. We created tools to check out both repositories, combine our Cargo.toml files (Rust’s equivalent of package.json) into a unified workspace, and merge our Cargo lockfiles. Unfortunately, these hacks are fragile partial solutions, and the bespoke nature of our tooling made it harder for us to onboard new engineers. In some cases, we’ve even had to upstream changes to IDE plugins to fix issues with our workflow.

Moving forward, we will utilize a top-level Cargo.toml configuration with Cargo workspaces, similar to how one might organize packages in a JavaScript workspace.

When creating and maintaining release branches in Next.js, we’ll be able to backport both Next.js and Turbopack hotfixes into the same Git branch, without needing to maintain a separate branch in the vercel/turbo repo with it’s own release tags.

Does this mean Turbopack will only support Next.js?

No. The core of Turbopack remains framework-agnostic. We still want to support other frameworks and standalone bundler usage, but our immediate focus is on Next.js to start. Ensuring this clear focus helps Turbopack users in a few ways:

• Helping as many developers as soon as possible. We're seeing increasingly large applications built with Next.js over time, and we want to make sure Turbopack helps users at scale. By using Next.js as a boundary to our current development scope, we have better clarity on how to help a cohort of millions of developers as soon as we can.

• Crafting better APIs for Turbopack. With Turbopack and Next.js in the same monorepo, it will be easier for us to make changes and iterate on our APIs in one pull request, validated against the Next.js test suite in CI.

In time, we will reach a stable state for the general-purpose bundler to be used outside of Next.js. At that point, we will move Turbopack to its own separate repository.

How will this migration be performed?

We intend to use git-subtree in combination with git-filter-branch to copy over all of the Turbopack source code, along with its commit history. In preparation for the change, we’ll need to make changes to our CI configuration and build scripts to ensure all of our testing infrastructure moves with our source code.

Looking forward: Priorities for Turbopack

We’re close to marking Turbopack as stable for development when used with Next.js. When this happens, Turbopack will initially remain opt-in for existing Next.js projects and we will align any breaking changes to the default bundler with a future major release of Next.js, with continued webpack support after the defaults are changed.

Current priorities for the team are:

• Solving remaining user-reported bugs and edge-case performance regressions. If you run into issues while using Turbopack, please let us know! We are paying close attention to reported issues, and we can only get to Turbopack 1.0 with your help.

• Reducing memory consumption. Turbopack uses fine-grained function-level caching inspired by other tools like the Rust compiler and rust-analyzer. We’re extending our caching framework to improve cache eviction and to avoid caching intermediate results that are unlikely to be reused.

• Finishing the persistent on-disk cache. Turbopack’s caching framework supports serialization and deserialization, and we’ve prototyped some on-disk representations for our computation graph, but we need to finish this work and turn it on by default. Surprisingly, even without an on-disk cache, we find that in nearly all cases Turbopack cold starts are still faster than webpack with a warm cache.

• Finishing support for production builds. We’re working on bringing the Next.js test suite for production builds to 100% passing with Turbopack. Supporting production builds requires implementing optimizations that are relevant for optimized production builds, such as tree shaking. Tobias Koppers recently gave a talk about the challenges of implementing production builds at JSNation 2024.

We look forward to continuing our work on Turbopack to help improve the development velocity of your web applications.

Original source Report a problem

Turborepo 2.0 improves the developer experience

Turborepo 2.0 improves the developer experience of JavaScript and TypeScript repositories, with features including:

• New terminal UI: Interactive tasks and clearer logs
• Watch Mode: Dependency-aware task watcher for any tooling in your repository
• All-new documentation: Core monorepo concepts, refreshed API reference, and ecosystem tooling guides
• Licensing and maintenance updates: Upgraded to MIT license and added Long Term Support policy

Update today by running npx @turbo/codemod migrate or get started with npx create-turbo@latest.
Visit the upgrading guide for update instructions. Breaking changes are listed below.

New terminal UI

Link to section

In Turborepo 1.13, we released an experimental interface to learn how a refined terminal UI could improve development velocity. Through the RFC process, we were able to work with the community on designing a revamped local experience, driven by your feedback. Thank you to those who participated.
Today, we’re releasing the new UI as stable, along with the highly requested features that it enables.

Improved clarity for logs

Link to section

Before 2.0, turbo would output logs as a stream while you were working on your libraries and applications. This could be overwhelming at times, since the intermixed logs made it difficult to understand what was going on with a specific task.
In this iteration of the UI, you can select individual tasks using your arrow keys to inspect their logs one at a time, making it easier to read the logs that you want to focus on.
Good to know: The streamed logs view from prior versions of turbo is still available for local development by using the --log-order flag. Note that tasks will not be interactive with this option and some tools may clear the terminal unexpectedly.

Interactive tasks

Link to section

Many tools allow for interacting with a script for important functionality. But, in previous versions of Turborepo, your scripts were trapped inside turbo so you couldn’t interact with them.
You can now enter the shell of individual tasks and pass inputs to your scripts via stdin by typing directly into the interface. This enables workflows like running specific test suites with Jest or Vitest, handling database migrations with Drizzle or Prisma, and much more.
To mark a task as interactive, add "persistent": true to its definition:
{
"tasks": {
"dev": {
"cache": false,
"persistent": true
}
}
}
With the task selected in the UI, use the Enter key to enter the task’s shell and CTRL+Z to exit.
To learn more about persistent and interactive tasks, visit the documentation.

Watch Mode

Link to section

Turborepo's ability to run many tasks at once gives you tighter feedback loops that help you ship faster. To get the most out of Turborepo's parallelization when working locally, your tools need to have a "watcher" feature available to re-run your code whenever you make changes. Unfortunately, many common tools don't, and most tools aren't monorepo-aware, leading to problems with scripts that depend on other scripts in your repository.
Today, we're releasing Watch Mode to bring this functionality to all your tooling:
Using turbo watch, Turborepo will re-run tasks whenever you make changes to your source code. Tasks will be run using your dependency graph and configuration from turbo.json, just like turbo run.
Learn more about Watch Mode in the documentation.

All-new documentation

Link to section

With this release, we’re also publishing revitalized documentation that builds on the strengths of prior versions. We’ve heard your feedback, so the docs now include:

• More monorepo fundamentals and how-tos
• Guides on integrating your favorite tools with Turborepo
• Clearer information architecture and improved search
  Visit the Turborepo documentation.

Breaking changes

Link to section

Visit the upgrading guide for instructions on how to update to 2.0.

Configuration

Link to section

Breaking changes for turbo.json can be updated using npx @turbo/codemod migrate.

• Ignore turbo field in package.json (PR)
• Turborepo’s default disk cache location moved to .turbo/cache from node_modules/.cache (PR)
• pipeline key in turbo.json renamed to tasks (PR)
• File globs for directories in inputs/outputs include the directory's contents (e.g. dist and dist/ equal dist/**) (PR)
• outputMode key renamed to outputLogs for clarity and to match the --output-logs flag (PR)
  • This change will be reflected in Run Summaries in resolvedTaskConfig
• Error on environment variable syntax in dependsOn and globalDependencies (deprecated since 1.4) (PR)
• globalDotEnv and dotEnv removed in favor of including .env files in inputs (PR)
• --ignore removed in favor of --filter and graph correctness changes below (PR)

Correctness

• Strict Mode for environment variables is now the default, moving from Loose Mode (PR)
• Workspace root directory is now an implicit dependency of all packages (PR)
• Removed --scope flag (deprecated since 1.2) (PR)
• Packages must have a name in package.json (PR)
• packageManager field in root package.json is now required (PR)
• engines field in root package.json is now used in hashing (PR)
• --filter no longer infers namespaces for package names (PR)
• --filter now errors when no package names or directories are matched (PR)
• --only restricts task dependencies instead of only package dependencies (PR)

Other

Link to section

• Minimum package manager version support for npm and pnpm updated to 8 (Source)
• Remove package manager argument from create-turbo, replaced by option (PR)

Community

Link to section

We're excited to see the continued growth and adoption of Turborepo:

• 25.2k+ GitHub Stars
• 2.3m+ weekly NPM downloads
• 347 years of compute time saved using Vercel Remote Cache
  Turborepo is the result of the combined work of all of its contributors, including our core team: Anthony, Chris, Greg, Mehul, Mitch, Nicholas, and Tom.
  Thank you for your continued support, feedback, and collaboration to make Turborepo your build tool of choice. If you haven't already, join the conversation on GitHub and Discord.

Original source Report a problem