Squirrel.Windows is no longer maintained

[dengyaolong]

https://github.com/Squirrel/Squirrel.Windows is no longer being maintained.

This project is no longer maintained, pull requests are no longer being reviewed or merged and issues are no longer being responded to.

so electron updater for windows will give a plan? still use squirrel or another update tech?
or use updater like electron-builder built-in updater ?

[MarshallOfSound]

We are aware of the situation and are currently assessing the courses of actions we could take 😄

[yklykl530]

@MarshallOfSound Excuse me, I would like to ask if there is a phased conclusion on the discussion of the official upgrade plan of Electron.

[shiftkey]

Just wanted to bump this issue to point to a discussion about rebooting Squirrel.Windows to keep the project going Squirrel/Squirrel.Windows#1470 - we'd love others to help get involved...

[b-zurg]

So it's been a year now since this issue was first brought to light. In that time it seems there's been no real activity on Squirrel.

But let's put that aside and say squirrel has enough attention and the few hopefuls with full-time jobs who want to contribute actually pull through - the necessity of having a release server is a big barrier to many who would like a cost-effective, secure, and easily maintainable update solution. None of the release servers officially documented are well-maintained except for Hazel (looks like Hazel is biting the dust too) and most of the options require integration with Github releases.

This means that anybody who...

1. doesn't want to rely on an unmaintained installer for reliably providing updates to their users
2. doesn't want to rely on Github releases' api limit (5000 requests / hour)
3. doesn't want to rely on release servers that are not maintained for years
4. Is not integrated deeply into Github's ecosystem

literally has no option but to go the route of adopting a non-official update route provided by electron-builder which allows for serverless updates with a well-maintained installation solution.

I am by no means a domain expert and am just presenting some observations and a few weeks of struggle with the current state of the ecosystem.

My two cents is that the electron team needs to give a hard look at this critical piece of the picture and its valid pain points and provide a solution that gives its users confidence.

[shash7]

Just a noob electron dev checking in. What's the meta these days? Electron builder or forge? And squirrel or NSIS for windows?

[LeonardoRick]

I'm new too and completely lost on my first build too. Have no idea what path to follow.

[korakot25]

Hi

[caesay]

In case anyone here is interested, I have been working on a fork of Squirrel for the last year, am actively maintaining it, and have improved hundreds of things and fixed most of the existing bugs.

Notably, it's now much faster, dependency free (no longer requires the net framework), among many other things. It's already been picked up by a few very big projects.

I'd be willing to discuss and work with people here if there is any interest in adopting it as a replacement in electron for Squirrel.Windows.

[mikehearn]

@Christilut Let's take it to the Conveyor forum (see link above). Our comments are being marked off-topic here.

[jbtobar]

So it's been a year now since this issue was first brought to light. In that time it seems there's been no real activity on Squirrel.

But let's put that aside and say squirrel has enough attention and the few hopefuls with full-time jobs who want to contribute actually pull through - the necessity of having a release server is a big barrier to many who would like a cost-effective, secure, and easily maintainable update solution. None of the release servers officially documented are well-maintained except for Hazel (looks like Hazel is biting the dust too) and most of the options require integration with Github releases.

This means that anybody who...

1. doesn't want to rely on an unmaintained installer for reliably providing updates to their users
2. doesn't want to rely on Github releases' api limit (5000 requests / hour)
3. doesn't want to rely on release servers that are not maintained for years
4. Is not integrated deeply into Github's ecosystem

literally has no option but to go the route of adopting a non-official update route provided by electron-builder which allows for serverless updates with a well-maintained installation solution.

I am by no means a domain expert and am just presenting some observations and a few weeks of struggle with the current state of the ecosystem.

My two cents is that the electron team needs to give a hard look at this critical piece of the picture and its valid pain points and provide a solution that gives its users confidence.

Pinging this back up.

@MarshallOfSound judging from your comments over the years you seem to have some beef with electron-builder and it is leading new users astray. However, that is not the point. The point is what @b-zurg very eloquently describes in the above comment.

What should we use? NSIS or Squirrel? And why?

In this comment here: electron/forge#485 (comment) you suggest Squirrel is alive and well and is recommended. Then in the discussion here
#17722 (comment) it seems that Squirrel is dead and you are "assessing the situation". Ok, so what did you assess, and why?

I used electron-builder for nearly 3 years for crossplatform distributing with NSIS on Windows, AppImage on linux, auto-updates - and it has worked like a charm, beautiful.

I began my app from scratch recently and saw the big "Forge 6" announcement. I jumped in because it is the "official tooling". Build the whole app and now when its time to publish I realized Forge doesnt support NSIS, doesnt support AppImage, auto-updates come with caveats and require instantiating a server if app isn't open source github release, etc. So after putting all this work into the "new official electron packaging pipeline" I realize that electron-builder is better than the "official tooling" so I have to go back to square one. This isn't a problem - I should have evaluated both options before starting. What is a problem is that there is no clear information to evaluate both options. All there is is talk about the "philosophy" of one or the other. All I care is about shipping a good app to my users. And I can't seem to inform myself what the best tooling is.

So, @MarshallOfSound, all many of us want to know is a direct answer to the following questions - so it would be really awesome if you can shine a light on this:

1. Why should one choose Squirrel over NSIS for auto-updates? Does the fact that Squirrel has some maintenance/deprecation issues factor into this?
2. Why does forge not support appimage on linux? Is it because the other alternatives are superior? If so, why?

Apologies about the rant but attempting to inform myself about what the best course of action has been quite frustrating and I just want to ship my app.

[MarshallOfSound]

In this comment here: electron/forge#485 (comment) you suggest Squirrel is alive and well and is recommended. Then in the discussion here
#17722 (comment) it seems that Squirrel is dead and you are "assessing the situation". Ok, so what did you assess, and why?

Just to point out the obvious, those comments are a year apart? 🙃 The first comment is still my stance though 😄 Read below for the "what did you assess" I guess.

Why should one choose Squirrel over NSIS for auto-updates?

Because the majority of the big Electron apps use Squirrel or some variant there-of. Using a different technology that "just works" is fine and good until people come running to us saying "why did this break", "how do I fix this", "how does this work" which happens more than you'd realize and their have been several historical issues specifically with NSIS and the electron-updater module (or maybe the old name electron-auto-updater) where it hasn't worked, has bricked installs, has left folks stranded, etc. There's a lot to be said for the near decade of battle testing that Squirrel has gone through.

There is also a lot of incorrect information out there about stuff to do with Squirrel. For instance even in your comment:

auto-updates come with caveats and require instantiating a server

This is simply fundamentally incorrect. Both Squirrel.Mac and Squirrel.Windows can update from any static storage solution like S3 or GCS or whatever you might want to use. In fact electron-updater the package that you must have used with builder uses Squirrel.Mac under the hood 🙃

The popularity of NSIS in builder was a forcing function of the builder maintainers declaring the squirrel windows target "deprecated" and that has never been the official stance of the electron maintainers. It is still our preferred installation / distribution technology on windows and there is no reason for that to change currently.

This is partially on us as our documentation (although massively improved in the last few months) still has several key gaps including probably a doc that would have saved you here "Auto updaters with Forge and S3" or something 😀

Does the fact that Squirrel has some maintenance/deprecation issues factor into this?

No, because those issues haven't had any meaningful impact on Electron or the ecosystem if they even exist. Squirrel is relatively stable and hasn't required any changes recently, if it came to it the Electron team is more than willing to do what is required to ensure the ecosystems continued usage of Squirrel.Windows is viable or provide a valid path to an alternative. Don't forget as I mentioned above most of the biggest Electron apps are using Squirrel, you'd be on the same side as the engineering teams at msft, slack, etc.

I realized Forge doesnt support NSIS, doesnt support AppImage,

This also technically isn't correct, the whole point of forge is it's extensible, pluggable and anyone can do anything if compatible tools are built. For the two you listed builder publishes interop layers for forge to expose their nsis and appimage targets amonst others.

Why does forge not support appimage on linux? Is it because the other alternatives are superior? If so, why?

Forge doesn't support appimage directly because (a) as mentioned above, it's already supported via a community maker and (b) alternatives are tangibly better, for instance snap. Has a store, is fully isolated, and you don't need to worry about an updater at all because the store manages it all for you.

[MarshallOfSound]

Per comment above and elsewhere, Squirrel.Windows isn't going anywhere right now. The Electron team is always discussing key things like our updater technology and if their are any changes in this area the first place you'll hear about them is probably our blog. Folks should continue using Squirrel.Windows like the rest of us 😄

[jbtobar]

In this comment here: electron/forge#485 (comment) you suggest Squirrel is alive and well and is recommended. Then in the discussion here
#17722 (comment) it seems that Squirrel is dead and you are "assessing the situation". Ok, so what did you assess, and why?

Just to point out the obvious, those comments are a year apart? 🙃 The first comment is still my stance though 😄 Read below for the "what did you assess" I guess.

Why should one choose Squirrel over NSIS for auto-updates?

Because the majority of the big Electron apps use Squirrel or some variant there-of. Using a different technology that "just works" is fine and good until people come running to us saying "why did this break", "how do I fix this", "how does this work" which happens more than you'd realize and their have been several historical issues specifically with NSIS and the electron-updater module (or maybe the old name electron-auto-updater) where it hasn't worked, has bricked installs, has left folks stranded, etc. There's a lot to be said for the near decade of battle testing that Squirrel has gone through.

There is also a lot of incorrect information out there about stuff to do with Squirrel. For instance even in your comment:

auto-updates come with caveats and require instantiating a server

This is simply fundamentally incorrect. Both Squirrel.Mac and Squirrel.Windows can update from any static storage solution like S3 or GCS or whatever you might want to use. In fact electron-updater the package that you must have used with builder uses Squirrel.Mac under the hood 🙃

The popularity of NSIS in builder was a forcing function of the builder maintainers declaring the squirrel windows target "deprecated" and that has never been the official stance of the electron maintainers. It is still our preferred installation / distribution technology on windows and there is no reason for that to change currently.

This is partially on us as our documentation (although massively improved in the last few months) still has several key gaps including probably a doc that would have saved you here "Auto updaters with Forge and S3" or something 😀

Does the fact that Squirrel has some maintenance/deprecation issues factor into this?

No, because those issues haven't had any meaningful impact on Electron or the ecosystem if they even exist. Squirrel is relatively stable and hasn't required any changes recently, if it came to it the Electron team is more than willing to do what is required to ensure the ecosystems continued usage of Squirrel.Windows is viable or provide a valid path to an alternative. Don't forget as I mentioned above most of the biggest Electron apps are using Squirrel, you'd be on the same side as the engineering teams at msft, slack, etc.

I realized Forge doesnt support NSIS, doesnt support AppImage,

This also technically isn't correct, the whole point of forge is it's extensible, pluggable and anyone can do anything if compatible tools are built. For the two you listed builder publishes interop layers for forge to expose their nsis and appimage targets amonst others.

Why does forge not support appimage on linux? Is it because the other alternatives are superior? If so, why?

Forge doesn't support appimage directly because (a) as mentioned above, it's already supported via a community maker and (b) alternatives are tangibly better, for instance snap. Has a store, is fully isolated, and you don't need to worry about an updater at all because the store manages it all for you.

@MarshallOfSound Thank you very much for your quick response. I was really stuck as to how to move forward and your response has given me more confidence to just stick with forge.

Informed by your response what I will do is use auto-update with nucleus for mac/windows squirrel updates and the snap store for linux. (btw the auto-update documentation of using a static storage is not clear as it only mentions nucleus,nuts,hazel,etc for auto-updates).

Apologies my comment was heated. Thank you for taking the time to answer and thank you for you work on the project.

[MarshallOfSound]

(btw the auto-update documentation of using a static storage is not clear as it only mentions nucleus,nuts,hazel,etc for auto-updates).

For sure, I've made a note of this and hopefully will get some better documentation on this out soon. You should be able to just use @electron-forge/publisher-s3 and the built-in autoUpdater module directly with minimal configuration

[shayded-exe]

(btw the auto-update documentation of using a static storage is not clear as it only mentions nucleus,nuts,hazel,etc for auto-updates).

For sure, I've made a note of this and hopefully will get some better documentation on this out soon. You should be able to just use @electron-forge/publisher-s3 and the built-in autoUpdater module directly with minimal configuration

Thank you!

Please also consider adding information for people who are deploying to internal enterprise networks like a network share. We can't have any public s3 buckets so s3 is out of the question. In the end we're deploying it to a local network share, but that isn't talked about anywhere. It also doesn't explain how to handle structuring your updates directory when the RELEASES file generated by Squirrel needs to be in the root. Having a subfolder per version like the S3 publisher does by default doesn't seem like it would work with that.

I've had to spend many hours reading through the source code of forge, electron-winstaller, squirrel, autoUpdater, etc. to figure out how all of this exactly works together. The documentation lacks a lot of details or examples showing how everything interacts. It's very confusing if you aren't on the happy path. Stuff like #17722 (comment) should be noted in the docs. Far too often do I finally find the details I'm looking for after hours of reading through issue threads.

Tangentially related, I had to eject from forge after hours of struggle getting things to work correctly. I'm using electron-vite for the build so I have a separate build directory. Forge provides little to no info regarding what to do in a situation like this. Eventually I just wrote my own build scripts using electron-packager and electron-winstaller directly and had a much easier time.

Sorry for the rant, had to vent a bit of frustration from the past few weeks. I really appreciate the amazing work y'all do and I'm happy to see things are improving.

Now I'm trying to set up a way to handle multiple release channels.

[MarshallOfSound]

I'm using electron-vite for the build so I have a separate build directory. Forge provides little to no info regarding what to do in a situation like this. Eventually I just wrote my own build scripts using electron-packager and electron-winstaller directly and had a much easier time.

Yeah using things like vite, webpack, etc. are complicated even when writing your own build systems. Forge currently has built-in support for webpack via a forge plugin and there's an open PR where we're working on adding support for vite via a forge plugin too which once shipped will make using vite with forge super easy.

Please also consider adding information for people who are deploying to internal enterprise networks like a network share. We can't have any public s3 buckets so s3 is out of the question. In the end we're deploying it to a local network share, but that isn't talked about anywhere.

Hm, this is tricky because although Squirrel.Windows supports file:// style URLs I don't believe that Squirrel.Mac does very effectively. I believe our suggested approach here would be to host some kind of static file server inside your intranet/ lan that could be backed by a network share but is accessible over http.

The docs / explanation for how the S3 uploader is going to work in the future should hopefully paint a much clearer picture for folks wanting to publish and update using a different static storage provider.

Having a subfolder per version like the S3 publisher does by default doesn't seem like it would work with that.

This is changing soon --> electron/forge#3108
Along with a better way of generating the static macOS updater manifest --> electron/forge#3107

Hopefully you'll see these docs / improvements before the end of the year, but if not they'll definitely coming flying in hot early next year when everyone is back from their respective breaks

[tbertels]

The fork https://github.com/clowd/Clowd.Squirrel could be switched to in case there's any need in the future.

[nkallen]

Hi,

I've been using squirrel and for some small percentage of users the installer never terminates (though the app is installed successfully). It's hard to know the root cause but it may be a race condition when several squirrel (electron) apps are auto-updating simultaneously (if you have discord and teams installed for instance). I just want to note that for me squirrel+electron hasn't been a positive experience and I would like to move away from it. I'm investigating both msi and nsis but both are difficult with forge unfortunately.

[mikehearn]

@nkallen If you want to stop using Squirrel entirely, there is a new section of the Electron website that discusses alternative tools:

https://www.electronjs.org/docs/latest/tutorial/forge-overview

(expand the expando). The second tool* is independent of Squirrel and will automatically integrate MSIX on Windows and Sparkle on macOS.

*disclosure: I made it

[eastrd]

Using a different technology that "just works" is fine and good until people come running to us saying "why did this break", "how do I fix this", "how does this work" which happens more than you'd realize and their have been several historical issues specifically with NSIS and the electron-updater module (or maybe the old name electron-auto-updater) where it hasn't worked, has bricked installs, has left folks stranded, etc. There's a lot to be said for the near decade of battle testing that Squirrel has gone through.

Unfortunately that was not my experience, for the past two weeks I've had to refactor my Electron app due to a lack of understanding on configuring webpacks to work with Electron so I've had to rely on Electron boilerplates with different toolings, and one of the boilerplates that I've spent the last 15 hours on was using Electron-Forge.

The initial experience of me implementing Electron Builder for my app was alright - there were a few issues here and there but most of the things work within my expectations and I could quickly find solutions.
However, that was not the case when I tried to refactor my app into using Electron Forge, I found myself asking more and more questions of "why did this break", "how do I fix this", "how does this work" when I was using Electon Forge. To me, the whole experience of using Forge was painful and frustrating. The tooling feels very quirky IMO. (e.g. checkForUpdate would throw an error if it's running outside of a packaged and installed app, I don't see a comment on whether or how you can bypass that. I cant even test the updater without packaging it first, this was very different from the experience I had when using Electron Builder - at least I could trick electron-updater into thinking it's packaged by overwriting the property isPackaged)

This is simply fundamentally incorrect. Both Squirrel.Mac and Squirrel.Windows can update from any static storage solution like S3 or GCS or whatever you might want to use. In fact electron-updater the package that you must have used with builder uses Squirrel.Mac under the hood 🙃

Yes but what about just Github itself?
Please correct me if I'm wrong, but in Forge you'd either have to use the Electron server's free endpoint or provide your own, why can't Forge just be like Builder, simply go up Github release section and check the files? Why is there an extra hop of having to reach the update.electronjs.org URL to fetch these update info that could be done without?

No, because those issues haven't had any meaningful impact on Electron or the ecosystem if they even exist. Squirrel is relatively stable and hasn't required any changes recently, if it came to it the Electron team is more than willing to do what is required to ensure the ecosystems continued usage of Squirrel.Windows is viable or provide a valid path to an alternative. Don't forget as I mentioned above most of the biggest Electron apps are using Squirrel, you'd be on the same side as the engineering teams at msft, slack, etc.

Large enterprises tend to choose the tools with lots of supports because it’s a safe bet and they can afford it. This does not imply those tools are well-designed or robust, and vice versa.

This also technically isn't correct, the whole point of forge is it's extensible, pluggable and anyone can do anything if compatible tools are built. For the two you listed builder publishes interop layers for forge to expose their nsis and appimage targets amonst others.

I've been searching everywhere for an example of how to use the nsis maker in Forge, I've seen others asking the same thing as well, yet the nsis page that you mentioned had already been pointing to Electron Builder's repo. (and yes, I do realize it's been almost a year since your last comment, I suppose it just shows how much things have changed)

I applogize for my rant. I am certain there are things about Electron Forge that I’ve missed and may have made unfair calls due to my ignorance.

I’m keen to hear your thoughts.

[nkallen]

Hi,

I do like the user experience Squirrel's installer. Some power users would prefer specifying the installation directory.

But I want to push back on "it just works". I have many tens of thousands of users. I get a couple reports like this each week:

[MarshallOfSound]

However, that was not the case when I tried to refactor my app into using Electron Forge

Switching from builder to forge is not as easy as we'd like it to be, but that isn't the green path forge has been optimized for. If you started your app with forge from the beginning things like webpack would Just Work ™️.

Why is there an extra hop of having to reach the update.electronjs.org URL to fetch these update info that could be done without?

Simple, github releases are behind the github api rate limit. If you want your updates to not work because the user has hit the github api more than 60 times an hour, sure, static files on github releases work just fine. But we don't want to do that, so instead we provide an open source free proxy that arguably works better than the direct approach 🤷

If you have specific issues with forge please raise issues or ask in the discord, folks will try our best to help you out.

But I want to push back on "it just works". I have many tens of thousands of users. I get a couple reports like this each week:

That looks like you aren't changing the default installer gif? Not sure why it would be getting stuck but the squirrel install log would tell you.

[nkallen]

Hi,

Yes I'm not changing the default installer gif, (unlikely that's the issue). The squirrel logs have nothing useful (I've had about a dozen users send me them at this point). The only suggestive evidence I have is that users have reported it failing while Discord was updating itself during an install. Could be a red herring though. Let me put it like this though: it is basically impossible to debug this and squirrel is basically unmaintained so there's no support to look towards either.

Let me provide an example. Here is a recent install on a test machine that failed. It's a reinstall.

From Squirrel-Install [global squirrel log]

[17/09/23 12:08:08] info: Program: Starting Squirrel Updater: --install .
[17/09/23 12:08:08] info: Program: Starting install, writing to C:\Users\nickkallen\AppData\Local\SquirrelTemp
[17/09/23 12:08:08] info: Program: About to install to: C:\Users\nickkallen\AppData\Local\plasticity_beta
[17/09/23 12:08:08] warn: Program: Install path C:\Users\nickkallen\AppData\Local\plasticity_beta already exists, burning it to the ground
[17/09/23 12:08:10] info: CheckForUpdateImpl: Reading RELEASES file from C:\Users\nickkallen\AppData\Local\SquirrelTemp
[17/09/23 12:08:11] info: CheckForUpdateImpl: First run, starting from scratch
[17/09/23 12:08:12] info: ApplyReleasesImpl: Writing files to app directory: C:\Users\nickkallen\AppData\Local\plasticity_beta\app-1.3.0-beta28
[17/09/23 12:08:16] info: LogHost: Rigging execution stub for plasticity-beta_ExecutionStub.exe to C:\Users\nickkallen\AppData\Local\plasticity_beta\plasticity-beta.exe
[17/09/23 12:09:14] info: ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\nickkallen\AppData\Local\plasticity_beta\app-1.3.0-beta28\plasticity-beta.exe]

<EOF>

From Squirrel-Shortcut [my app's squirrel log]

[17/09/23 12:09:14] info: Program: Starting Squirrel Updater: --createShortcut=plasticity-beta.exe
[17/09/23 12:09:14] info: ApplyReleasesImpl: About to create shortcuts for plasticity-beta.exe, rootAppDir C:\Users\nickkallen\AppData\Local\plasticity_beta
[17/09/23 12:09:14] info: ApplyReleasesImpl: Creating shortcut for plasticity-beta.exe => C:\Users\nickkallen\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Nick Kallen\plasticity-beta.lnk
[17/09/23 12:09:15] info: ApplyReleasesImpl: About to save shortcut: C:\Users\nickkallen\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Nick Kallen\plasticity-beta.lnk (target C:\Users\nickkallen\AppData\Local\plasticity_beta\plasticity-beta.exe, workingDir C:\Users\nickkallen\AppData\Local\plasticity_beta\app-1.3.0-beta28, args , toastActivatorCSLID 6970a6db-d5ae-5da6-b320-14e219cc5a15)
[17/09/23 12:09:15] info: ApplyReleasesImpl: Creating shortcut for plasticity-beta.exe => C:\Users\nickkallen\Desktop\plasticity-beta.lnk
[17/09/23 12:09:15] info: ApplyReleasesImpl: About to save shortcut: C:\Users\nickkallen\Desktop\plasticity-beta.lnk (target C:\Users\nickkallen\AppData\Local\plasticity_beta\plasticity-beta.exe, workingDir C:\Users\nickkallen\AppData\Local\plasticity_beta\app-1.3.0-beta28, args , toastActivatorCSLID 6970a6db-d5ae-5da6-b320-14e219cc5a15)
[17/09/23 12:09:15] info: Program: Finished Squirrel Updater

The squirrel global log didn't complete the install process; it would normally continue with entries like this:

[12/09/23 08:34:26] info: ApplyReleasesImpl: Starting fixPinnedExecutables
[12/09/23 08:34:26] info: ApplyReleasesImpl: Fixing up tray icons
[12/09/23 08:34:26] info: ApplyReleasesImpl: cleanDeadVersions: checking for version 1.2.16
[12/09/23 08:34:26] info: ApplyReleasesImpl: cleanDeadVersions: exclude new version folder app-1.2.16
[12/09/23 08:34:27] info: Program: Finished Squirrel Updater

I have briefly looked at the squirrel source code, I've asked for support in the forge discord three times... but this is still an unsolved problem