Habitica

Certain static asset subfolders are excluded from Webpack processing. Because they are not processed by Webpack, their filenames are not hashed. These assets are cached by the browser for 1 week.

Affected subfolders:

• audio
• emails
• icons
• merch
• presskit

Important for updates: If you need to update an asset in one of these folders, you should change the filename to ensure the new version is fetched instead of the cached version. For implementation details regarding how these are served, refer to website/server/middlewares/static.js.

Data Persistence

MongoDB data is persistent. If you want to start with a fresh database, you must manually remove the EBS volume and re-create it.

AWS Instance Sizing

When running on AWS, it is recommended to use at least t2.medium minion nodes for your Kubernetes cluster. The default t2.small instances are insufficient for running more than two Habitica nodes.

The project follows a specific directory structure to maintain clarity between pages and reusable components:

• /src/pages: Contains page-level components. Each page can have its own subfolder containing sub-components that are only used by that specific page.
• /src/components: Contains reusable components that are shared across multiple different pages.

Best Practice: Avoid mixing pages and components in /src/components. Move page-specific logic to /src/pages and keep only truly global, shared components in /src/components.

This guide provides sample Kubernetes configuration files to launch Habitica on AWS. You can deploy it as either a single-node web frontend or a multi-node web frontend.

Prerequisites

• An AWS account.
• A working Kubernetes installation.
• A persistent volume for MongoDB data.
• Docker images of Habitica (you can use the ones included in the YAML files or your own).

Before you begin

1. Set up your Kubernetes cluster.
2. Create an EBS volume for MongoDB data and note its name for later configuration.

To run linting and automatically fix style issues, use the lint script.

npm run lint

To deploy a multi-node instance of the Habitica web frontend, run:

kubectl.sh create -f habitica-rc.yaml
kubectl.sh create -f habitica-service.yaml

Wait for the frontend pods to start up.

Habitica's translations are managed via an external translation platform at https://translate.habitica.com/.

To change any text in the application, follow these rules:

1. Edit only the American-English strings: All text changes must be made directly in the locales/en directory via GitHub.
2. Do not edit other locales: Never edit files in any other locale directory (e.g., locales/fr, locales/es). These files are automatically pulled from the translation platform.
3. Automatic Sync: Once you update the locales/en files, you do not need to request translations. Changes are automatically copied to the translation website on a regular basis for linguists to process.

Because spritesheet compilation is not part of the standard production build process (due to Heroku environment constraints), you must manually compile spritesheets whenever new images are added to the repository. Run the following command from the project root:

npm run sprites

To find the address of your deployment:

1. Run kubectl describe svc habiticaweb to retrieve the generated hostname for the service.
2. Open a browser and navigate to http://<hostname>:3000.

To shut down the deployment, delete the resources in reverse order of creation:

kubectl.sh delete -f habitica-service.yaml
kubectl.sh delete -f habitica.yaml # (or habitica-rc.yaml if using multi-node)
kubectl.sh delete -f mongo-service.yaml
kubectl.sh delete -f mongo.yaml