Default Javascript Linter (e.g. ESLint) Configuration/Standard?

If Phoenix is going to follow a style guide for generated JavaScript files, Standard should be considered. In at least one respect Standard is closer to Elixir’s syntax than the Airbnb style guide since it gets rid of those noisy semicolons.

Agreed. I actually find Phoenix’ default JavaScript strange and ugly lol. I get it that they tried to make it look like Elixir, but it’s a different language.

Most people use single quotes in JavaScript, so most pre-configured linters will prefer them. I also use Standard for all my JavaScript stuff. I recommend that Phoenix at least generate JavaScript that conforms to most people’s uses (Airbnb or Standard).

[quote=“SZJX, post:1, topic:1745”]the user should just modify the default files to their own taste and follow their own standard when writing new JS files?
[/quote]
This would be my assumption - (unless there is re-generated JS in Phoenix which I haven’t come across yet). Obviously the Phoenix project has made some of it’s own choices (for whatever reason) but that shouldn’t override your needs (i.e. your custom eslint configuration).

So I’d basically “clean up” the initial JS assets placed by mix in web/static/js to conform with my chosen standard and move forward from there.

Probably a lost cause given how divisive just the semicolon issue is (e.g. hence the existence of semistandard).

Well, it’s been a while and no one’s complained about the lack of semis in the default JavaScript, so maybe we can get away without them. That said, any modern styleguide is fine. I just think it looks weird at the moment.

@SZJX with ESLint you can do eslint --fix to attempt to format any JS files to your configuration. Works for standard as well (standard --fix.)

I had to change mine to use semi-colons at the end of lines, but I figured it was just a starter “example” app js. That said, if it’s at all possible, at the very least explicit semi-colons would be proper since javascript has odd rules for the implicit semi-colons (i.e. it isn’t just a style thing).

Sure, but the standard linter lints against the gotchas of no semis. But yes, without it you’ll be in danger!

ES5 automatic colon insertion (ASI) - have to admit it feels bolted on after the fact. If they were serious they should have designed the language without semicolons in the first place (Clojure even downgraded commas to whitespace in many places).

Even as an explicit semicolon author you may want to defensively prefix your IIFEs with a semicolon if there is any possibility of your script being included in/concatenated to another “non-semi” script:

;(function () {
  /* */
}());

;(function () {
  /* */
}());

Ouch. Yeah. Apparently there are a ton of gotchas with implicit semi-colons, and that is yet another new one to me. I would think that is all the more reason to have it in the learning material for beginners, as I’m not sure I agree with that particular video’s quote of “I mean really, who does that?” Because new learners specifically don’t know what to do, and his example of bear is trivial. If the return value is a long function that would possibly wrap, such as:

return 
    myLongJavaScriptName.someArrayProperty.forEach(function(i) { return isFoo(i) })

So this would be a mistake that would not be caught until the beginner was farther down the line and had no idea about this implicit semi-colon problem, etc. etc., yada yada yada. So me personally, I can’t remember all the little rules because my memory is horrible, so it is far easier to just say “use semi-colons” explicitly. Then if I forget one, probably no biggie (and a linter will catch it).

The Standard linter will pick up on lines that begin with a character that should be prefixed with a semicolon for safety purposes. From the Standard rules:

Never start a line with (, [, or `. This is the only gotcha with omitting semicolons, and standard protects you from this potential issue.

… which is covered via the /*eslint semi: ["error", "never"]*/ rule.

My most recent point was that /*eslint semi: ["error", "always"]*/ really needs an option to flag non-prefixed IIFEs as well - because as it stands the “implicit semicolon” authors are forcing the “explicit semicolon” authors to defensively prefix their IIFEs with an extra semicolon - not to satisfy the ECMA spec per se but to guard against a blind-spot in ASI that is exposed when merging or concatenating scripts authored against divergent linting rule sets.