How to Build From Source (For the Curious)

Edge-Drop is open source under the Apache-2.0 license. The source is on GitHub at https://github.com/Deepender25/Edge-Drop. Building from source is useful for developers who want to inspect the code, contribute a fix, test a branch before release, or run a debug build with extra logging. It is not the recommended path for end users — the packaged installers are easier and auto-update. This guide covers the prerequisites, the clone-and-build workflow, dev mode, packaging, and the common pitfalls. For the bug-report workflow see how to report a bug in Edge-Drop; for the packaged-install path see how to install Edge-Drop on Windows 10 and 11.

Prerequisites

To build Edge-Drop from source on Windows, you need:

• Node.js 18 or later — Edge-Drop uses Electron 34, which requires Node 18+. Download from https://nodejs.org/ or install via winget install OpenJS.NodeJS.LTS.
• npm — comes with Node. Version 9 or later is recommended.
• Git — to clone the repository. Download from https://git-scm.com/ or install via winget install Git.Git.
• Windows 10 or 11 — Edge-Drop is Windows-only. macOS and Linux are not supported.
• Python and Visual Studio Build Tools — only required if any dependency needs native compilation. Most Edge-Drop dependencies are pure JavaScript; the build tools are needed only for occasional native modules. Install via winget install Microsoft.VisualStudio.2022.BuildTools with the "Desktop development with C++" workload.

Verify the prerequisites:

node --version    # should print v18.x or higher
npm --version     # should print 9.x or higher
git --version     # should print 2.x

Cloning the repository

Clone the repository to a local directory:

git clone https://github.com/Deepender25/Edge-Drop.git
cd Edge-Drop

This clones the default branch (typically main). To work on a specific release, check out the corresponding tag:

git tag                       # list available tags
git checkout v0.2.7           # check out a specific release

For contributing, the typical workflow is to fork the repository on GitHub, clone the fork, and create a feature branch. See the GitHub Forks documentation for the workflow.

Installing dependencies

Install the project's npm dependencies:

npm install

This downloads all dependencies listed in package.json and any native modules that need compilation. It may take a few minutes on a fresh clone. If the install fails on a native module, ensure the Visual Studio Build Tools are installed (see Prerequisites).

The install creates a node_modules/ directory. This is gitignored and should not be committed.

Running in dev mode

Dev mode launches Edge-Drop with hot-reload enabled for the renderer. Changes to the React/TypeScript source are reflected in the running app without a manual restart.

npm run dev

This typically does three things:

1. Starts Vite (or webpack, depending on the project setup) to bundle the renderer.
2. Starts the Electron main process.
3. Opens the Edge-Drop window.

The dev console (Chrome DevTools) is usually open by default in dev mode, with verbose logging. Use it to inspect the renderer state, network requests, and any errors.

For a more thorough exploration of the source, see reading an Electron app's IPC surface as a user.

Close running instances before packaging

The single most common packaging failure is having a running Edge-Drop instance when npm run dist is invoked. The packager needs to write to the install directory and the executable file; a running instance holds a lock on those files.

Before packaging:

1. Quit Edge-Drop via the tray icon (right-click → Quit).
2. Verify in Task Manager that no Edge-Drop.exe process remains.
3. Run the packaging command.

If the packager still fails with a "file in use" error, reboot the machine and retry. This is a Windows file-locking behaviour, not an Edge-Drop bug.

Packaging an installer

To build a distributable installer:

npm run dist

This runs electron-builder, which produces:

• An NSIS .exe installer under dist/ (for GitHub-style distribution).
• Optionally an MSIX package if configured.

The output is a full installer equivalent to what is published on GitHub Releases. Installing it over an existing Edge-Drop install upgrades in place; user data is preserved.

For the differences between GitHub and Store builds, see how Edge-Drop updates on GitHub builds and Microsoft Store listing: what to expect.

Common pitfalls

A few patterns cause build failures:

• Node version too old — Electron 34 requires Node 18+. Check node --version and update if needed.
• Native module compilation failure — usually a missing Visual Studio Build Tools. Install the "Desktop development with C++" workload and retry.
• npm install fails on Electron download — Electron downloads a binary for the host platform; corporate proxies may block the download. Set ELECTRON_MIRROR to a mirror or pre-download the binary.
• Port conflict on dev mode — Vite defaults to a port (often 5173); if another process is using it, dev mode fails. Set VITE_PORT to a different value or kill the conflicting process.
• Antivirus quarantining the build output — some antivirus products flag freshly-built Electron binaries. Whitelist the project directory.
• Running instance during packaging — see above. Quit Edge-Drop before npm run dist.
• Stale node_modules — if a dependency upgrade changed the lock file, node_modules may be out of sync. Delete node_modules and package-lock.json, then npm install fresh.
• Wrong branch — building from main may include unreleased changes. For a build that matches a specific release, check out the corresponding tag first.

How dev mode differs from a packaged build

Dev mode and packaged builds differ in several ways:

• Auto-update — dev mode does not auto-update. Packaged GitHub builds do.
• Launch at login — dev mode does not write the Run key. Packaged builds do.
• Window styling — dev mode may show the DevTools docked by default. Packaged builds do not.
• Logging verbosity — dev mode logs at debug level. Packaged builds log at info or warn level.
• Source maps — dev mode has full source maps for debugging. Packaged builds do not.

For testing a behaviour that a user reported, a packaged build is more representative. For inspecting code or testing a fix, dev mode is faster.

How to contribute a fix

If you have identified a bug and want to contribute a fix:

1. Fork the repository on GitHub.
2. Clone your fork locally.
3. Create a feature branch: git checkout -b fix/my-bug-fix.
4. Make the change. Test in dev mode.
5. Run any tests: npm test (if the project has a test suite).
6. Commit with a clear message.
7. Push to your fork.
8. Open a pull request on the upstream repository.

The maintainers review pull requests on a best-effort cadence. A clear description, a minimal change, and a test case significantly improve the chance of merge.

For the bug-report companion, see how to report a bug in Edge-Drop.

How to inspect the source without building

If you want to read the source without building, browse it on GitHub directly: https://github.com/Deepender25/Edge-Drop. The repository has:

• src/main/ — Electron main process code.
• src/renderer/ — React renderer code.
• src/shared/ — shared types and utilities.
• package.json — dependencies and scripts.
• README.md — project overview.
• LICENSE — Apache-2.0 license text.

Reading the source is a useful exercise for users who want to verify Edge-Drop's behaviour claims. For example, the concealment-flag check can be read directly in the poller code; the encryption-at-rest path can be traced through the storage code. See Apache-2.0 clipboard tools you can actually audit for the broader topic.

What Edge-Drop does not claim

• Building from source is not supported as a primary distribution path. The maintainers do not guarantee that every commit on main builds cleanly; tagged releases are the supported checkpoints.
• Dev mode is not a substitute for a packaged install. Behaviour in dev mode may differ from packaged.
• Source builds do not auto-update and do not write the launch-at-login Run key. See how to launch Edge-Drop at login for the manual setup.
• The source code is the canonical reference for behaviour. If a marketing claim disagrees with the source, the source wins. See what Edge-Drop is not trying to become for the project's scope boundaries.

Summary

Building Edge-Drop from source requires Node 18+, npm, Git, and on Windows, optionally the Visual Studio Build Tools for native modules. Clone the repository, run npm install, then npm run dev for dev mode or npm run dist for a packaged installer. The most common packaging failure is a running Edge-Drop instance holding a file lock; quit Edge-Drop before packaging. Dev mode differs from packaged builds in auto-update, launch-at-login, window styling, and logging verbosity. For contributing a fix, fork the repository, create a feature branch, and open a pull request. For users who only want to read the source, browsing on GitHub is sufficient.

The click-path is in Onboarding Tutorial: What It Covers and How to Replay.

Related reading

• Microsoft Store Listing: What to Expect
• Ko-fi and UPI Support: What Donations Fund
• How to Install Edge-Drop on Windows 10 and 11
• What Local-First Software Means for Clipboard Apps

Sources

• Node.js — Downloads — the canonical source for Node.js installers
• Electron — Documentation — official documentation for the framework Edge-Drop is built on
• electron-builder — Documentation — the packaging tool Edge-Drop uses to produce NSIS and MSIX installers
• Apache Software Foundation — Apache License 2.0 — the license under which Edge-Drop is distributed
• Edge-Drop — GitHub repository — the canonical source for the Edge-Drop codebase

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support