JavaScript, Best Practice and Chrome Updates
We had quite the scare this morning when Google Chrome updated to version 97 for our Windows developers; a Slack message from any dev that says “anyone else have this issue” is never good, but doubly so when it comes with a strange error message that I simply wasn’t seeing.
I asked to see the error since I had a moment of downtime anyway, and it was interesting:
Uncaught TypeError: cannot assign to read only property 'name' of function 'class Foo {
static name = "bar";...'A type error was strange to me; we’re in a pure JavaScript environment, so that certainly isn’t common. To my knowledge (at the time) “name” wasn’t a reserved word; I checked around just to make sure, and it didn’t seem to be. Better yet, there were no recent changes to that portion of code; it had been months since it was touched. So I asked, what version of Chrome are you on? Sure enough, I was on 96, they were on 97.
I quickly ran an apt upgrade and sure enough, a new Chrome version dropped. Lo and behold, the same error pops up now when an alternate Chromium on version 96 has no issue. Okay, so what changed?
Well, if I changed the name of the static variable, the error message went away entirely. Strange…
I went to google and searched for any V8 updates in Chrome 97. While there were some updates introduced, none that I could see reflected this behaviour. I could check out the git commits directly, but that seemed like overkill. After a moment I slapped myself for not thinking to just use the dev console to check what Foo.name was set to, now that I had changed the static variable name.
-> Foo.name
<- 'Foo'Ah. So this means that Class.name is supposed to hold the same as Class.prototype.constructor.name; well, at least that’s a convenient way of writing that out now (it doesn’t come up often, but when it does I’ll remember that).
It makes sense; function.name returns the name of the function, and classes aren’t any different from functions in JavaScript. This really should have been self-evident.
I then started to feel embarrassed, as though I should have known for ages that Class.name served a purpose and shouldn’t just be overwritten. I’m still questioning if I get to call myself a developer after not realizing that we were breaking conventions. But as I’ve thought more on it, how were we really supposed to know? And a better question, why did Chrome allow us to overwrite Class.name in the first place?
You can follow all the tutorials on earth for a language and still find out things you didn’t know. Classes in JavaScript aren’t exactly widely used; many projects use TypeScript and transpile to different browsers, so it’s not like you see many instances (pun intended) of classes. If you’re coming from the OOP world, like me, JavaScript with prototypes, functions and vars seems archaic and weird; you work with what you’ve got, though. And lucky for me, classes exist and are awesome for OOP in the language.
Reflecting on it, this was very clearly a bug; you should never be able to overwrite the name of a function. The fact that we’ve not seen issues with this since we wrote this class means it’s been a longstanding bug, too. I’d love to hear how this was discovered and what dev thought “oh, better fix this”; I’d also love them to know that they broke our app and reminded us of JavaScript basics all in one fell swoop. I’m not upset in the least; in fact, thank you, whoever you are, you’ve actually given us a lot of food for thought and a reminder to keep our knowledge up to date.
I did push out a fix for the issue, and it will later be merged into production. We weren’t exactly planning a push to production today, but considering our clients might wake up with an update, Shiny and Chrome, well… I’m not ready for Valhalla just yet, and neither are they. So kudos to Chrome for not breaking things over the Holidays and instead on a Thursday, when I can actually fix the issues with our code.
