- Download track data for flights
- Manage logbook
- Get tour statistics
Typical docker-compose.yml
:
version: '3.8'
services:
contour:
image: 'keenanrnicholson/contour:local'
container_name: contour
restart: unless-stopped
volumes:
- /path/to/db/folder:/db
- /path/to/file/folder:/files
environment:
PUID: 1000
PGID: 1000
ORIGIN: 'http://localhost:5173'
TZ: 'America/New_York'
ports:
- '5173:3000'
Contour is not designed to be accessible to the public internet. A reverse proxy such as traefik or Nginx Proxy Manager should be used if https
is required. Access to Contour should be confined to your local network or intelligently managed.
Contour is based on SvelteKit, and therefore is developed using vite
. Development for Contour is done inside a developmental Docker image.
If first-time:
# Switch to correct version of node using `nvm`
nvm use
# Install prisma globally
npm i prisma -g
# Create the database file
npx prisma db push
Create the dev image and start a local development session:
# Start dev environment
make dev
Build the project and serve it locally without creating the full Docker image:
# Build to node-adapter and preview result
make preview
Create the Docker image and serve it locally:
# Build the full image and host it locally
make create-local && make local
In all of the above cases, the front-end URL is http://localhost:5173/
Contour uses prisma
for database (sqlite
) access and management, with the schema stored in prisma/schema.prisma
. When the dev environment is loaded, prisma
expects the database to already exist. In the production environment, prisma
performs database migrations and will create the database if it does not exist. An automatic database migration is not performed in dev to allow database schema modifications and experiments without creating an official database migration.
# Check the prisma format
npx prisma format
# Push the changes to the DB. This may delete DB data.
npx prisma db push
# Check the prisma format
npx prisma format
# Create a migration & push the changes to the DB
npx prisma migrate dev --name v0.0.0 # Changes this version
# Check the resulting migration file in `/prisma/migrations` to make sure it will do what is expected during the migration
During development, a node_modules
folder is created in the top-level directory. Note that the libraries within are not necessarily compatible with your local machine, as they were installed within the Docker container environment. This means that if npm i
is ran outside the Docker container, the incorrect libraries will be loaded by the dev environment. If issues are encountered with respect to dependencies, delete the node_modules
folder and try again to allow the container environment to install the correct libraries.
All source code is in src
, with lib
and routes
being the primary development folders.
Directory Client/Server Description
───────────────────────────────────────────
src
├─lib
│ ├─components C # Svelte components
│ ├─events C # Client-side event library
│ ├─helpers S/C # Client-side and server-side helpers
│ ├─server S # Primary server code
│ │ ├─helpers S # Server-side helper functions
│ │ ├─prisma S # Prisma instance
│ │ └─settings S # Settings sub-system
│ └─types S/C # Shared client-side and server types
└─routes S/C # Front-end routes and API endpoints
└─api S/C # Front-end API endpoints
There are some differences between the dev environment and the production environment. The primary difference applicable to development is hot-reloading. Since vite
watches for changes in files, and the dev Docker container is mounted to the local file directory, changes in code will trigger a reload in the dev environment. This makes for very efficient development, as the container does not have to be restarted to reflect changes. However, the hot-reload is not an actual reload. The following are some examples of async code server-side that will still exist after the hot-reload:
setTimeout
andsetInterval
functions- The processes created by
child_process.spawn(...)
and similar - Anything stored in
global
During development, it is often useful to see more logs. Activate debug
in settings
to increase the verbosity of console logs. Use the debug
level setting in code when appropriate:
const debug = await settings.get('system.debug');
if (debug) console.log('Debug message here!');