Foundations of a Frontend Platform - Design System & Core Libraries
In order to make sure common, cross-cutting concerns are handled in a consistent way, you make sure you encapsulate the complexity of handling Design elements and working with your proprietary environment into shared libraries, used in all Frontend projects.
Design System
More and more organizations these days have their own Design System: a complete set of UI components and CSS classes/helpers to make sure their branding is consistently used throughout their Digital Experiences. Some completely build their own set of components from the ground up, others leverage Open Source libraries and only define their own styling on top of it. However you set it up, you need to make sure that all Frontends use this design system consistently.
Over time, companies change their Designs - usually more than once. Consider a merger or simply a renewed branding after some years of having the same colors or logo. Not only that, you also see seasonal changes in design. Think of Black Friday, Christmas, or 'Summer Collection' vs 'Winter Collection'. It happens more often than you think - or it happens less than your Marketing department would like to see.
If you have a consistent way of working with your Design System throughout all of your Digital Experiences, these changes can be made centrally and rolled out in lockstep so at any given point in time, your customers have one consistent experience - no breaks in Design in a Customer Journey. But if the implementation of your design is fragmented, and allows CSS overrides (to name one example), or has multiple implementations for every different framework that is used in your organization, simply changing the background color throughout all of your Frontend code can be a nightmare to implement or result in a horrible User Experience.
Custom Core Libraries
Core Libraries encapsulate the complexities of your environment and provide easy to use APIs. These are custom building blocks to be consumed by Product teams. There's usually a need to centralize infrastructural, cross-cutting concerns into Core Libraries.
A common example of this, that everybody understands, is Logging. You don't want every product team to build their own Client-side Logging service that talks to their Log server of choice, where everybody formats their log messages in their own way, using their own identifier to track what happened. These are typical things you want to have standardized throughout your entire organization in order to have full end-to-end traceability.
As another example, if you want live updates to be delivered to your Frontend application, you don't want every product team to set up their own way of handling WebSockets or other form of Server Push, but rather use a central service that is robust and secure, works with scaleable infrastructure on the server and uses central logging. The client-side library to handle Server Push, where Product features can easily hook into, can be built and maintained centrally by a Platform team.
And if you happen to be leveraging a Hybrid Mobile App, you may want to have a standard way of falling back to Web technology for functions you have built in Native technology and exposed on a Native bridge. Or a standard way of informing a user that a certain function is not available in the browser. Thus you may want to encapsulate this functionality into a Core Library that handles Native functions in a standardized way.
Depending on your setup, infrastructure and organization, you probably have specific items you want to offer to your product teams, in order to provide standardized, secure and compliant functionality that speeds up their development.