Files
directus/docs/contributing/running-locally.md
Connor 92621429ee Linting and Formatting Upgrade (#18892)
* add docs to eslint

* update prettier ignore

* fix vitepress linting

* eslint ignore fixes

* prettier run

* update prettier ignore

* fix formatting

* enable linting of markdown files

* revert format command change

* fix irregular whitespace

* update dictionary

* (Changelog) Create four-boxes-shake.md

* Rework ESLint / Prettier setup

- Disable js/ts/vue files for Prettier to ensure linting/formatting is
  only happening via ESLint
- Rework formatting of code blocks in md files
  - Disable formatting of code blocks in md files under '/docs' by Prettier
  - Instead use "eslint-plugin-markdown" to format & __lint__ js*/ts*/vue such code blocks
  - Replace unmaintained "eslint-plugin-md" plugin by official "eslint-plugin-markdown" plugin
  - I'll check whether we can use this to format other code blocks
    (json, html, ...) as well
- Restructure, clean-up and apply some fixes to the ESLint config
  (Note: Not ready for flat config yet since not supported by
  vscode-eslint)
- Enable cache for ESLint / Prettier in scripts
- Clean-up ignore file
  - Explicit folder declaration (.../)
  - Don't ignore all 'extensions' folders in ESLint (only
    '/api/extensions/')
  - Enable formatting in '/.github' folder

* Fix all formatting issues with Prettier

* Update md files under /docs/.typedocs

* Fix lint issues in vue/js files

* ESLint / Prettier config revision v2

Enable Prettier for md code blocks, but only as warnings since it can
get into the way with Vitepress md extensions like '[!code ...]'
comments

* Remove prettier-ignore comments

* Make spellchecker happy

* Remove changeset

* Revert lint setup for code blocks

There are many cases in the docs where linting / formatting of code
blocks doesn't make
sense:
- Code block is only an excerpt - linter fails
- Code block contains special comments (e.g. markdown extensions) which
  needs to remain at the same place - formatting would break it
- ...

* Apply lint issues / formatting from temp lint setup

* Run formatter

* Fix merge failure

* Simplify & modernize ESLint / Prettier setup

No longer run Prettier via ESLint. Nowadays, this is the recommended
setup. There's no real need to run it this way, it's just an additional
layer.

Add VS Code settings to make the work with the new setup easier.

* Remove unused eslint disable directives

* Make editorconfig more useful

* Fix formatting issues reported by editorconfig

* Format files with Prettier

* Enable formatting of source translations file

* Format source translations file

* Remove unnecessary console error

* Remove unnecessary line

* Only ignore md files under .changeset

* Add CI reporter for Prettier

* Fail job on wrongly formatted files

* Fix format

* Test Prettier action on changed/added file

* Use simple CI format check for now & no cache

* Revert "Test Prettier action on changed/added file"

This reverts commit 4f7d8826ad.

* Introduce code blocks check for docs

* Fix code block issues

* Ignore auto-generated packages dir

* Fix comment position

* Also lint `/app/.storybook`

* Reformat modified files

---------

Co-authored-by: Pascal Jufer <pascal-jufer@bluewin.ch>
Co-authored-by: Rijk van Zanten <rijkvanzanten@me.com>
2023-06-29 11:54:01 +02:00

6.1 KiB

description, readTime
description readTime
This guide explains how to install the _Development_ version of Directus locally so that you can work on the platform's source code. 4 min read

Running Locally

This guide explains how to install the Development version of Directus locally so that you can work on the platform's source code. To install the Production version locally, please follow to our Docker Guide.

::: tip Minimum Requirements

You will need to have the latest version of Node to build a Development version of Directus.

You will also need to have the package manager pnpm installed.

:::

1. Fork the Directus repository

Go to the repository and fork it to your GitHub account. A fork is your copy of the Directus repository which allows you to freely experiment with changes without affecting the original project.

2. Clone from your repository

git clone git@github.com:YOUR-USERNAME/directus.git

3. Make a new branch

git checkout -b YOUR-BRANCH-NAME

4. Install the dependencies and build the project

pnpm install
pnpm build

5. Setup Local Configuration

Create a .env file in /api

Create an .env file under the api folder using vars from the online config help.

::: tip Config Values

The KEY& SECRET config options from Security are mandatory.

Also the Database Configuration must be specified. You might want to use the docker-compose.yml file to spin up a test database.

:::

Upload/Extensions Folder

If you are using the local storage driver, your files will upload to /api/uploads. If you are locally developing extensions from the extensions folder, that folder should be located at /api/extensions.

6. Initialize the database

For this step, you'll need to already have a SQL database up-and-running, except if you're using the SQLite driver, which will create the database (file) for you.

::: tip Admin Account

Adding the ADMIN_EMAIL & ADMIN_PASSWORD to the .env file before running the bootstrap command, will populate the admin user with the provided credentials instead of random values.

:::

To start the initialization run the following command:

pnpm --filter api cli bootstrap

This will set-up the required tables for Directus and make sure all the migrations have run.

7. Start the development server

You can run all packages in development with the following command:

pnpm --recursive dev

::: warning Race Conditions

When running multiple or all packages, sometimes ts-node may not start up the API properly because of race conditions due to changes happening to other packages. You can either rerun the command to restart the API or opt to choose what packages to work on as described below.

:::

If you wish to choose what packages to work on, you should run the dev script for that package. You can see their names and list of scripts in their related package.json.

Example of running the API only:

pnpm --filter api dev

If you want to work on multiple packages at once, you should create a new instance of your terminal for each package. Example of running both the API and App at the same time:

Terminal 1 [Api] Terminal 2 [App]
pnpm --filter api dev
pnpm --filter app dev

::: tip

If you encounter errors during this installation process, make sure your node version meets the minimum requirements

:::

8. Make your fixes/changes

At this point you are ready to start working on Directus! Before diving in however, it's worth reading through the introduction to Contributing.

Debugging The App

There are several ways to debug the app but the easiest way to do it is with the Vue Devtools. It's recommended to use the Vue Devtools with Chrome.

::: tip Computed Debugging

To debug computed properties, it can be helpful to have a look at this Vue Guide.

:::

Debugging The API in VS Code

To debug the API, we recommend to use Visual Studio Code with it's built in debugger.

  1. First you need to setup the config for the debugger. Create the following file ./directus/api/.vscode/launch.json and paste in the following structure.
{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "node",
			"request": "launch",
			"name": "Debug Api",
			"skipFiles": ["<node_internals>/**"],
			"cwd": "${workspaceFolder}/api",
			"runtimeExecutable": "pnpm",
			"runtimeArgs": ["run", "dev"]
		}
	]
}
  1. Make sure that you have caching disabled as it otherwise returns the cached response. To disable this, go to your .env file in the API and set CACHE_ENABLED to false.

  2. In the tsconfig.json, set sourceMap to true.

  3. Now you can start the API by going to the debugger view in VS Code, select to debug the API and press Start Debugging. This runs the API and allows you to set breakpoints.

9. Running tests

Tests run automatically through GitHub Actions. However you may wish to run the tests locally especially when you write tests yourself.

Install Docker and ensure that the service is running.

# Ensure that you are testing on the lastest codebase
pnpm build

# Run the unit tests
pnpm test

# Clean up in case you ran the blackbox tests before
docker compose -f tests/blackbox/docker-compose.yml down -v

# Start the necessary containers for the blackbox tests
docker compose -f tests/blackbox/docker-compose.yml up -d --wait

# Run the blackbox tests
pnpm test:blackbox