Streamlining Web Development: My Journey to a Monorepo Structure

As a solo web developer, managing the complexities of multiple repositories for a single web application project can be daunting. My recent project – a robust web application requiring a WebAssembly (WASM) module, dynamic landing pages, and a REST backend – presented me with a significant challenge in terms of manageability. This led me to explore the world of monorepos, a journey I embarked on to streamline my development process.

The Decision to Switch to a Monorepo

In the past, juggling multiple code repositories for different segments of the project was becoming increasingly cumbersome. The main components of my project included a web application and landing pages, both developed using Svelte, along with a separate REST backend. The redundancy in handling similar structures across repositories prompted me to seek a simpler, more efficient approach.

Choosing the Right Tool: npm Workspaces

After weighing my options, I chose to implement my monorepo using npm Workspaces. While Yarn was also a contender, my familiarity with npm and its straightforward integration with my existing workflow made it the ideal choice. I was aware of other tools like DX and Narwhal, but I found that they added unnecessary complexity, whereas my priority was simplicity.

Transitioning to a Monorepo: A Step-by-Step Guide

1. Preparing the Existing Repository:

I started by creating a new branch in my existing repository to retain my code history. I moved my existing code, including package.json and various configuration files, into a subfolder within the project.

2. Configuring npm Workspaces:

I created a root package.json file and specified my web application as the first workspace.

3. Streamlining Dependencies and Scripts:

Next, I shifted shared dependencies and scripts from my web application's package.json to the root package.json. This involved modifying the scripts to function correctly within the new structure.

4. Adding the Second Workspace:

For the landing pages, I added a second entry to the root package.json and set up a corresponding subfolder. I used SvelteKit for these static HTML pages, inheriting shared dependencies from the root.

5. Implementing Landing Pages:

With the setup in place, I easily ran npm run dev:landing-pages and quickly developed two landing pages.

Conclusion: Embracing the Monorepo

The switch to a monorepo has significantly simplified my workflow. Not only has it made my codebase more manageable, but it has also allowed me to maintain a cleaner, more organized structure. As I continue to work with this setup, the benefits of a monorepo in terms of efficiency and manageability are increasingly apparent.

For fellow developers considering this transition, I can confidently say that the journey to a monorepo, though initially daunting, is well worth the effort for the simplicity and coherence it brings to your projects.