Monorepo - How to do frontend faster, better and safer - Kari Meling Johannessen - NDC Oslo 2023

At Norkart, we have a wide range of products and a history dating back to 1961. With such a large portfolio, it can be challenging to keep our systems up to date with our desired DevSecOps, technological, and universal design practices. Moreover, we often find ourselves re-creating the same components across different applications. The adoption of monorepo (built with NX and React) has helped us overcome these issues. We are just at the start of our monorepo journey, having used it for most of the new frontend-applications built the last 2 years but we are convinced that adopting monorepo as a companywide standard for frontend development will enable us to make frontend applications faster, better, and safer. Hear about our experience, challenges and ambitions and discover how monorepo can benefit your own development process.
Check out our new channel:
NDC Clips:
‪@ndcclips‬
Check out more of our featured speakers and talks at
ndcconferences.com/
ndcoslo.com/

[@webartem]

Today I started to learn monorepos to use it on my work. I am happy to find this keynote. Any other sources you could recommend on that topic?

[@Siddiskongen]

Yeah. Lots of lose claims and sales pitch for NX. Dealing with multiple application will have multiple stakeholders and project owners. When some dude/dudet does something clever to introduce a new feature when app-x have already testet their application and is ready to go to production, but suddenly have to delay it because of this or worse, notice bugs because it broke something. Having shared libs in some sort of package manager (npm, nuget etc) will let the applications depend on a version of a library and upgrade when it suites them. Developers making shared libs must be able to spot breaking changes and control release notes and versioning accordingly. Making refactoring on a library that breaks every application and the developer making the change has to fix thousands of lines of code will lead to developers not being motivated to refactor code. Thus, refactor the library, publish a new package with new major/minor version Then the developers upgrading the package is responsible to read the release notes and fix the code. Thus more people are aware of the changes done in the core libs. I like app specific repos. e.g containing the frontend, api and other application specific functions/tools in the same repo since all of them has to be deployed as a unit to keep the application consistent.

[@GBlunted]

First! Whoohooo! 🎉🤗🥳