Last 12 weeks · 0 commits
2 of 6 standards met
I'm the author of UpgradeLink, an open-source, zero-modification-integration auto-upgrade tool specifically designed for Electron applications. UpgradeLink is completely open-source and free to use. The detailed Electron integration documentation and usage guide can be found here: https://github.com/toolsetlink/upgradelink Reduces the learning curve for new Electron developers who want to implement auto-upgrades without diving deep into Electron’s complex updater configurations. Saves development resources for teams of all sizes (indie developers, startups, enterprises) building Electron apps, allowing them to focus on core functionality instead of upgrade logic.
Repository: vercel/hazel. Description: Lightweight update server for Electron apps Stars: 3079, Forks: 403. Primary language: JavaScript. Languages: JavaScript (84.3%), Handlebars (15.7%). License: MIT. Homepage: https://twitter.com/notquiteleo/status/893547786255421441 Topics: electron, github-releases, updates. Latest release: 5.1.1 (4y ago). Open PRs: 20, open issues: 42. Last activity: 1y ago. Community health: 50%. Top contributors: leo, AndyBitz, safinn, dominiklessel, karanjthakkar, styks1111, 1000ch, thealexbaron, bhageena, LabhanshAgrawal and others.
JavaScript
Fixes an issue: "Error: Update check failed. The server sent an invalid JSON response. Try again later." because hazel is using VERCEL_URL to download the update (which is set to the branch URL, which is behind vercel auth for most projects) Fix: either disable System Environment Variables for the Hazel deployment in Vercel or merge this so that it respects over
Hello everybody! As you may have mentioned this repo has grown very cold and old, and now unable to work. I've taken the task upon myself for making a new maintained version. Firstly, there's almond which is a rewrite into TypeScript using Express. As of now all the current API routes from hazel should work with almond and in the future there will be more nice-to-haves. Secondly, for those that want to experiment I've started writting hazel into Go with the codename pecan. This is still incomplete and non-operational as of now. If anyone wishes to help contribute or drop some ideas, please feel free to do so. I made these rewrites to be more adaptable for various platforms and use cases.
I've been using Hazel, but I believe there's an error in the documentation for Programmatic Usage. The following code from the README does not work as expected. The request hangs and never receives a response. Diagnostics The issue is that specifies the main file as . Using also confirms that this file is loaded when calling the module programatically. exports a composed function with a object of options as its parameter and then expects to receive a and as the next function parameters. With the above code block, this means that is being passed as the config and the route handler is never called. This explains why the request never receives a response. This works with the auto-deploy on Vercel because uses the file to use , which loads the necessary config. Potential Solutions I have 3 different ideas on how this could potentially be resolved. 1. Change module resolution to By switching the module to resolve to , the API would work as intended. However, this would be a breaking change and require migration from existing projects. 2. Update Programmatic Usage example The package will be left as is, but documentation will need to be modified to show that a config will need to be specified. The option could also be shown to resolve directly to if the developer wants the same experience as the deploy button's zero-config magic. 3. Allow a config to get passed to To have both the zero-config magic and manual configuration in using Programmatic Usage, could be refactored to include an optional config parameter that would overwrite any environment variables set. I've made a repository to show this issue and easily reproduce. I'm happy to submit a PR with any changes to help improve this feature.