Managing Multiple LookML Projects
In larger organisations, it's very common to have multiple LookML projects and employ a 'hub and spoke' architecture, with a core (hub) project and multiple child/satellite projects (spokes) which import its code for reuse, extension or refinement. There are a few articles and Looker community posts on this that are easy to find if you want to learn more about this.
It's a great way to centrally manage parts of your LookML while allowing different departments and teams some flexibility to develop their own models. It sadly also adds some complexity to managing and developing LookML, so here are a few tips that can help.
Understand the limitations
The Looker IDE is mostly only aware of the current project you're working on.
While the LookML validator will take account of any imported code from a hub project when you're working in a spoke project, the reverse isn't true. This means it's possible for changes in the hub project to cause previously-valid LookML in a spoke project to have errors!
Looker's recent LookML metadata feature also only works within a single project, so it's hard to find references between views etc between projects.
Find & replace in the IDE also operates only on the current project, which can mean some tasks can be a bit tedious and repetitive.
My suggestion for tackling all of these is to remember that Looker projects are git repositories. By cloning all your projects locally, you can easily use a text editor to search all of your LookML projects, find/replace etc. This is really handy for finding cross-project references.
It's a pain to have to manually enter each subdirectory and run git pull but you can use the below command to do this for you & ensure all of your local LookML is up to date:
$ find . -type d -depth 1 -exec git --git-dir={}/.git --work-tree=$PWD/{} pull \;\n
The validation issue is a bit trickier, but the Looker API has an endpoint to run project validation (and control the current git branch). Using this you could implement a simple script to run on merge/pull requests which would ensure that cross-project LookML validation errors are caught before your developers have this confusing problem!
Finally, it's likely that with multiple projects, and enforced Pull/Merge Requests (which you should always do...!) that you'll have different approvers and mergers for different projects. Make sure that there are enough people that it's always possible to get code changes reviewed and merged in all projects, otherwise you could find that a small issue could cause a big block for your developers and end users.
