-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve detection of Chrome channel variants #61
Conversation
Let's remove that line altogether (L48):
We already have the |
Breaking: remove 'bitness' from chrome metadata
0702e27
to
967fdca
Compare
I've merged the change to drop bitness, and we're all good now I think. Updated debug output for reference:
|
Released 5.0.0. Thanks! |
Amazing, thank you! 👍 |
Working towards a fix for #55, based on the comments there. This implements the suggested change, and improves the detection in general, especially for beta & dev channels.
Output of
node cli.js --debug
with lots of Chromes installed on a Windows 10 VM:That said, while this is an improvement, I haven't reproduce the reported issues, so I can't confirm that the ChromeHTML key is the main culprit.
I did manage to hit issues on this test environment due to the default 'stable' assumption from
find-update-clients
though. That's definitely incorrect for a few cases here. My installed dev & beta versions for example have exactly the sameap
value, but different channels. Notably my stable install does explicitly say stable here (x64-stable-statsdef_1
), so I've changed this to an explicit check.I'm a bit suspicious of the bitness check in
find-update-clients
too, since it defaults to 32, which would cause this reported issue. I can't reproduce a similar error myself here, but how would you feel about something likeap.has('x64') ? 64 : null
instead? I'm assuming there's no explicit 32 bit value we can check for.