mirror of
https://github.com/FancyInnovations/FancyPlugins.git
synced 2025-12-06 07:43:36 +00:00
acb9b6f717
* Update branding in docs * Update branding in README.md * Update branding in plugin READMEs * Update branding in plugins * Update branding in libraries * Update branding in the remaining places * Add CONTRIBUTING.md and LICENSE files * More branding in docs
61 lines
3.3 KiB
Markdown
61 lines
3.3 KiB
Markdown
---
|
||
authors:
|
||
- name: Oliver Schlüter
|
||
email: oliver@fancyinnovations.com
|
||
link: https://github.com/OliverSchlueter
|
||
avatar: https://avatars.githubusercontent.com/u/79666085?v=4
|
||
|
||
date: 2025-03-21
|
||
description: The reasons why we switched to a monorepo for our Minecraft plugins and libraries.
|
||
---
|
||
|
||
|
||
|
||
# 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.
|
||
|