Possible bug in JavaScript Basics, Unit 3 Challenge task

I agree with Steven, reporting this to Support seems like a good idea. I doubt the intention was to forbid you from creating an intermediate variable to solve this.

That first one alters the contents of width which I don't think is part of the intent of the exercise. If that one passes I'd say it is also a bug.

It does pass - I tried both before posting them. I see what you're saying, but it seems debatable - in a real solution, you wouldn't declare something as a string only to immediately parse it separately, so it would seem that any solution that successfully parses the string and uses it in a calculation would satisfy the intent. Changing the variable's value would only be an issue if we actually still needed the string value for something, and we don't. Changing width's initialization value would definitely violate the challenge's intent, because it would subvert the need to parse, but I don't think changing the value later necessarily goes against the intent (I'll leave that up to them, though).

Just like in the real world, you don't know if this code is intended to be expanded later in some way. We just don't know if the variable is intended to be used again in a way that would require it to stay intact. It would certainly be extremely odd to initialize a variable using a string with both a number and a unit designation if it was never to be used other than as a numeric value.

So on general principle I would consider altering any of the initial values when not explicitly asked to in the instructions would be a legitimate cause for a fail. But allowing that to pass is not as serious a bug as failing a solution just for creating an intermediate variable.

I don't disagree - my point is really that the challenge is focused on making sure you know how to convert - it's not set up to look like an actual solution. In a real solution, you simply wouldn't declare a pointless variable in the first place - you'd probably just convert it inline if you had to pull it from a user input or some other string-based location, but the challenge is set up otherwise so that you can convert it separately, to prove that you picked up the concept. The best solution is to do it all in one line without changing the variable, but sometimes when learning it's easier to read/follow if it's separated out a bit. I generally don't assume how comfortable someone is with reading code when I answer a question, hence my offering of a one-line and a separated solution. Normally you'd do that with an intermediate variable, but, well.. that didn't work, and that's why we're here.

You're correct that you usually wouldn't do that in a real solution, but what I'm saying is that this challenge isn't set up like a real solution - it's just meant to illustrate whether you can use the parse method with correct syntax. To that end, I think both of these solutions AND the one Emanuel had originally should pass - they all successfully use parseInt().

Again, I really don't disagree with what you're saying - just trying to accurately illustrate my point. I personally feel that challenges should grant a pass for following the instructions and obtaining the desired result, within reason. That's just based on my own opinion of the purpose of the quick challenges, though - I definitely get what you're saying, and do feel that promoting best practices is important too. If anything, this conversation has made me think about how deeply the code-checking code should go into making sure the answer is correct AND that best practices are encouraged.