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

One of the advantages of monorepos is sharing configurations across packages, which is especially useful for ESLint and TypeScript configs.

Before we do that, though, let's initialize your repository and add a 

There are several ways to go about this. You could create a package that contains the configs and then reference it from the other packages. You could also create a folder in the root of the repository that contains the configs and then reference them from the other packages. For now, simply leave them in the root folder.

Start with TypeScript. First, install it as a dependency in the root of the repository:

Create a configuration file for typescript. You could do this using 

 of shared configurations which I like to use.

With this available, you can simply reference it from your own configuration file. Create a 

 file in the root folder that looks like this:

{
  "extends": "@tsconfig/recommended/tsconfig.json"
}

Now, there are a lot of configuration options for TypeScript and going into those details is out of scope for this course. The default settings will do fine for now. You will, however, want to add two things to the 

{
  "extends": "@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "baseUrl": "./packages" /* Specify the base directory to resolve non-relative module names. */,
    "paths": {
      /* Specify a set of entries that re-map imports to additional lookup locations. */
      "@easybooking/schema": ["packages/schema"]
    }
  }
}

This will enable "go to definition" and other features in our IDE to work across packages. It will also allow you to import packages using the 

Now, to configure TypeScript in our backend package, manually add a 

This file tells TypeScript to use our shared configuration, but specifying the output folder and the root folder for the package. We will do something similar for the schema package. Create the following 

As you can see, this is almost the same, except we also specify that it should create declarations. This is because we are using it as a "library" from your services, so we want access to the types from there. You have set the output folder to 

{
  // ..other options
  "main": "dist/index.js",
  "types": "dist/index.d.ts"
  // ...
}

Prettier is a code formatter that automatically formats code to a consistent style. Install it as a dependency in the root of the repository:

Using Prettier or any other code formatter is a matter of personal preference. If you are not used to it, be forewarned that you will probably not like it initially. They say: "Everyone hates what Prettier does to their code, and everyone loves what it does to their colleagues' code," which I find to be true. After a while, you will start to rely on it and won't live without it.

Prettier allows precious little configuration. Will create a 

{
  "semi": true,
  "singleQuote": true
}

This is the way I personally like my code to be formatted. You can find the full list of options 

Many people think of linting as a way of enforcing formatting rules, and since we have Prettier, we do not need it, right? Well, while it's true that ESLint can enforce formatting rules, and we will be using a plugin to enforce Prettier to run on everything, linting is a lot more powerful than that.
I think of linting rules as "architecture assertions" we want to enforce to structure our code in a way that makes it easy to maintain and extend. For example, we could want to enforce that all our functions are pure, that we don't use 

 in production code. These are all things that ESLint can help us with. Furthermore, writing custom linter rules is surprisingly easy and very beneficial as soon as you are a team. I wrote a 

Install ESLint as a dependency, as well as a few plugins for it in the root of the repository:

$ npm i eslint eslint-plugin-prettier eslint-config-prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin

Create a configuration for ESLint called 

You'll also want to create a file called 

This sets up ESLint to use the TypeScript parser and the recommended rules for TypeScript. It also enables the Prettier plugin, which checks that the code looks how it wants it to. We will get more into the rules later.

Now, you'll create a script for running ESLint on everything in our repo. Add the following to the root 

{
  // ... other items

  "scripts": {
    "lint": "eslint . -f visualstudio --report-unused-disable-directives --ext .ts,.tsx"
  }
}

This will run ESLint on all TypeScript files in the repository. Two things to note here:

---
title: Shared Configs
description: Setting up shared TypeScript, ESLint and Prettier configs
isPublicLesson: true
privateVideoUrl: https://stream.mux.com/jp4mo8cxX2Re64KBD02sV7J4Wdxz01f4e00NaKTMLLyReM.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.04?ref_type=heads
---

## Shared Configs

One of the advantages of monorepos is sharing configurations across packages, which is especially useful for ESLint and TypeScript configs.

Before we do that, though, let's initialize your repository and add a `.gitignore` file to it. You can create it using [gitignore.io](https://gitignore.io) and specify `node`.

There are several ways to go about this. You could create a package that contains the configs and then reference it from the other packages. You could also create a folder in the root of the repository that contains the configs and then reference them from the other packages. For now, simply leave them in the root folder.

## TypeScript

Start with TypeScript. First, install it as a dependency in the root of the repository:

```bash
$ npm i typescript
```

Create a configuration file for typescript. You could do this using `tsc --init`, but there is a [repository](https://github.com/tsconfig/bases) of shared configurations which I like to use.

```bash
$ npm i @tsconfig/recommended
```

With this available, you can simply reference it from your own configuration file. Create a `tsconfig.json` file in the root folder that looks like this:

```json
{
  "extends": "@tsconfig/recommended/tsconfig.json"
}
```

Now, there are a lot of configuration options for TypeScript and going into those details is out of scope for this course. The default settings will do fine for now. You will, however, want to add two things to the `compilerOptions` section:

```json
{
  "extends": "@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "baseUrl": "./packages" /* Specify the base directory to resolve non-relative module names. */,
    "paths": {
      /* Specify a set of entries that re-map imports to additional lookup locations. */
      "@easybooking/schema": ["packages/schema"]
    }
  }
}
```

This will enable "go to definition" and other features in our IDE to work across packages. It will also allow you to import packages using the `@easybooking` namespace.

Now, to configure TypeScript in our backend package, manually add a `tsconfig.json` file to the `services/backend` folder:

```json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "lib": ["ESNext"],
    "outDir": "./dist"
  },
  "include": ["./src"]
}
```

This file tells TypeScript to use our shared configuration, but specifying the output folder and the root folder for the package. We will do something similar for the schema package. Create the following `/packages/schema/tsconfig.json` file:

```json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "lib": ["ESNext"],
    "outDir": "./dist",
    "declaration": true
  },
  "include": ["./src"]
}
```

As you can see, this is almost the same, except we also specify that it should create declarations. This is because we are using it as a "library" from your services, so we want access to the types from there. You have set the output folder to `dist`, so update `packages/schema/package.json` to reflect this:

```json
{
  // ..other options
  "main": "dist/index.js",
  "types": "dist/index.d.ts"
  // ...
}
```

## Prettier

Prettier is a code formatter that automatically formats code to a consistent style. Install it as a dependency in the root of the repository:

```bash
$ npm i prettier
```

:::tip
Using Prettier or any other code formatter is a matter of personal preference. If you are not used to it, be forewarned that you will probably not like it initially. They say: "Everyone hates what Prettier does to their code, and everyone loves what it does to their colleagues' code," which I find to be true. After a while, you will start to rely on it and won't live without it.
:::

Prettier allows precious little configuration. Will create a `.prettierrc` file in the root of the repository:

```json
{
  "semi": true,
  "singleQuote": true
}
```

This is the way I personally like my code to be formatted. You can find the full list of options [here](https://prettier.io/docs/en/options.html).

## ESLint

Many people think of linting as a way of enforcing formatting rules, and since we have Prettier, we do not need it, right? Well, while it's true that ESLint can enforce formatting rules, and we will be using a plugin to enforce Prettier to run on everything, linting is a lot more powerful than that.
I think of linting rules as "architecture assertions" we want to enforce to structure our code in a way that makes it easy to maintain and extend. For example, we could want to enforce that all our functions are pure, that we don't use `any` as a type, or that we don't use `console.log` in production code. These are all things that ESLint can help us with. Furthermore, writing custom linter rules is surprisingly easy and very beneficial as soon as you are a team. I wrote a [blog post](https://kristiandupont.medium.com/are-you-using-types-when-you-should-be-linting-e9369404ef5b) that discusses this further.

Install ESLint as a dependency, as well as a few plugins for it in the root of the repository:

```bash
$ npm i eslint eslint-plugin-prettier eslint-config-prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin
```

Create a configuration for ESLint called `.eslintrc.json` in the root of the repository:

```json
{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 2017,
    "sourceType": "module",
    "project": "./tsconfig.json"
  },
  "plugins": ["@typescript-eslint", "prettier"],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "no-unused-vars": "off",
    "no-undef": "off",
    "@typescript-eslint/no-unused-vars": [
      "error",
      { "argsIgnorePattern": "^_", "varsIgnorePattern": "^_" }
    ],
    "@typescript-eslint/no-explicit-any": "off"
  }
}
```

You'll also want to create a file called `.eslintignore` in the root of the repository:

```text
node_modules
dist
```

This sets up ESLint to use the TypeScript parser and the recommended rules for TypeScript. It also enables the Prettier plugin, which checks that the code looks how it wants it to. We will get more into the rules later.

Now, you'll create a script for running ESLint on everything in our repo. Add the following to the root `package.json`:

```json
{
  // ... other items

  "scripts": {
    "lint": "eslint . -f visualstudio --report-unused-disable-directives --ext .ts,.tsx"
  }
}
```

This will run ESLint on all TypeScript files in the repository. Two things to note here:

-   We are using the `--report-unused-disable-directives` flag. This will report any ESLint rules that are disabled but not used anywhere in the code. Linter rules can be ignored with comments which I think is a good thing. But it's easy to forget to remove them when you are done. This flag will help us keep our code clean.
-   We are using the `--format` flag to specify the output format. You are using the `visualstudio` format, which will show us problems in a way that we can click on them in the terminal and go directly to the file and line where the problem is. If you use a different editor, you might want to leave this out.


Setting up shared TypeScript, ESLint and Prettier configs

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

Shared Configs