En Croissant is a chess GUI that ships the analysis loop, not just the board

Games come from two online platforms, and that shapes everything

En Croissant is an open-source, cross-platform chess GUI, and the first feature in the list is the one that defines the product: store and analyse your games from lichess.org and chess.com.

That ordering matters. This is not a board-first application with an optional database import. The game library is populated from your accounts on two online platforms, and the analysis, training and search features operate on that library. The board, in other words, is where you act on games you already have rather than the place where games come from.

The frontend components in the manifest confirm the domain rather than surprising it. `@lichess-org/chessground` is the board library used by the site whose games you are importing, so the interaction model is deliberately compatible with what players already know. React handles the interface through Mantine, and `@tanstack/react-virtual` is present for virtualized rendering. `@badrap/result` as a dependency is a small signal about the code: error handling is modelled as values rather than exceptions, which suits an application that talks to a network service and to external engine processes.

Position search is listed as absolute or partial search in the database, which is the feature that separates this from a game viewer. Finding every game where a position ever appeared, even with some moves missing, is what makes a library usable for opening preparation.

The GPL-3.0 licence is worth noting for a desktop application, because it is the licence a copyleft project like this normally carries and it constrains redistribution rather than use. The repository is not archived and the last push was on 2026-10-16, with v0.15.1 the most recent release from 2026-09-05.

Multi-engine analysis and the engine manager

The analysis side is the second pillar: multi-engine analysis supporting all UCI engines.

UCI is the de facto protocol for chess engines, so "supports all UCI engines" is a compatibility claim rather than a list. It means the application does not bundle a preferred engine or wrap an engine in a proprietary protocol, and it means the analysis you see comes from whichever engine you point it at. That is the right design for a tool meant to be taken seriously, since engine strength and behaviour vary so much that a bundled default would be a liability.

The corollary is that the application is responsible for the whole lifecycle of those engines, and the README lists simple engine and database installation and management as a feature of its own. A GUI that runs any UCI engine still has to find the binary, pass arguments, allocate time, parse output and shut the process down, and that plumbing is what the management feature covers. It also means the app is doing work Node-based GUIs do poorly, which is a fair reason for the project to exist as a native application rather than a web page.

Repertoire training is the third feature and the least obvious one. You prepare a repertoire and train it with spaced repetition. Spaced repetition is a scheduling technique: cards are shown at intervals that expand as you get them right and collapse when you do not, so the time spent reviewing is concentrated on the positions you have not yet learned. For chess that maps directly onto the two things a player actually needs to memorise, openings you play and the tactical positions you keep getting wrong.

The distinction from database search matters here. Search finds something that exists in your games. Repertoire training is a scheduled curriculum built from positions you chose, with the interval between reviews decided by your recall rather than by a date. Both are in the same application because both operate on the same underlying data.

Tauri plugins in the manifest line up with the feature set: `plugin-cli` for launching engine processes, `plugin-fs` and `plugin-dialog` for engine and database files, `plugin-http` for the online platforms, and `plugin-process` plus `plugin-updater` for managing the application itself.

Building produces a native binary, not a web bundle

The build path reflects the architecture. It is a Tauri application with a Rust backend, `src-tauri/`, and a TypeScript and React frontend in `src/`, bundled by Vite.

The build prerequisites are delegated to the Tauri documentation, which the README links for per-platform requirements, so the Rust toolchain and platform-specific build libraries are covered there rather than duplicated. The package manager is pnpm, and the README points at pnpm's own installation instructions.

The build itself is four commands:

git clone https://github.com/franciscoBSalgueiro/en-croissant
cd en-croissant
pnpm install
pnpm build

The output lands in `src-tauri/target/release`, which is the Rust target directory rather than a JavaScript one. That detail matters if you are looking for a build artefact: you will not find a `dist` directory with a standalone bundle, you will find the compiled application.

The scripts in `package.json` separate the two halves of the build, which is useful when you are debugging. `build-vite` runs the TypeScript type check with `tsc --noEmit` and then the Vite build, so the frontend can be built and checked without Rust. `build` runs `tauri build --no-bundle`, and the `--no-bundle` flag is what produces the binaries in the target directory without also generating installers.

Development follows the same split: `pnpm dev` runs `tauri dev`, and `pnpm start-vite` runs only the Vite dev server. The second is the useful one for frontend work, since it gives you hot reload without recompiling Rust.

Everything else in the manifest is conventional tooling: oxlint and oxfmt for linting and formatting, vitest for tests, and a full set of i18next commands for translation extraction, status checking, type generation and syncing, backed by an `i18next.config.ts` at the root. That translation tooling is more infrastructure than a hobby project usually carries, and it is a reasonable signal about the intended audience.

Where the online dependency becomes the limit

The honest limitation is the same one that makes the product convenient.

Because games come from your lichess.org and chess.com accounts, the analysis loop requires working access to those services. That means account credentials in a desktop application, a network connection for anything beyond what has already been downloaded, and exposure to whatever those platforms decide about third-party clients. The application ships plugins for deep links and an HTTP client, which suggests it also handles opening links from a browser, and both of those are places where the platform's behaviour rather than the developer's decides what happens.

The README does not describe an offline mode, an import of PGN files from an arbitrary source, or a way to point the tool at a local database you built yourself. The feature list is explicit about lichess.org and chess.com and says nothing further. That is the boundary, and for anyone who wants to analyse games from tournaments, correspondence chess or their own annotated files, it is a real one.

The second limitation is smaller but worth stating: “supports all UCI engines” means the protocol is supported, not that every engine works identically. Different engines have different interfaces beyond UCI, different default hash and thread expectations, and different output formats for the things a repertoire trainer would want to extract.

The third is that this is a GUI with a large dependency surface. The manifest lists around thirty Tauri plugins alongside the Mantine component family and the TipTap editor stack, and each of those is a version that moves. A single-user desktop application on a stable release is the reasonable deployment, and tracking `main` and building it yourself is the path where the dependency churn is felt most.

The README is short by design. There is a documentation site at encroissant.org/docs, downloads at encroissant.org/download, and a Discord server, and the README itself points to those rather than duplicating them. Contributions are governed by a separate CONTRIBUTING guide.

Editorial conclusion

En Croissant suits a player who analyses from the desktop, wants to work on an existing repertoire rather than start from scratch, and would rather manage UCI engines and a local database through a GUI than through scripts. Do not reach for it if you need offline analysis of games you have already imported, since the feature list centres on storing and analysing games from the two online platforms and describes no offline data source. Verify first that you can sign in to your lichess.org or chess.com account from the app, that the UCI engines you intend to use are installed in a location the app's engine manager can find, and that the version you download matches the platform binaries published at encroissant.org rather than only building from source.

Frequently asked questions

Official sources

1. franciscoBSalgueiro/en-croissant on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases