combine eslint-plugin-coffee

[UziTech]

@danielbayley I thought I would move the discussion here from https://github.com/github/super-linter/issues/169#issuecomment-648781514 so we aren't bothering the super-linter devs.

I'm all for anything that will make linting coffeescript better/easier. I think the eslint-plugin-coffee approach will get better over time I just don't think it is quite ready for all codebases to move over to it yet.

It would be great if we could combine them or even just add the missing pieces to eslint-plugin-coffee. How were you thinking of merging the two packages?

[danielbayley]

add the missing pieces to eslint-plugin-coffee

I think this is probably the best approach. Although another idea is if coffeelint became a packaged up version of ESLint with eslint-plugin-coffee and a well thought out default config… What do you think? @UziTech

I just don't think it is quite ready for all codebases to move over to it yet.

Specifically which blockers remain? Is it only the 'Not yet implemented' rules listed here?

[UziTech]

Although another idea is if coffeelint became a packaged up version of ESLint with eslint-plugin-coffee and a well thought out default config

I would be ok with that. My only concern is making sure there aren't any breaking changes for users.

Specifically which blockers remain?

The 'Not yet implemented' rules and any other differences between rules.

---

If we could bundle eslint and eslint-plugin-coffee and it would be a drop in replacement I would be all for moving to that.

[danielbayley]

@UziTech Maybe something along the lines of XO for CoffeeScript?

[danielbayley]

cc: @helixbass

[UziTech]

Maybe something along the lines of XO for CoffeeScript?

Ya if we could make it work without breaking too many things. Maybe create a flag to revert back to the old behavior initially and remove the flag once we know there aren't too many negative side effects.

[helixbass]

Ok it's an interesting idea to make coffeelint a wrapper around ESLint + eslint-plugin-coffee. I'd heard of XO but didn't realize it was just an opinionated/packaged-up ESLint wrapper

Without having a really clear picture of what that would entail, my biggest initial question would be is it worth it/what are the upsides? For me a lot of what's nice about using eslint-plugin-coffee is that I can "tap directly into" the familiar + robust ESLint tooling/configuration. And for new projects, I'd personally lean toward encouraging people to get comfortable with configuring ESLint themselves, since in the "bigger picture" it's a valuable skill set whether working in Coffeescript/JS/Typescript

So ya the biggest question that comes to mind about the "wrapper layer" would be that if you're aiming for backwards-compatibility, that'd presumably mean supporting Coffeelint's existing configuration file format, which sounds a little tricky (especially if you ultimately want to allow users to tap into the full power/set of available rules from ESLint/eslint-plugin-coffee)

Regardless, I agree that the not-yet-implemented rules could be considered a blocker before recommending whatever migration path. I've currently got some downtime between work projects so I can put in some time working on those