[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?
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).
@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.)
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).
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.
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.