Project structure · More
Electron desktop app project structure
Opens with creditsA desktop notes app for Windows, macOS and Linux, built from the Electron Forge 8 Vite and TypeScript template. The tree starts with the scaffold's three entry files (main, preload, renderer) and grows into separate folders for each process, a typed IPC contract, signed installers, auto-update and end-to-end tests on the packaged app. For students who know web development and want to ship a real desktop app; if a small download matters more than a large JavaScript ecosystem, Tauri is the alternative worth comparing first.
Curated by Tauseef FayyazIntermediate138 files and foldersElectron 44, Electron Forge 8.0, Vite 8Checked October 2026How it grows
Each stage opens the explorer there
- 1Day 1What the scaffold and your first hour give you22 files and folders
- 2GrowingWhat a real app with features and tests adds+58 files and folders
- ProductionWhat running it for real users adds+29 files and foldersOpens with credits
- ExpertWhat a team needs to keep it healthy for years+29 files and foldersOpens with credits
How it is organised
- Three kinds of code, three places. The main process (Node.js, full OS access) goes in `src/main`, the UI (a web page, no Node) in `src/renderer`, and the preload bridge in `src/preload.ts`. Code that every process needs, and that imports nothing from any of them, goes in `src/shared`.
- Keep the secure defaults: contextIsolation and sandbox on, nodeIntegration off, and the Forge fuses that block `RunAsNode` and only load the app from its asar archive. If something only works with a protection turned off, the design is wrong.
- The renderer talks to main only through a small typed API that preload exposes with `contextBridge`. One function per action, never a raw `ipcRenderer`. Every main handler validates its input and checks who sent it.
- Treat every IPC channel like a public API endpoint: the page can run untrusted content (a pasted link, a Markdown file), so a handler that reads any path it is given is a hole in the user's whole machine.
- User data lives in `app.getPath('userData')`, written atomically and versioned. The install folder is replaced on every update.
- Ship signed builds with auto-update from the first public release. Unsigned apps are blocked on macOS and flagged on Windows, and without an updater you cannot fix what you shipped.
- Test most code without Electron (Vitest for storage, validation and components) and only a few journeys against the packaged app with Playwright, on all three operating systems.
- Electron or Tauri: Electron bundles Chromium and Node.js, so every user gets the same engine and you write the backend in TypeScript, at the cost of a larger download and more memory. Tauri uses the system web view and a Rust backend, so apps are much smaller but render slightly differently per OS. Pick one and write down why.
At the top of the project
Open one in the explorer for the full story
- notes-desktop/
- .git/Git history for the app.
- .husky/Git hooks that run lint and type checks before each commit.1 inside
- .vite/Vite build output: the bundled main, preload and renderer that Electron actually runs.
- .vscode/Shared VS Code settings and a launch configuration that debugs the main process.1 inside
- .editorconfigIndent style, final newline and charset for every editor.
- .gitattributesNormalises line endings so Windows and macOS contributors do not fight over them.
- .gitignoreKeeps node_modules, .vite, out, logs and local env files out of Git.
- .nvmrcThe Node.js version for running Forge, Vite and tests.
- .oxfmtrc.jsonSettings for oxfmt, the formatter Forge 8 templates use.
- .oxlintrc.jsonoxlint rules for the project.
- coverage/Vitest coverage reports.
- forge.config.mtsElectron Forge configuration: packaging, makers for each platform, the Vite plugin and fuses.
- index.htmlThe HTML page the main window loads; Vite injects the renderer script.
- LICENSEThe license your app is distributed under.
- assets/Files used to build the app: icons per platform and macOS entitlements.1 inside
- node_modules/Installed npm packages, including the Electron binary for your platform.
- out/Packaged apps and installers from `npm run package` and `npm run make`.
- package-lock.jsonExact versions of every installed package.
- package.jsonApp name, version, `main` entry, Forge scripts and dependencies.
- README.mdHow to run, test, package and release the app.
- src/All app code: the main process, the preload script and the renderer (the UI).8 inside
- tests/Unit tests, end-to-end tests against the packaged app, and later performance checks.1 inside
- tsconfig.jsonTypeScript settings for all three processes, with bundler module resolution.
- vite.main.config.mtsVite config for the main process build.
- vite.preload.config.mtsVite config for the preload script build.
- vite.renderer.config.mtsVite config for the UI: plugins, aliases, CSS.
- vitest.config.tsVitest settings: test folder, environment per file, coverage.
Learn more on Sefism
Roadmaps, cheat sheets and projects that go with Electron desktop app.
- RoadmapFrontend development roadmapHTML, CSS, JavaScript and a framework
- Roadmap· TypeScriptSoftware design and clean code roadmapOOP, SOLID, design patterns, refactoring
- RoadmapLinux, terminal and Git roadmapShell, Git, SSH and your dev setup
- Roadmap· Application securityCybersecurity roadmapDefend systems, test them, secure code
- Cheat sheetFrontend development cheat sheetHTML, CSS, JavaScript and a framework.
- Cheat sheetLinux, terminal and Git cheat sheetShell, Git, SSH and your dev setup.
- Cheat sheetCybersecurity cheat sheetDefend systems, test them, secure code.
- FYP idea· AdvancedIn-Browser Document Redaction for ID Cards, Bank Statements and Medical ReportsBuild a web app that finds and removes personal details such as CNIC numbers, account numbers, phone numbers, addresses and names from PDFs and photos entirely inside the browser, using on-device OCR and small models, so the file never leaves the phone. People share copies of ID cards and bank statements with landlords, employers and agents every day, usually unredacted. The hard part is true redaction that removes hidden text, not black boxes drawn on top.
- FYP idea· IntermediatePower-Cut-Resilient Programming Lab Exam Server That Runs on the Local NetworkBuild a self-hosted exam system for university programming labs that runs on a single server inside the lab, saves every keystroke-level change so no student loses work when power or Wi-Fi drops, runs code in sandboxes for automatic test results, and gives invigilators a live view of the room. Load-shedding, unstable internet and shared lab machines make online exam platforms fragile in Pakistani universities. The hard parts are crash-safe saving, fair resumption and safe code execution.
See 7 moreShow fewer
- FYP idea· AdvancedUrdu Nastaliq OCR for Printed Books and Newspaper Archives with Searchable OutputBuild an OCR pipeline that turns scanned Urdu books, magazines and old newspapers printed in Nastaliq into searchable text, with line detection, a recognition model, a dictionary-based correction pass and a review screen for librarians. Most Urdu print from the last century exists only as page images, so it cannot be searched, quoted or read aloud by screen readers. The project measures accuracy honestly on real archive scans, not only on clean benchmark lines.
- FYP idea· AdvancedOffline-First Update System for School and Clinic Device Fleets on Poor ConnectionsBuild an update system for fleets of Linux devices in rural schools, clinics or shops, such as Raspberry Pi kiosks or low-cost PCs, where the internet is slow, metered or missing for days. It ships small delta updates, lets one device on a site download once and share with the rest over the local network, accepts updates from a USB stick, and rolls back automatically if a device fails to boot.
- QuestionShould I learn TypeScript or Python first in 2026?Learn Python first if you are new to programming or drawn to data and AI. Learn TypeScript first only if you already know some JavaScript or are certain about web development, and even then learn plain JavaScript for a few weeks before the types. The second language is much easier than the first.
- QuestionWhat projects should I build in my first year of university?Build small, finished projects that solve problems you or people around you actually have: a script that automates a chore, a command line tool, a simple website for a society or family business. First year is about finishing things and using Git, not about impressive ideas.
- QuestionWhat does proof of work mean for a fresher developer?Proof of work is evidence someone can check in a few minutes that you can do the job: a deployed project real people could use, readable code with tests, a pull request merged into someone else's project, or a clear write-up of a problem you solved. It replaces the experience a fresher does not have yet, so it must be easy to find and easy to verify.
- QuestionHow do I learn to write clean code as a junior developer?Clean code is a set of habits, not a book you finish. Fix names, function size, flag arguments and error handling one habit at a time, let a formatter and linter settle style, learn to refactor in small steps behind tests, and keep a list of the review comments you get twice: that list is your personal curriculum.
- Resource· CourseMIT 6.102: Software ConstructionMIT's undergraduate course on writing software that is safe from bugs, easy to understand and ready for change, with every reading free on the public course site. Its readings on specifications, abstract data types, rep invariants, interfaces and code review are the university-level version of good object-oriented design.
Checked against 16 official sources, October 2026. If something has changed, the docs win.Show sourcesHide sources
- Electron Forge Vite template (v8.0.1)
- Electron Forge base template (v8.0.1)
- Electron Forge: Vite template
- Electron Forge: Vite plugin
- Electron Forge: Signing a Windows app
- Electron Forge: Signing a macOS app
- Electron Forge: Auto update
- Electron: Process model
- Electron: Inter-process communication
- Electron: Security checklist
- Electron: Electron fuses
- Electron: utilityProcess
- Electron: Automated testing
- Electron: Updating applications
- Playwright: Electron
- Tauri: What is Tauri?
Best practices and checklists for this stack
Picked from the other libraries by shared topics.
Best practices
See all- React Best PracticesModern React best practices for 2026: pure components, lean state, fewer effects, React Compiler, form actions, accessibility and testing.
- TypeScript Best PracticesModern TypeScript best practices for 2026: strict settings, TypeScript 7, modeling data with unions, safe narrowing, runtime validation, generics and typed linting.
- Modern CSS Best PracticesModern CSS best practices: cascade layers, low specificity, custom properties, Grid and Flexbox layout, responsive design, container queries, :has() and nesting, plus Tailwind CSS v4 tips.
Checklists
See all- Web Accessibility ChecklistA practical web accessibility checklist built on WCAG 2.2 level AA, with a severity and a concrete way to verify every check.
- Web Performance ChecklistA practical web performance checklist built on Core Web Vitals: LCP, INP and CLS, with a severity and a concrete way to verify every check.
- Pull Request Checklist: Before You Open a PRA pull request checklist to run before you ask for review: scope and size, a clean diff, tests, a clear description, safe releases and a tidy branch, each with a way to verify it.
Work with me
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com