Should you go for a monorepo or a poly-repo? Should you use a monorepo solution better suited for managing integrated applications or one better su...
For further actions, you may consider blocking this person and/or reporting abuse
Each approach has its pros and cons that's for sure, every company needs to analyze what's best for them.
As a rule of thumb, a software factory would probably benefit more from a monorepo whereas a product company with well-defined product lines will probably do better with a poly-repo approach.
Regarding the approach mentioned in the post I have a couple of concerns initially but I need to read it carefully later on (I'm rushing a bit now 😅)
Sounds pretty cool. I'm usually not a huge fan of absolute imports tho because VS Code doesn't automatically refactor them in case if I move the module being imported. Also I wonder if by using this system I'm being locked in into using Ripple CI? With NX, for example, I'm free to install it anywhere: local or on-premises and it will still do smart incremental builds. Another concern is type definitions in typescript packages. If I use separate packages - I will have to rebuild I order for d.ts files to get generated, so that I can use newly added export in another package, which can become annoying if you're working on multiple packages at once...
Anyway, looks like a cool concept, thanks for sharing 👍
Ripple is the default CI for Bit (and the recommended one) but you choose to run the components' build pipeline on any CI platform (you can read more about it in the docs.
Regarding the d.ts files - when a component is maintained locally, Bit ensures its corresponding package uses its source files for type resolution so that you don't have to re-generate the declaration files on every change.
Love the idea of autonomous modular repo-ish entities
I wasn't a fan of Monorepo's approach, though I have had to live with it in the past. This is super interesting since we can get the same benefits of a Monorepo in Polyrepos using Bit Components.