CONTRIBUTING.md

January 21, 2026 ยท View on GitHub

Requirements

Make sure you have the following programs installed:

  1. git
  2. Node
  3. npm

Start

First of all, let's try to package this extension and install it to your vscode.

$ git clone --depth 1 https://github.com/reese/everforest-vscode.git
$ cd everforest-vscode
$ npm ci
$ npm run package
$ code --install-extension ./everforest-*.vsix

Now, use vscode to open this project and modify some code, then press F5 to start debugging.

The theme files

The most critical files for a theme extension are some json files located in /themes, they defined all the colors of a theme.

A theme file can be roughly divided into three parts:

For all available workbench colors, see this documentation.

To get current token of syntax highlighting or semantic highlighting, press Ctrl+Shift+P to open command panel and search for "Inspect Editor Tokens and Scopes".

In this extension, the json files will be automatically generated when user configuration changes, so don't keep your changes in the json files, but modify the typescript code instead.

Publishing

I set up a github action for this repository that can publish this extension to vscode marketplace and open vsx registry automatically when a new tag is created. For example, to release v6.2.10, do something like this:

  1. Edit package.json, modify the version field: "version": "6.2.10",
  2. Update package-lock.json: $ npm install
  3. Commit this change: $ git commit -am "release v6.2.10"
  4. Create a tag: $ git tag -a v6.2.10 and edit the tag message based on CHANGELOG.md
v6.2.10

- Publish to open vsx registry.
- Setup a pre-commit hook that can regenerate the theme file using default settings.
  1. Push the commit and tag to github: $ git push origin master v6.2.10

Versioning

This color scheme doesn't follow the semantic versioning convention, because there are almost no "bugs" in a color scheme. Everything is regarded as a feature.

Given a MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make breaking changes (often with changes to design),
  2. MINOR version when you change configuration options, and
  3. PATCH version when you add small features (with no configuration changes).

Some designs

There are 3 workbench styles available in this theme:

It's highly recommended to try them first if you want to modify the code of a workbench style.

When you are modifying a workbench style, remember a principle:

Don't make elements too colorful, because this will easily distract you from the code.

You may notice that I used many grey colors in workbench styles, it's exactly because of this, colorless elements will help you focus more on the code.

In addition, this theme is designed to be borderless, so DO NOT add unnecessary borders.

There are 2 syntax highlighting logic available in this theme: default and colorful

In the default syntax highlighting logic, only minimum but necessary tokens will be colored.

Unnecessary tokens include: variables, properties, members, parameters, etc.

In contrast, in the colorful syntax highlighting logic, as many tokens as possible will be colored.

Note

  • I set up 2 pre-commit hooks, one of which is used to generate /themes/*.json automatically using default user settings. So when developing this extension, don't care about how the themes files looks like, but just focus on the typescript code.
  • DO NOT add new colors or modify existing colors in /src/palette. The current color palettes are very carefully designed and tested on several devices. If you do want to change the color palettes, create a new theme extension instead.
  • Don't add new configuration options casually, there are already so many configuration options and too many options may confuse users.
  • Don't forget to update the changelog.
  • Don't forget to update italic syntax file if the syntax source code is modified.