vscode-icons: what activating the theme actually changes

Activation is a second step the install command does not do

Installing the extension does not switch icons on. After the window reloads you get a message offering to `Activate` the icons, and that second choice is the part people miss. When the message never shows up, the theme has to be picked by hand, and the menu path differs by platform. On Linux and Windows the chain runs through `File > Preferences > Theme > File Icon Theme > VSCode Icons`. On MacOS it starts one level up at `Code > Preferences > File Icon Theme`, then the same `VSCode Icons` entry. The list shows the display name, not the package identifier, so looking for `vscode-icons` there is a dead end. The manifest carries `icon-theme` among its keywords and describes itself only as icons for Visual Studio Code, with no field that forces a theme switch on upgrade. A major version bump can therefore leave you on the previous set until you revisit this menu yourself.

Three spellings of the install command, and why the first one misses

In the Command Palette this single line finds the theme:

ext install vscode-icons

It does not always resolve, and the project answers that with two shorter forms instead of diagnosing the failure:

ext install icons
# or
ext install "vscode-icons"

Lookup is name based, so a misspelled or over specific query returns an empty result that looks identical to the extension not existing. The listing sits under the publisher `vscode-icons-team`, which is why the bare word lands on nothing while the namespaced identifier reaches it. There is no offline or sideload command anywhere in the repository, so the palette is the only documented route and the homepage is a Marketplace item page.

Project auto detection swaps your icon set on its own

Project Auto Detection reads the project you have open and switches the icon set without being asked, with Angular given as the worked example and other frameworks said to work. No list of those other frameworks appears in the package manifest, and there is no configuration key for the behaviour either. Three consequences follow. A workspace holding two frameworks in one window has no documented tie breaker, so the detected set may not match the file you are editing. Detection also only knows about frameworks someone added, so a language server or build tool outside that set keeps generic icons no matter how the repository is laid out. The keyword `multi-root ready` says multi root workspaces are supported, but support is not the same as per folder detection being documented, so treat framework coverage as something to verify rather than assume.

Icon artwork is ShareAlike even though the source is MIT

The licensing is split three ways, and the split matters if you redistribute anything. The extension source is MIT under the root `LICENSE` file, with Roberto Huertas as author and Remco Haszing, Dimitris Charalampidis and Manuel Bojato as maintainers. The icon artwork is not: it is Creative Commons ShareAlike, CC BY-SA 4.0. Branded icons, meaning the logos of other products, sit under their own copyright licence instead. Adding your own icon therefore does not put your file under MIT either, it lands in the same ShareAlike bucket as the built in set, and anyone repackaging the theme has to carry that attribution obligation forward. Contributors are pointed at `.github/CONTRIBUTING.md` before any artwork is submitted, with a separate wiki section for the artistic side. Translations arrive through Crowdin rather than pull requests, so the `locale/` directory is generated by that pipeline.

The manifest ties a VS Code floor to a Node floor

Two version constraints ship together in package.json, and only one of them applies to you:

  "engines": {
    "vscode": "^1.104.3",
    "node": ">=22.18.0"
  },

The same 1.104.3 figure is printed as the minimum supported version in the project banner. Node 22.18.0 is a floor for building the source, not for using the theme. The repository carries its own toolchain: `husky install` runs on prepare, prettier handles formatting, `webpack.config.ts` holds the bundle config, and coverage is wired through `codecov.yml` and `.nycrc`, with Mocha configured in `.mocharc.json` and tests under `test/`. A clean rebuild is the single `reinstall` script, which removes `./package-lock.json` and `./node_modules` before installing again, and `build` shells out to `node ./out/src/tools/build.js "--release"`. None of that runs on a Marketplace install, but a contributor on Node 20 fails at the install step, not at the build step.

Version 13 sits next to a release numbered 2.18.0

The release history does not run in one direction. The newest tag is v13.0.0, dated 2026-09-29, and it matches the `version` field in the manifest. The tag before it is v12.19.0 from 2026-06-27, and after that comes v2.18.0 dated 2026-04-19, a number below both that nonetheless lands between them in calendar time. The project states that it follows Semantic Versioning 2.0.0, yet a 2.x tag appearing after 12.x is not what that scheme describes. For anyone pinning a version in settings or reproducing a build this gap is a real hazard: sorting by number treats 13.0.0 as newest and 2.18.0 as ancient, so a script or lockstep workflow that reasons about versions rather than dates can select the wrong release. Read dates out of `CHANGELOG.md` instead of trusting numeric order.

Supported icons live in wiki pages, not in the repository

The repository carries no inventory of what it can draw. Supported file icons and supported folder icons both live in wiki pages named `ListOfFiles` and `ListOfFolders`, and the `icons/` directory is the only local hint. So there is no way to confirm from the tree alone that your particular file extension has a dedicated glyph, and no count of how many are covered. The same gap applies to framework detection, where Angular is named and everything else is left open. What the repository does state is the shape of the work: TypeScript sources under `src/`, compiled output at `out/src/`, a browser bundle at `dist/src/vscode-icons.web.bundle.js`, and listing artwork at `images/logo.png`. If a needed icon is absent the documented answer is an issue through the tracker address in the manifest, not a setting you can change.

Editorial conclusion

Adopt vscode-icons if your work spans many file types and you want per extension glyphs without configuring each one, and take the Marketplace build rather than compiling from source unless you already run Node 22. Check your specific extensions against the wiki file list first, and confirm the theme is activated by name after every major bump, since the 2.18.0 tag dated after 12.19.0 makes version pinning unreliable.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vscode-icons/vscode-icons on GitHub