From 42a6f02fca4ac373a3301a457f805535bd5ea953 Mon Sep 17 00:00:00 2001 From: Alberto Vilches Date: Wed, 5 Apr 2023 10:08:33 +0200 Subject: [PATCH] fix: typos --- docs/pages/blog/turbopack-benchmarks.mdx | 2 +- docs/pages/pack/docs/advanced/profiling.mdx | 2 +- docs/pages/pack/docs/comparisons/vite.mdx | 2 +- examples/design-system/README.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/pages/blog/turbopack-benchmarks.mdx b/docs/pages/blog/turbopack-benchmarks.mdx index df5ba24127089..e6a0818ede3fc 100644 --- a/docs/pages/blog/turbopack-benchmarks.mdx +++ b/docs/pages/blog/turbopack-benchmarks.mdx @@ -242,7 +242,7 @@ This blog post has been updated to include React Refresh numbers. [Evan You’s benchmark application](https://github.com/yyx990803/vite-vs-next-turbo-hmr) is composed of a single, very large file with a thousand imports, and a thousand very small files. The shape of our benchmark is different – it represents a tree of files, with each file importing 0 or 3 other files, trying to mimic an average application. Evan helped us find a regression when editing large, root files in his benchmark. The cause for this was [quickly identified and fixed by Tobias](https://github.com/vercel/turbo/commit/a11422fdf6b1b3cde9072d90aab6d9eebfacb591) and was released in Next 13.0.1. -We have adapted our HMR benchmarks to samples modules uniformly at all depths, and we have updated this blog post and our documentation to include more details about this proces. +We have adapted our HMR benchmarks to samples modules uniformly at all depths, and we have updated this blog post and our documentation to include more details about this process. ### SWC vs. Babel diff --git a/docs/pages/pack/docs/advanced/profiling.mdx b/docs/pages/pack/docs/advanced/profiling.mdx index d46f0b61393c1..7c50d1807f91f 100644 --- a/docs/pages/pack/docs/advanced/profiling.mdx +++ b/docs/pages/pack/docs/advanced/profiling.mdx @@ -19,7 +19,7 @@ Make sure you have all the [prerequisites](https://github.com/cmyr/cargo-instrum ### Run the profiler -By default, the next-dev CLI will keep watching for changes to your application and never exit until you manually interrupt it. However, [`cargo-instruments`] waits for your program to exit before building and opening the trace file. For this purpose, we've added a `profile` feature to `next-dev` which exits the program if no updates are detected within a given timeframe and there are no pending tasks. +By default, the next-dev CLI will keep watching for changes to your application and never exit until you manually interrupt it. However, [`cargo-instruments`] waits for your program to exit before building and opening the trace file. For this purpose, we've added a `profile` feature to `next-dev` which exits the program if no updates are detected within a given time frame and there are no pending tasks. To profile `next-dev`, run the following command: diff --git a/docs/pages/pack/docs/comparisons/vite.mdx b/docs/pages/pack/docs/comparisons/vite.mdx index a8a0875e9a0fe..542579697dfd5 100644 --- a/docs/pages/pack/docs/comparisons/vite.mdx +++ b/docs/pages/pack/docs/comparisons/vite.mdx @@ -49,7 +49,7 @@ Note that Vite is using the official [SWC plugin](https://github.com/vitejs/vite Vite is extremely fast in development because of its speedy Fast Refresh capabilities. When you update a file, Vite uses its Native ESM system to to send the updated module to the browser - and performs a little bit of magic to integrate that into the existing module graph. -In Turbopack, we discovered that for Fast Refresh, we don't really need to do bundling work at all. We can send updates in a similar style to Vite. In fact - a little bit more efficently: Turbopack sends changed modules directly through the WebSocket without doing any bundling at all. +In Turbopack, we discovered that for Fast Refresh, we don't really need to do bundling work at all. We can send updates in a similar style to Vite. In fact - a little bit more efficiently: Turbopack sends changed modules directly through the WebSocket without doing any bundling at all. In a 1,000 module application, Turbopack can react to file changes ** faster** than Vite. diff --git a/examples/design-system/README.md b/examples/design-system/README.md index f4f6c2aa70518..b733050cc0469 100644 --- a/examples/design-system/README.md +++ b/examples/design-system/README.md @@ -38,7 +38,7 @@ git init . && git add . && git commit -m "Init" [Turborepo](https://turbo.build/repo) is a high-performance build system for JavaScript and TypeScript codebases. It was designed after the workflows used by massive software engineering organizations to ship code at scale. Turborepo abstracts the complex configuration needed for monorepos and provides fast, incremental builds with zero-configuration remote caching. -Using Turborepo simplifes managing your design system monorepo, as you can have a single lint, build, test, and release process for all packages. [Learn more](https://vercel.com/blog/monorepos-are-changing-how-teams-build-software) about how monorepos improve your development workflow. +Using Turborepo simplifies managing your design system monorepo, as you can have a single lint, build, test, and release process for all packages. [Learn more](https://vercel.com/blog/monorepos-are-changing-how-teams-build-software) about how monorepos improve your development workflow. ## Apps & Packages