Opens multiple Alfred instances
When an update is found, Alfred is opened using open -n -a "Alfred 3":
https://github.com/SamVerschueren/alfred-notifier/blob/1655892dbf56402bf13ad777cb8f59434cad668a/check.js#L36
This causes a second instance of Alfred to open which can lead to a few issues. For example, if Alfred is open and you press its hotkey, Alfred no longer closes (presumably because it opens the second instance).
I'm not sure why we use the -n flag. I think we can just drop it. @SamVerschueren ?
Good point, I think we can.
FYI, this bug breaks Alfred's snippet expansion (two running Alfred instances means each snippet gets expanded twice).
As I understand it, the aim is to get Alfred to reload a symlinked workflow after an update. Deleting and re-creating the symlink is the best way to do that, imo. Alfred will notice that change and reload the workflow. It can't otherwise tell when symlinked workflows are updated because FSEvents, which Alfred uses to watch for changes in its preferences bundle, doesn't resolve symlinks.
Thanks for weighing in, @deanishe. The aim is to get Alfred to reload the workflow after the subtext in the Info.plist is updated. Having this in mind, #9 basically breaks alfred-notifier since the updated subtext won’t be displayed until Alfred reloads the workflows for other reasons.
Deleting and recreating the symlink indeed seems to be the best solution. I’ve also tried touch -h but Alfred didn’t pick up on any changes.
This might no longer be an issue with Alfred 4. From Alfred’s changelog:
Prevent multiple copies of Alfred from running if, for example, a workflow accidentally attempts to re-launch Alfred as a new process
I actually found a solution in alfred-updater by killing Alfred first and then re-opening it. It's this block https://github.com/SamVerschueren/alfred-updater/blob/master/index.js#L67-L74.
Alfred 4 does indeed prevent this but it shows a warning message

The reason alfred-notifier doesn't do this for Alfred 4 is because it tries to start Alfred 3 still :p. So have to fix that first.
I actually found a solution in
alfred-updaterby killing Alfred first and then re-opening it.
This solution won’t work for alfred-notifier, though, right? After all, the update check runs while the user is interacting with the workflow so we wouldn’t want to kill Alfred during that.