Sounds like you have a ‘core’ spa that lives in its own repo then
n number of other repos that apply facades to the SPA and ship it as a customer-specific version. Here’s what I’d recommend in that case.
For starters, you can make your own build script. If you make a file called
./build.js then tell netlify to use a build command like
node ./build.js, it’ll run that script as your “build” — it’s all very flexible. Additionally, since you can write your own build script, there’s nothing stopping you from using GitHub’s API to access other private repos and pull in code/files from them during build-time. Here’s a layout I’d recommend for you:
While I don’t know your architecture, I’ll give you the Gatsby.js analog since I know it well. That would give me a ‘core’ app and, let’s say 2 client/customer repositories. The idea here is that each client repository is empty except for a
gatsby-config.js file that needs to override the core config.
In your “core” repository, have a
./buildCustomerApp.js file that uses the GitHub SDK to pull down the
gatsby-config.js file from a repository whose name I specify as an ENV var… maybe
process.env.FACADE_REPO_NAME. Once it pulls the file down, it replaces the
gatsby-config.js that comes with the ‘core’ repo (either by full file replace or even json merge, since Gatsby’s config files are just js objects). Finally, the script runs the gatsby build (which should still take advantage of gatsby build caching, yay!)
Great! Now all you have to do is generate multiple Netlify Sites from that single ‘core’ repository, which Netlify lets you do. You can do the “New Site From Git” for the same site as many times as you’d like. The key here being that each site you generate, you set a different
FACADE_REPO_NAME environment variable. Then you end up with each site pulling the code from the ‘core’ repo but the build-script pulling the specific configuration from each client repository at build time.
Hope that makes sense and gives you an idea for how to move forward. Happy to chat more!