docs: write why-monorepo.md blog article

docs/src/blog/why-monorepo.md

@@ -8,4 +8,50 @@ authors:
 description: The reasons why we switched to a monorepo for our Minecraft plugins and libraries.
 ---
 
-# Why we switched to a monorepo
+# Why We Switched to a Monorepo
+
+## Introduction
+
+Managing multiple repositories for our Minecraft plugins and libraries became increasingly complex. Over time, we noticed that our two main plugins, **FancyNpcs** and **FancyHolograms**, were becoming more independent of each other. However, our long-term vision is to ensure a consistent **user experience** and **developer experience** across all our plugins.
+
+### Our Goals:
+- Maintain a consistent **command structure** across all plugins.
+- Standardize the **configuration structure**.
+- Establish a **uniform API design**.
+- Follow the same **design patterns** in all plugins.
+
+To make it easier to achieve these goals, we decided to **switch to a monorepo**. This approach lowers the barrier to collaboration and helps us maintain consistency more effectively.
+
+## Problems with Multiple Repositories
+
+### Dependency Management
+
+Our plugins rely on **FancyLib** and **FancySitula** as shared libraries. In a multi-repo setup, testing changes in **FancyLib** requires us to publish a new version to Maven local, update the version in each plugin, and then test the changes. This is a **time-consuming process**.
+
+With a **monorepo**, dependencies are linked directly to the source code, allowing for seamless testing and modification. This approach offers several advantages:
+- Changes in **FancyLib** can be tested instantly without publishing intermediate versions.
+- Dependencies are updated in a **single place**, preventing version mismatches between plugins.
+- Redundant dependency versions are eliminated, making maintenance easier.
+
+### Code Duplication
+
+Both **FancyNpcs** and **FancyHolograms** rely on **spawning and managing entities with packets**, but they implement this functionality in different ways. As a result, there is **significant code duplication**, leading to maintenance challenges and duplicated bugs.
+
+With a **monorepo**, we can extract common functionality into a shared library, ensuring:
+- **Code reuse** across multiple plugins.
+- **Less duplication**, reducing the chances of bugs occurring in multiple places.
+- **Easier maintenance**, as fixes and improvements benefit all plugins simultaneously.
+
+## CI/CD Pipelines
+
+Managing CI/CD pipelines for multiple repositories introduces unnecessary overhead. Each plugin requires its own pipeline, meaning any updates or improvements must be **duplicated across multiple repositories**.
+
+A **monorepo** simplifies this by:
+- Providing a **single CI/CD pipeline** that builds and tests all plugins in one place.
+- Ensuring **better compatibility** between plugins by automatically testing their interactions.
+- Reducing maintenance efforts, as changes to the pipeline only need to be made **once**.
+
+## Conclusion
+
+Switching to a monorepo has streamlined our development process, improved collaboration, and helped us maintain a consistent structure across all our plugins. By eliminating dependency headaches, reducing code duplication, and unifying our CI/CD pipelines, we’ve set ourselves up for **a more efficient and scalable** future.
+

docs/src/product-direction/concepts/new-projects/fancyvisuals.md

@@ -0,0 +1 @@
+# FancyVisuals