Welcome to the nx nestjs starter-kit 👋 This template tries to shed light on our nx-conventions and make it easier to get started.

The nest portion of this repo has a few features to get you started more easily:

• i18n translations
• i18n translated errors
• basic module structure
• prisma implementation
• a typesafe env config module
• some super fast pino http logging
• automatic request validation
• custom nest lib generation plugin

I've intentionally left out the authentication part, as there is a good tutorial on the nestjs website. Our authentication needs oftentimes differ a lot, as we are sometimes behind auth proxies and need to handle headers and other times we have to implement a custom full-blown auth solution.

I just left in the express-session package as it might come in handy in more api projects just to keep track of different requesters. You can rip it out though. Make sure to also remove all excess tables from the prisma schema if you do so.

• You'll need docker and docker-compose (or docker compose).
• The node version is pinned to the current lts version of node which is 18 as the time of writing. (I recommend using n for node version management)
• This repo uses pnpm as package manager, which has to be major version 8. Read up about how to install it here. The recommended way is to use corepack which comes pre-installed with node.
• Some basic understanding of nx would be good to being able to better grasp the whole concept - there are a lot of short introduction guides and videos to get you started.

If you just seeded your project with this template you need to follow some basic setup steps. If somebody already set up the project you can skip this section.

• you have to rename all instances of "@nestjs-starter" with your project name. There is a convenience script in the root of the project which you can use (./setup_repo.sh -new "@your-new-project"), otherwise you can just search-replace it yourself.

• install your dependencies via pnpm install in the root of the repo
• to get started you can simply copy the .example.env file to a fresh .env file located in the root AND ./apps/api folders. The root env is for docker-compose and the api env is for the nestjs app.
• make sure to execute docker-compose up -d (first start your Docker Desktop application if you're on a Mac) in the root folder to spin up your database, if you have set up your .env correctly compose should pick up your settings
• execute the command pnpm prisma:migrate:dev to initialize the database and generate the prisma client.

If you have done all those steps you can start your application by executing pnpm nx serve or pnpm nx serve api which will start an auto hot reloading development server. You can also use the npm scripts via executing pnpm start or pnpm run start:api. If no project is specified nx will default to the api project.

All the most important commands are located in the "scripts" section in package.json.

One of the greatest features of nx is that it sees which libs/apps are affected by your changes and only applies actions to those affected libs/apps.

If you want to see your affected libs/apps just type in the following command

pnpm nx affected:graph

If you paid close attention, all the lint and build commands work with the "affected" part to save you some time to not having to test/lint/build projects you didn't touch.

Nx has a few different schematics to generate different kinds of libraries/apps from react to next or even nestjs.

This project contains a custom nestjs library generation command which already adds our standard config without having to consider that yourself. It's invoked by executing the following command:

pnpm gen:lib:nest name-of-lib

If you want to pass parameters, you have to use an extra double hyphen (thanks npm 🙄) like this:

pnpm gen:lib:nest name-of-lib -- --directory=api --dry-run

• npm invokes the nx cli with our custom generator
• @nestjs-starter/workspace:nest-library indicates that our custom schematic is used, and we want to generate a nest-library.
• "name-of-lib" is the name of the library we want to create
• --directory lets us modify the directory where we want to generate our lib/app
• you can also append --dry-run to test out your command without changing anything

If you happen to have generated a wrong lib you can always look at the workspace.json file in the root and just remove the lib you just generated via this command:

pnpm rm:lib name-of-lib

You can also move libraries with the following command:

pnpm mv:lib -- --project name-of-lib --destination api/new-name-for-lib

Don't forget the double -- after the npm command though 🧐

If you want to know more about all available commands, nx' website has some great docs to get started

If you generated a new library WITHOUT our custom plugin make sure to go to the lib/app root directory and add the respective tag to it in the project.json. You can use existing libs as starting point. In the root .eslintrc.json there are some rules which lib/app tags can import other tags or also cannot.

An example would be that the scope:backend-app can only import from scope:backend-core to prevent the generation of circular dependencies right out of the box.

This repo contains a starting template implementation of a nestjs app called api.

Basically in all nx repos apps should only be an empty shell that import all code from a library. The full folder structure can be seen below.

This project aims to build a base general nx starter scaffolding for apps that use NestJS as API and maybe expand to some more apps in the future.

The most important module is the core module, as it bundles all important code into one "entry-point" module which is then imported by the api app. This repo works with eslint module boundaries which make sure, that the app can only import code from the core module library. Every piece of code that should be exposed to the app must be re-exported through the core module.

nestjs-starter
├── apps
│   ├── api-app-name
│   └── frontend-app-name
└── libs
    ├── api
    │   ├── types                     (lib)
    │   ├── app                       (lib)
    │   │   ├── middlewares           (dir)
    │   │   ├── filters               (dir)
    │   │   └── decorators            (dir)
    │   └── modules
    │       ├── feature-1             (lib)
    │       ├── feature-2             (lib)
    │       └── feature-3             (lib)
    ├── frontend
    │   ├── util                      (lib)
    │   ├── types                     (lib)
    │   └── components                (lib)
    ├── frontend-shared
    │   ├── util                      (lib)
    │   ├── types                     (lib)
    │   └── components                (lib)
    └── shared
        ├── util                      (lib)
        └── types                     (lib)

If you're using a graphical git user interface program, make sure your node/npm is in your PATH before this program is opened. This repo uses git hooks that are executed on pre-commit and pre-push. You could also use --no-verify but then you'll not be able to merge your code into the repo as the ci will prevent you from merging non-linted code that maybe has type errors.