Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next iteration of ronin #37

Closed
daviddias opened this issue Jun 28, 2016 · 2 comments
Closed

Next iteration of ronin #37

daviddias opened this issue Jun 28, 2016 · 2 comments

Comments

@daviddias
Copy link

Hi @vdemedes! How have you been?

I've been using ronin for a while and I'm really enthusiast of the features it offers, recommending it to anyone that wants to do a CLI in Node.js. However, the project has been stale for a while and the lack of new features, specially when it comes to be more descriptive about documentation of the commands, start making ronin missing some of our goals.

I'm aware that you are super busy, but if you could kick off the next iteration and lay out the vision, me, @RichardLitt and other folks would be happy to help you get there :)

@vadimdemedes
Copy link
Owner

Hey guys, let me get back to you tomorrow ;)

@vadimdemedes
Copy link
Owner

vadimdemedes commented Aug 14, 2016

Hey @diasdavid and @RichardLitt, I know it's been long overdue and I'm sorry for this, I had a lot of stuff on my plate lately.

So, the next iteration of Ronin. Currently, it's a pile of unflexible code, but with a nice list of features and ideas. I was thinking how to make the underlying code easy and straightforward, as well as simple to customize and introduce new features.

I decided to go Express/Connect route. What this means is, now we have 2 separate projects:

  • Sushi (like Connect) - a middleware layer for CLI apps.
  • Ronin (like Express) - a project that uses Sushi underneath and bundles a lot of helpful middleware.

Ronin will keep a list of its existing features, like auto-registration of commands. However, it'll remain clean, because it will basically be a bundle of individual middleware for Sushi.

As for Sushi, it's simply a middleware layer, without any fancy functionality. Think of it like Connect for CLI apps, instead of HTTP servers. Today I pushed a rewritten version of Sushi, as well as example help middleware:

Would love to hear your feedback, ideas and suggestions! What use cases did Ronin not fulfill in your projects? What was unneeded? What features you liked (so that I know what to keep in the next major iteration of Ronin)?

Thank you a lot of understanding and your patience!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants