Sharing code across front-end applications

Introduction

When building applications, many developers focus on making sure the code they write is efficient and consistent. This might seem simple at first, but as a project grows it becomes harder to maintain. One way to tackle this issue is through code sharing.

When you abstract away and extract shared code, you reduce duplication and make the code more maintainable. Whether you're working on a small project or a large-scale application, sharing code is a good practice that comes with many benefits.

In this post we will look at some of the benefits, as well as the different approaches developers use when writing shared code.

Code sharing benefits

An illustration of multiple applications importing a shared library.

Code sharing is about reusing components, functions, and modules across different parts of an application or even across multiple applications.

By reusing code, you ensure that your projects can benefit from:

1. Consistency — ensuring that different parts of an application behave uniformly.
2. Reduced redundancy — writing the code once, instead of duplicating the same code across multiple places.
3. Easier maintenance — fixing issues in one place in the shared code, and having it resolve issues across all consumer applications.
4. Faster development — reusing existing code makes developing new features a lot faster.

Working with shared libraries

When preparing code to be shared, it is often hard to ensure it will work across multiple applications. Sure, you can make a shared function or a navigation bar component. But what about more complex things? Building shared libraries offers a more advanced approach to code sharing.

A shared library is a collection of reusable code that is maintained separately and can be versioned and distributed independently. Shared libraries are very useful when working on larger projects, and provide a few benefits:

• Centralized management — a single source of truth for shared code.
• Version control — ability to manage different versions of the library.
• Modularity — encapsulated functionality that can be moved around and integrated into various projects.

Developers often encounter challenges when building shared libraries. The most common include handling dependencies correctly, designing intuitive and consistent APIs, as well as maintaining compatibility with older versions of the library. Luckily, most of these challenges can be dealt with by following a couple of suggestions.

When creating shared libraries on the front-end, make sure you keep in mind some of these useful points:

• Break down the code into small, self-contained modules — this way you can independently update and maintain different parts of the library.
• Provide clear documentation for the library — this way you can help other developers use it across different projects.
• Write comprehensive tests — this will help you guarantee that the shared code works as expected in various environments.
• Use semantic versioning — this will help with managing updates and ensure compatibility across different projects, if you choose to publish and version your library.

To learn more about how to manage dependencies in a shared library, you can check out this other blog post.

Using build systems

A visualisation of a build system serving a shared library to multiple applications

When working on a large codebase, developers often have to ensure multiple applications are built, libraries are compiled and no issues happened in between. Because this is a tough task to do manually, many teams integrate and configure build systems to handle their projects needs.

Build system help organize larger projects, execute tasks across packages and applications, as well as provide various additional tools that significantly improve the developer experience.

👉 Lerna

Lerna - a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages

Lerna is a tool for managing projects with multiple packages. It helps with:

• Versioning — managing versions of packages automatically.
• Publishing — facilitating the publishing process to package registries like NPM.

Link to docs

👉 NX

Nx - a build system with built-in tooling and advanced CI capabilities.

NX extends the capabilities of other build systems. It provides more advanced tools for monorepo management, such as:

• Project Organization — splitting a project into libraries and applications.
• Task Execution — optimizing task execution with caching and parallel processing.
• Dependency Graph — visualizing dependencies between different parts of the project.

A visualization of a hierarchical approach to developing application using a build system

In a monorepo setup, NX structures the project into distinct libraries and applications. This separation enables:

• Code Reuse — libraries can be shared across different applications within the monorepo.
• Independent Development — teams can work on separate libraries without affecting the entire codebase.
• Caching and Task Synchronization — caching build results, synchronizing tasks, and speeding up the development process.

Link to docs

Conclusion

Knowing how to share code effectively is a useful skill to master, especially on a larger project. Many teams start building shared libraries to help extract common components and functions.

Building shared libraries might be a bit confusing in the beginning, but over time the benefits they bring to larger projects are definitely worth it.

There are great tools and approaches available to help developers share code across applications. By using build systems like Lerna and NX, teams can effectively manage dependencies, streamline builds, and maintain a clean and modular codebase.