Skip to main content

How the Rebrand Engine Works

A step-by-step breakdown of the rebranding process.

Overview

Understanding the internal workflow of the rebrand engine can help you troubleshoot issues and extend its capabilities.

Execution Workflow

1. Initialization

The build-rebrand.sh script starts by setting up the environment, checking for prerequisites (Node.js, pnpm), and defining the source and destination directories.

2. Configuration Parsing

The engine reads the rebrand/settings.md file. It uses a combination of grep and sed (or a Node.js helper) to extract values for the app name, theme, and enabled features.

3. Workspace Preparation

The engine creates a fresh copy of the application in build/web/rebranded/. This ensures that the original source code remains untouched.

4. String Replacement

A global search-and-replace is performed across the entire rebranded workspace.

  • "LibreApps Desktop" -> [App Name]
  • "LibreApps" -> [Company Name]
  • "https://LibreApps Desktop.dev" -> [Website URL]

5. Theme Injection

The engine looks for the theme CSS in rebrand/themer/[ThemeName]/index.css. If a URL is provided, it fetches the theme first. The CSS is then injected into the application's global styles.

6. Asset Management

Custom logos, favicons, and background images are copied from rebrand/assets/ to the public/ directory of the rebranded application.

7. Navigation Logic

The rebrand-nav-logic.js script is executed to update the sidebar and navigation configuration files based on the enabled/disabled sections in settings.md.

8. Final Build

Once all customizations are applied, the engine runs pnpm build (or pnpm dev) in the rebranded directory to generate the final application.

Best Practices

  • Do this: Use the --verbose flag (if available) to see detailed logs of each step.
  • Do this: Ensure your settings.md file is saved before running the engine.
  • Don't do this: Interrupt the engine while it's running; it may leave the rebranded workspace in an inconsistent state.