Plans for eslint support?

[blimmer]

Do you have plans to support this behavior in eslint? Dockyard recently created an eslint-plugin-ember-suave and many folks are using eslint vs. jshint/jscs today.

I found @alexlafroscia 's fork of this repo, but it isn't incredibly active.

This functionality is extremely valuable in the fast-paced Ember community and I would love to be able to use it with eslint. Some thoughts ... we could:

• convert to eslint and integrate with eslint-config-ember-suave ( cc @brzpegasus , @alexlafroscia )
• create a new repo / eslint plugin for this behavior
• something else? cc @minichate

thoughts?

[minichate]

I'd like to! I plan on taking some time next week to refractor into a
library that can support both linters.

On Wed, Oct 12, 2016, 20:08 Ben Limmer [email protected] wrote:

Do you have plans to support this behavior in eslint? Dockyard recently
created an eslint-plugin-ember-suave
https://github.com/DockYard/eslint-plugin-ember-suave and many folks
are using eslint vs. jshint/jscs today.

I found @alexlafroscia https://github.com/alexlafroscia 's fork
https://github.com/alexlafroscia/eslint-ember-deprecations of this
repo, but it isn't incredibly active.

This functionality is extremely valuable in the fast-paced Ember community
and I would love to be able to use it with eslint. Some thoughts ... we
could:

• convert to eslint and integrate with eslint-config-ember-suave ( cc
  @brzpegasus https://github.com/brzpegasus , @alexlafroscia
  https://github.com/alexlafroscia )
• create a new repo / eslint plugin for this behavior
• something else? cc @minichate https://github.com/minichate

thoughts?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#41, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAttj34ZEU9cCTkR8tIBIvB8YGuvSAKks5qzXZ4gaJpZM4KVWdC
.

[alexlafroscia]

I created my fork when I did the port of Suave over to ESLint but getting the Suave done ended up stealing the majority of my OSS time at that point.

Suave is specifically the tool that Dockyard uses internally, so I have a feeling they would want to keep things separate. I think this is a good idea too; there's not a strong reason to ship them together. You can specify as many ESLint plugins as you want, so having them separate doesn't really have any downsides.

I'd be interested in giving this some more attention, but if @minichate is on it, that's cool with me.

[blimmer]

@minichate do you think it would be exposed as something like eslint-plugin-ember-deprecations?

@alexlafroscia , I think it'd be OK to keep it separate as well.

Also, I've never done work on JSCS or ESLint but would be interested in trying to help out if I can see an example of one of the conversions.

[alexlafroscia]

I think that would be the right name; the ESLint community has a convention of naming plugins eslint-plugin-XXX and I think that's an important thing to be consistent with.

What might be cool is shipping sets of configurations as well (a plugin can expose configs as well as rules, which is what Suave does now). Then you can turn whole sets of deprecation warnings on and off based at once based on your needs.

[blimmer]

I like that idea @alexlafroscia . Could be especially helpful at major Ember versions. For instance, turn on all 1.13 -> 2 deprecation warnings. Or just 2.x, etc.

@minichate also, is it worth taking the time to make the project work with JSCS or ESLint? JSCS has merged with ESLint, so it might make sense to create the new eslint-plugin repo and stop production on the jscs flavor.

[alexlafroscia]

I'm with you there @blimmer, I don't think continuing to support JSCS anymore makes sense. I'm happy to continue work on my ESLint fork now that Suave is officially an ESLint package.

Really, I'd like to create a separate ESLint plugin for general Ember best practices, not so much deprecations, but that's a separate thing ¯_(ツ)_/¯

[blimmer]

@alexlafroscia (if @minichate is into it) I think it'd be great to break your repo out into the aforementioned naming convention and start to match what this repo provides.

this repo could probably be deprecated (heh) unless @minichate feels strongly about continuing on with it.

[alexlafroscia]

I don't personally want to maintain a plugin for deprecations (seems like a lot of ongoing churn) but would be happy to help get an ESLint plugin to feature parity with this JSCS one. Maybe we could chat with someone about putting an ESLint version on the Ember or Ember CLI org.