This repository is the Linux fork of GitHub Desktop, a TypeScript/Electron app.
Application code lives in app/src: UI components are under app/src/ui, shared
logic under app/src/lib, models under app/src/models, and Electron main
process code under app/src/main-process. Styles are in app/styles, static
assets in app/static, and documentation in docs/. Build, release, and
maintenance scripts live in script/. Tests are in app/test, with unit tests
in app/test/unit, helpers in app/test/helpers, mocks in app/test/__mocks__,
and Git fixture repositories in app/test/fixtures.
Use Yarn 1.x and Node 20.x, as described in docs/contributing/setup.md.
yarninstalls root and app dependencies.yarn build:devcompiles a development build.yarn startlaunches the development app with background recompilation.yarn compile:devruns the development webpack compilation only.yarn testruns unit tests and script tests.yarn test:unit -- <pattern>runs matching Jest unit tests.yarn test:scriptruns tests for repository scripts.yarn lintchecks Prettier formatting and ESLint rules.yarn lint:fixapplies Prettier and ESLint autofixes.
Write TypeScript using the repository ESLint and Prettier configuration. Use
camelCase for methods and variables, PascalCase for classes and React
components, and JSDoc /** ... */ comments for public or non-obvious APIs. In
application code, prefer asynchronous Node APIs; synchronous variants should be
rare and named with a Sync suffix. Script code may favor synchronous APIs for
readability.
Jest is the primary test framework. Add unit tests beside related areas under
app/test/unit, mirroring app/src when practical. New test files should use
the pattern [app-module]-test.ts. Keep unit tests focused on one module or
function, and use app/test/fixtures for repository state needed by Git tests.
Run yarn test:unit before submitting application changes; run yarn test when
touching shared behavior or scripts.
Recent history uses short imperative subjects, often with scoped prefixes for
automation such as build(deps): bump .... Keep commits focused and mention PR
or issue numbers when relevant. Open draft PRs for work in progress, include a
clear description, link related issues, and add screenshots or recordings for UI
changes. Expect review iteration; mark the PR ready only after tests and linting
that match the change have passed.