I'm working on a Swift-project (an iOS-app) where a webview is used to show an HTML-document. This document is manipulated by some JS, which is compiled and minified from TypeScript. There's also SASS being compiled to CSS.

There's obviously quite some building going on here. There's also quite a bit of package management. Both parts use separate builders and package managers, and would in some circumstances be viewed as entirely separate projects. They're however inseparable.

How does one - when a project like this becomes more complex with even more parts to it - manage this?

Should the build scripts from one part be forked onto the build script from the other part? If so, which should be considered the main one? Or would you write a custom build script that manages the entire project?

What about gits? Should the entire project be a single git-repo? It could be split up, but changes in one part would mean changes in another part as they work together, so how do you keep this clear with multiple gits?

1 Answer 1


If both projects are inseparable, then there is no point in trying to keep them in different repos. Having two different repos would make sense if one project could evolve independently of the other, and would potentially be used by other projects as a dependency. In this case, it seems that you are talking about very specific, custom parts of a project that belong together.

Once you accept that both parts belong to the same project, it becomes clear that you or any developer in your team will need a single build script to kick start the project. It's ok and even desirable to have one boot script for each part if that makes it easier to understand and maintain each one, but adding a third, more general script that just combines the other two and allows a developer to get started with one command would be really helpful.

Sometimes you will design custom components for your own application that would be good candidates for being released on their own. At Smylen, we sometimes design custom UI components for our Vue frontend because we can't find anything that is simple enough for our use case. When we do so, we release these in separate repos. However, this adds an extra level of complexity when we need to make changes to these components, because even if no one is using them besides us, we do need to keep a minimum of consistency in the design of the interface of the component, ensure its backwards compatible, etc. It's a fun task for the Engineers, but some Project Managers would say it's a waste of time and would prefer to keep everything coupled in the same project/repo.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.