Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
code style changes for skel-full #8045
Updated the code style (and dependencies) for the full scaffold to match (as best as seems reasonable) the Meteor guide.
There is some discrepancy with the recommended eslint configuration. For example there are a number of rules that make sense within the context of a Meteor project, which is exactly why these have been added in the todos example. So to address that I've added a few
In some cases like this it is pretty much standard practise (in Meteor) to not bother with naming function expressions (
Perhaps a solution is that it can be handled by the eslint meteor plugin, though I'm not totally sure how that might work since it's designed to work independently to the airbnb rules. @dferber90 any thoughts? :)
So in the meantime until there's a solution like above should we remove the
Overall some great changes here!
As to the ESlint stuff, I'm really not up to date on the latest in
eslint suggestions for Meteor. I'd agree it's a bit funky, but will leave that to others to recommend.
@dburles The way the ESLint ecosystem works is that plugins like
referenced this pull request
Nov 16, 2016
@dburles Do you think you can nuke those
@abernix @dferber90 @iDoMeteor here's a start, it's not yet published to npm. https://github.com/dburles/eslint-config-meteor ideas/feedback are welcome. The idea is that this will be the official config referenced within the guide. Which then means we can be confident that if this configuration is added to skel-full there will be no linting errors to speak of :)
@dburles Did a quick overview and this looks good
You may want to introduce upper limits to your peer dependencies since new rules introduced into them through major releases can mean that the build of people using