fix: Replace update notifier with simplified deps

[alexbrazier]

• Closes Consider removing/replacing update-notifier #1961
• Closes Update package-json to >=8.0.0 for vulnerability in got >= 12.0.0, < 12.1.0, < 11.8.5 #2028
• Fixes security issue with got (CVE-2022-33987)
• Replace update-notifier with simple-update-notifier which does the same thing but has one dependency (semver) rather than several
• Same caching settings as update-notifier

Demo

[netlify]

✅ Deploy Preview for nodemon ready!

Name	Link
🔨 Latest commit	65432a6
🔍 Latest deploy log	https://app.netlify.com/sites/nodemon/deploys/62bafb3c30e36400090079c9
😎 Deploy Preview	https://deploy-preview-2033--nodemon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[remy]

this is good, but I'm wary your windows test didn't pass: https://github.com/alexbrazier/simple-update-notifier/runs/7033149767?check_suite_focus=true

[alexbrazier]

this is good, but I'm wary your windows test didn't pass: https://github.com/alexbrazier/simple-update-notifier/runs/7033149767?check_suite_focus=true

@remy thanks for looking into it! I actually force pushed that update as the isTTY check was causing the update checker not to run on CI so had to update a flag to force it to run during the tests. That is original test run from the old commit and the latest one has all three passing https://github.com/alexbrazier/simple-update-notifier/actions/runs/2554631152

Edit: Looks like I was looking at the wrong build you referenced - that failure was an old one caused by the single quotes that Windows wasn't liking and has since been fixed

[zorn-v]

Seems it is not compatible with node 8.10.0 (minimum required version for nodemon) because for await
https://github.com/alexbrazier/simple-update-notifier/blob/91085738fbd27138dc510069d663e013e81af1eb/src/getDistVersion.ts#L10

[alexbrazier]

Seems it is not compatible with node 8.10.0 (minimum required version for nodemon) because for await
https://github.com/alexbrazier/simple-update-notifier/blob/91085738fbd27138dc510069d663e013e81af1eb/src/getDistVersion.ts#L10

Thanks @zorn-v, I've now pushed an update to fix that

[remy]

@alexbrazier worth wrapping this in a try/catch - https://github.com/alexbrazier/simple-update-notifier/blob/master/src/getDistVersion.ts#L13= - I can't remember what happens if this fails inside of the deep event handler - might be worth injecting some bad code to see how it behaves.

[alexbrazier]

@alexbrazier worth wrapping this in a try/catch - https://github.com/alexbrazier/simple-update-notifier/blob/master/src/getDistVersion.ts#L13= - I can't remember what happens if this fails inside of the deep event handler - might be worth injecting some bad code to see how it behaves.

Sure, something like this? https://github.com/alexbrazier/simple-update-notifier/pull/2/files

[MaximMaximS]

Tbh @remy, you should probably choose this or #2035, because it is pretty bad to have a random vulnerability in a project, which is used by a lot of people. When using npm, the alert is kinda discouraging.

[oldium]

@alexbrazier have you thought about using semver module instead of implementing your own version check?

[alexbrazier]

@alexbrazier have you thought about using semver module instead of implementing your own version check?

I was originally trying to keep it simple but now the version check has become more complicated than expected and still not perfect so happy to swap it out for semver if that is preferred?

[remy]

Tbh @remy, you should probably choose this or #2035,

I'm letting @alexbrazier have some time to settle the code base. It's not a straight up simple change and a few extra days to help iron out issues will be worthwhile in the long run.

Plus, the reality of the vuln in nodemon has near zero impact. Of course it's not zero, but there's no path to exploit the actual vuln through nodemon (partly because it's fired outside of calling your code - which would take advantage of the vuln, and partly because nodemon in a lot of cases forks the sub process, so it never has access to any of the nodemon code - and thusly the vuln on got).

The issue isn't being ignored, @alexbrazier has kindly and valiantly taken up the mantle to solve this dependency once and for all.

[alexbrazier]

Thanks @remy!

As the last couple of changes have been around some issues with the semver comparison and there were still some edge cases I've decided to just switch to using semver to make it more reliable. Should hopefully be good to go now unless anyone has any other comments.

[zorn-v]

semver 7.3.7 has

  "engines": {
    "node": ">=10"
  }

There is "semver": "^5.7.1" in nodemon deps

[alexbrazier]

semver 7.3.7 has

  "engines": {
    "node": ">=10"
  }

There is "semver": "^5.7.1" in nodemon deps

Hmm, I've tested with node 8.10.0 and it seems to work as expected:

[remy]

semver 7.3.7 has

  "engines": {
    "node": ">=10"
  }

There is "semver": "^5.7.1" in nodemon deps

Hmm, I've tested with node 8.10.0 and it seems to work as expected:

Are there any warnings during install if you're using node 8? It could be just that.

[alexbrazier]

Are there any warnings during install if you're using node 8? It could be just that.

Nothing when installing with npm, but seems there is an issue with yarn

[Axent96]

related to #2039 & #2040

[zorn-v]

Are there any warnings during install if you're using node 8? It could be just that.

Nothing when installing with npm, but seems there is an issue with yarn

You can use ~7.0.0 to avoid then

[alexbrazier]

You can use ~7.0.0 to avoid then

👍 Decided to go with this to avoid the yarn issue with node 8. Just pushed the update now.

[slaytr]

hi @remy is there a projected release date for this change?

[remy]

In the verry near future. Why are you asking? Is there a genuine situation that you've managed to find that the `got` package can be reached? (I'm certain it can't but it would be useful to share with others).

…

On Wed, 29 Jun 2022, 06:02 Bill Li @ SiteMinder, ***@***.***> wrote: hi @remy <https://github.com/remy> is there a projected release date for this change? — Reply to this email directly, view it on GitHub <#2033 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADLBG7D3ECCP5LLQAU3J3VRPKGVANCNFSM5ZXOO2GQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[remy]

@alexbrazier I want to merge this up, I feel like it's had it's time to percolate. But when I merge there's suddenly going to be, quite literally, millions of users in an absolute boat load of different scenarios using this library through nodemon.

So what I wanted to ask is: is there anything you're not 100% sure about? (Not meant as this is all on you!). I've been reading and re-reading your code to see if I can see anything.

Couple of things I wondered were:

• what happens with a network timeout (though IIRC these are really hard to catch as they seem to fire outside of the promises...)
• is it possible that the config directory or files can't be written, and what exception is thrown?
• are there any environments that original update-notifier disabled itself (like CI or TEST) that yours should take inspiration from (I currently don't think there are, but just putting the question out).

[alexbrazier]

@remy I would say I'm fairly confident with it as it's been tested down to node 8.10.0 and it currently handles errors in the background and chooses not to output anything if this happens to be on the safe side. I can't be 100% sure the cache/config dir is going to work on every OS particularly if there are some strict file permissions, however it's set to just catch these errors and just ignore the update check for now so should be handled.

I think it's the same thing for network timeouts or errors (I've tested without an internet connection) where the promise will reject it will just catch the error.

For the testing scenario it uses process.stdout.isTTY so will be ignored on CI/scripts which I think should cover most cases and I think is the same as what the original update-notifier used.

[peter-sattler]

Thanks for fixing this @alexbrazier. Looking forward to its deployment. :)

[github-actions]

🎉 This PR is included in version 2.0.19 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[jimmywarting]

Don't really like that modules creates files outside of it's own directory and caches things in config store files...
when i uninstall something then i want this files to be removed as well...

[remy]

@jimmywarting update-notifier was always doing this, and if you look in your ~/.config directory (assuming mac or linux - not sure where it is on windows), you'll find the other systems that store files outside of the directory.

[oldium]

What about this project focused to standardize the way of using the .cache folder? https://github.com/avajs/find-cache-dir

[remy]

Firstly, it isn't standardised. Secondly, again, the aim was to keep things the same as possible, and update-notifier was using an existing .config directory for many years prior.

[peter-sattler]

@jimmywarting and @remy - My suggestion is to create a different story if this makes sense to do, then the work can be prioritized accordingly. It’s not really a part of this PR.