Bring project back to life
MarcoScabbiolo opened this issue · 13 comments
I've couldn't help but notice this project is not in good shape, the builds are failing and many helpful PRs are not being merged. This is a very helpful and widely used project, and usually a must have for CLIs.
I'm willing to invest time into bringing this project back to life and have it well maintained.
Here are some things that I think should be done:
- Rewrite in TypeScript, for typechecking, better DX and for listr to have its own type definitions.
-
Use jest instead of ava - Update dependencies and review any unnecessary ones
- Fix failing builds
- Update docs #134
- Make listr a monorepo and include in it the satellite modules listr-update-renderer, listr-silent-renderer, listr-verbose-renderer and maybe , listr-input although it is not a direct dependency
- #125 , #127: Move rxjs to peerDependencies
- Merge good PRs to prevent forking: #113 #114 #116
I don't think any breaking changes are needed for all of this as long as the surface API is used, and not any internals.
@SamVerschueren what do you think about this? I can work on all of this in a separate branch.
if @SamVerschueren agrees. This would be awesome 👌
Looking forward to having a better version of listr 😃
Can I get some time to come with an appropriate response. Could definitely use some help from others!
Happy to see people are picking up the bat here. I would personally love to see some sort of pluggable core so things like observables and streams become plugins rather than core features. Not all authors (myself included) need that stuff.
I have prior experience setting up a monorepo for this kind of purpose. I'm maintaining a project that uses Lerna and Yarn workspaces for this, along with relative-deps.
Hi, and sorry for the slow response. Some things in my personal life changed the last year so I wasn't so active in the open source community anymore.
I would really like some help from other people. @LitoMore already fixed the tests and switched to GitHub actions to run the tests. He asked if he could help triage issues and solve some open PRs which I would really love to see. I'll try to help as well.
Rewriting in TypeScript is definitely something I want to do as well. But first I believe we should solve some low-hanging fruit issues and PRs.
I don't want to switch from jest to AVA. I use AVA for all my open source work and I like it.
Making listr a monorepo is definitely something we can consider, I use lerna at my job as well so definitely worth looking into it bringing everything together.
Thanks to everyone who wants to help get this project going! 🙏
Great to see you want to go in this direction @SamVerschueren .
I agree it should be a priority to solve long-standing issues and merge PRs before starting any refactors.
Can you consider giving permissions to more people so we/they can help you with PRs and Issues?
@MarcoScabbiolo Thank you for your offer! By the way, you can still help out with all this without being a maintainer though!
Sure can and will, it was just a suggestion, and needs not to be me the one assigned the permissions.
I don't want to switch from jest to AVA. I use AVA for all my open source work and I like it.
AVA's support for TypeScript is cumbersome compared to jest's . On top of that, jest, babel and ts align themselves very well when working with monorepos. The 3 of them allowing for both workspace, project and reusable configurations. AVA lacks support for monorepos AFAIK.
By the way listr2 is already out there (version 1.0 is 2 months old) but still hasn't taken off, although lint-staged has already switched to it. It is written in TS. It would be great to join efforts with @cenk1cenk2 and have him help with the "official" listr so it doesn't branch out.
I'm definitely open to collaborate with @cenk1cenk2!
Hearing that @SamVerschueren is on-board is great news. The basic bones of the project are still the same and I tried to not change much in the sense of not breaking backward compatibility since I was already relying on it. While some TLC was needed to expand it in my own use case, I butchered it so much that I could not justify creating a pull request to the original project that seemed acceptable in my mind. Therefore, if the end result will give this beautiful project more life in the upcoming years, I will be happy to chip in whatever way I can.
The only two things I was thinking about to change that can break backward compatibility is putting the renderer options into their own options key and push observables to a peer dependency. Since verbose renderer does not need keys like collapse and such I think it is a wise idea to isolate the options on per renderer basis, but there shall be some typescript trickery to be done for not losing the autocomplete functionality while for my use case I added some more options directly to the task wrapper which will even complicate things more. The peer dependency one is a bit trickier since the task needs to detect whether the given task is an instance of observable.
@cenk1cenk2 I want to extract the rendering options to their own key as well. Shortly after I did it like it is now, I already had regret that I did it this way. So that would definitely be an improvement.
Listr2 really needs to be pointed out in the readme