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