Merge branch 'main' into blog-toc-fix

Author: thejessewinton

src/routes/blog/post/announcing-database-reads-and-writes-pricing/+page.markdoc

@@ -7,7 +7,7 @@ cover: /images/blog/announcing-database-reads-and-writes-pricing/cover.png
 timeToRead: 6
 author: eldad-fux
 category: announcement
-featured: true
+featured: false
 callToAction: true
 ---
 
@@ -49,7 +49,7 @@ Any action that modifies data in your database, including:
 - Updating documents with `updateDocument`.
 - Deleting documents with `deleteDocument`.
 
-**Important to note**: Operations are counted based on the number of documents affected, not API calls. For example, if you fetch a collection of 50 documents with a single API call, this counts as 50 read operations, not as a single operation. If your query returned no documents, **it won't be counted**.
+Most operations are counted based on the number of documents affected. For example, if you fetch a collection of 50 documents with a single API call, this counts as 50 read operations, not as a single operation. However, if your query returns no documents, it will count as a single operation.
 
 # Your usage
 

src/routes/blog/post/image-transformation-with-appwrite-storage/+page.markdoc

@@ -277,10 +277,10 @@ const webpImage = storage.getFilePreview(
 The above image is originally a PNG file. However, by setting the output format to WebP, Appwrite automatically converts the image to WebP format and returns the transformed image.
 You can confirm this by downloading the image or inspecting its source.
 
-The `output` parameter supports `png`, `jpeg`, `webp`, `gif`, `heic`, and `avif`.
+The `output` parameter supports `png`, `jpeg`, `webp`, `gif`, and `heic`.
 
-Choosing the right format can significantly impact your application's performance. For example, WebP and AVIF are modern formats that offer better compression and quality than JPEG and PNG.
-However, while these are compatible with most modern browsers, it's good practice to implement a fallback for older browsers.
+Choosing the right format can significantly impact your application's performance. For example, WebP is a modern format that offers better compression and quality than JPEG and PNG.
+However, while it's supported in most modern browsers, it's good practice to implement a fallback for older browsers.
 
 # Final thoughts
 

src/routes/blog/post/typescript-7-faster-with-go/+page.markdoc

@@ -0,0 +1,76 @@
+---
+layout: post
+title: TypeScript 7.0 will be 10x faster with Go
+description: Microsoft is rewriting TypeScript's compiler in Go. Learn what this means and how it will impact your workflow.
+date: 2025-03-18
+cover: /images/blog/typescript-7-faster-with-go/cover.png
+timeToRead: 5
+author: ebenezer-don
+category: tutorial
+---
+
+Over the past decade, TypeScript has earned the trust of developers building large-scale JavaScript applications. It offers the safety net of a type system, reliable tooling, and codebases that are *arguably* easier to maintain. Yet, if you ask developers working with large projects, they'll likely express one common frustration: the TypeScript compiler can feel painfully slow.
+
+To address this challenge, Microsoft recently confirmed a significant shift under the hood. They are rewriting TypeScript's compiler (tsc) in Go. Officially codenamed "Project Corsa," this transition aims to dramatically improve compilation performance. Early benchmarks and public demonstrations from Microsoft suggest compilation speeds could improve roughly tenfold.
+
+Let's break down what this transition means, what's officially confirmed, and how it'll affect you as a developer.
+
+# What does this mean for TypeScript?
+
+Here's what we know so far:
+
+- **Compiler rewrite:** The TypeScript compiler, currently written in TypeScript and running on Node.js, is being rewritten from scratch in Go. Microsoft announced this under the internal name "Project Corsa."
+- **Motivation:** The primary motivation is performance. TypeScript compilation times and type-checking responsiveness are known to degrade as projects scale.
+- **Language stability:** The rewrite will not affect TypeScript's syntax or language design. It will continue emitting standard JavaScript as before. Developers will still write TypeScript exactly as they currently do.
+- **Standalone binary:** The new Go-based compiler will run as a standalone binary, removing the Node.js runtime dependency currently required for compilation.
+
+Microsoft has not announced any changes to TypeScript's language features, syntax, or output because of this rewrite. The transition to Go is an engineering effort to improve performance and maintainability.
+
+# Why Go specifically? Not Rust or C++?
+
+One question naturally arises: why Go specifically? While Microsoft hasn't provided a comprehensive breakdown comparing Go to alternatives like Rust or C++, they've [publicly shared](https://github.com/microsoft/typescript-go/discussions/411) some key factors:
+
+**Structural similarity:** Go's programming style closely resembles the existing TypeScript codebase, making it much easier to port TypeScript's logic while keeping behavior and optimizations intact. This is critical since Microsoft plans to maintain both the JavaScript and Go-based compilers for some time.
+
+**Memory management tradeoffs:** Unlike Rust, which requires manual memory handling, Go provides fine-grained control over memory allocation without forcing constant memory management decisions throughout the codebase. TypeScript's compiler doesn't suffer from latency-sensitive GC pauses, so Go's garbage collection works well for this use case.
+
+**Graph processing & AST traversal:** Go provides an ergonomic way to traverse complex trees and graphs, a key part of TypeScript's type-checking and compilation process.
+
+**Long-term API design considerations:** The TypeScript team wants more control over internal compiler APIs. While Go's interop with JavaScript isn't as strong as some alternatives, moving to a more intentional API design will help modernize the ecosystem.
+
+# Benchmark numbers: early results, still preliminary
+
+Perhaps the most attention-grabbing details involve benchmark numbers shared by Microsoft and industry publications. For instance, compiling the Visual Studio Code codebase (about 1.5 million lines of TypeScript) reportedly went from around 78 seconds with the current compiler down to roughly 7.5 seconds with the new Go-based compiler; a 10x improvement. Other large projects, such as Playwright and TypeORM, reportedly saw similar performance improvements (approximately 10x-13x faster).
+
+These numbers come directly from early demonstrations and internal testing shared by Microsoft. But benchmarks at this early stage often represent idealized or carefully selected scenarios. Real-world improvements for diverse TypeScript projects may vary, and final figures might differ as the implementation matures.
+
+# How will this affect tooling and ecosystem compatibility?
+
+A main concern among developers centers around compatibility with existing tools and integrations. Currently, TypeScript integrates smoothly with bundlers like Webpack, Vite, and esbuild, plus countless IDE plugins and language-server implementations.
+
+Microsoft has publicly committed to maintaining compatibility and minimizing disruption throughout the compiler transition. Still, it's realistic to expect that tooling relying heavily on internal compiler APIs or deeply integrated TypeScript behaviors may require some adjustments. It's been [confirmed](https://github.com/microsoft/typescript-go/discussions/411) that the TypeScript team will initially support both the existing JavaScript-based compiler and the new Go-based compiler concurrently. This dual-compiler support would allow tool authors and ecosystem maintainers ample time to adapt without immediate disruption.
+
+While Microsoft is prioritizing a smooth transition, developers and tool authors should prepare for minor integration adjustments, especially if their workflows rely directly on internal TypeScript compiler APIs.
+
+# Timeline and versioning: what we know
+
+Microsoft has confirmed that **TypeScript 7.0 will ship with the Go-based compiler** once it reaches feature parity with the current JavaScript-based version. Meanwhile, the existing compiler will continue under the **TypeScript 6.x** series, which will receive updates and breaking changes to align with the upcoming transition.
+
+Since some projects may depend on specific APIs or legacy configurations, **Microsoft will maintain TypeScript 6.x alongside TypeScript 7+** until the Go-based compiler reaches full stability and adoption.
+
+The rough timeline is:
+
+- **Mid-2025** – Preview release with basic type-checking.
+- **Late 2025** – Feature-complete version for project builds and language services.
+
+For now, both compilers will coexist, allowing developers to upgrade at their own pace.
+
+# What does this mean for you?
+
+This transition changes how TypeScript is compiled but not how developers use it. The language itself remains the same, and the compiler will continue outputting JavaScript as before. The main difference is that builds should be significantly faster, with better performance in large projects.
+
+That said, the new compiler is still in development, and benchmarks are early-stage. While Microsoft is working to maintain compatibility, some tools may need updates, and TypeScript 6.x will remain available for projects that aren't ready to switch immediately.
+
+The long-term goal is for the Go-based compiler to fully replace the current one, but until it reaches full stability, both will be maintained in parallel.
+
+We'll continue monitoring official announcements and detailed benchmarks as Microsoft progresses through this transition. Until then, you can remain cautiously optimistic: the future of TypeScript looks promising, and notably faster.

src/routes/blog/post/what-is-mcp/+page.markdoc

@@ -7,6 +7,7 @@ cover: /images/blog/what-is-mcp/cover.png
 timeToRead: 7
 author: ebenezer-don
 category: tutorial
+featured: true
 ---
 
 If you've ever tried using an AI assistant for something practical, like pulling real data from your work files, checking a database, or sending a message, then you've probably hit a frustrating wall.

src/routes/docs/advanced/migrations/firebase/+page.markdoc

@@ -49,7 +49,7 @@ To begin migrating to Appwrite, follow these steps.
 
 1. Click on the **Create Migration** button and select **Firebase** as your source.
 
-1. Upload the JSON file to Appwrite and follow the migration wizard to select which resources you need to migrate. Finally click **Start migration** to begin the migration process.
+1. Paste the contents of your JSON file into the textbox and follow the migration wizard to select which resources you need to migrate. Finally click **Start migration** to begin the migration process.
 
 {% /section %}
 {% section #next-steps step=4 title="Next steps" %}

src/routes/pricing/compare-plans.svelte

@@ -115,7 +115,7 @@
                     free: '1 hour',
                     pro: '7 days',
                     scale: '28 days',
-                    enterprise: '90 days'
+                    enterprise: 'Custom'
                 },
                 {
                     title: 'Budget caps and alerts',