-
Notifications
You must be signed in to change notification settings - Fork 0
Building from Source
You need Node 22 or newer, because the main process uses node:sqlite, which is not
available without a flag before that. Node 24 is what the release workflow uses.
git clone https://github.com/Lucki74/draggy.git
cd draggy
npm install
Ollama has to be installed and running, same as for a normal install.
npm run electron:dev
Vite and Electron start together with hot reload on the renderer. Changes to
anything under electron/ need a restart.
npm run dev starts only Vite, which is useful for renderer work but note that
window.electronAPI will be undefined. Every call site guards for that, so the
app loads, but anything touching the filesystem, the database or search does
nothing.
npm run check
Typecheck, lint and the test suite. Around 940 tests in under two seconds; run it before every commit.
Individually: npm run typecheck, npm run lint, npm run test. npm run test:watch while working on something, npm run test:coverage for the report.
npm run electron:build
Windows installer into dist-electron.
If that fails with unable to verify the first certificate, something on the
machine is intercepting TLS (antivirus, a corporate proxy, a VPN) with a root
Windows trusts and Node does not. Node will read the system store when told to:
$env:NODE_OPTIONS = "--use-system-ca"
npm run electron:build
The workflow runners have clean trust stores, so a tagged release is unaffected. There is electron:build:mac,
electron:build:linux and electron:build:all as well. All of them pass
--publish never, so a local build cannot upload anything by accident.
The icons are generated from source art with npm run icons if you change them.
From a clean main:
npm run check
npm version patch
git push --follow-tags
npm version writes the version into package.json, commits it and tags it.
Pushing the tag starts the release workflow, which builds on Windows and Linux
and publishes the installers plus the latest.yml files the in-app updater
reads. It authenticates with the automatic GITHUB_TOKEN, so there is no secret
to configure.
RELEASING.md in the repository has the detail, including how to publish from
your own machine instead.
The version in package.json is the single source of truth. A release whose tag
and package.json disagree will never be offered as an update.
macOS is not in the release workflow on purpose. Squirrel.Mac refuses to update
an app that is not signed and notarised, so an unsigned build would install and
then never update itself again. npm run electron:build:mac still produces a
.dmg for manual distribution.
Adding it properly needs an Apple Developer certificate, CSC_LINK and
CSC_KEY_PASSWORD as repository secrets, notarisation credentials, and a
macos-latest entry in the workflow matrix.
Comments explain why, not what, and fit in two lines of at most twenty-five
words each. The codebase leans on them heavily, and most of the non-obvious numbers in
src/voice/constants.ts say where they came from, but the reason still has to
fit in two lines, including module headers.
New behaviour that encodes a decision should be a pure function with a test. Anything needing a GPU, a network or Electron belongs at the edges where it can be stubbed.
The interface holds no English: every user-visible string goes through
src/translations.ts in all twelve languages. The tests enforce this in both
directions: one fails if a t() call has no matching key, another fails if a
key is defined that nothing reads, so a string cannot be left behind by a
feature that was removed.
Draggy is under the GNU GPL v3.0 or later. If you are sending a patch, read CONTRIBUTING.md first. It covers the workflow above plus what opening a pull request means for copyright.
CI runs npm run check on every push and pull request, on Windows with Node 24,
so a mistake will be caught. It is caught faster on your own machine and the
suite takes two seconds, so run it anyway. CodeQL scans separately for security
issues, and the release workflow still fires only on a version tag.