From 30232223986c46c68b3587b28a46549f7bd5e743 Mon Sep 17 00:00:00 2001 From: 简律纯 Date: Fri, 28 Apr 2023 13:25:43 +0800 Subject: --- docs/content/team.ts | 72 +----- docs/pages/blog/_meta.json | 19 +- docs/pages/blog/hydroroll-0-1-3.mdx | 17 ++ docs/pages/blog/joining-vercel.mdx | 23 -- docs/pages/blog/saml-sso-now-available.mdx | 52 ---- docs/pages/blog/turbo-0-4-0.mdx | 211 ---------------- docs/pages/blog/turbo-1-1-0.mdx | 141 ----------- docs/pages/blog/turbo-1-2-0.mdx | 132 ---------- docs/pages/blog/turbo-1-3-0.mdx | 202 --------------- docs/pages/blog/turbo-1-4-0.mdx | 139 ----------- docs/pages/blog/turbo-1-5-0.mdx | 142 ----------- docs/pages/blog/turbo-1-6-0.mdx | 223 ----------------- docs/pages/blog/turbo-1-7-0.mdx | 150 ----------- docs/pages/blog/turbo-1-8-0.mdx | 119 --------- docs/pages/blog/turbo-1-9-0.mdx | 121 --------- docs/pages/blog/turbopack-benchmarks.mdx | 275 --------------------- ...ight-not-need-typescript-project-references.mdx | 95 ------- docs/public/background_or_logo.png | Bin 0 -> 26941 bytes docs/public/images/people/HsiangNianian.jpg | Bin 0 -> 25916 bytes docs/public/images/people/alexanderlyon.jpg | Bin 29857 -> 0 bytes docs/public/images/people/alexkirsz.jpg | Bin 7675 -> 0 bytes docs/public/images/people/anthonyshew.png | Bin 120634 -> 0 bytes docs/public/images/people/becca__z.jpeg | Bin 21199 -> 0 bytes docs/public/images/people/chrisolszewski.jpg | Bin 107504 -> 0 bytes docs/public/images/people/empty.jpeg | Bin 5850 -> 0 bytes docs/public/images/people/gaspargarcia.jpeg | Bin 11515 -> 0 bytes docs/public/images/people/gregsoltis.jpeg | Bin 36241 -> 0 bytes docs/public/images/people/jaredpalmer.jpeg | Bin 86398 -> 0 bytes docs/public/images/people/mattpocock.jpeg | Bin 24092 -> 0 bytes docs/public/images/people/mehulkar.jpeg | Bin 43522 -> 0 bytes docs/public/images/people/nathanhammond.png | Bin 789645 -> 0 bytes docs/public/images/people/nicholasyang.png | Bin 171566 -> 0 bytes docs/public/images/people/tobiaskoppers-avatar.jpg | Bin 64618 -> 0 bytes docs/public/images/people/tobiaskoppers.jpg | Bin 9612 -> 0 bytes docs/public/images/people/tomknickman.jpeg | Bin 25817 -> 0 bytes 35 files changed, 24 insertions(+), 2109 deletions(-) create mode 100644 docs/pages/blog/hydroroll-0-1-3.mdx delete mode 100644 docs/pages/blog/joining-vercel.mdx delete mode 100644 docs/pages/blog/saml-sso-now-available.mdx delete mode 100644 docs/pages/blog/turbo-0-4-0.mdx delete mode 100644 docs/pages/blog/turbo-1-1-0.mdx delete mode 100644 docs/pages/blog/turbo-1-2-0.mdx delete mode 100644 docs/pages/blog/turbo-1-3-0.mdx delete mode 100644 docs/pages/blog/turbo-1-4-0.mdx delete mode 100644 docs/pages/blog/turbo-1-5-0.mdx delete mode 100644 docs/pages/blog/turbo-1-6-0.mdx delete mode 100644 docs/pages/blog/turbo-1-7-0.mdx delete mode 100644 docs/pages/blog/turbo-1-8-0.mdx delete mode 100644 docs/pages/blog/turbo-1-9-0.mdx delete mode 100644 docs/pages/blog/turbopack-benchmarks.mdx delete mode 100644 docs/pages/blog/you-might-not-need-typescript-project-references.mdx create mode 100644 docs/public/background_or_logo.png create mode 100644 docs/public/images/people/HsiangNianian.jpg delete mode 100644 docs/public/images/people/alexanderlyon.jpg delete mode 100644 docs/public/images/people/alexkirsz.jpg delete mode 100644 docs/public/images/people/anthonyshew.png delete mode 100644 docs/public/images/people/becca__z.jpeg delete mode 100644 docs/public/images/people/chrisolszewski.jpg delete mode 100644 docs/public/images/people/empty.jpeg delete mode 100644 docs/public/images/people/gaspargarcia.jpeg delete mode 100644 docs/public/images/people/gregsoltis.jpeg delete mode 100644 docs/public/images/people/jaredpalmer.jpeg delete mode 100644 docs/public/images/people/mattpocock.jpeg delete mode 100644 docs/public/images/people/mehulkar.jpeg delete mode 100644 docs/public/images/people/nathanhammond.png delete mode 100644 docs/public/images/people/nicholasyang.png delete mode 100644 docs/public/images/people/tobiaskoppers-avatar.jpg delete mode 100644 docs/public/images/people/tobiaskoppers.jpg delete mode 100644 docs/public/images/people/tomknickman.jpeg (limited to 'docs') diff --git a/docs/content/team.ts b/docs/content/team.ts index 0130589..7f4b27e 100644 --- a/docs/content/team.ts +++ b/docs/content/team.ts @@ -1,72 +1,8 @@ const TURBO_TEAM: Record = { - jaredpalmer: { - name: "Jared Palmer", - twitterUsername: "jaredpalmer", - picture: "/images/people/jaredpalmer.jpeg", - }, - gaspargarcia: { - name: "Gaspar Garcia", - twitterUsername: "gaspargarcia_", - picture: "/images/people/gaspargarcia.jpeg", - }, - becca__z: { - name: "Becca Z.", - twitterUsername: "becca__z", - picture: "/images/people/becca__z.jpeg", - }, - gregsoltis: { - name: "Greg Soltis", - twitterUsername: "gsoltis", - picture: "/images/people/gregsoltis.jpeg", - }, - nathanhammond: { - name: "Nathan Hammond", - twitterUsername: "nathanhammond", - picture: "/images/people/nathanhammond.png", - }, - tomknickman: { - name: "Tom Knickman", - twitterUsername: "tknickman", - picture: "/images/people/tomknickman.jpeg", - }, - mehulkar: { - name: "Mehul Kar", - twitterUsername: "mehulkar", - picture: "/images/people/mehulkar.jpeg", - }, - mattpocock: { - name: "Matt Pocock", - twitterUsername: "mattpocockuk", - picture: "/images/people/mattpocock.jpeg", - }, - tobiaskoppers: { - name: "Tobias Koppers", - twitterUsername: "wSokra", - picture: "/images/people/tobiaskoppers-avatar.jpg", - }, - alexkirsz: { - name: "Alex Kirszenberg", - twitterUsername: "alexkirsz", - picture: "/images/people/alexkirsz.jpg", - }, - anthonyshew: { - name: "Anthony Schew", - twitterUsername: "anthonysheww", - picture: "/images/people/anthonyshew.png", - }, - nicholasyang: { - name: "Nicholas Yang", - twitterUsername: "nicholaslyang", - picture: "/images/people/nicholasyang.png", - }, - chrisolszewski: { - name: "Chris Olszewski", - picture: "/images/people/chrisolszewski.jpg", - }, - alexanderlyon: { - name: "Alexander Lyon", - twitterUsername: "_arlyon", - picture: "/images/people/alexanderlyon.jpg", + HsiangNianian: { + name: "简律纯", + twitterUsername: "HsiangNianian", + picture: "/images/people/HsiangNianian.jpg", }, }; diff --git a/docs/pages/blog/_meta.json b/docs/pages/blog/_meta.json index 3de89ce..1bdc4e4 100644 --- a/docs/pages/blog/_meta.json +++ b/docs/pages/blog/_meta.json @@ -3,24 +3,11 @@ "//": "Hide all the links from the sidebar or navbar, and disable ToC and Sidebar for these pages.", "display": "hidden", "theme": { - "toc": false, - "sidebar": false, + "toc": true, + "sidebar": true, "pagination": false, "typesetting": "article" } }, - "turbo-1-9-0": "Turborepo 1.9", - "turbo-1-8-0": "Turborepo 1.8", - "turbo-1-7-0": "Turborepo 1.7", - "turbopack-benchmarks": "Turbopack Performance Benchmarks", - "turbo-1-6-0": "Turborepo 1.6", - "turbo-1-5-0": "Turborepo 1.5", - "turbo-1-4-0": "Turborepo 1.4", - "turbo-1-3-0": "Turborepo 1.3", - "turbo-1-2-0": "Turborepo 1.2", - "turbo-1-1-0": "Turborepo 1.1", - "joining-vercel": "Joining Vercel", - "saml-sso-now-available": "SAML SSO now available", - "you-might-not-need-typescript-project-references": "You might not need TypeScript project references", - "turbo-0-4-0": "Turborepo 0.4.0" + "hydroroll-0-1-3": "HydroRoll'水系 0.1.3" } diff --git a/docs/pages/blog/hydroroll-0-1-3.mdx b/docs/pages/blog/hydroroll-0-1-3.mdx new file mode 100644 index 0000000..8358dfd --- /dev/null +++ b/docs/pages/blog/hydroroll-0-1-3.mdx @@ -0,0 +1,17 @@ +--- +title: HydroRoll 0.1.3 +date: 2023/04/28 +description: 水系0.1.3发布 +tag: dev story +ogImage: /images/blog/joining-vercel/twitter-card.png +--- + +# Turborepo 0.4.0 + +import { Authors } from "../../components/Authors"; + + + +我很高兴能够发布 `v0.1.3` 版本的水系库, 这对我来说是个严峻的挑战——因为我的生活非常忙碌, 节奏很快——因此我也需要一些帮手来协助我, 让我欣慰的是, 我的朋友们大多数都非常支持我编写这样一个骰系系统。 + +是的, 他们非常支持我。 \ No newline at end of file diff --git a/docs/pages/blog/joining-vercel.mdx b/docs/pages/blog/joining-vercel.mdx deleted file mode 100644 index f84ec49..0000000 --- a/docs/pages/blog/joining-vercel.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Turborepo is joining Vercel -date: 2021/12/09 -description: Turborepo is joining Vercel to make the web even faster. -tag: web development -ogImage: /images/blog/joining-vercel/twitter-card.png ---- - -# Turborepo is joining Vercel - -import { Authors } from "../../components/Authors"; - - - -Turborepo has been acquired by Vercel and the Turborepo CLI is now open-source! Also, Turborepo now provides zero-config remote caching through [Vercel](https://vercel.com/?utm_source=turbo.build&utm_medium=referral&utm_campaign=docs-link)! - -beta.turborepo.com and its remote caching service will be shut down on January 15th, 2022 and older versions of the `turbo` CLI will not be installable. Learn more about how to upgrade your CLI and migrate to Vercel [here](/repo/docs/upgrading-to-v1). - -This is a milestone moment for the project and for all of you who have supported and adopted Turborepo. With Vercel's infrastructure and team backing, I'll expand on the capabilities of Turborepo and build out a team focused on improving their world-class build system. I can't wait to bring you along for this [next chapter](https://vercel.com/blog/vercel-acquires-turborepo). - -Join me this [Friday, December 10 at 4:00 p.m. ET | 9:00 p.m GMT for a livestream Q&A](https://www.youtube.com/watch?v=YX5yoApjI3M) with Vercel's Head of Developer Relations, Lee Robinson. We'll go over what's in store for Turborepo and Vercel as we work toward improving the developer experience together. - -This is just the beginning. We're about to embark on a world of even faster builds, even more flexibility, and even better workflows. Thanks for joining us on this amazing journey. diff --git a/docs/pages/blog/saml-sso-now-available.mdx b/docs/pages/blog/saml-sso-now-available.mdx deleted file mode 100644 index 0014cfc..0000000 --- a/docs/pages/blog/saml-sso-now-available.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: SAML SSO is now available -date: 2021/08/03 -description: SAML Single Sign-on (SSO) is now available to Enterprise customers thanks to our friends over at WorkOS. -tag: web development -ogImage: /images/blog/saml-sso-now-available/twitter-card.png ---- - -# SAML SSO is now available - -import { Authors } from "../../components/Authors"; - - - -Thanks to our friends over at [WorkOS](https://workos.com/), in addition to GitHub, Gitlab, and Passwordless auth, Turborepo now supports Single Sign-on (SSO) from the following SAML providers for enterprise customers: - -- AD FS SAML -- Auth0 SAML -- Azure AD SAML -- CyberArk SAML -- Generic SAML -- G Suite OAuth -- G Suite SAML -- JumpCloud SAML -- Microsoft OAuth -- Okta SAML -- OneLogin SAML -- OpenID Connect -- PingFederate SAML -- PingOne SAML -- Shibboleth -- VMWare SAML - -We also support SCIM (a.k.a. "Directory Sync") via: - -- Azure AD SCIM -- BambooHR -- G Suite -- Gusto -- Hibob -- Okta SCIM v1.1 -- Okta SCIM v2.0 -- Rippling -- SCIM v1.1 -- SCIM v2.0 -- Workday - -If you're team in interested in activating SAML SSO, please contact us [turborepo@vercel.com](mailto:turborepo@vercel.com). - -## What's next? - -We take security extremely seriously. And while SSO is certainly a must in 2021, we are also currently undergoing a third-party SOC 2 Type 2 examination as well. Last but not least, we are adding biometric/U2F access controls and audit logs this fall. Stay tuned for updates. diff --git a/docs/pages/blog/turbo-0-4-0.mdx b/docs/pages/blog/turbo-0-4-0.mdx deleted file mode 100644 index c4b92ba..0000000 --- a/docs/pages/blog/turbo-0-4-0.mdx +++ /dev/null @@ -1,211 +0,0 @@ ---- -title: Turborepo 0.4.0 -date: 2021/04/02 -description: Turborepo 0.4.0 introduces 10x faster hashing, pruned workspaces with sparse installs, a new pipeline configuration API, and improved cache control. -tag: web development -ogImage: /images/blog/joining-vercel/twitter-card.png ---- - -# Turborepo 0.4.0 - -import { Authors } from "../../components/Authors"; - - - -I'm excited to announce the release of Turborepo v0.4.0! - -- **10x faster**: `turbo` has been rewritten from the ground up in Go to make it even more blazing fast -- **Smarter hashing**: Improved hashing algorithm now considers resolved dependencies instead of just the contents of the entire root lockfile -- **Partial lockfiles / sparse installs**: Generate a pruned subset of your root lockfile and monorepo that includes only the necessary packages needed for a given target -- **Fine-grained scheduling**: Improved task orchestration and options via `pipeline` configuration -- **Better cache control**: You can now specify cache outputs on a per-task basis - -## Rewritten in Go - -Although I initially prototyped `turbo` in TypeScript, it became clear that certain items on the roadmap would require better performance. After around a month or so of work, I'm excited to finally release Go version of the `turbo` CLI. Not only does it boot in a milliseconds, but the new Go implementation is somewhere between 10x and 100x faster at hashing than the Node.js implementation. With this new foundation (and some features you're about to read about), Turborepo can now scale to intergalactic sized projects while remaining blazing fast all thanks to Go's awesome concurrency controls. - -## Better Hashing - -Not only is hashing faster in v0.4.0, but also _a lot_ smarter. - -The major change is that `turbo` no longer includes the hash of the contents of the root lockfile in its hasher (the algorithm responsible for determining if a given task exists in the cache or needs to be executed). Instead, `turbo` now hashes the set of the resolved versions of a package's `dependencies` and `devDependencies` based on the root lockfile. - -The old behavior would explode the cache whenever the root lockfile changed in any way. With this new behavior, changing the lockfile will only bust the cache for those package's impacted by the added/changed/removed dependencies. While this sounds complicated, again all it means is that when you install/remove/update dependencies from npm, only those packages that are actually impacted by the changes will need to be rebuilt. - -## Experimental: Pruned Workspaces - -One of our biggest customer pain points/requests has been improving Docker build times when working with large Yarn Workspaces (or really any workspace implementation). The core issue is that workspaces' best feature--reducing your monorepo to a single lockfile--is also its worst when it comes to Docker layer caching. - -To help articulate the problem and how `turbo` now solves it, let's look at an example. - -Say we have a monorepo with Yarn workspaces that includes a set of packages called `frontend`, `admin`, `ui`, and `backend`. Let's also assume that `frontend` and `admin` are Next.js applications that both depend on the same internal React component library package `ui`. Now let's also say that `backend` contains an Express TypeScript REST API that doesn't really share much code with any other part of our monorepo. - -Here's what the Dockerfile for the `frontend` Next.js app might look like: - -```docker {7} -FROM node:alpine AS base -RUN apk update -WORKDIR /app - -# Add lockfile and package.jsons -FROM base AS builder -COPY *.json yarn.lock ./ -COPY packages/ui/*.json ./packages/ui/ -COPY packages/frontend/*.json ./packages/frontend/ -RUN yarn install - -# Copy source files -COPY packages/ui/ ./packages/ui/ -COPY packages/frontend/ ./packages/frontend/ - -# Build -RUN yarn --cwd=packages/ui/ build -RUN yarn --cwd=packages/frontend/ build - -# Start the Frontend Next.js application -EXPOSE 3000 -RUN ['yarn', '--cwd', 'packages/frontend', 'start'] -``` - -While this works, there are some things that could be a lot better: - -- You manually `COPY` in the internal packages and files needed to build the target app and need to remember which need to be built first. -- You `COPY` the root `yarn.lock` lockfile into the correct position very early in the Dockerfile, but this lockfile is the lockfile for the _entire_ monorepo. - -This last issue is especially painful as your monorepo gets larger and larger because any change to this lockfile triggers a nearly full rebuild regardless of whether or not the app is actually impacted by the new/changed dependencies. - -....until now. - -With the all new `turbo prune` command, you can now fix this nightmare by deterministically generating a sparse/partial monorepo with a pruned lockfile for a target package--without installing your `node_modules`. - -Let's look at how to use `turbo prune` inside of Docker. - -```docker {11,16} -FROM node:alpine AS base -RUN apk update && apk add git - -## Globally install `turbo` -RUN npm i -g turbo - -# Prune the workspace for the `frontend` app -FROM base as pruner -WORKDIR /app -COPY . . -RUN turbo prune --scope=frontend --docker - -# Add pruned lockfile and package.json's of the pruned subworkspace -FROM base AS installer -WORKDIR /app -COPY --from=pruner /app/out/json/ . -COPY --from=pruner /app/out/yarn.lock ./yarn.lock -# Install only the deps needed to build the target -RUN yarn install - -# Copy source code of pruned subworkspace and build -FROM base as builder -WORKDIR /app -COPY --from=pruner /app/.git ./.git -COPY --from=pruner /app/out/full/ . -COPY --from=installer /app/ . -RUN turbo run build --scope=frontend - -# Start the app -FROM builder as runner -EXPOSE 3000 -RUN ['yarn', '--cwd', 'packages/frontend', 'start'] -``` - -So what exactly is the output of the `turbo prune`? A folder called `out` with the following inside of it: - -- A folder `json` with the pruned workspace's package.jsons -- A folder `full` with the pruned workspace's full source code, but only including the internal packages that are needed to build the target -- A _new_ pruned lockfile that only contains the pruned subset of the original root lockfile with the dependencies that are actually used by the packages in the pruned workspace. - -Thanks to the above, Docker can now be set up to only rebuild each application when there is a real reason to do so. So `frontend` will only rebuild when its source or dependencies (either internal or from npm) have actually changed. Same same for `admin` and `backend`. Changes to `ui`, either to its source code or dependencies, will trigger rebuilds of both `frontend` and `admin`, but _not_ `backend`. - -While this example seems trivial, just imagine if each app takes up to 20 minutes to build and deploy. These savings really start to add up quickly, especially on large teams. - -## Pipelines - -To give you even more control over your Turborepo, we've added `pipeline` to `turbo`'s configuration. This new field in lets you specify how the npm scripts in your monorepo relate to each other as well as some additional per-task options. `turbo` then uses this information to optimally schedule your tasks in your monorepo, collapsing waterfalls that would otherwise exist. - -Here's how it works: - -```json -// /package.json -{ - "turbo": { - "pipeline": { - "build": { - // This `^` tells `turbo` that this pipeline target relies on a topological target being completed. - // In english, this reads as: "this package's `build` command depends on its dependencies' or - // devDependencies' `build` command being completed" - "dependsOn": ["^build"] - }, - "test": { - // `dependsOn` without `^` can be used to express the relationships between tasks at the package level. - // In English, this reads as: "this package's `test` command depends on its `lint` and `build` command first being completed" - "dependsOn": ["lint", "build"] - }, - "lint": {}, - "dev": {} - } - } -} -``` - -The above config would then be interpreted by `turbo` to optimally schedule execution. - -What's that actually mean? In the past (like Lerna and Nx), `turbo` could only run tasks in topological order. With the addition of pipelines, `turbo` now constructs a topological "action" graph in addition to the actual dependency graph which it uses to determine the order in which tasks should be executed with maximum concurrency. The end result is that you no longer waste idle CPU time waiting around for stuff to finish (i.e. no more waterfalls). - -![Turborepo scheduler](/images/blog/turbo-0-4-0/turbo-vs-lerna-execution.png) - -## Improved Cache Control - -Thanks to `pipeline`, we now have a great place to open up `turbo`'s cache behavior on a per-task basis. - -Building on the example from above, you can now set cache output conventions across your entire monorepo like so: - -```json -// /package.json -{ - "turbo": { - "pipeline": { - "build": { - // Cache anything in dist or .next directories emitted by a `build` command - "outputs": ["dist/**", ".next/**", "!.next/cache/**"] - "dependsOn": ["^build"] - }, - "test": { - // Cache the test coverage report - "outputs": ["coverage/**"], - "dependsOn": ["lint", "build"] - }, - "dev": { - // Never cache the `dev` command - "cache": false - }, - "lint": {}, - } - } -} -``` - -_Note: Right now, `pipeline` exists at the project level, -but in later releases these will be overridable on per-package basis._ - -## What's Next? - -I know this was a lot, but there's even more to come. Here's what's up next on the Turborepo roadmap. - -- A landing page! -- [Remote caching w/ `@turborepo/server`](https://twitter.com/jaredpalmer/status/1359627800840462341) -- Build scans, telemetry, and metrics and dependency and task graph visualization -- [Desktop Console UI](https://twitter.com/jaredpalmer/status/1360315387372572672) -- Intelligent `watch` mode -- Official build rules for TypeScript, React, Jest, Node.js, Docker, Kubernetes, and more - -## Credits - -- [Iheanyi Ekechukwu](https://twitter.com/kwuchu) for guiding me through the Go ecosystem -- [Miguel Oller](https://twitter.com/ollermi) and the team from [Makeswift](https://www.makeswift.com/) for iterating on the new `prune` command diff --git a/docs/pages/blog/turbo-1-1-0.mdx b/docs/pages/blog/turbo-1-1-0.mdx deleted file mode 100644 index d111a09..0000000 --- a/docs/pages/blog/turbo-1-1-0.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Turborepo 1.1 -date: 2022/01/31 -description: Turborepo 1.1 introduces automatic migrations, turbo.json configuration, environment variable dependencies, partial Yarn v2 support, and more! -tag: web development -ogImage: /images/blog/turbo-1-1-0/twitter-card.png ---- - -# Turborepo 1.1 - -import { Authors } from "../../components/Authors"; - - - -Since releasing Turborepo v1.0 in mid-December, we've seen incredible adoption: - -- 5.5k+ GitHub Stars -- 70k+ weekly npm downloads -- 65+ OSS contributors -- In production at [Vercel](https://github.com/vercel/next.js), [AWS](https://github.com/aws-amplify/amplify-ui), [PayPal](https://twitter.com/jaredpalmer/status/1485617973477978121), [Twilio](https://github.com/twilio-labs/function-templates), [Contentful](https://github.com/contentful/forma-36), [Miro](https://github.com/miroapp/app-examples), [Framer](https://github.com/framer/motion), [Discord.js](https://github.com/discordjs/discord.js), [Rocket.chat](https://github.com/RocketChat/fuselage), [Astro.build](https://github.com/withastro/astro) -- 585+ members of the [Turborepo Community Discord](https://turbo.build/discord) - -![Weekly npm downloads of `turbo`](/images/blog/turbo-1-1-0/turborepo-weekly-npm-downloads.png) - -We're further improving build performance and caching with Turborepo v1.1, featuring: - -- [**Automatic Migrations:**](#automatic-migrations) Official idempotent migration scripts to assist with upgrading. -- [**`turbo.json` Support:**](#turbojson-support) Turborepo configuration now lives in its own file. -- [**Faster Package Manager Detection:**](#faster-package-manager-detection) Turborepo now respects the `packageManager` key in the root `package.json`. -- [**Environment Variable Dependencies:**](#environment-variable-dependencies) Define how environment variables impact global and task-specific caching. -- [**Partial Support for Yarn v2+:**](#partial-yarn-v2v3-support) Support for yarn v2+ with `nodeLinker: "node-modules"`. - -Update today by running `npm install turbo@latest`. After running `turbo`, you'll see instructions about how to use `@turbo/codemod` to run automatic migrations for `v1.1`. - -## Automatic Migrations - -Turborepo now provides idempotent code transformations and automatic migration scripts (a.k.a "codemods") to help upgrade your Turborepo codebase when a feature is deprecated or will be deprecated in the future. - -Codemods are transformations that run on your codebase programmatically. This saves you time by applying a large number of changes to your code automatically, without having to manually go through and edit every file. - -### Usage - -```bash -npx @turbo/codemod -``` - -- `transform` - the name of transform, [see available transforms in the docs](/repo/docs/reference/codemods#turborepo-1x). -- `path` - files or directory to transform. -- `--dry` - Do a dry run, no code will be edited. -- `--print` - Prints the changed output for comparison. - -For more information about specific transforms, check out the [new Codemods documentation](/repo/docs/reference/codemods#turborepo-1x). - -## `turbo.json` Support - -Turborepo configuration is now defined in a `turbo.json` file in the root of your monorepo. This is an improvement over having a `turbo` key in `package.json` for those who want to quickly jump straight to their Turborepo configuration in their code editors. - -To automatically migrate from your current configuration in `package.json`, check out a new branch, navigate to the root of your monorepo and run the following codemod: - -```bash -npx @turbo/codemod create-turbo-config . -``` - -For more information on this transformation, [check out the documentation](/repo/docs/reference/codemods#create-turbo-config). - -## Faster Package Manager Detection - -Turborepo now supports the recently established `packageManager` field in `package.json` for faster package manager detection. Previously, `turbo` would check for specific files to infer this information. To automatically set this field, check out a new branch, navigate to the root of your monorepo and run: - -```bash -npx @turbo/codemod add-package-manager . -``` - -For more information on this transformation, [check out the documentation](/repo/docs/reference/codemods#add-package-manager). - -## Environment Variable Dependencies - -When you use `turbo` with tools that inline environment variables at build time (e.g. Next.js or Create React App), it is important you tell `turbo` about it to avoid shipping a cached artifact with the wrong environment variables. - -You can now control `turbo`'s [cache fingerprinting (a.k.a. hashing)](/repo/docs/core-concepts/caching#hashing) behavior based on the values of both environment variables and the contents of files: - -- Including environment variables in a `dependsOn` in your `pipeline` definition prefixed by a `$` will impact the cache fingerprint on a per-task or per-package-task basis. -- Including environment variables in `globalDependencies` list prefixed by a `$` will impact the cache fingerprint of _all_ tasks. -- Including files or globs of files in `globalDependencies` will impact the cache fingerprint of _all_ tasks. -- The value of any environment variable that includes `THASH` in its name will impact the cache fingerprint of _all_ tasks. - -```jsonc -{ - "pipeline": { - "build": { - "dependsOn": { - "^build" - // env vars will impact hashes of all "build" tasks - "$SOME_ENV_VAR" - }, - "outputs": ["dist/**"] - }, - "web#build": { // override settings for the "build" task for the "web" app - "dependsOn": [ - "^build", - // env vars that will impact the hash of "build" task for only "web" app - "$STRIPE_SECRET_KEY", - "$NEXT_PUBLIC_STRIPE_PUBLIC_KEY", - "$NEXT_PUBLIC_ANALYTICS_ID", - ], - "outputs": [".next/**", "!.next/cache/**"], - }, - "docs#build": { // override settings for the "build" task for the "docs" app - "dependsOn": [ - "^build", - // env vars that will impact the hash of "build" task for only "web" app - "$STRIPE_SECRET_KEY", - "$NEXT_PUBLIC_STRIPE_PUBLIC_KEY", - "$NEXT_PUBLIC_ANALYTICS_ID", - ], - "outputs": [".next/**", "!.next/cache/**"], - } - }, - "globalDependencies": [ - "$GITHUB_TOKEN"// env var that will impact the hashes of all tasks, - "tsconfig.json" // file contents will impact the hashes of all tasks, - ".env.*" // glob file contents will impact the hashes of all tasks, - ] -} -``` - -Note: In most monorepos, you don't often use environment variables in shared packages, but mostly in applications. Thus, to get higher cache hit rates, you should only include environment variables in the app-specific tasks where they are used/inlined. - -For more information, read the [caching and hashing documentation](/repo/docs/core-concepts/caching). - -## Partial Yarn v2/v3 support - -In addition to Yarn v1, npm, and pnpm package managers, Turborepo now supports Yarn v2+ with [`nodeLinker: "node-modules"` set in `.yarnrc.yml`](https://yarnpkg.com/configuration/yarnrc#nodeLinker). This key tells Yarn v2+ to mimic Yarn v1's `node_modules` installation behavior. Yarn v2+ Plug'n'Play (a.k.a. "PnP") is not currently supported. - -## What's next? - -[Since our launch](/blog/joining-vercel), Turborepo has focused on seamless incremental adoption/migration and speeding up CI/CD. We are committed to both of those values, but now we'll also be focusing on improving Turborepo's day-to-day ergonomics for local development and observability. We're really excited about this next chapter and will be sharing more details soon. - -## We're hiring! - -The Turborepo team at [Vercel](https://vercel.com/) is hiring! We're specifically looking for full time [Senior Full Stack Software Engineers](https://vercel.com/careers) and [Senior DevOps/Infrastructure Engineers](https://vercel.com/careers) to help us make Turborepo even better. diff --git a/docs/pages/blog/turbo-1-2-0.mdx b/docs/pages/blog/turbo-1-2-0.mdx deleted file mode 100644 index 1b49f6f..0000000 --- a/docs/pages/blog/turbo-1-2-0.mdx +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Turborepo 1.2 -date: 2022/04/08 -description: Turborepo 1.2 introduces improved task filtering, artifact signing and integrity, human-readable and JSON dry runs, and more! -tag: web development -ogImage: /images/blog/turbo-1-2-0/twitter-card.png ---- - -# Turborepo 1.2 - -import { Authors } from "../../components/Authors"; -import Date from "../../components/blog/Date"; - - - Friday, April 8th, 2022 - - - - -Since releasing Turborepo v1.1 in late January, we've seen incredible adoption and community growth: - -- **6.5k+** [GitHub Stars](https://github.com/vercel/turbo) -- **140k+** weekly npm downloads (doubling since our [last blog post for v1.1](/blog/turbo-1-1-0)) -- **95+** OSS contributors -- **900+** members of the [Turborepo Community Discord](https://turbo.build/discord) -- **1.6 years** of Time Saved through Remote Caching on Vercel, saving more than 2.5 months every week - -We've further improved ergonomics, observability, and security with Turborepo v1.2 featuring: - -- [**New Task Filtering API**](#new-task-filtering-api): `--filter` adds more powerful task filtering capabilities to `turbo run` -- [**Human-readable and JSON dry runs**](#debug-and-automate-with---dry-run): `--dry-run` flag can print out information about a `turbo run` without executing any tasks, in both human and JSON-parse friendly formats -- [**Improved Internal Scheduler and Graph**](#improved-internal-scheduler-and-graph): We refactored `turbo` 's internal scheduler and graph to be more ergonomic and predictable -- [**Enhanced Remote Cache Security**](#cache-outputs-integrity-and-signature-verification): Cryptographically sign remote cache artifacts with your own secret key - -Update today by running `npm install turbo@latest`. After running `turbo run` for the first time, you'll see instructions about how to use `@turbo/codemod` to run automatic migrations for `v1.2`. - -## New Task Filtering API - -We are excited to release one of our most requested features: the ability to expressively filter tasks through a `--filter` flag. The `--filter` flag is the much more powerful successor to the current combination of `--scope`, `--include-dependencies`, `--since`, and `--no-deps` flags. - -With `--filter` you can tell `turbo` to restrict executing commands to a subset of matched packages in your monorepo based on name, folder, or even if it has changed since a git commit ref. - -Take a look at some examples of what you can accomplish with the new `--filter` command: - -- `--filter=` - match by exact package name or glob pattern -- `--filter=...`- match by package name/glob and include all dependent packages of matches -- `--filter=...^`- match by package name/glob and include all dependent packages of matches, but exclude the matches themselves -- `--filter=...` - match by package name/glob and include all the matched packages' dependencies -- `--filter=^...` - match by package name/glob and include all matched package dependencies, but exclude the matches themselves -- `--filter={./path/to/package}` - match by path or filesystem glob pattern -- `--filter=[origin/main]` - match by changed packages since a git commit ref - -You can use multiple filters together to get even more granular filtering as well as combine each part of the above patterns `{}`, `[]` , `^` , and `...` to express more complex behavior. - -For example, if you had an app located in `./apps/web` directory with local packages used as dependencies, and a Turborepo pipeline where `test` depends on `^build` topologically, running: - -```sh -turbo run test --filter={./apps/web}[HEAD^1]^... -``` - -would tell `turbo` to ensure dependencies are built and to run the `test` script in all of the local dependencies of the app located in `./apps/web`, not including that app itself, if the app has changed since HEAD^1. - -For more details and examples, refer to the new [filtering documentation](/repo/docs/core-concepts/monorepos/filtering). - -## Debug and Automate with `--dry-run` - -You can now see the impact of `turbo run` without actually executing any commands by appending either `--dry-run` or `--dry-run=json` to any `turbo run` command. This will result in either human or JSON output. - -Dry runs are incredibly useful for two situations: - -- Debugging and testing run options -- Using `turbo` filtering and task graphs for building automations - -import { Bleed } from "nextra-theme-docs"; - - -
- ![Turborepo Dry Run](/images/blog/turbo-1-2-0/turbo-dry-run.png) -
- - -We hope that this will improve visibility into what `turbo` is doing, speeding up debugging, and make it easier to leverage `turbo` in dynamic CI/CD systems. - -## Improved Internal Scheduler and Graph - -When using `turbo run`, every `package.json` task is added to an internal graph to map dependencies based on the inferred relationships defined in your Turborepo `pipeline`. This task graph allows Turborepo to efficiently schedule incremental concurrent task running and cache task outputs for later use. - -We have made major improvements to the internal task scheduler and resulting graph structure, resulting in better performance and a better developer experience. For example, in many cases, you will no longer need to use `--include-dependencies`. Instead, after specifying your task entry points, the new and improved graph will automatically handle this graph resolution on your behalf. - -## Cache Outputs Integrity and Signature Verification - -You can now configure Turborepo to sign remote cache outputs using HMAC-SHA256 with a secret key before uploading them to the Remote Cache. When Turborepo downloads signed cache artifacts, it will now verify the artifact's integrity and authenticity. Any artifact that fails to verify will be ignored, discarded, and treated as a cache miss by Turborepo. - -To enable this feature, set the `remoteCache` options in your `turbo.json` config file to include `signature: true`. Then specify your secret key by declaring the `TURBO_REMOTE_CACHE_SIGNATURE_KEY` environment variable. - -```jsonc -{ - "$schema": "[https://turbo.build/schema.json](https://turbo.build/schema.json)", - "remoteCache": { - // Indicates if signature verification is enabled. - "signature": true - } -} -``` - -## Other bug fixes and improvements - -- `--sso-team` flag now enables teams with SAML tokens to log in through `turbo login` with correct team permissions -- `--log-output` flag allows you to control what logs are printed to the terminal, and when, allowing you to focus only on what's new -- `FORCE_COLOR` environment variable is now supported -- `TURBO_FORCE=true` environment variable will now force execution -- `--remote-only` and `TURBO_REMOTE_ONLY=true` will tell `turbo` to only use Remote Caching -- We now show `>>> FULL TURBO` when there's at least one task attempted -- Yarn v2+ with Plug'n'Play (PnP linker) is supported for the `turbo run` command, but `turbo prune` is still not fully supported -- Fixed regression with chrome tracing if `--profile` is specified -- You can now set concurrency by percentage of CPUs with `--concurrency=50%` - -## We're hiring! - -The Turborepo team at [Vercel](https://vercel.com/) is hiring! We're up to five core team members already this year and are looking to hire even more. We're specifically looking for full-time [Senior Build Systems Engineers](https://vercel.com/careers). - -## What's next? - -Along with seamless incremental adoption/migration and speeding up CI/CD, we've been focusing on improving Turborepo's day-to-day ergonomics, security, and observability. The new `--filter` flag, signed artifacts, and dry runs are important steps toward those goals. - -Next up, we'll be focusing an enhanced local development experience, codebase automations, and overall CLI performance. - -## Thank you, contributors - -Turborepo is the result of the combined work of over 95 individual developers and our core team. - -This release was brought to you by the contributions of: @gsoltis09, @jaredpalmer, @gaspar09, @shuding, @rajatkulkarni95, @VanTanev, @Kikobeats, @tknickman, @thebanjomatic, @chelkyl, @elado, @finn-orsini, @becca, @weyert, @ekosz diff --git a/docs/pages/blog/turbo-1-3-0.mdx b/docs/pages/blog/turbo-1-3-0.mdx deleted file mode 100644 index f84b57e..0000000 --- a/docs/pages/blog/turbo-1-3-0.mdx +++ /dev/null @@ -1,202 +0,0 @@ ---- -title: Turborepo 1.3 -date: 2022/06/23 -description: Turborepo 1.3 introduces restricted hash inputs, root script running and caching, new CI/CD Recipes, and more! -tag: web development -ogImage: /images/blog/turbo-1-3-0/twitter-card.png ---- - -# Turborepo 1.3 - -import { Authors } from "../../components/Authors"; -import Callout from "../../components/Callout"; -import Date from "../../components/blog/Date"; - - - Thursday, June 23rd, 2022 - - - - -With Turborepo 1.3 we are bringing improved caching and flexibility which includes: - -- [**Restricted hash inputs:**](#pipeline-inputs) Specify the files in a package folder that impact caching with `inputs`. -- [**Root script running and caching:**](#run-and-cache-scripts-from-the-root-of-your-monorepo) Run and cache `package.json` scripts from the root of the monorepo. -- [**New CI/CD Recipes:**](#new-cicd-recipes) We added recipes for using Turborepo with popular CI providers. - -Update today by running `npm install turbo@latest`. - -## Pipeline `inputs` - -In addition to [environment variables, dependencies, and pipeline configurations,](/repo/docs/core-concepts/caching#hashing) `turbo` will consider all non-gitignored files in package folder when calculating each `package.json` script's hash fingerprint (the key that `turbo` uses to index its cache and to determine if a script needs to be re-executed). **With Turborepo 1.3+, you can now specify globs of `inputs` in your `turbo.json` `pipeline` to control which files are relevant for a particular script for caching.** This means that you can now express the following in `turbo.json` - -- Ignore changes to all markdown files in a package or app's folder. -- Don't bother rebuilding an app if only its test files have changed. -- Only re-run tests if either source files or test files have been changed in a package or folder. -- and more. - -Let's walk through a concrete example: imagine we have a monorepo with a Next.js application for a documentation website in `./apps/docs-site`, some packages, and some markdown files in the root of the monorepo in a `./docs` folder. - -```sh filename="Example monorepo" -. -├── docs/ -│ ├── api-reference.md -│ ├── getting-started.md -│ └── intro.md -├── apps/ -│ ├── docs-site/ -│ │ ├── components/ -│ │ ├── pages/ -│ │ │ └── [slug].js -│ │ ├── README.md -│ │ └── package.json -│ └── web-site/ -│ ├── pages/ -│ ├── README.md -│ └── package.json -├── packages/ -│ ├── configs/ -│ └── ui/ -├── package.json -└── turbo.json -``` - -Let's assume that the Next.js `docs-site` renders the markdown files from the `./docs` folder. We can now set up the `build` script in the app's `package.json` to use `inputs` in `turbo.json` to better specify exactly which files are relevant (and which should impact caching) as follows: - -```jsonc filename="./turbo.json" -{ - "$schema": "https://turbo.build/schema.json", - "pipeline": { - // ... omitted for brevity - "build": { - "dependsOn": ["^build"], - "outputs": [".next/**", "!.next/cache/**", "dist/**"] - }, - "docs#build": { - "dependsOn": ["^build"], - "outputs": [".next/**", "!.next/cache/**"], - // Define set of relevant globs which impact caching of docs site - // builds - "inputs": [ - "../../docs/**/*.md", - "pages/**", - "components/**", - "package.json" - ] - } - } -} -``` - -Note: Like `outputs`, `inputs` are defined relative to the related `package.json` , but they can be outside of a given folder (`e.g. ../../docs/**`). - -## Run and cache scripts from the root of your monorepo - -As of 1.3, **`turbo` can now run and cache scripts from the `package.json` file at the root of the monorepo**, which will help significantly when migrating to Turborepo. - -To set this up, specify a root script in your `pipeline` configuration in your `turbo.json` using the form `"//#