It's a Coke and Pepsi argument, both have their pluses and minuses. For me I can add in GitLab CI instructions to build for all the different platforms and make sure everything is good before releasing all at once.
Also so far I've really enjoyed doing one commit that represents a larger body of work. For example, I needed to make a Chrome extension and that doesn't just involve the extension package, it involves, the client package and the api package. So it makes sense to me to have centralized commits that represent the whole idea. It's easier for me to track things.
And each of these repos is technically a npm package. I am just not publishing them.
Also running git push origin master once just saves time rather than doing it 8 times. And having one PR/MR is easier to deal with for me. It's a larger PR/MR which is usually bad but in this case it doesn't cause conflicts because it's many separate packages.
Also by keeping the yarn link inside the repo the setup is easier. One clone and a link, and you are good to go. It means I can develop the common library at the same time as the client for example.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
It's a Coke and Pepsi argument, both have their pluses and minuses. For me I can add in GitLab CI instructions to build for all the different platforms and make sure everything is good before releasing all at once.
Also so far I've really enjoyed doing one commit that represents a larger body of work. For example, I needed to make a Chrome extension and that doesn't just involve the extension package, it involves, the
clientpackage and theapipackage. So it makes sense to me to have centralized commits that represent the whole idea. It's easier for me to track things.And each of these repos is technically a npm package. I am just not publishing them.
Also running
git push origin masteronce just saves time rather than doing it 8 times. And having one PR/MR is easier to deal with for me. It's a larger PR/MR which is usually bad but in this case it doesn't cause conflicts because it's many separate packages.Also by keeping the
yarn linkinside the repo the setup is easier. Onecloneand a link, and you are good to go. It means I can develop the common library at the same time as the client for example.// , I'm glad to see you want your git commits to tell a cohesive story. It's kind of what the Sand of Sky blog recommends:
sandofsky.com/workflow/git-workflow/