Rūdolfs Ošiņš
954222cb11
Most copy-pasting between the two front-ends happens in UI code. These propose making explorer and desktop siblings and sharing code from source, without an npm workspace for now.
1.8 KiB
2. Shared front-end code in an npm workspace
Date: 2026-10-21
Status
Proposed
Context
Desktop and explorer have copied a lot of front-end code from each other. Desktop is the most developed of the two and already on Svelte 5, so it is the source we extract shared code from.
We also considered consuming shared/ui as a plain source folder and as a
local file: dependency. Both need workarounds in each app's Vite and
TypeScript config, and leave shared/ui without its own lints and tests.
Decision
A root npm workspace holds shared/ui, explorer and desktop, with one
lockfile, .npmrc and .nvmrc at the root.
shared/ui is the package @radicle-gui/ui. It has svelte as a peer
dependency and its own checks, lints, tests and CI workflow. The apps depend on
it and import it from source, without a build step.
Shared stylesheets and fonts live in shared/ui/public. A Vite plugin from the
package serves them next to each app's public directory in dev and adds them
to the build, so the apps keep their <link> tags, marked vite-ignore.
Shared code must not import @tauri-apps/*, @bindings or @http-client.
It takes plain props, and each app adapts its own data to them.
Consequences
- The apps share one dependency tree. Shared code gets a single copy of
svelteand its other dependencies, and is checked and tested on its own, without workarounds in either app. - Dependency versions are coupled. Where the apps' ranges overlap, a bump lands in both, and an app that needs to diverge has to pin its own version.
- Installs and builds start from the repository root. Working on one app means
installing it with
-w, and Nix, Docker and CI have to use the root lockfile. - Shared components are written with runes. Explorer can render them while it still uses legacy syntax, at the cost of some friction where the two meet.