This guide is for installing a local development copy of Ghost from source, primarily for the purpose of modifying Ghost core
Before getting started, you’ll need these global packages to be installed:
Then install these global packages
yarn global add knex-migrator ember-cli
Create GitHub fork
First you’ll need to make a fork of the Ghost repository. Click on the fork button right at the top, wait for a copy to be created over on your personal GitHub account, and you should be all set!
The main Ghost repository is a monorepo containing the full Ghost code, including the Admin client and default theme which will also be automatically set up
# First clone Ghost with submodules and make it your working dir git clone --recurse-submodules firstname.lastname@example.org:TryGhost/Ghost && cd Ghost
Properly rename your references
# Rename origin to upstream git remote rename origin upstream # Add your fork as an origin, editing in <YourUsername>! git remote add origin email@example.com:<YourUsername>/Ghost.git
Run setup & installation
# Only ever run this once yarn setup
setup task will install dependencies, initialise the database, set up git hooks, and initialise submodules.
# Run Ghost in development mode yarn dev
Ghost is now running at http://localhost:2368/ - Ghost Admin lives at http://localhost:2368/ghost/
Stay up to date
When your working copies become out of date due to upstream changes, this is the command that brings you back up to the latest
# Update EVERYTHING yarn main
That’s it, you’re done with the install! The rest of this guide is about working with your new development copy of Ghost.
When running locally there are a number development utility commands which come in handy for running tests, building packages, and other helpful tasks.
The most commonly used commands for running the core codebase locally
# Default way of running Ghost in development mode # Builds admin files on start & then watches for changes yarn dev # Ignores admin changes yarn dev:ghost # Ignores server changes yarn dev:admin # Run Ghost, Admin and the Portal dev server yarn dev --portal
Ghost uses its own tool called
knex-migrator to manage database migrations.
# Wipe the database yarn knex-migrator reset # Populate a fresh database yarn knex-migrator init
Building Ghost from source
From the top-level directory of the monorepo, run
This will produce a tarball archive called
ghost-<version>.tgz, which can be installed with Ghost-CLI’s
Tests run with SQLite. To use MySQL, prepend commands with
# Run unit tests yarn test:unit # Run acceptance tests yarn test:acceptance # Run regression tests yarn test:regression # Run a single test yarn test:single path/to/test.js # Run a folder of tests yarn test:single test/unit/helpers # Run all tests yarn test:all # Make sure your code doesn't suck yarn lint
Client tests should always be run inside the
ghost/admin directory. Any time you have
yarn dev running the client tests will be available at
# Run all tests in Chrome + Firefox ember test # Run all tests, leave results open, and watch for changes ember test --server # Run tests where `describe()` or `it()` matches supplied argument # Note: Case sensitive ember test -f 'gh-my-component' # Run all tests in Chrome only ember test --launch=chrome # Most useful test comment for continuous local development # Targets specific test of area being worked on # Only using Chrome to keep resource usage minimal ember test -s -f 'Acceptance: Settings - General' --launch=chrome
Some common Ghost development problems and their solutions
ERROR: (EADDRINUSE) Cannot start Ghost
This error means that Ghost is already running, and you need to stop it.
This error means that the mentioned file doesn’t exist.
ERROR Error: Cannot find module
Install did not complete. Run
Error: Cannot find module ‘./build/default/DTraceProviderBindings’
You switched node versions. Run
ENOENT: no such file or directory, stat ‘path/to/favicon.ico’ at Error (native)
Your admin client has not been built. Run
TypeError: Cannot read property ’tagName’ of undefined
You can’t run
ember test at the same time as
yarn dev. Wait for tests to finish before continuing and wait for the “Build successful” message before loading admin.
When rebasing a feature branch it’s possible you’ll get conflicts on
yarn.lock because there were dependency changes in both
- Note what dependencies have changed in
dev-1was added and dev dep
git reset HEAD package.json yarn.lock- unstages the files
git checkout -- package.json yarn.lock- removes local changes
yarn add dev-1 -D- re-adds the dependency and updates yarn.lock
yarn remove dev-2- removes the dependency and updates yarn.lock
git add package.json yarn.lock- re-stage the changes
git rebase --continue- continue with the rebase
It’s always more reliable to let
yarn auto-generate the lockfile rather than trying to manually merge potentially incompatible changes.