Use StandardJS

[lesander]

http://standardjs.com

[tomsmeding]

And that would be useful because?

[lesander]

My bad @tomsmeding - I clicked the submit button too fast. Please bear with me while I try to explain why I think Standard is a perfect solution for MagisterJS.

Contributing to an open source project can sometimes be a struggle, since so many different coding styles and personal opinions exist.

Adopting this standard style means ranking the importance of code clarity and community conventions higher than personal style. This might not make sense for 100% of projects and development cultures, however open source can be a hostile place for newbies. Setting up clear, automated contributor expectations makes a project healthier and easier to access and contribute to for every developer.

There are lots and lots of debates about tabs vs. spaces, etc. Those will never be resolved. These debates just distract from getting stuff done. At the end of the day you have to 'just pick something', and that's the whole philosophy of Standard - its a bunch of 'just pick something' opinions. Hopefully, you can see the value in that over defending own opinions.

I think in order to be a more welcoming community for new developers, pull and feature requests, MagisterJS should start using Standard. This would make it tremendously easier for anyone to follow up on that sarcastic you're always free to open a PR if you want x to be implemented, fixed or added comment. We, as (somewhat) experienced developers know of all people that an existing open-source project is not something you can just start working on right away.

This brings me to another (somewhat unrelated) point, proper documentation and a clear explanation of a project's architecture, is of vital importance for new contributors to understand what they're working on and to be able to improve existing work. Because, let's face it, you can't edit something without understanding how it works in the first place.

It is our responsibility and in our best interest to give everyone who has access to our repository (and has basic knowledge of Javascript) a chance to contribute and share their ideas, without all the hassle of following a custom in-house style that only a few people master.

(Bonus: the standard --fix command can fix the most common problems locally and automatically, even before a commit is submitted to a PR).

So in short:

• Improve getting started guide for contribution and development.
• Explain the architecture of the project.
• Use Standard as the code guide.
• Be friendly and happy, yay! 😄

Edited 2 times

[lieuwex]

Hey @lesander!
Thanks for your in depth explanation and request, I have some thoughts I will write out when I've more time today. :)

[lieuwex]

Hey,

Talking about v2 here, of course, since v1 is deprecated and is in coffeescript.

First I want to point out that we already use everything of standard I agree with, which is everything except for the indention style (we prefer tabs). I won't go in a tabs vs space debate here.

Adopting this standard style means ranking the importance of code clarity and community conventions higher than personal style.

Hopefully, you can see the value in that over defending own opinions.

Sorry but I just disagree with this completely, we already had popular style guides, Google has one for years, airbnb has a really in-depth one, and there are more for sure.
Just the fact that somebody comes around and labels something as 'standard' doesn't mean it should become the go-to coding standard for the js community; we didn't even design the standard as a community.

We, as (somewhat) experienced developers know of all people that an existing open-source project is not something you can just start working on right away.

I don't really see a standard fixing this. If it's something like being afraid of helping out, which I can see (I was afraid too with my first PR), I fail to see how a standard would improve that. We need some other way to improve that.
If it's needing to study the code, sure thing, documentation (which really is going to improved in v2, but not ready yet) will help with that, but a standard will not.
If it's not being sure what kind of indention or code style in general you should use, it doesn't matter: I can just point it out if needed or fix it myself and merge the commit(s) in.

This brings me to another (somewhat unrelated) point, proper documentation and a clear explanation of a project's architecture, is of vital importance for new contributors to understand what they're working on and to be able to improve existing work.

Sure thing, very true.

(Bonus: the standard --fix command can fix the most common problems locally and automatically, even before a commit is submitted to a PR).

This is not a standard-only feature, this feature belongs to eslint, which we use, so everybody can use too, just replace standard with eslint and you're ready to go. The standard repo says standard is easier since you don't have to maintain a .eslintrc, but I already have set one up so no more work tho be done there (and I'm willing to take some time to configure it properly).

I already thought of jumping to standard for personal projects, but I don't to give up tabs.

(And if somebody can figure out how to set their space width to 2, they can also figure out how to turn off tab expansion and set their tabstop to something they like (2 for example).)

Sorry for the rant.

[lesander]

Talking about v2 here, of course, since v1 is deprecated and is in coffeescript.

Obviously, yes 😄 .

Just the fact that somebody comes around and labels something as 'standard' doesn't mean it should become the go-to coding standard for the js community, we didn't even design the standard as a community.

That's true, yeah. Although I would not call Feross just 'somebody'. But the fact is that StandardJS is rapidly becoming one of the most popular coding styles for JavaScript.

I don't really see a standard fixing this. If it's something like being afraid of helping out, which I can see, I was afraid too with my first PR, I fail to see how a standard would improve that. We need some other way to improve that.

While that is true, this standard could lower the barrier for people to start contributing a little.

Perhaps I shouldn't have made the title of this issue StandardJS, but rather Making contributing easier for everyone or something like that. The main issue for me is not particularly using a different code style, but I would rather see it as a first small step.

I already have set [ .eslintrc ] up so no more work the be done and I'm willing to take some time to configure it properly.

I stand corrected, I wasn't aware of that.

[..] documentation (which really is going to improved in v2, but not ready yet) will help with that [..]

Great, I look forward to that 😊. One of the main reasons I have not committed to v2 yet, is because I'm unsure what development environment works the best and is required.

Sorry for the rant.

No problem, I was the one being blunt 😆 .

[lieuwex]

One of the main reasons I have not committed to v2 yet, is because I'm unsure what development environment works the best and is required.

So as you maybe have seen I have created #65, which should help with that issue!

I hope this fixes the problems, thanks again for sharing your idea :)