# Go Modules- A Guide for monorepos (Part 1)

[Grab](https://yomu.fyi/company/grab) · Michael Cartmell · May 29, 2020

**Type:** Problem & solution

## Summary

Grab transitioned its large Go monorepo dependency management from Glide to Go modules while retaining an existing vendor directory structure. The team generated root go.mod configurations from glide.yaml and used go mod vendor without directly enabling module-mode builds. Incompatible nested sub-vendor paths were excluded by placing empty go.mod files, relying on the rule that modules cannot contain other modules. Post-migration maintenance revealed challenges with dependency inheritance and implicit go.mod updates during builds, which engineers investigated using go mod graph and digraph to trace dependency paths.

## Context

Managing dependencies in a large monorepo with multiple Glide lock files led to non-reproducible vendor directories, prompting Grab to adopt Go modules to align with official Go toolchains.

## Approach / What changed

Grab scripted the generation of go.mod files from Glide manifests, managed the vendor folder with go mod vendor, isolated conflicting nested paths using empty go.mod files, and inspected unexpected dependency updates using go mod graph.

## Takeaways

- A Go module cannot contain other modules, meaning Go ignores nested module directories when running commands at the monorepo root.
- Placing an empty go.mod file in problematic nested paths effectively excludes them from the root module's go mod vendor execution.
- Implicit updates to go.mod can occur automatically during standard commands like go build if broken imports or local replace directives exist.

**Tags:** [Go](https://yomu.fyi/topic/go), [Migrations](https://yomu.fyi/topic/migration), [Monoliths](https://yomu.fyi/topic/monolith)

[Read original post](https://engineering.grab.com/go-module-a-guide-for-monorepos-part-1)