Files
unleash/contributing/backend/overview.md
Christopher Kolstad 78eb6ad911 task: migrate to pnpm (#11898)
Things worth noticing (+14075, -20262 most of this is due to yarn.lock
being deleted, and a new package manager tool being checked in)

## Code changes (actual changes to ts files)
### Not interesting
- being explicit about test imports in frontend rather than using
tsconfig globals to resolve `describe`, `it`, `test`, `expect` et al.
### Interesting
- Type signatures resolutions have changed a slightly bit, so some of
our Knex queries needed to be extracted for tsc to manage to type
analyse and pass type checking. All tests are green, so I'm assuming I
managed to reproduce the behaviour, in particular
src/lib/features/project/project-read-model.ts has some extra variables
to pass typechecking.


### Other considerations
- Do we still build the way we did? (pnpm pack produces the same
files/artifact as yarn pack)
- Will this merge cleanly with enterprise (which runs prepack)?

#### Known unknowns
- I've changed our vite.config.mts in frontend to use vite's own built
in tsconfigpaths, but Thomas pointed out that he tried that already and
ran into some issue when enterprise used the dependency, so we'll need
to double check that it works, and be ready to rollback to using the
deprecated plugin (and accept that vite gives us a warning that this is
now native functionality).

### Build failures
- Expected is openapi validation on main, we've changed to using pnpm
action rather than yarn action so it won't recognize yarn as a
packageManager on main
- dependency scanner, due to how pnpm resolves dependencies, we now have
a more direct dependencies, which our scanner apparently is scoring too
low for it to be OK with them. These were already a dependency, just
transitively rather than direct, so I'm comfortable with this.
2026-05-06 12:17:17 +02:00

3.8 KiB

title
title
Back end

The backend is written in nodejs/typescript. It's written as a REST API following a CSR (controller, service, repository/store) pattern. The following ADRs are defined for the backend:

ADRs

We have created a set of ADRs to help guide the development of the backend:

Requirements

Before developing on this project you will need two things:

  • PostgreSQL 14.0+
  • Node.js v22.0+
corepack enable
pnpm install
pnpm dev

PostgreSQL

To run and develop Unleash, you need to have PostgreSQL 14.0+ locally.

Unleash currently also works with PostgreSQL v14.0+, but this might change in a future feature release, and we have stopped running automatic integration tests below PostgreSQL 14. The current recommendation is to use a role with Owner privileges since Unleash uses Postgres functions to simplify our database usage.

Create a local Unleash database in Postgres

Start the ready-to-use Postgres container (first run builds a small image that executes the required SQL automatically):

$ docker compose -f docker-compose.postgres.yml up -d

The container exposes Postgres on localhost:5432 with the expected role and databases already created. Stop it with docker compose -f docker-compose.postgres.yml down.

If you prefer to run the SQL manually outside of Docker, you can execute:

$ psql postgres <<SQL
CREATE USER unleash_user WITH PASSWORD 'password';
ALTER USER unleash_user CREATEDB;
CREATE DATABASE unleash WITH OWNER unleash_user;
CREATE DATABASE unleash_test WITH OWNER unleash_user;
ALTER DATABASE unleash_test SET timezone TO 'UTC';
SQL

Then set env vars:

(Optional as unleash will assume these as default values).

export DATABASE_URL=postgres://unleash_user:password@localhost:5432/unleash
export TEST_DATABASE_URL=postgres://unleash_user:password@localhost:5432/unleash_test

PostgreSQL with docker

If you don't want to install PostgreSQL locally, you can spin up an Docker instance. We have created a script to ease this process: scripts/docker-postgres.sh

Start the application

In order to start the application you will need Node.js v22.x or newer installed locally.

// Install dependencies
pnpm install

// Start Unleash in development
pnpm dev

// Unleash UI
http://localhost:3000

// API:
http://localhost:3000/api/

// Execute tests in all packages:
pnpm test

Database changes

We use database migrations to track database changes. Never change a migration that has been merged to main. If you need to change a migration, create a new migration that reverts the old one and then creates the new one.

Making a schema change

To run migrations, you will set the environment variable for DATABASE_URL

export DATABASE_URL=postgres://unleash_user:password@localhost:5432/unleash

Use db-migrate to create new migrations file.

> pnpm run db-migrate create YOUR-MIGRATION-NAME

All migrations require one up and one down method. There are some migrations that will maintain the database integrity, but not the data integrity and may not be safe to run on a production database.

Example of a typical migration:

/* eslint camelcase: "off" */
'use strict';

exports.up = function(db, cb) {
  db.createTable(
    'examples',
    {
      id: { type: 'int', primaryKey: true, notNull: true },
      created_at: { type: 'timestamp', defaultValue: 'now()' },
    },
    cb,
  );
};

exports.down = function(db, cb) {
  return db.dropTable('examples', cb);
};

Test your migrations:

> pnpm run db-migrate up
> pnpm run db-migrate down

Publishing / Releasing new packages

Please run pnpm test checks before publishing.

Run npm run publish to start the publishing process.

npm run publish:dry