Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Updater module #292
It was hard testing without actually having a
@mklabs Since you're our code master, would you mind taking a look and let me know if there's anything weird going on?
The API is simple. You call updater.getUpdate() each time your module is run and it will handle the rest for you. It will skip the update if the time since last update hasn't passed.
For testing I've set
The module comes with a prefilter (
Notes on user experience/possibly bugs:
It says that I have version 0.5.13 and that 0.3.14 is the latest version. Great. In the update available line however it says current 0.3.14. Does this mean the update available is 0.3.14? If so, why show the 0.5.13 in this context? Would that not confuse the user? I read this as 0.5.13 was available, but 0.3.14 was the update available (which feels weird to say). I'd just show the version available remotely personally.
Please feel free to let me know if I misinterpreted anything. Sure I have somewhere :)
Great work on this otherwise. The refactor looks awesome!
Right now it just exits, but I like the idea of capturing the command and just continuing.
I'm not sure that's necessary. The update check is superquick and the update process itself is heavily console.log'd and process.pipe'd. Anyone else feel this is necessary? The reason I'm a bit against it is because I would like to keep the updater module fairly generic.
That is because you've set the current version to higher than the latest version, which would never happen in a real scenario. Actually the original updater did check the last number first, but that was wrong, since it would return 'patch' on current 0.2.0 and latest 0.3.1, which obviously is 'minor'.
@addyosmani Done :)
I just put everything in bin/yeoman into a init() method and execute that after the update check. I had to change some of the semantics. Previously the getUpdate() callback was executed after the update check. It's now executed after the update is complete, which makes more sense, now that the updater handles all the update stuff and console.logging anyway. Thoughts?
We need to look into how to better handle the various error points at a later time.