search

adametry / gulp-eslint

A Gulp plugin for identifying and reporting on patterns found in ECMAScript/JavaScript code.
MIT License
563 stars 118 forks source link

Offer to take over this project #266

Open thebenlamm opened 3 years ago

thebenlamm commented 3 years ago

Hey @adametry and @shinnn

Looks like you guys have built an awesome project here but have decided to move on. Any chance you'd be willing to hand over this repo someone else?

doamatto commented 3 years ago

Second that and have been slowly working on a fork here that I can merge whenever. I can add you to that repo if you want @thebenlamm

thebenlamm commented 3 years ago

@doamatto That's awesome! I've been using gulp-eslint7 from @fasttime. Maybe we can loop him in as well. His fork seems to have gained some traction.

fasttime commented 3 years ago

Well, I'd be glad to help if I can. I haven't been very active on my fork lately, mostly because I started using other tools to run ESLint. But anyway, this project has been abandoned for more than two years now, so I'm going to publish an update.

doamatto commented 3 years ago

The more the merrier; I've been slowly working on bringing everything into TypeScript and generally making the code that much easier to read. Should we schedule a meeting via Email (mine is on my GH profile) to discuss and block out things generally?

thebenlamm commented 3 years ago

@fasttime @doamatto Seems like the two of you have put some work into this already. I'd be glad to pitch in if needed but if the two of you want to sync up without me that'd be fine too. Let me know if you want me involved to coordinate or review anything. We might also want to come up with a new name as gulp-eslint7 won't last much longer. thoughts?

fasttime commented 3 years ago

@thebenlamm actually it wasn't my idea to take over this project, and I was hoping that somebody would do it before me. But without the maintainers consenting or even replying to messages I don't think it's going to be possible. A fork with a new name seems the only solution. Maybe gulp-eslint-new or gulp-eslint-next? @doamatto I'm in the CEST time zone and mostly only available in the evening. If you don't have a problem with that let me know and we can arrange a meeting.

doamatto commented 3 years ago

I'm in the CEST time zone and mostly only available in the evening. If you don't have a problem with that let me know and we can arrange a meeting.

Pacific time with similar availability. Work and school come first for me, for obvious reasons.

A fork with a new name seems the only solution. Maybe gulp-eslint-new or gulp-eslint-next?

IMO a new name should be the last thought. Bringing in all the needed bug fixes, ensuring everything is up-to-date, and keeping things secure should come first, not branding. As for a name though, I don't know what would be ideal, but scoped packaging does exist on the NPM and can prove to be useful.

thebenlamm commented 2 years ago

@fasttime Looks like you've been putting a lot of work into your branch and renamed it to gulp-eslint-new. Thank you!!

fasttime commented 2 years ago

@thebenlamm Glad that you appreciate it. Yes, I renamed the package after the release of ESLint 8. And I updated the documentation and the examples. That was a lot of work, mainly because of my lack of knowledge of both ESLint and Gulp. The documentation part isn't finished yet, and I would also like to make some small changes to the core logic to make it more consistent with the way ESLint 8 behaves, and add type declarations for TypeScript. Finally, the biggest change will be updating the formatter functionality which has been completely redesigned since ESLint 6 (for now, I'm using a kind of hack to make the old implementation work). When all that work is done, hopefully, there will be a release 1.0.0.

electric-el commented 2 years ago

Hello all. I maintain yet another package which brings ESLint to the gulp ecosystem.

https://github.com/electric-eloquence/fp-eslint https://www.npmjs.com/package/fp-eslint

The code is based on adametry/gulp-eslint, but its dependencies have been updated to pass security reviews. It also works with ESLint 8.

If you maintain a similar package, and like my code, by all means, incorporate it into your own.

Also, if you know of a forum where gulp is discussed, please recommend it to me. A big interest of mine is how others incorporate promise data into streams.

@fasttime @doamatto , I haven't looked at your code yet, but I'm definitely looking forward to seeing how you implement the above.

fasttime commented 2 years ago

@electric-el Welcome to the club. The way I know of dealing with streams in modern, promise-based code is by using async iterations. When gulp was designed, JavaScript didn't even have promises, not to mention async functions and generators. Enabling promise-based tasks was one big challenge that gulp had to overcome when they upgraded to version 4. Still, a large part of the gulp codebase is old and not the style you would do things today. This extends to the way of streaming and piping how many gulp tasks are designed to work.

Anyway, I finished to work on my repo, so if you are interested in the code to handle async functions in stream events, you could have a look there.

I don't know of a gulp forum, but if you find one, I'd be interested too. I offered to transfer my project to the gulp-community, which is not a forum, more like a collection of community-maintained packages, but they were not excited.

electric-el commented 2 years ago

Happy New Year everyone!

@doamatto Not meaning to throw any shade, but I didn't really see anything in your fork suggesting any compatibility with the latest ESLint.

@fasttime Looks like great work to me! Mostly the same approach as mine, but actually better IMHO. I like how you handle gulpEslint.format and gulpEslint.formatEach. I wasn't sure how to handle the fact that they await async calls to Eslint.prototype.loadFormatter. You return Transform streams, and invoke the async function as the callback parameter for the Transforms. Since format and formatEach normally print to stdout, or else don't affect the actual streams of file data, it doesn't really matter if they run as fire-and-forget async functions (I think).