I don’t think that skipping the “monolithic component” step will cause you any problems. The reason it’s suggested in the documentation is because the step doesn’t add much overhead, keeps the system in a functional state during the migration, and puts the code closer to where it should be in a single step.

First you migrate to a single base, and then you extract all code except the public API into a monolithic component. The result is one base and one component. Another way of doing it is to start with a base, and then tease out one component at a time from that base. Normally your codebase has some kind of public API and that’s the reason we recommend starting with a base.

Yeah, I am doing the latter

We had 4 big apps, we started by migrating 1 of them in as a base. Then using those learnings we migrated in the second, also as a base, and continued like that. We are now up to 4 bases and our components have organically started growing out of these. We do not plan to actively move everything into components, because it will be too much work, but as we build new things and touch existing things, we do it from the component perspective. This is working pretty well for us as we could keep on delivering features while gradually optimising the codebase. We did have to overcomes (and are still overcoming) some issues because of existing architecture in our bases, but these are more of a speed bump than a road block and we are also overcoming those as time goes on. All in all still very happy we moved over

I think we should skip the “monolithic component” step in the documentation. It’s better to keep the “mess” in the base while extracting to components. I add it to my todo list.

Without the monolithic component, the components you extract can’t access code in the base, which means you can only extract code in “the leaves”, that doesn’t depend on other components (alternatively, also extract the code it needs into components at the same time). I guess this is probably still a better alternative (in many cases) than having a huge monolithic component that exposes parts of its functionality in its interface to support extracted components.

Indeed there were some… dependencies that I needed to solve. I really wanted one piece of functionality out of the base, so I could share it with another (cli and api). Ended up doing 5 components in the first refactor to solve the internal dependencies. But I could have just as well taken it all into one component that still wouldn't have been as massive as the original monolith.

I like that now while my base is bloated, I know that the components make sense

Yes, I agree that it makes sense to keep all components clean.

I’ve updated the https://app.gitbook.com/o/-LAhrWK-mSHRqiTNUTDP/s/-LAhrWK1psIWk5h5zNLV/conclusion/should-you-convert-your-system so that we now suggest people to extract one component at a time from the base.