Introduction

Working With Monorepos

Workspaces

Shared Configs

Frontend

Schema

Backend

Introduction and Getting Started

Analyzing

Designing the Customer-facing UI with TailwindCSS

Data Model

Analysis and Design

PostgreSQL Ranges

The Provider Table

The Booking Table

Modelling with advanced Postgres features

Tailwind CSS

Foundation

Frontend State

Shared Components

Select Day

Frontend UI

Introducing tRPC

Connecting to tRPC

Refining the tRPC setup

Connecting to the Database

Generating Zod schemas

Endpoints

Testing tRPC Endpoints

Testing With the Database

Testing Frontend

Testing

Completing the Select Date Page

Infrastructure for Ranges

Completing Booking

Connecting The Dots

Conclusion and extra resources

This comprehensive course will equip you with the skills and knowledge to build modern full-stack applications using TypeScript, TailwindCSS, tRPC, and PostgreSQL. You will learn how to create a robust and scalable application architecture, from the backend data layer to the frontend UI.

PostgreSQL

NodeJS

Knex

React

TypeScript

tRPC

Monorepos simplify code development and can be split when necessary.

Setting up npm workspaces in our monorepo

Setting up shared Typescript, ESLint and Prettier configs

Master full-stack development with a single repository for everything!

Learn the art of full-stack development with this comprehensive course. Through implementing the latest technologies and techniques, the course directly addresses the most common challenges full-stack developers face:
- **Code consistency and sharing:** Monorepos eliminate the need for multiple repositories, ensuring consistent code across your application and facilitating seamless code sharing.
- **Technology integration:** Learn how to integrate modern technologies like TypeScript, Tailwind CSS, and tRPC, empowering you to build robust and maintainable applications.
- **Database management:** Master advanced PostgreSQL features to optimize data storage, retrieval, and manipulation, ensuring a high-performance and scalable backend.

Build type-safe full-stack applications with database-centric strategies

This comprehensive full-stack development course covers monorepos, TypeScript, Tailwind CSS, tRPC, and PostgreSQL, empowering you to build modern, scalable applications. Structured into 7 modules of bite-sized lessons, each module is designed to be engaging and informative, combining video lectures, hands-on coding exercises, and real-world examples.

Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL

Writing PostgreSQL ranges for the application database.

Breaking down the UI to build it with Tailwind CSS

Master monorepos for streamlined development workflows and enhanced collaboration

Implement TypeScript for type-safe code that prevents errors and improves maintainability

Utilize Tailwind CSS to create consistent and beautiful user interfaces

Employ tRPC for seamless data exchange between frontend and backend

Harness advanced PostgreSQL features for optimized data storage, retrieval, and manipulation

Build modern, scalable full-stack applications using a unified approach

You will use a feature called workspaces and npm as package manager.

There are several others package manager to choose from with different tradeoffs. I chose npm simply because it's the standard and works well. Nothing in this course, including workspaces, relies specifically on npm; in fact, package manager Yarn was the first to offer native support for workspaces. Hence, feel free to use your favorite package manager. Just keep in mind that the CLI commands might vary.

Workspaces are a lightweight alternative to publishing packages to npm or another registry, allowing you to reference packages across folders in your repository.

Npm will ask us a series of questions. You can enter the details as you want or just press ENTER to set the to the default. Set 

 file for us. Open it and add the property 

 because this is not something we want to (accidentally) publish to the npm registry, and it's required for the workspaces feature to work.

We can now create a folder structure. It's a semi-standard to have a folder called 

 in the root that contains packages, some times combined with a folder called 

 for "packages" that aren't libraries but rather things that can be run. We will create two folders:

Now, the architecture for this course will rely on three packages: 

 package is responsible for database schema migration and types. It will go in the 

$ mkdir packages/schema
$ cd packages/schema
$ npm init --scope easybooking

It will ask you questions again. Since we gave it the scope parameter, it should suggest the name 

Let's create the backend package in the same manner:

$ cd ../..
$ mkdir services/backend
$ cd services/backend
$ npm init --scope easybooking

Answer the questions like you did for the 

Now that you have two packages in your repository, let's enable them as workspaces so they can reference each other.
Edit the 

 file in the root folder to look like this:

easybooking-monorepo

You've now set up your workspaces-based monorepo.

Some people like to use a wildcard here, like 

. I prefer to be explicit for the simple reason that the order of packages in the array matters.

In a moment, we will be making the backend depend on the schema. Thus, we want to build the schema before the backend. If using a wildcard, we can't control the order.

In order to reference the package, modify the 

@easybooking/backend

 in the root folder. This will install all dependencies which at this point is just 

. The schema package is "installed" as a symbolic link. Note that we are naming the package under the 

 by using the @-character and a slash. This is optional, but it decreases the risk that the name will collide with something in the Npm package repository. If that happens, the workspace name takes precedence but can still mean that if something goes wrong, you might end up installing something that you didn't intend to.

. This is only a requirement for the root package (or the workspaces feature will refuse to work), whereas it's optional for the other packages.

---
title: Workspaces
description: Setting up npm workspaces in our mono-repo
isPublicLesson: true
privateVideoUrl: https://stream.mux.com/68aHs4QThaM7h5NlsYAc1bXjYO1gx900CZgsT8o5vfaE.m3u8
code: https://gitlab.com/fullstackio/books/newline-course-apps/fullstack-typescript-with-tailwindcss-and-trpc-using-modern-features-of-postgresql-app/-/tree/main/module_01/lesson_01.03?ref_type=heads
---

## Workspaces

You will use a feature called workspaces and npm as package manager.

There are several others package manager to choose from with different tradeoffs. I chose npm simply because it's the standard and works well. Nothing in this course, including workspaces, relies specifically on npm; in fact, package manager Yarn was the first to offer native support for workspaces. Hence, feel free to use your favorite package manager. Just keep in mind that the CLI commands might vary.

Workspaces are a lightweight alternative to publishing packages to npm or another registry, allowing you to reference packages across folders in your repository.

To get started, we will create a `package.json` file in the root of your repository:

    $ npm init

Npm will ask us a series of questions. You can enter the details as you want or just press ENTER to set the to the default. Set `name` to be `easybooking-monorepo` and `license` to `UNLICENSED`.

This will create a `package.json` file for us. Open it and add the property `private: true` because this is not something we want to (accidentally) publish to the npm registry, and it's required for the workspaces feature to work.

We can now create a folder structure. It's a semi-standard to have a folder called `packages` in the root that contains packages, some times combined with a folder called `services` or `apps` for "packages" that aren't libraries but rather things that can be run. We will create two folders:

    $ mkdir packages
    $ mkdir services

Now, the architecture for this course will rely on three packages: `schema`, `backend` and `frontend`. The `schema` package is responsible for database schema migration and types. It will go in the `packages` folder. Let's create a folder and a `package.json` file for it:

    $ mkdir packages/schema
    $ cd packages/schema
    $ npm init --scope easybooking

It will ask you questions again. Since we gave it the scope parameter, it should suggest the name `@easybooking/schema`, which is what we want.

We will get into the details of the `schema` package later.

Let's create the backend package in the same manner:

    $ cd ../..
    $ mkdir services/backend
    $ cd services/backend
    $ npm init --scope easybooking

Answer the questions like you did for the `schema` package.

Now that you have two packages in your repository, let's enable them as workspaces so they can reference each other.
Edit the `package.json` file in the root folder to look like this:

```json
{
  "name": "easybooking-monorepo",
  "version": "1.0.0",
  "license": "UNLICENSED",
  "private": true,
  "workspaces": ["packages/schema", "services/backend"]
}
```

You've now set up your workspaces-based monorepo.

:::note
Some people like to use a wildcard here, like `"packages/*"`. I prefer to be explicit for the simple reason that the order of packages in the array matters.

In a moment, we will be making the backend depend on the schema. Thus, we want to build the schema before the backend. If using a wildcard, we can't control the order.
:::

In order to reference the package, modify the `package.json` file in the `backend` folder manually to look like this:

```json
{
  "name": "@easybooking/backend",
  "version": "1.0.0",
  "license": "UNLICENSED",
  "private": false,
  "dependencies": {
    "@easybooking/schema": "*"
  }
}
```

After doing this, run `npm install` in the root folder. This will install all dependencies which at this point is just `@easybooking/schema`. The schema package is "installed" as a symbolic link. Note that we are naming the package under the _scope_ `easybooking` by using the @-character and a slash. This is optional, but it decreases the risk that the name will collide with something in the Npm package repository. If that happens, the workspace name takes precedence but can still mean that if something goes wrong, you might end up installing something that you didn't intend to.

The backend package is not marked as `private`. This is only a requirement for the root package (or the workspaces feature will refuse to work), whereas it's optional for the other packages.


Setting up npm workspaces in our mono-repo

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL

Module 1: Introduction and Getting Started

Introduction:

Start Here

Lesson 1: (3:09)

Introduction

Lesson 2: (6:35)

Working With Monorepos

Lesson 3: (6:45)

Workspaces

Lesson 4: (17:56)

Shared Configs

Lesson 5: (9:27)

Frontend

Lesson 6: (16:20)

Schema

Lesson 7: (5:21)

Backend

Module 2: Analysis and Design

Lesson 1: (3:09)

Analyzing

Lesson 2: (4:04)

Designing the Customer-facing UI with TailwindCSS

Lesson 3: (2:49)

Data Model

Module 3: Modelling with advanced Postgres features

Lesson 1: (6:18)

PostgreSQL Ranges

Lesson 2: (16:10)

The Provider Table

Lesson 3: (4:47)

The Booking Table

Module 4: Frontend UI

Lesson 1: (1:25)

Tailwind CSS

Lesson 2: (7:58)

Foundation

Lesson 3: (21:53)

Frontend State

Lesson 4: (4:52)

Shared Components

Lesson 5: (16:13)

Select Day

Module 5: Endpoints

Lesson 1: (7:45)

Introducing tRPC

Lesson 2: (17:22)

Connecting to tRPC

Lesson 3: (7:22)

Refining the tRPC setup

Lesson 4: (7:28)

Connecting to the Database

Lesson 5: (4:56)

Generating Zod schemas

Module 6: Testing

Lesson 1: (4:33)

Testing tRPC Endpoints

Lesson 2: (25:00)

Testing With the Database

Lesson 3: (12:37)

Testing Frontend

Module 7: Connecting The Dots

Lesson 1: (21:07)

Completing the Select Date Page

Lesson 2: (14:07)

Infrastructure for Ranges

Lesson 3: (15:49)

Completing Booking

Module 8: Conclusion and extra resources

Lesson 1: (1:02)

Conclusion and extra resources

Workspaces