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

Use Nash for cli.js #240

Closed
SBoudrias opened this issue Nov 28, 2014 · 12 comments
Closed

Use Nash for cli.js #240

SBoudrias opened this issue Nov 28, 2014 · 12 comments

Comments

@SBoudrias
Copy link
Member

I kind of like their API https://github.com/scottcorgan/nash

And it'll allow us to program the cli in a more declarative way instead of having these nested if/else chains.

@hemanth
Copy link
Member

hemanth commented Nov 28, 2014

I vote for this. 👍

@addyosmani
Copy link
Member

👍

@kevva
Copy link
Member

kevva commented Nov 28, 2014

I'm usually against using tools like this but https://github.com/mcollina/commist is pretty neat and doesn't do too much like nash.

@SBoudrias
Copy link
Member Author

@kevva What feature of nash do you think are too much or useless for yo?

@kevva
Copy link
Member

kevva commented Nov 28, 2014

Well, the only thing we need is .command() imo, the rest is useless.

@SBoudrias
Copy link
Member Author

Well actually, how I see it:

  • We could use the before hooks to run the sudo block where it's relevant.
  • We'll need the default function to run generators.
  • We'd use flags for --help, --version, --generators

So, I guess the fluff we wouldn't need is the after hook, the deprecation notices and the catch all invalid command.

I checked commist last week, but the lack of default cli handler is an issue for yo as we really need it to process the generator.

@kevva
Copy link
Member

kevva commented Nov 28, 2014

I was thinking we could use https://github.com/sindresorhus/meow for options parsing etc and commist for registring the commands. default() could easily just be if (cli.input.length === 0) instead.

But do whatever you see fits :). I'm not totally against nash either. I just think it's pretty big.

@sindresorhus
Copy link
Member

👎 I'd prefer smaller stuff too. Frameworks like commander and nash always end up being limiting in some way.

@scottcorgan
Copy link

I'd be interested in hearing what can be taken out of nash to make it more flexible.

Would moving before, after, deprecate, etc. into separate modules that can be used with nash help this?

@arthurvr
Copy link
Member

arthurvr commented Mar 8, 2015

I should personally say I prefer smaller stuff as well. 👎

@arthurvr
Copy link
Member

Where did we end up with this?

@SBoudrias
Copy link
Member Author

Oh, I abandoned the project for now. There was some backward compatibility issues and it was hard to handle it in the current state of Nash. Anyone's free to try it out, but I'll close this issue as this is not on anyone in the core team roadmap anymore.

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

No branches or pull requests

7 participants