Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Using feross/standard instead of eslint-config-trails #285

Open
LobeTia opened this issue Mar 24, 2017 · 2 comments
Open

Using feross/standard instead of eslint-config-trails #285

LobeTia opened this issue Mar 24, 2017 · 2 comments

Comments

@LobeTia
Copy link

LobeTia commented Mar 24, 2017

I'm thinking about the trails eslint config.
I wonder if it's smart to create our own code-style instead of following a standard.

Some months ago I started using feross/standard for my projects and I found myself very well using it.
I know that everyone has his own preferences but I think that as a Javascript community we must be united and avoid fragmentation (Android teaches a lot in this case) and all of this code-style stuff isn't a "business core stuff" so we can avoid talking about it and just follow a convention.

Also, having a codebase that follows other famous projects code-style is a great way of making life easy to new users/maintainers
Disclaimer: I'm not a standard maintainer

tl;dr We are creating our niche for code-style, why not adopt a standard from Trails 3.0?

@tjwebb
Copy link
Member

tjwebb commented Mar 24, 2017

The config is based very closely on eslint:recommended already, which I'd argue as just as much as much of a "standard" as anything else.

@LobeTia
Copy link
Author

LobeTia commented Mar 30, 2017

I agree the fact that we are very closely to eslint:recommended configuration and that's great
My main concern was about investing time in maintaining and expanding a code style when there's some good projects that are just "ready for use" (standard but also eslint:recommended) so we can focus on trails core 😄

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants