Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/bastndev/Lynx-Theme-Pro/llms.txt

Use this file to discover all available pages before exploring further.

Lynx Theme Pro welcomes contributions of all kinds — whether you want to craft a new color theme, add SVG icons, or improve the documentation. All active development happens on the dev branch, and every PR should target that branch. Before you start, read the Architecture guide to understand how themes, icons, and the Liquid Glass engine fit together.

​
Prerequisites

Read the Architecture guide first. It explains the directory layout, how the 8 themes are structured, how the SVG icon pool is mapped, and how the esbuild pipeline compiles the Liquid Glass engine. Knowing this context will save you time and ensure your contribution lands in the right place.

​
Quick Start

1

Fork the repository on GitHub

Visit github.com/bastndev/Lynx-Theme-Pro and click Fork to create your own copy of the repository under your GitHub account.
2

Clone your fork

git clone https://github.com/YOUR-USERNAME/Lynx-Theme-Pro.git
3

Switch to the dev branch

cd Lynx-Theme-Pro && git checkout dev
All contributions must be based on dev, never on main.
4

Open in VS Code and launch the Extension Development Host

code .
Press F5 to open the Extension Development Host — a sandboxed VS Code window where your local changes are live. You can switch themes, inspect icons, and verify behavior in real time without installing anything.

​
Contribution Types

Location: src/themes/Naming: Lynx-[Name]-theme.jsonBase type: vs-dark for dark themes, vs for light themes.Copy an existing theme JSON as your starting point — for example, 01_Lynx-Dark-theme.json for a dark variant or 02_Lynx-Light-theme.json for a light one. The file must follow the standard VS Code color theme schema with these top-level keys: $schema, semanticClass, semanticHighlighting, name, type, colors, and tokenColors.The numeric prefix (01_ through 08_) controls the alphabetical sort order in VS Code’s theme picker. If you are adding a brand-new theme, you do not need a prefix unless you are explicitly adjusting display order. Do not renumber existing prefixes without a good reason — it breaks muscle memory for existing users.Current themes for reference:
#NameType
01DARKDark
02LIGHTLight
03NIGHTDark
04GHIBLILight
05FURYDark
06KIRODark
07NVIMDark
08LIQUIDDark + Glass
Test your theme against at least TypeScript, Python, Dart, and Rust source files before submitting. Check syntax highlighting, comments, strings, and UI chrome (sidebar, status bar, tabs) in each.
SVG files: src/assets/svg/JSON mappings: src/icons/icon-themes/ (Style A — dark, Style B — light, Style C — gray)All three file/folder icon styles share the same SVG pool, so adding a single SVG makes it available to all three styles once you add the mapping. Follow this naming convention strictly:
  • name-file.svg — file icon
  • name-folder.svg — closed folder icon
  • name-folder-open.svg — open folder icon
After adding your SVG(s), open the relevant style JSON(s) and map the icon under the appropriate key:
  • fileExtensions — map by file extension (e.g., "ts", "py")
  • fileNames — map by exact file name (e.g., "Dockerfile", "AGENTS.md")
  • languageIds — map by VS Code language identifier (e.g., "typescript", "rust")
  • folderNames / folderNamesExpanded — map by folder name
You only need to update the styles you want to support; it is acceptable to add to just one style if the others already have adequate coverage.
The documentation source files live in the repository root. Target files for documentation contributions are:
  • README.md — main extension readme shown on the VS Code Marketplace
  • ARCHITECTURE.md — codebase deep dive
  • CONTRIBUTING.md — contribution guidelines
  • CHANGELOG.md — version history
Screenshots go in public/screenshots/themes/ or public/screenshots/icons/ and are referenced in the README via GitHub raw URLs. They are not bundled in the VSIX package — the public/ directory is stripped by .vscodeignore.If you are adding new translated documentation, place it in public/docs/ following the existing naming pattern (e.g., README_DE.md, README_JA.md). The extension currently supports 11 languages: AR, DE, ES, FR, HI, JA, KO, PT, RU, VI, and ZH.

​
Build Commands

Before submitting a PR, verify your changes compile cleanly. Run commands in this order: lint → check-types → compile/package. 
npm run lint        # ESLint — checks code style and catches common errors
npm run check-types # tsc --noEmit — TypeScript type checking without emitting files
npm run compile     # Development build → dist/
npm run watch       # Watch mode — rebuilds on file changes during active development
npm run package     # Production build (runs vscode:prepublish via esbuild --production)
The compile and package commands both invoke esbuild.js, which produces two separate outputs: a CJS bundle for the extension host and an ESM .mjs bundle for the Electron runtime. CSS files from src/themes/liquid-theme/css/ are automatically copied to dist/ after each build.

​
PR Guidelines

  • Target the dev branch — never open a PR against main. The maintainer promotes dev to main for releases.
  • Keep PRs small and focused — one theme, one icon set, or one documentation fix per PR. If you are touching multiple unrelated things, split them into separate PRs. Focused PRs are reviewed and merged faster.
  • Describe your changes — your PR description should include what changed, why it was needed, and confirmation that you tested on at least 2–3 language files.
  • Include screenshots for any visual change — a before/after pair is ideal. This is especially important for theme and icon contributions.
  • Never edit package.json — this file is maintainer-only. Versioning, contributes entries, and script definitions are managed by the project maintainer.
By participating in this project, you agree to follow the Code of Conduct. Please keep all interactions respectful and constructive.

​
Need Help?

Have a bug to report or an idea to propose? Open an issue on GitHub — it’s the best place to discuss new features, report problems, or ask architecture questions before investing time in a large change.

Build docs developers (and LLMs) love

Get started for freeTalk to us