Everywhere we build the JS, we asked Yarn to install itself twice:
yarn set version berry
yarn set version <the version from packageManager>
The first call fetches whichever release is "berry" today and the second
immediately replaces it, so every build made two downloads to end up with one
Yarn, and the one that could not be reproduced tomorrow was fetched first.
That first fetch broke CI outright on 17 August 2026, during a GitHub
incident, when it returned an empty body and Yarn 1 died writing it out:
error TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of
type string or an instance of Buffer, TypedArray, or DataView
at writeFile (node:fs:2373:5)
The unpinned call is dropped everywhere it appeared: Make.bat, the macOS and
pip package builds, and the four workflows. The packaging scripts keep their
pinned "yarn set version ${YARN_VERSION}", which still reads packageManager
from package.json, so their behaviour is unchanged beyond losing a download.
The workflows go further and use Corepack, which reads packageManager itself
and provisions exactly that Yarn without writing .yarnrc.yml and
.yarn/releases into the repository root, where the JS project is not. The
Dockerfile already installed and enabled Corepack immediately before both
"set version" calls, so both were redundant there and are simply removed.
CONTRIBUTING.md and README.md already tell contributors to start with
"corepack enable", so this brings the automation in line with the documented
setup. Note that Corepack ships with Node.js only up to (but not including)
25.0.0, so it will need installing explicitly once the runners move past it,
as the Dockerfile already does.
pgAdmin macOS Builds
Required Packages
Either build the sources or get them from macports or similar:
-
Yarn & NodeJS
-
PostgreSQL 12 or above from http://www.postgresql.org/
-
Python 3.6+ (required for building). The build environment should run this version of python in response to the python command.
Building
-
To bundle a different version of Python from the default of 3.14.7, set the PGADMIN_PYTHON_VERSION environment variable, e.g:
export PGADMIN_PYTHON_VERSION=3.13.11 -
If a path different from the default of /usr/local/pgsql for the PostgreSQL installation has been used, set the PGADMIN_POSTGRES_DIR environment variable appropriately, e.g:
export PGADMIN_POSTGRES_DIR=/opt/local/pgsql -
If you want to codesign the appbundle, copy codesign.conf.in to codesign.conf and set the values accordingly.
-
If you want to notarize the appbundle, copy notarization.conf.in to notarization.conf and set the values accordingly. Note that notarization will fail if the code isn't signed.
-
To build only DMG file, go to pgAdmin4 source root directory and execute:
make appbundleTo build both DMG and ZIP files, go to pgAdmin4 source root directory and execute:
make appbundle BUILD_OPTS="--zip"This will create the python virtual environment and install all the required python modules mentioned in the requirements file using pip, build the runtime code and finally create the app bundle and the DMG and/or ZIP in ./dist directory.