
#### Introduction

As companies grow and scale their applications, more and more teams start focusing more on improving their existing developer experience.

Faster build speeds, AI code integrations and preview environments started to appear more often on the backlogs of many projects. But, with applications increasing in size and becoming more complex, scaling the development processes can become a tough challenge.

In this post, we'll explore how teams can use NxCloud to speed up build times by storing task results for multiple applications in the cloud.

#### Using a build system

![A visualization of a large project with multiple applications handled by a build system](/images/content/sending-front-end-cache-artifacts-to-nx-cloud_1.jpg)

Nx is a build system that focuses on handling large monorepo projects. It allows developers to manage large codebases with multiple projects, and comes with a few great benefits:

- **Modularization** — breaking down large applications into smaller, manageable modules or libraries, making the project easier to maintain.
- **Dependency graph** — providing a visual representation of a project's dependency graph, helping developers get a better overview and manage dependencies more effectively.
- **Incremental builds** — ensuring that only the affected parts of the project are rebuilt, reducing build times and improving developer experience.

One of the key features of Nx is being able to cache task results, which decreases build times and cuts costs on resource usage.

#### How does caching work?

![A visualization of cache inputs and outputs](/images/content/sending-front-end-cache-artifacts-to-nx-cloud_2.jpg)

The caching mechanism used by Nx is based on **inputs** (e.g., source files, environment variables) and **outputs** (e.g., build artifacts).

If the same task is executed again with the same inputs, Nx can reuse the cached results instead of performing the task again.

![A visualization of Nx using local and cloud caching to store task results](/images/content/sending-front-end-cache-artifacts-to-nx-cloud_3.jpg)

By default, Nx stores cache artifacts locally. Local caching is fast as the cache artifacts are stored on the same machine. It's also easy to set up and requires no external dependencies.

In the project's `nx.json`, the `cacheableOperations` property specifies the list of tasks that are cached, and `cacheDirectory` sets the directory where cache artifacts are placed:

```json
{
  "tasksRunnerOptions": {
    "default": {
      "runner": "@nrwl/workspace/tasks-runners/default",
      "options": {
        "cacheableOperations": ["build", "test", "lint"],
        "cacheDirectory": ".nx/cache"
      }
    }
  }
}
```

#### Integrating NxCloud

Storing cache locally is great, but placing it in the cloud and sharing it across multiple environments is even better. To use NxCloud, you need to first install and set it up in your workspace.

###### 👉 Install NxCloud

In order to get NxCloud to work, you need to install it first as part of your project's `devDependencies`:

```shell
$ npm install @nrwl/nx-cloud --save-dev
```

###### 👉 Configure the `nx.json`

To get NxCloud to handle your cache, you need to set the runner to `@nrwl/nx-cloud` and provide your unique `accessToken`:

```json
{
  "tasksRunnerOptions": {
    "default": {
      "runner": "@nrwl/nx-cloud",
      "options": {
        "cacheableOperations": ["build", "test", "lint"],
        "accessToken": "your-nx-cloud-access-token"
      }
    }
  }
}
```

###### 👉 Run a task

If done correctly, all tasks that were specified in `cacheableOperations` should now be cached in the cloud using NxCloud.

By running the task multiple times, notice how it fetches the same cache artifact, as long as none of the inputs have changed:

```shell
// 1st try: No cache available
$ pnpm nx build application-1

// 2nd try: Fetched from cache
$ pnpm nx build application-1

// 3rd try: Fetched from cache
$ pnpm nx build application-1
```

#### What's next?

![A visualization of various areas where NxCloud can be used for caching](/images/content/sending-front-end-cache-artifacts-to-nx-cloud_4.jpg)

Using NxCloud is not only relevant for local development. Cloud caching of task results can be used across various environments, with the ability to share artifacts and prevent redundant reruns.

###### 👉 PR Previews

If your development process includes spinning up previews on PR creation, NxCloud can help a lot with making that setup even better by generating and reusing cached build artifacts, decreasing the build times and making sure changes are visible faster.

###### 👉 CI/CD Pipelines

By sharing cache artifacts between pipeline runs and preventing compiling the same code over and over, NxCloud can decrease resource usage and improve build times. If configured correctly, subsequent builds are not starting from scratch, but rather reusing previous build results, making the entire pipeline more efficient.

Here’s an simple example of a pipeline with NxCloud caching configured in GitHub Actions:

```yaml
name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install
      - run: npx nx affected --target=build --parallel --maxParallel=5
        env:
          Nx_CLOUD_ACCESS_TOKEN: ${{ secrets.Nx_CLOUD_ACCESS_TOKEN }}
```

#### Conclusion

When working on large projects, keeping the development process in good shape is essential for maintaining great developer experience.

Using Nx as a build system comes with many great benefits for teams that are working on multiple applications that are part of a monorepo. One of the powerful features that Nx comes with is the ability to store and retrieve task results as local or cloud cache artifacts.

By using cloud caching tools like NxCloud, teams can have faster builds and a more consistent workflow across local development, PR previews, and CI/CD pipelines.


Caching is cool, but can we make it even more awesome? Let's figure out how we can configure an Nx project to store cache remotely using NxCloud.

Sending front-end cache artifacts to NxCloud


#### 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.](/images/content/sharing-code-across-front-end-application_1.jpg)

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](/post/making-sense-of-package-dependencies).

#### Using build systems

![A visualisation of a build system serving a shared library to multiple applications](/images/content/sharing-code-across-front-end-application_2.jpg)

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](/images/content/sharing-code-across-front-end-application_6.jpg)

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](https://www.npmjs.com/).

[Link to docs](https://lerna.js.org/docs/introduction)

##### 👉 NX

![Nx - a build system with built-in tooling and advanced CI capabilities.](/images/content/sharing-code-across-front-end-application_7.jpg)

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](/images/content/sharing-code-across-front-end-application_5.jpg)

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](https://nx.dev/getting-started/intro)

#### 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.


Copy-pasting might be fun, but there are other ways to share code. Let's learn about different approaches for building shared libraries to share stuff across front-end applications.

Sharing code across front-end applications


#### Introduction

When developers are tasked with building and maintaining applications, they often have to deal with dependencies. Dependencies refer to the external libraries and packages that a project relies on.

As applications grow and scale, managing these dependencies might be tricky. In this post, we'll try to figure out the main differences between various `dependencies` fields and how those are supposed to be used.

#### Understanding dependencies

![A visualization of a UI library dependency that is used by multiple applications](/images/content/making-sense-of-package-dependencies_1.jpg)

In simple terms, dependencies are external pieces of code that applications can import and use. These can include libraries, frameworks, and other tools.

Front-end dependencies are managed by package managers like [NPM](https://www.npmjs.com/), [Yarn](https://yarnpkg.com/) or [PNPM](https://pnpm.io/). They automate the process of installing, updating, and removing packages by using the `package.json` file to figure out the project's dependencies.

The `package.json` file includes metadata about the project and specifies the dependencies needed for the project:

```json
{
  "name": "UI Library",
  "version": "1.0.0",
  "description": "A simple library",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve",
    "build": "webpack"
  },
  "dependencies": {
    "react": "^17.0.2",
    "three": "^0.165.0"
  },
  "devDependencies": {
    "webpack": "^5.24.0",
    "webpack-cli": "^4.5.0",
    "webpack-dev-server": "^3.11.2",
    "babel-loader": "^8.2.2",
    "@babel/core": "^7.13.1",
    "@babel/preset-react": "^7.12.13",
    "jest": "^29.7.0"
  },
  "peerDependencies": {
    "react": "^17.0.0"
  }
}
```

As you can notice, the `package.json` contains **3** fields that list dependencies. The dependencies listed in each field are meant to be separate, as they are used for different purposes.

![A visualization showing the 3 types of dependencies being present in a project](/images/content/making-sense-of-package-dependencies_5.jpg)

##### 👉 What are `dependencies`?

The packages listed as **dependencies** are essential for the application to run. They are included in the bundle of the application and are expected to be used in production. For example, `react` and `react-dom` are dependencies because the app cannot function without them.

##### 👉 What are `devDependencies`?

![A visualization of the different dependencies and devDependencies](/images/content/making-sense-of-package-dependencies_2.jpg)

The packages that are part of **devDependencies** are only required during the development phase. They help with testing, building, and linting but are not needed in the production build. Great examples are packages like `webpack` or `babel`.

##### 👉 What are `peerDependencies`?

![A visualization of the different dependencies and peerDependencies](/images/content/making-sense-of-package-dependencies_4.jpg)

If your library expects a certain dependency to be available in the consumer application, that dependency is placed in the `peerDependencies` field. This is useful for libraries that need to ensure compatibility with a specific version of a peer package, as it makes sure the dependency used will not be part of the compiled code.

![A visualization of multiple react applications using the same shared UI library](/images/content/making-sense-of-package-dependencies_3.jpg)

For example, if you are developing a React component library, you would list `react` as a peer dependency. This ensures that the library will work with the version of `react` provided by the application that uses the library. If another project installs your library, the package manager will warn if the peer dependency constraint is not met:

```json
"peerDependencies": {
  "react": "^17.0.0"
}
```

#### Conclusion

By understanding the differences between dependencies listed in your `package.json`, you can make sure that your project is configured correctly:

- **dependencies** — lists the packages required for the application to run in a production environment. For example, `styled-components` is often used as a styling tool, and it is required to be present in production to style the application correctly.

- **devDependencies** — contains the packages needed during the development and build process. `webpack`, `babel-loader`, and other packages are listed under this field because they are used to compile and bundle the code, but not required to be present in the production environment.

- **peerDependencies** — specifies packages that your project needs, but expects the consuming project to provide. This is mostly used for libraries and shared code.


When working with front-end packages, how do you differentiate between direct dependencies, peerDependencies and devDependencies? Let's find out!

Making sense of package dependencies


#### Introduction

As companies grow and scale, maintaining a unified UI across multiple projects becomes increasingly challenging. Many teams struggle with duplicated components, inconsistent designs, and redundant code across different applications.

To help solve these issues, some teams introduce design systems — a set of rules, guidelines, and sharable components that help unify the UI across projects. It might sound simple, but planning and developing a design system is a complicated task, as it depends heavily on the company's design processes, which might vary widely even from project to project.

#### What to look out for?

![The design system can be used to build any number of applications within an organization](/images/content/figuring-out-a-design-system-setup_1.jpeg)

Even though there is no "one size fits all" solution, there are some useful pointers to keep in mind, regardless of the company or the specifics of the project you are currently working on.

##### 👉 Detach applications from libraries

Having a well-defined architecture for a complex project is one key to ensuring the code does not become a bunch of spaghetti code. One effective way to maintain a clear hierarchical order is to split the projects into multiple independent packages.

The code that is shared (ex., design system) is extracted into a separate library, whereas the consumer (ex., landing page) remains a separate application. The library becomes the direct dependency of the application and is specified in the `package.json`:

```json
// landing-page/package.json

{
  "name": "landing-page",
  "dependencies": {
    "design-system": "1.0.0"
  }
}
```

```jsx
// landing-page/index.tsx

import { Button } from 'design-system';

const LandingPage = () => <Button>Buy now!</Button>;

export default LandingPage;
```

By organizing your projects and defining strict boundaries between libraries and applications, you can get some really great benefits:

- **Modularity** — both libraries and applications are independent packages that can be configured in different ways depending on the specific needs.
- **Maintainability** — adding changes becomes easier and more predictable.
- **Scalability** — adding, replacing, and removing libraries or applications is straightforward due to the hierarchical relationship.

##### 👉 Find the source of truth

![The design system can be the source of truth for both designers and developers](/images/content/figuring-out-a-design-system-setup_4.jpeg)

One of the ways teams can build stuff faster, is if all shared components can be found in one place — in the design system. They are defined in the code, versioned, and accessible to both developers and designers.

If done correctly, the design system ensures that all teams use the same components, guidelines, and rules. This helps reduce friction between designers and developers and significantly decreases the overhead of aligning across multiple projects.

##### 👉 Add flexibility where needed

As projects grow, so do the requirements. When receiving a complex task for a feature that includes some crazy designs, it might be tempting to respond: "If it is not in the design system, I am not implementing that!”. Sure, the design system might be the single source of truth, and those guidelines should be followed. On the other hand, the source of truth can be best compared to a living organism - it mutates, adapts, and changes.

A design system should allow for some flexibility, for example, by providing the ability to compose variants or pass custom themes to components. Consider a `<Button/>` component in your shared design system. This component can be customized with different themes in various consumer applications.

```jsx
// a-design-system/Button.jsx

import React from 'react';

const Button = ({ theme }) => (
  <button style={{ backgroundColor: theme.primaryColor }}>Click me!</button>
);

export default Button;
```

Each application can provide its own theme:

```js
// landing-page/theme.js

export const theme = {
  primaryColor: 'blue',
};
```

```js
// admin-interface/theme.js

export const theme = {
  primaryColor: 'red',
};
```

By allowing for flexibility in the design system, we can help the developers and designers collaborate better and build things much faster. 🔨

#### Visualize it!

![Storybook: Frontend workshop for UI development](/images/content/storybook.png)

Having the design system as a single source of truth defined in the code is great. But how can w give it life and transform it into a living and breathing organism?

[Storybook](https://storybook.js.org/) might be a perfect tool to visualize design systems:

- **Isolated** — implemented as a separate application, it can exist in parallel with your other projects.
- **Intuitive** — listing and documenting design system stuff like UI components, guidelines and rules is really easy and straightforward.
- **Flexible** — the addon features can help improve the development process with features like theming, viewport resizing, and more.

![The design system can be visualized using Storybook](/images/content/figuring-out-a-design-system-setup_3.jpeg)

By connecting a design system with a presentational tool like Storybook, teams get access to an independent instance of the design system that is always available to be inspected and played around with. This instance can even be shared internally within the organization or displayed publicly to the rest of the world! 🎉

#### Setting up the library

![The design system can be build as a compilable library](/images/content/figuring-out-a-design-system-setup_2.jpeg)

If a design system is structured as a separate library, it should be able to handle its own development processes. One of the most common ways of developing a design system is extracting it into a separate library, configuring the separate development processes, and finally setting up versioning and packaging.

Developing the design system as a standalone library brings several benefits:

- **Independent workflows** — having independent linting, testing, and compilation workflows ensures the design system library is self-contained and does not depend on other applications.
- **Separate dependencies** — having a separate `package.json` for the library, you keep full control over the direct dependencies and the supported versions.
- **Optimizations** — when compiling and packaging the library, you can manually configure and change the output bundle specifics to match your needs.

#### What about monorepos?

The approach above works well when projects are separated into multiple repositories. But what if your applications are built within a [monorepo](https://monorepo.tools)?

During last couple of years, I have been trying to figure out how to effectively share UI components across multiple projects that are part of the same repository. One of the best ways I found was introducing a shared design system library within the monorepo using **React**, **Storybook**, **PNPM**, and **Nx**.

Create the Nx workspace:

```shell
$ npx create-nx-workspace my-workspace
```

Add a shared library "ui":

```shell
$ npx nx g @nrwl/react:lib design-system
```

Add the Storybook interface:

```shell
$ npx nx g @nrwl/react:storybook-configuration --name=design-system
```

This setup contains all the benefits of having separate applications and libraries while remaining in the same repository.

#### Conclusion

Building a shared design system library is not an easy task. But, if equipped with the proper tools and processes, any team can succeed at creating a well-functioning setup.


How to effectively align the user interface across multiple projects? Let's figure out a better way to build a shared design system setup!

Figuring out a design system setup


#### Introduction

In this blog post, we'll explore a typical code quality setup, compare single projects and monorepos, and provide a step-by-step guide to setting up `husky`, `pre-commit`, and `lint-staged`. We'll also highlight the benefits of using a build system like Nx to manage code quality task execution across multiple projects.

#### Why enforce quality standards?

Maintaining code quality is an important task for any team working on the front-end. Whether it's a small application or a huge project, many developers prefer to have defined coding standards and automated processes to help keep things in order.

A good code quality setup helps achieve a couple of things:

1. **Consistency** — enforcing styling and coding standards makes the codebase more maintainable and readable.
2. **Reliability** — tests, linters, and type checkers catch errors before code is committed, reducing the chances of issues creeping into production.
3. **Developer Experience** — automated formatting and linting removes the manual overhead from developers, allowing them to focus on more important things.

#### Code quality setup

![A visualization of the most common code quality checks for a typical project](/images/content/enforcing-coding-standards-on-the-front-end_1.jpg)

Even though the setup depends on the team and project specifics, a typical setup often includes the following parts:

- **Type checking** — static type checking, catching type-related errors during development. Comes out of the box with a language like `typescript`.
- **Linters** — catching syntax errors and enforcing coding standards. Usually handled by `eslint` and `stylelint`.
- **Tests** — ensuring code behaves as expected. `jest` is a popular testing framework for most kind of projects.
- **Code formatters** — ensuring code is consistently styled. `prettier` is an opinionated code formatter that is considered the default when it comes to front-end development.

In smaller projects, ensuring code quality is relatively straightforward - all tools and configurations are contained within a single project. The setup is different though for monorepos, which house multiple projects or packages in a single repository. Each package usually has its own dependencies and configurations, so ensuring code quality across the entire monorepo requires additional efforts and a custom setup:

![A visualization of a monorepo setup with multiple applications and separate code quality checks](/images/content/enforcing-coding-standards-on-the-front-end_2.jpg)

#### What tools to use?

##### `husky`

This tool allows you to easily manage Git hooks within a project. Git hooks are scripts that run automatically on specific events in your Git workflow, such as before a commit or a push. `husky` simplifies the process of setting up and maintaining these hooks, making sure that certain tasks (like running linters or tests) are executed automatically.

[Link to docs](https://typicode.github.io/husky/)

##### `pre-commit`

This tool helps manage and maintain multi-language hooks. It allows you to specify a set of hooks that should run before a commit is made, ensuring that the process is aborted if certain checks are not successful. `pre-commit` works and integrates with many languages and tools, making it super useful in a code quality setup.

[Link to docs](https://pre-commit.com/)

##### `lint-staged`

This tool allows you to run linters on staged files in Git. This means that only the files that are about to be committed are checked, which can help developers avoid unchecked code being merged accidentally. `lint-staged` works well with `husky` and `pre-commit`, allowing you to create a complete quality check workflow.

[Link to docs](https://www.npmjs.com/package/lint-staged)

#### How to configure the setup?

##### 👉 Install the dependencies

First, we need to add `husky` and `lint-staged` to our development dependencies:

```shell
$ npm install husky lint-staged --save-dev
```

##### 👉 Initialize `husky`

Next, we need to execute the `install` command for `husky`. This command automatically adds some relevant changes and configs to your project:

```shell
$ npx husky install
```

Once done, we can execute the automatically generated `prepare` script that was added to `package.json`:

```shell
$ npm run prepare
```

This command will create a couple of files in your project. To make things work, we need to manually modify `.husky/pre-commit` to run `lint-staged`:

```sh
. "$(dirname -- "$0")/_/husky.sh"

npm lint-staged
```

##### 👉 Add a custom `lint-staged` config

To configure `lint-staged`, we need to add a `.lintstagedrc` file for each application. This file will make sure that we execute various checks depending on the type of file being committed:

```json
{
  "**/*.js": "eslint",
  "**/*.{css,scss}": "stylelint",
  "**/*.{js,ts,jsx,tsx,json,css,scss,md}": "prettier --write"
}
```

##### 👉 All done!

Once complete, the code quality setup for our project will look somewhat similar to this one:

![A visualization of a code quality system built with husky, pre-commit, and separate lint-staged configurations per application](/images/content/enforcing-coding-standards-on-the-front-end_4.jpg)

#### Introducing a build system

![A visualization of how the Nx build system can be used to run code quality tasks across projects in a monorepo](/images/content/enforcing-coding-standards-on-the-front-end_3.jpg)

Nx is a build system that offers many helpful tools for working with monorepos. It handles managing dependencies between applications, running tasks in parallel, and ensuring consistent configurations across multiple projects.

By integrating `husky`, `pre-commit`, and `lint-staged` with a powerful build system like Nx, you can execute commands across multiple applications and cache the outputs. This can significantly reduce the development time, as redundant tasks are not re-calculated, but fetched directly from the cache.

A build system like Nx can help scale task execution and maintain consistency across multiple applications, making it a great tool for managing large-scale monorepos.

[Link to docs](https://nx.dev/getting-started/intro)

#### Conclusion

Using `husky`, `pre-commit`, and `lint-staged` to (gently) enforce coding standards can help developers keep track of code quality and ensure code is merged only if the quality checks pass.

For individual projects and monorepos, automating repetitive tasks and ensuring coding standards can help prevent errors, reduce technical debt, and significantly improve the developer experience.


Following coding guidelines might be hard, especially on larger projects. Let's figure out a setup that enforces code quality standards using Husky, Pre-commit, and Lint-staged.

Enforcing coding standards on the front-end


#### Introduction

In this post, we will explore how to use tools like Vercel, PNPM, and Nx to build and deploy a multi-application monorepo. We'll cover the basics of each tool, the challenges of deploying single vs. multiple applications, and how to set up an effective deployment pipeline that works well with monorepos.

###### 👉 Vercel

Vercel is a cloud platform that helps developers deploy and scale modern web projects. It supports front-end frameworks like Next.js, React, Vue, and others. By providing CI/CD pipelines and serverless functions, Vercel makes it simple to deploy applications.

[Documentation](https://vercel.com/docs)

###### 👉 PNPM

PNPM (Performant NPM) is a fast, space-efficient package manager. When managing dependencies, PNPM stores them in a way that avoids duplications and reduces the overall storage space required. This is a very useful feature for monorepos with multiple projects, as it reduces the installation times significantly.

[Documentation](https://pnpm.io/motivation)

###### 👉 Nx

Nx is a popular build system that supports monorepos out-of-the-box. It provides powerful tools to manage, build, and test large codebases with multiple applications and libraries. Nx helps build development workflows, enforces best practices, and optimizes builds by having a clear overview of the project's dependencies.

[Documentation](https://nx.dev/getting-started/intro)

#### Deploying an application

![A visualization of a simple deployment process in a single application](/images/content/deploying-a-multi-application-monorepo-to-the-moon_1.jpg)

If you are working on a simple application, deploying it is pretty straightforward. The CI/CD pipeline focuses on one codebase, one set of dependencies, and one deployment target.

![A visualization of a complex deployment process in a monorepo](/images/content/deploying-a-multi-application-monorepo-to-the-moon_3.jpg)

A monorepo is composed of multiple applications and libraries within a single repository. Each application can be developed and deployed independently.

Many developers prefer monorepos because they have several advantages, including shared dependencies, consistent tooling, and easier code sharing. On the other hand, working on a large monorepo introduces challenges:

- **Dependency management** — ensuring all projects use compatible versions of shared dependencies.

- **Build coordination** — building and testing only the affected parts of the repository.

- **Deployment complexity** — managing deployment configurations and environments for multiple applications.

Luckily, combining Vercel, PNPM, and Nx might help with solving all three!

#### How to deploy in Vercel?

![A visualization of a simple deployment trigger in Vercel](/images/content/deploying-a-multi-application-monorepo-to-the-moon_4.jpg)

Vercel can be set up to trigger deployments on specific events, such as merges to the master branch. To do that, you might need to configure a couple of things first:

##### 👉 Enable automatic deployments

In the Vercel dashboard, you can enable automatic deployments for branches. Vercel will automatically deploy changes pushed to the configured branches.

##### 👉 Configure conditional task execution

You can use the Nx's `affected` commands to optimize deployments. Nx can determine which projects are affected by changes and Vercel can be configured to deploy only those.

```json
{
  "build": {
    "script": "nx affected:build"
  },
  "deploy": {
    "script": "vercel --prod"
  }
}
```

##### 👉 Integrate with Github Actions

To make sure that conditional deployments are properly configured, you can add a GitHub Actions workflow to integrate Nx and Vercel:

```yaml
name: Deploy

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Install dependencies
        run: pnpm install

      - name: Build affected projects
        run: npx nx affected:build --base=origin/main --head=HEAD

      - name: Deploy to Vercel
        run: vercel --prod
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
```

##### 👉 Configure routing

![A visualization of deploying multiple applications within a monorepo to multiple sub-domains](/images/content/deploying-a-multi-application-monorepo-to-the-moon_2.jpg)

Vercel supports deploying multiple applications from a monorepo using its built-in configuration. Each application can be assigned a unique sub-domain. You can specify the domains by adding the configuration to the `vercel.json` file at the root of your monorepo:

```json
{
  "projects": {
    "app1": {
      "src": "apps/app1",
      "alias": "app1.yourdomain.com"
    },
    "app2": {
      "src": "apps/app2",
      "alias": "app2.yourdomain.com"
    },
    "app3": {
      "src": "apps/app3",
      "alias": "app3.yourdomain.com"
    }
  }
}
```

In the Vercel dashboard, you can configure custom domains and link them to the respective sub-domains defined in `vercel.json`.

![A screenshot from the Vercel application that shows the domain configuration page](/images/content/deploying-a-multi-application-monorepo-to-the-moon_6.png)

#### Conclusion

Deploying applications might be complicated, especially when working with large monorepos. Luckily, by combining tools like Vercel with Nx and PNPM, you can prepare a setup for deploying monorepos containing multiple applications to individual targets, all while handling conditional task execution and deployment triggers.


Are you looking for a single deployment setup to handle multiple applications? Let's explore combining Vercel, Nx, and PNPM to handle releasing monorepos to production.

Deploying a multi-application monorepo to the moon


#### Introduction

In front-end development, a package manager is a tool that helps install, upgrade, configure, and remove external packages (dependencies) for your project.

Quite a few front-end package managers are available, each with its own developer community and unique set of features. The choice of a specific package manager can affect the installation speeds, package resolution efficiency, and ease of managing your project. Currently, the most popular front-end package managers are **NPM**, **Yarn**, and **PNPM**.

In this post, we'll try to determine which one might better fit your needs.

#### How are they similar?

![Top 4 similarities between NPM, Yarn, and PNPM package managers](/images/content/choosing-your-front-end-package-manager_1.jpg)

- **Dependency management** — all of them manage project dependencies, ensuring that the correct versions of packages are resolved and installed.
- **Package registry** — all of them use the [NPM registry](https://www.npmjs.com/) to fetch packages from.
- **Semantic versioning** — all of them support semantic versioning, which helps specify and resolve package versions correctly.
- **CLI Tools** — each manager comes with a command-line interface (CLI) that executes various useful commands.

#### How are they different?

![A visualization of the top 3 differences between NPM, Yarn, and PNPM package managers](/images/content/choosing-your-front-end-package-manager_2.jpg)

##### 👉 NPM (Node Package Manager)

- **Speed and performance** — it is traditionally slower than others due to its nested dependency structure (even though it has improved significantly in speed with recent updates).

- **Architecture** — it installs dependencies in a nested folder structure, which can lead to a larger `node_modules` folder and potential issues with deeply nested dependencies.

- **Additional capabilities** — it has integrated several useful features over time, including security audits and an improved `npm ci` command for faster, more reliable installs.

[Link to docs](https://docs.npmjs.com/)

##### 👉 Yarn

- **Speed and performance** — it was [created by Facebook](https://engineering.fb.com/2016/10/11/web/yarn-a-new-package-manager-for-javascript/) to address performance issues with that came with using **NPM**. It uses a parallel installation process, making it much faster than older versions of **NPM**.

- **Architecture** — it uses a flat dependency structure to avoid duplication of packages, which made the size of the `node_modules` folder smaller and resolved issues related to having a lot of nested dependencies.

- **Additional capabilities** — it has a couple of extra features like workspaces for monorepo management, deterministic installs (ensuring the same `node_modules` structure across environments), and a `yarn.lock` file that ensures consistent dependency versions across environments and developer machines.

[Link to docs](https://classic.yarnpkg.com/lang/en/docs/)

##### 👉 PNPM (Performant NPM)

- **Speed and performance** — it uses a unique approach to installing dependencies by creating a global store for all package versions, and linking them into the project's `node_modules`. This feature makes it known for its speed and efficient use of disk space.

- **Architecture** — instead of duplicating dependencies across projects, it uses symlinks to reference packages. This approach decreases disk space usage and significantly improves installation times.

- **Additional capabilities** — it supports advanced monorepo features through workspaces that ensure that packages are not resolved by accident from neighboring monorepo projects.

[Link to docs](https://pnpm.io/motivation)

#### Conclusion

Choosing the right package manager depends mostly on the size of your project, as well as any additional requirements you might have.

##### 🐠 For small pet projects

For simple projects that do not require any advanced features, **NPM** is often a good choice. It comes out of the box with `node.js` and makes starting a new project really easy. Its recent performance improvements make it a good fit for small applications and pet projects.

##### 🐋 For large and complex applications

For larger projects, a good choice might be **Yarn** — it supports workspaces, has deterministic installs, and is based on a flat dependency structure that can prevent many common issues related to dependency management.

On the other hand, I am also a huge fan of **PNPM** — its unique linking system ensures that dependencies are handled correctly, making it a great fit for monorepos with many applications and dependencies.

Understanding the similarities and differences of each package manager can help you figure out which might the best option for your next project!


Trying to pick the best package manager between NPM, PNPM and Yarn? Let's see if we can figure out which one might be a better fit.

Choosing your front-end package manager


#### Introduction

Nx is a build system containing many tools and functions to help optimize the development process of front-end applications. One of the powerful features Nx offers is task caching - caching the outputs of tasks and reusing them when the same task is run again.

In this post, we'll try to figure out how to cache your application task outputs using the Nx build system.

#### How does caching works?

![A visualization of the difference between "inputs" and "outputs" in Nx build system](/images/content/caching-and-busting-front-end-task-outputs_4.jpg)

The Nx caching mechanism is based on the idea of having a split between two main concepts:

- **Inputs** — the files, configurations, and environment variables that a task depends on. Inputs could include source code files, configuration files, and environment settings.
- **Outputs** — the artifacts produced by running a task. Outputs could be the generated static files, the `/public` directory, or other build artifacts.

Nx caches task outputs by creating a hash of the inputs. If the inputs did not change, Nx will skip the task execution and retrieve the existing cached output instead.

When you enable caching for your application using Nx, you can enjoy having:

- **Reduced build times** — by reusing cached outputs, Nx can significantly cut down on build times, speeding up your development workflow.

- **Resource efficiency** — by reducing redundant task executions, Nx can save computational resources and lower infrastructure costs of CI/CD pipelines.

- **Improved developer experience** — by having faster builds, you experience less waiting and a more efficient development setup.

#### How to configure caching?

Let's use a simple example of building a `Next.js` application with caching enabled for `build`, `lint`, and `test` tasks.

##### 👉 Create a workspace

First, you need to set up an Nx workspace by running:

```shell
$ npx create-nx-workspace@latest
```

##### 👉 Enable caching of tasks

To enable caching, you need to specify the `cacheableOperations` in your `nx.json` configuration. Here’s a basic configuration:

```json
// nx.json

{
  "tasksRunnerOptions": {
    "default": {
      "runner": "@nrwl/workspace/tasks-runners/default",
      "options": {
        "cacheableOperations": ["build", "lint", "test"]
      }
    }
  }
}
```

##### 👉 Configure targets and outputs

For caching to work correctly in your application, you need to specify which tasks should have their outputs cached. For a `Next.js` project, you might cache `build`, `lint`, and `test` operations:

```json
// package.json

{
  "nx": {
    "namedInputs": {
      "default": ["{projectRoot}/**/*"]
    },
    "targets": {
      "lint": {
        "outputs": [],
        "dependsOn": ["^build"]
      },
      "build": {
        "outputs": ["{workspaceRoot}/public"],
        "dependsOn": ["^build"]
      },
      "test": {
        "outputs": [],
        "dependsOn": ["build"]
      }
    }
  }
}
```

##### 👉 Done!

Once configured, running a command like `nx build your-application` will produce an output that will end up in the Nx cache storage. On the next run, Nx will use the latest cache if the inputs haven’t changed.

#### Invalidating the cache

![A visualisation of cache invalidation using the Nx build system](/images/content/caching-and-busting-front-end-task-outputs_3.jpg)

When dealing with cache, we also have to keep in mind cache invalidation. By default, Nx handles this by providing a default mechanism based on hashing the inputs. Cache invalidation is complicated and it might be tricky to ensure the cache reliably reflects the current state of your project:

- **Configuration changes** — if you changed any configurations (like `.babelrc` or `next.config.js`), you need to make sure the cache is cleared correctly.
- **Dependency updates** — if you update any dependencies in your project, this will most probably affect the output artifacts. Make sure you clear the cache if you make significant dependency updates.
- **Environment changes** — if your build uses environment variables, changes to them should invalidate the cache.

To manually clear the cache, you can run:

```shell
$ nx reset
```

#### What's next?

![A visualization of caching multiple application outputs in a monorepo using the Nx build system](/images/content/caching-and-busting-front-end-task-outputs_1.jpg)

Now that you have your basic caching set up using Nx, you might want to consider these enhancements:

1. **Enabling distributed caching** — you can use Nx Cloud to share cache across different machines. This can help a lot with optimizing the CI/CD workflows.
2. **Adding a custom configuration** — you can provide custom configurations and specify which tasks and files should be included or excluded from caching for more granular control.
3. **Searching for sneaky issues** — you can use Nx Cloud’s analytics to monitor cache hits/misses to optimize further.
4. **Automating cache management** — you can implement scripts to automate cache clearing based on specific triggers. This will help ensure your cache is always up to date.


How to prevent redundant compilations on the front-end? Let's figure out how to speed things up by storing and retrieving front-end task output cache artifacts using the Nx build system.

Caching and busting front-end task outputs

I'm Ievgenii and I write about front-end development, scaling web applications and fancy build tools.