As it has been described in the section Penneo frontend codebase originally had been created as a multi repository project

As it has been described in the section Penneo frontend codebase originally had been created as a multi repository project, consisting of separate and independently versioned packages which were the following: `fe-auth`, `fe-branding`, `fe-casefiles`, `fe-forms`, `fe-translations`.
All of these packages were highly dependent on the `fe-application-loader` project which served as a loader package for them. All Penneo frontend packages were linked with the master project with npm link. The application loader project used to import also other dependencies among the others React packages: `react` and `react-dom`. The other Penneo packages did not have to install these dependencies even though they required them. The application loader used to create a code bundle using Gulp and Browserify. After creating the bundle all the packages together with the loader package would become as one so the React dependencies could be accessed by all the packages without explicitly including them in their own `node_modules` directory.

Snippet of package.json file from the `fe-application-loader` project
Usually splitting up large projects into smaller independent packages is a good idea. However in this case it was particularly bad solution due to the fact that all the separate packages were highly coupled so there was no actual reason for keeping them apart.
Furthermore the multi repository structure made the project very complicated to test.
When attempted to test `fe-casefiles` package, the Jest framework threw an error saying it could not find React dependencies because obviously that package did not have them installed. It could not have them because if it did, after creating a bundle an error would be thrown due to having two copies of React loaded. The difficulty level for creating simple tests have escalated very quickly as more errors appeared while trying to fix it.

A decision about changing a strategy has been made. Following some of the biggest projects out there like Babel, React, Angular or Jest a new idea came up. It was to organize all the packages into one multi-package repository. Lerna is a tool that helps to optimize a workflow for coping with this kind of projects.
Giving a shot to Lerna a new file structure has been created. Following the instructions from Lerna’s GitHub repository page all Penneo frontend packages have been moved into one common package, a new package.json file for this directory has been created and the whole directory has been turned into Lerna repo by creating lerna.json configuration file.
After….

Eventually a decision regarding merging frontend packages into one repository and making them as one project has been made. The idea of turning the not so well designed frontend microservice architecture into a monolithic project germinated because of the encountered issues relevant to cross repository testing mentioned above. Although there were a few more reasons for restructuring the web application.

The microservice approach in frontend web development is a good solution for applications that have multiple independent teams working on different modules because it helps to scale up quickly. In case of Penneo’s frontend the microservice architecture was first of all badly implemented due to the fact that packages were highly coupled, they were not entirely independent from each other. This specific architectural approach perhaps should not even be called microservices, as it seemed more like one application spreaded out into separate repositories.
Penneo’s frontend is being built and maintained by a small team of three developers – one senior and two junior developers so there is no need for flexibility to scale across multiple development teams. Size of the frontend team is not going to be expended much in the future. Furthermore spreaded out packages only added an extra complexity which tended to slow down development process instead of improving it as it usually takes place while doing microservices.