Flashpoint Launcher is the Electron catalog that fronts the Flashpoint Archive

A catalog for an archive, not a storefront

The Flashpoint Launcher is a desktop application for browsing, storing and launching other applications, which in this context means games, animations and web apps. The README is careful about the purpose: it was made for Flashpoint Archive, a non-profit with the goal of furthering archival and accessibility efforts for games, animations and other digital interactive experiences on the web.

That framing matters for how the software should be judged. A launcher for an archive is a catalog with a player attached. The value is in the metadata, the search, the organisation of a large collection and the ability to launch a title that would otherwise be a folder of files with no way in. The archive is downloaded from the Flashpoint Archive site, and the README says the launcher is bundled with it.

The division of labour is visible in the repository. The top level has src/ for the application code, extensions/ for the extension system, static/ and lang/ for assets and localisation, pkg/ for packaged resources, extern/ for external code, a website/ directory, a bench/ directory, and docs/ for the configuration, development and extension authoring information. There is a CHANGELOG.md, a CONTRIBUTING.md and a separate Extension API Documentation site.

The project is under the FlashpointProject organisation and the site is flashpointarchive.org. Donations go through OpenCollective, and the README is explicit about where the money goes: funds go towards the Flashpoint Archive non-profit to sustain archival efforts, not to fund developers of the launcher. That is a useful thing for a maintainer of a non-profit tool to state plainly.

Extensions are how a curator customises the catalog

The launcher supports extensions, and the documentation structure shows that this is a first class part of the system rather than an afterthought. There is a docs folder for extension authoring, a separate Extension API Documentation site, a gulpfile.extensions.js in the repository, and an electron-extension-installer package in the dependencies.

The purpose of the extension system follows from what a catalog needs. Archive metadata is not uniform: one collection may have complete platform and publisher data, another may only have a title and a date, and the person curating it knows more than the data contains. An extension is where that extra knowledge goes, whether it is a new metadata provider, a custom search behaviour, or a way to present a particular collection.

The npm scripts show the pipeline. The postinstall hook runs electron-builder install-app-deps and then gulp extInstall, so extension installation is part of the ordinary install step. The build script is gulp build, and the lint script targets the TypeScript sources and the gulpfile with eslint over ./src/**/*.{ts,tsx}, while a separate eslint.config.mjs sits at the top level next to an older .eslintrc-old.json.

The project uses lefthook for git hooks, jest for tests with a jest.config.ts, and separate TypeScript configurations for the backend and the renderer, tsconfig.backend.json and tsconfig.renderer.json, with a shared tsconfig.json. The renderer and main processes are compiled differently, which is the normal shape for an Electron application with a strict process boundary.

Building it means Node, Gulp and a release branch discipline

The build instructions are detailed enough to be followed without guesswork, and they are the clearest part of the README for anyone who wants to run the launcher from source.

The external dependencies are Git, for downloading the source and submodules, and Node with npm, for building and running. On Linux there are two system packages, libgtk-3-0 and libnss3, installed with sudo apt install libgtk-3-0 libnss3. The README also points at a Development Setup document, and says to use the master branch for a stable release or develop for the latest features.

The setup steps are a clone with submodules, an npm install, a build, and a start:

git clone --branch develop --recurse-submodules https://github.com/FlashpointProject/launcher.git launcher
cd launcher
npm install
npm run build
npm run start

The clone uses the develop branch in the example and the --recurse-submodules flag, which matters because the repository carries submodules that a plain clone would leave empty. The README notes that npm install has to be rerun whenever a dependency is added or upgraded in package.json, and that it may take a few minutes.

npm run build compiles the source, and npm run watch rebuilds automatically when a source or static file changes. npm run start runs the latest build, and the README recommends running it in a second terminal so the build process stays usable.

The package scripts separate a local build from a distributable one

The scripts in package.json describe a clear progression, and understanding it tells you what you actually need.

build compiles the launcher, building main and renderer and copying static files to./build/. watch does the same incrementally. pack packages the latest build, putting the packaged file with the executable Electron app in./dist/. snapshot builds then packs, and release builds then packs in release mode, which also creates installers and build artifacts. start runs the latest build, test runs the jest suite and lint runs eslint.

The main entry point is build/main/index.js, and the start script is electron./build/main/index.js, with a start-logger variant that passes logger=true to the process. That flag is a hint about how the application handles diagnostics.

The scripts that matter for distribution set platform and architecture explicitly. The snapshot script is pinned to win32 and x64 with NODE_ENV=production, and the release script sets NODE_ENV=production and PUBLISH=true. For other targets the README says to use the handy per-platform scripts such as pack:linux or release:win32, or to set the PACK_PLATFORM and PACK_ARCH environment variables directly. By default, pack, snapshot and release target the operating system and architecture of the machine that runs them.

The nexusBuild and nexusPack scripts are a legacy path for a 32-bit Windows target, using ia32 for the architecture, which suggests an older build destination that is still wired up.

The Flashpoint folder is the state, and it is not backward compatible

The most important practical note in the README is about the Flashpoint folder, and it comes with a warning that is easy to skim past.

The Flashpoint folder is where the launcher reads and writes most data, and you set its path in the Config tab. The README tells you to make sure the background of the text field is green, which means the path is valid, and not to forget to hit Save and Exit. That green field is a validation indicator, and the Save and Exit step is where the setting is committed.

Then the warning. The launcher is changing rapidly and does not always support older Flashpoint folders, and sometimes it does not even support the most recent one. The recommendation is to have a separate Flashpoint folder for launcher development than for normal usage. That is a strong signal about the state of the format: it is versioned implicitly by the launcher version, and a folder written by one build may not be readable by another.

For a curator this is manageable and worth understanding, because it means the folder is a database-like artifact rather than a pile of files. Migrating a library to a new launcher version may involve regenerating or updating the folder rather than copying it forward unchanged.

The troubleshooting section gives one concrete example of a common failure. A 'Not allowed to load local resource' error in the Electron console usually means the file it is looking for does not exist, and the fix is to run npm run build, with the example path pointing at build/renderer/index.html.

Licence, localisation and the shape of the repository

The licence is worth a careful read, because the GitHub listing classifies it as a custom licence that GitHub cannot categorise, while the package.json declares MIT. There is a LICENSE file at the top of the repository, and the package metadata is the project author Jesper Gustafsson with license set to MIT, so the two agree on paper even though GitHub's classifier does not.

Localisation is handled with Crowdin, with a badge pointing at the Crowdin project and a crowdin.yml file at the top level, and a lang/ directory for the strings, plus an updateLangs.mjs script and a website/ directory that presumably serves the documentation site.

The build stack mixes a few tools, which is what you would expect from a project of this age that has been modernised in place. Gulp drives the build through gulpfile.js, gulpfile.extensions.js and gulpfile.util.js. SWC handles the TypeScript compilation, with swcrc.back.dev.json and swcrc.back.prod.json distinguishing development from production backend builds. Jest runs the tests, Coveralls tracks coverage with a branch badge for master, and lefthook.yml manages the git hooks. There is also a bench/ directory, an ormconfig.json, a secrets.json.example, a tslint.json alongside the modern eslint config, and a typings/ directory.

Releases are named after the launcher version. 14.0.1 shipped on 2025-02-17, 14.0.2 on 2025-04-28 and 14.0.3 on 2025-10-29, and the last push was on 2026-09-28 with the repository not archived.

Editorial conclusion

Flashpoint Launcher suits a curator who maintains a Flashpoint library and wants a searchable catalog with pluggable metadata providers rather than a folder of files. It is the wrong tool if you are looking for a games storefront, since the launcher is a front end for an archive rather than a distribution platform, and it is a poor fit for anyone unwilling to run an Electron application. Before installing from source, read the notes about Flashpoint folder compatibility, because the README says the launcher is changing rapidly and does not always support older Flashpoint folders, and keep a separate Flashpoint folder for development as it recommends.

Frequently asked questions

Official sources

1. FlashpointProject/launcher on GitHub
2. Issues
3. Project website
4. README
5. Releases