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
--verboseflag (if available) to see detailed logs of each step. - ✅ Do this: Ensure your
settings.mdfile 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.