Choose React Dependencies for a Maintainable Component Library

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the The newline Guide to Building a Company Component Library course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to The newline Guide to Building a Company Component Library, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course The newline Guide to Building a Company Component Library

When creating any shared asset, the technologies that you choose will affect your consumers. This is especially true with front-end shared assets including component libraries. In this course, we will be choosing dependencies that allow our component library to be used in a wide variety of React code bases. Within NPM there are three types of core dependencies. Common dependencies, which are required by your application to be random production. Dev dependencies, which are only native for local development and testing. And peer dependencies, which consuming code bases are required to install. Some common peer dependencies would be React and React DOM, which is due to them requiring a single instance and they can't be duplicated across different modules. When it comes to front-end application styling, there are a variety of technologies to style content. SAS, LESS, and Post-CSS are just a handful of the popular solutions available that produce static CSS. Component libraries can also use the same technologies, but providing static CSS for consumers can create complicated styling scenarios. Common problems include style specificity and ensuring that the component styles don't affect any other styles within the consuming application. Asset management and providing non-JavaScript assets may require consumers to customize their build configurations to use your component library and bundle size impacts. With CSS, you often have to include a single file with all required styling. This negates some of the size savings that can result from tree shaking components that you're not using. For component libraries, CSS and JS is a common solution for these problems. It allows us to create our styles in the same way that we develop or react components and have all the benefits of being able to be tree shakeable as well . In this course, we will be using style components as our CSS and JS library. If your organization uses a different library like Emotion, these same concepts will apply. TypeScript is another technology that we're going to be using. It is a typed superset of JavaScript that helps find errors at build time. It's not only a benefit to us as library authors, but can also help document components for TypeScript and JavaScript consumers. If developers are using VS Code or any other TypeScript to wear editor, they will have auto-completion and prop descriptions even if they're not using Type Script. [BLANK_AUDIO]