Freecodecamp: asi: suppress 'missing semicolon' warning in editor

[no-stack-dub-sack]

@freeCodeCamp/moderators What does everyone think about suppressing the 'missing semicolon' linter warning in the editor?

With asi, manually adding semicolons is rarely needed except in some very specific cases, and the semicolon-less style in ES6/ES7 is becoming more popular (or at least sparking debate) among the JS community (try looking through the lodash codebase, you won't find a single semicolon! Same with NPM — quick example).

Point being, with this being the case, I don't think it's as important that this be stressed so forcefully, even with new developers. This warning pops up so frequently during coding challenge solutions, that it just ends up becoming a pesky problem rather than a helpful linter error, which is what I think the point of the linter should be.

If it's not going to cause problems in their code, and is not even a stylisitc must like it used to be, why bother warning campers about it every other line of code?

Overall, I think this would be a small, but highly impactful UX improvement (and an easy fix, simply add asi: true right here and here).

Thoughts?

[raisedadead]

Oh, boy! Lets not start the semi or no-semi (because, tabs vs spaces war is long over) war here!

All, jokes aside, yes please, we should not be limiting / enforcing any style preferences, et al. Lets be flexible for all such preferences.

Are this only ones?

[no-stack-dub-sack]

@raisedadead haha! Yeah, I know, dangerous ground 😄

The only other linter warning I can think of off hand that would be a stylistic type choice would be the laxbreak rule, which, when set to true would suppress warnings for what the linter thinks is a dangerous line break... take the popular ternary syntax, for example:

const isAnnoying = linter.laxbreak
  ? true
  : false

This would throw a linter warning about 'misleading line-breaks', however, this has come to be the accepted syntax for multi-line ternary expressions.

I vote 'YES' for suppressing both of these warnings!

[no-stack-dub-sack]

@raisedadead @Ethan-Arrowood unless anyone dissents, I'll go ahead and make a PR for this tomorrow at some point.

@BerkeleyTrue @QuincyLarson do either of you want to weigh in on this?

[BerkeleyTrue]

is rarely needed except in some very specific cases

I understand the desire but it is this very reason we do enforce it and why it is enforced in the codebase.

Semicolons are not a style choice. If they were then you would never run into errors because of their absence as apposed to 2/4/tab indenting which truly is optional.

They are important to enforce especially at an early stage as the errors that do happen when they happen are not helpful at all and to a new camper completely nonsensical.

When a developer comes into their own, then they can chose how to write their code.

[Ethan-Arrowood]

I can see Berkeley’s point is valid. Personally I don’t use semicolons and
I rely on Babel or Prettier to inject them whenever I work on projects with
developers who do use them. Of course I’d never expect a new programmer to
do these things which is where I see a lot of validation in Berkeley’s
opinion.

As a common ground, could we ‘enforce’ semicolons as warnings instead of
errors? Red X’s are a universal signal for they are doing something wrong.
While a yellow triangle just means warning, make sure you understand what
you are doing.

• Ethan

EDIT: Removed Ethan's personal info from email reply

[BerkeleyTrue]

@Ethan-Arrowood Warnings are usually ignored. Errors are not.

[raisedadead]

Yup, I can see in the long term this can encourage a habit that should rather be avoided. Well initially seeing the error flag, I too thought this is a bit rigid, check.

But yeah, I 100% agree that we should encourage this practise.

Warnings are usually ignored. Errors are not.

Very very true. All the reason why I guess we should leave the "missing semi-colon errors" as they are.

[no-stack-dub-sack]

@BerkeleyTrue @raisedadead @Ethan-Arrowood I can see the logic here. And I 100% agree that they are NOT a style-choice when it really comes down to it - the language does rely on them, and compilation would fail without them.

I guess my main point is that it really no longer matters whether or not you put them in your own code (to denote line breaks, except with lines that begin with ( or [) — the lodash codebase (the most relied on dependency in all of JS) being a prime example of this — since automatic semicolon insertion is now a language feature, and fully standardized across all browsers.

That said, as an education platform, and because of the few rare exceptions, I suppose I can concede that educating new developers about this from the beginning is not a bad thing (I just wish there was a way to turn this off once the point was really driven home).

Maybe one day, after beta ships, and the multi-tab editor really becomes a reality, we can add an options section for configuring the editor to your own personal specs (could just use a text input with a linter options object and parse that into the codemirror options).

[no-stack-dub-sack]

@BerkeleyTrue what about laxbreak?

[raisedadead]

Maybe one day, after beta ships, and the multi-tab editor really becomes a reality, we can add an options section for configuring the editor to your own personal specs (could just use a text input with a linter options object and parse that into the codemirror options).

I think yup. That would be the right thing to do. And we could add cautionary warnings there citing reasons, when the options are being turned on / off, etc.

[QuincyLarson]

I agree with @BerkeleyTrue that everyone should use semicolons, and I think the resistance some developers have to them is a bit strange.

This said, there will be some developers who stubornly refuse to use them, and for those developers, basically all CodeMirror linting errors will lose their meaning because they'll become desensitized to seeing red circles in the margins. So I agree that it would be nice for those stubborn people to be able to toggle off missing semicolon linting errors. There might be some other linting options that campers would like to have, too.

I'd say this is an extremely low priority, though. There are probably hundreds of things we could do that would have more of an aggregate impact on user experience than this.

[no-stack-dub-sack]

@QuincyLarson This is an interesting point:

for those developers, basically all CodeMirror linting errors will lose their meaning because they'll become desensitized to seeing red circles in the margins

Anyway, I couldn't agree more that this is VERY low priority. If we're not considering suppressing the warning altogether, than offering linter options should, if ever, happen way down the line.

I'd say it's probably safe to close this at this point, and revisit when and if the time is right.

[raisedadead]

Yup, agreed.