👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
I strongly agree. If you're going to use the same framework, a well-structured monorepo will help you a lot more. It should allow teams to work in isolation, only test, build, and deploy according to what has changed in their commits. It should guard them from making deep imports.
The only real use case for most organizations in my mind is if feature modules are not known at build time. JavaScript itself is very dynamic and even allows arbitrary dynamics imports. Out build tools and compilers are the issue here. Recently, a build tool provided a solution for a problem it introduced itself. Webpack Module Federation. This is just scratching the surface. Microfrontends bring a lot of complexity and challenges as mentioned in this insightful article.
Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
I strongly agree. If you're going to use the same framework, a well-structured monorepo will help you a lot more. It should allow teams to work in isolation, only test, build, and deploy according to what has changed in their commits. It should guard them from making deep imports.
The only real use case for most organizations in my mind is if feature modules are not known at build time. JavaScript itself is very dynamic and even allows arbitrary dynamics imports. Out build tools and compilers are the issue here. Recently, a build tool provided a solution for a problem it introduced itself. Webpack Module Federation. This is just scratching the surface. Microfrontends bring a lot of complexity and challenges as mentioned in this insightful article.
100% agreed, Lars. Monorepos are definitely the way to go!