Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Telemetry] Remind users about telemetry on each minor version #49644
[Telemetry] Remind users about telemetry on each minor version #49644
Changes from all commits
9586b4f
1823bbd
bec03fe
69dbee4
60a0759
07be553
d5e3950
d9e5690
4b7902e
dc11b3e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an FYI, Jest has helpers to make asserting on exceptions easier https://jestjs.io/docs/en/expect#tothrowerror
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does, I've used them before, but I couldn't get it to work this time. For some reason, it wouldn't catch the exception in the jest test, but then also claimed the exception that got thrown wasn't handled, and I was .... waaa??? ... spent 20 minutes trying to figure it out in the debugger, gave up, did it by hand :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change this to triple equals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's against my nature, since
==
catchesundefined
as well asnull
. I could be convinced otherwise, but don't remember doing a=== null
in a long time, unless I was specifically wanting to checknull
vsundefined
for some reason.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what valid situation would
attributes.enabled
beundefined
, and why should we returnnull
in that situation?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone (maybe us, accidently??) reset the saved object attributes to
{}
, theenabled
field would beundefined
, not null. In questionable cases like this (as well as if the semver wasn't parseable), I've made some arbitrary decisions, and in most cases, you'd want this to be considered "re-prompt the user".It's easy for me to imagine folks wanting to defeat banner-ism by hacking saved objects, so ... I've tried to be pretty conservative here in our checks of things users might be "providing" to use :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this scenario the fact that
enabled
is undefined is a bug and IMO we shouldn't act like it means something it doesn't. Looseness like this leads to subtle bugs that are hard to fix.That said, the stakes are low in this context, so if you don't want to make the change we can simply agree to disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll have to agree to disagree at this point, but would welcome some kind of project-wide guidance on this. As noted elsewhere, I think I lived for a while with a linter than MADE you use
== null
, so I'll admit my brain may be warped.Still, seems like unless you are specifically expecting a
null
ORundefined
, as semantically different things, from an API, you should always just use== null
for such checks. Also note, there are plenty of folks who shorten this check to!x
(fromx == null
), since it's often the case that this works as well, but those ones do kinda bug me :-)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Triple equals would be nice here as well if semver specifically returns
null
when there is a parse error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for cases like this, where there's a local function I can validate won't return
undefined
, I'm happier to to use a===
check, but still kind of consider it to be bad form, for future-proofing in case some day the called function DOES end up returningundefined
.I'm curious why you're looking for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs for semver's
parse
specifically state that null is returned if the value can't be parsed. You're guessing that in the future, ifparse
starts to returnundefined
, thatundefined
will mean the same asnull
. But that is not necessarily the case. Some future version ofparse
might returnundefined
for some other reason, and then we might have a bug on our hands because this condition is overly loose. I don't considernull
andundefined
interchangeable, they can mean two very different things depending on context.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I'd say, based on my years-long, unhappy history with
semver
(as much as I don't like it, it gets a lot of use, so it's the best out there, as long as you protect yourself), that we'd more likely see some future of version ofparse()
returnundefined
where it returnsnull
today, and then we might have a bug on our hands because=== null
is overly strict. :-)I don't trust 3rd party libraries much ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's also the case that I've used linters (
standard
?) that used to complain if you ever DID do an=== null
or=== undefined
. Happened to fit with my world view, so was happy with it. Or was I brainwashed?!?! hehThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, because our unit tests would catch this. The
=== null
condition would fail and we would get an unexpected result. This is the benefit of being strict. On the other hand, our unit tests would likely not catch the bug in my example because the looseness of the check may cover up an issue. Semver might respond to some issue by returning undefined but this==
check will make it look like everything is fine.My decades long, unhappy history with Javascript has taught me to never use double equals :) It's not just me:
https://2ality.com/2011/12/strict-equality-exemptions.html (look especially at Case 2)
https://stackoverflow.com/a/359509 (note in particular the quote from Javascript: The Good Parts)
Preferring triples equals is a best practice most of the community agrees upon.
But like I said above, the stakes in this particular situation are probably low, so if you are not convinced, we can agree to disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pro-tip: you will never convince me of anything based on references to "JavaScript: The Good Parts". hehe
I'm slightly curious, because I thought triple quotes were best practice for number/boolean/string, but double quotes was actually best practice for null/undefined.
It would certainly be interesting to add a lint rule disallowing
== null
and see what the vsCode Problems page looks like.quick search:
== null
=== null
=== undefined
== undefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was attempting an appeal to authority out of frustration since the concrete explanations I gave you are for some reason unconvincing. You didn't actually respond to the concrete explanation I gave about this specific piece of code we're looking at. You also ignored the information from the first link I provided, which has a section (which I called out) that specifically deals with this particular use of
==
. Instead you made a flippant comment about Javascript: The Good Parts and listed a statistic from the existing code base which is irrelevant to the discussion of whether using==
is actually a good idea, or if it is appropriate to use in this specific context. You also keep noting that the default ruleset of some linter you used encouraged use of==
. This is also an appeal to authority, except the authority is anonymous and their reasoning is unknown, so I would say this is also irrelevant to this specific conversation.I won't reply anymore, because I'm obviously extremely frustrated and this is not a productive conversation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: sent a note to Bargs offline, as I didn't realize his frustration level on this - I thought the issue was resolved but we were just having some banter on the topic of
== null
.