should most rules be strictly enforced?

[RnbWd]

I'm putting this out there just to see if there's an opinion on the subject.

Most of the rules enforced are strict ([2, always/never]), very few 1's. Is there a process to determine the importance of rule? Like... semicolons maybe (i know 🚯)? This has been discussed already, and semistandard is an alternative for people who LOVE semicolons, but I'm fine without them 80% of the time. I'm legitimately curious why semicolons are strictly enforced instead of passively enforced (semi: 0 or semi: [1, never]. Are there major downsides to using semicolons in general? I can change the settings, ignore it, etc. - but back to the point - is there a priority of rules?

I really like standard. Not only for convenience (I've wasted so much time configuring jshintrc files) - conceptually, philosophically, culturally - it's a great move 🙌. But is there wiggle room? Would it benefit standard by laxing some of the rules? Or would it contradict the principles standard is based upon?

Two side notes: Is there any informal / open committee that would maybe vote on this standard's rules (4-5 great dev's like @maxogden and @substack getting together)? Because it blew up - and I'd like it to actually be a standard independent of w3c / corporations. Also, was there a setting changed a week or 2 ago about named function () spacing?

[jprichardson]

I really like standard. Not only for convenience (I've wasted so much time configuring jshintrc files) - conceptually, philosophically, culturally - it's a great move 🙌.

Agreed.

But is there wiggle room?

From what I've seen, to a degree. Just post an issue and @feross is very good about addressing it. If it's a stylistic choice though, you'd be barking up the wrong tree.

Would it benefit standard by laxing some of the rules? Or would it contradict the principles standard is based upon?

As you stated, It'd violate the principles IMHO.

Two side notes: Is there any informal / open committee that would maybe vote on this standard's rules (4-5 great dev's like @maxogen and @substack getting together)?

Committees are for those who don't want to get things done, but feel like they're getting things done. Also, committees tend to pander to the masses. What we have now is @feross as benevolent dictator with some consensus from @maxogden. @feross has done an excellent job on moving this project forward and listening to concerns from standard's users.

My take? Let's not break what is working.

[maxogden]

The goal of this module isn't to be a W3C style standard intended to be included in e.g. web browsers. it's an opinionated opt-in thing for people who value stylistic choices very low on the totem pole and don't want to waste time arguing over cosmetic/style choices all the time (except in this issue tracker :P).

I also think it would violate the principles by making things non-strict.

[feross]

@RnbWd Thanks for opening this issue and sharing your thoughts so politely.

I think warnings would be a bit confusing; they would print messages to stderr but still return exit code 0, indicating success. This would leave other contributors to later clean up the warnings, or they'd be perpetually ignored.

I'd rather standard return a simple pass or fail, without distinguishing between important and less important rules.

[RnbWd]

I think warnings would be a bit confusing; they would print messages to stderr but still return exit code 0, indicating success. This would leave other contributors to later clean up the warnings, or they'd be perpetually ignored.

@feross That makes sense - I only use lint text editors so I'm not familiar with that aspect.

@maxogden I agree with most of what you're saying, but, it's nice to have a standard within open-source communities to help facilitate contributions to source code (although standard-format is pretty cool)

Committees are for those who don't want to get things done, but feel like they're getting things done. Also, committees tend to pander to the masses. What we have now is @feross as benevolent dictator.

@feross (da boss) will always be benevolent dictator - but that's not === to him deciding everything... unless he chooses to 😎 - IMO it shouldn't be treated like a dotfile repo at this point. But one size doesn't fit all - so having 2-3 official versions is the most likely outcome. semistandard already exists. It'd be nice to create a collection of standards... (just change a few eslint rules here and there, nothing drastic)

[jcrben]

I'd prefer warnings for things which won't break the code and errors for things that will. Many of the warning issues can be autofixed with --fix anyhow. More efficient not to worry about them and run autofix later. I doubt people would really leave a bunch of warnings spit out anyhow.

It seems that none major shareable configs take this approach, however, altho there is https://github.com/Shopify/eslint-plugin-shopify. With the fast progression of IDE integration of autofixing, maybe it doesn't matter...