Powered by

# Why We Switched to a Monorepo

By
Oliver Schlüter
●
Published 2025-04-01

# 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.