You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 😄
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?
The text was updated successfully, but these errors were encountered: