When programming Javascript files with Emacs/Vim etc. a linter like ESLint is likely enabled. In my case it seems that the default airbnb style configuration is not very compatible with default Javascript files generated by Phoenix. For example, airbnb standard insists on using singlequotes for strings while Phoenix generates double-quoted ones. Also it insists on appending semicolons which are by default not there. This results in the linter showing a lot of errors in a JS file.
I would like to know, is there any kind of standard followed by Phoenix when generating its Javascript files, or is there any convention/consensus in the community? Ideally I would be able to set the default options of ESLint to report much fewer errors.
Or is it the case that this really varies a lot from person to person and since the Javascript files generated by default are relatively few, the user should just modify the default files to their own taste and follow their own standard when writing new JS files?
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).
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:
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:
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.
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.
AMD and CommonJS were never part of the JavaScript language - only ES6 introduced modules into ECMAScript.
A minefield doesn’t disappear (and therefore the need for warnings around it) just because you build a safe highway right beside it - it just makes it somewhat less likely that someone tries to drive through it (i.e. the “language wart” still continues to exist. To a certain extent I’m reminded of the “<insert your most despised Java wart here> is OK because the IDE can deal with it” mentality ).
"people don’t write IIFEs any more" is probably too general. "people don’t write IIFEs any more as part of the module pattern or to namespace" (in most modern code) is probably more accurate - which of course are the type of IIFEs that are at risk. IIFEs that establish private variables and functions will likely continue to see use - but they aren’t the IIFEs that are at risk.
There are other ways and reasons to “combine/inject” code - sweet.js is just one example. Now off the top of my head I couldn’t imagine why a macro would include a standalone IIFE but that doesn’t rule anything out.
