Skip to content

modify mojito commands to have sensible user-friendly defaults #537

Closed
dmitris opened this Issue Sep 20, 2012 · 7 comments

5 participants

@dmitris
dmitris commented Sep 20, 2012

Following up on the discussion in #533

proposing to modify mojito defaults options for "test" and "jslint" commands to make them intuitive for the end-users (rather than framework developers) - therefore running commands on the current directory and not on Mojito framework itself. Having "mojito test" and "mojito jslint" operate on the Mojito framework code instead of the current directory will confuse and frustrate the new users and generate unnecessary volume of support requests and emails. It is also inconsistent with the way "mojito start" and (I believe) "mojito build" work - without requiring an extra [app] [path] arguments.

I think we could provide --self or "framework" for cases when you want to run mojito on the Mojito code itself, for example:
mojito test framework
mojito jslint framework
or:
mojito test --self
mojito jslint --self

(copying from the issue referenced above)
#533 (comment)
@mojito: I'd be good with a default that works inversely to that. Seems to me the default should serve customer application needs first.

#533 (comment)
@dmitris
agreeing with @mojit0 - the current command-line usage is counterintuitive, and it is also inconsistent. You run "mojito start" to start the server using the resources in the current directory, even if you try to do (the invalid) "mojito start app ". "mojito build" and "mojito compile", if I understand correctly, work on the files under the current directory (the help descriptions do not mention "mojito build app"). But test and jslint options require to pass "app ." to work on the current directory. I think the defaults should be modified: "mojito test" and "mojito jslint" should have "app ." as the default, and there should be separate options to test/jslint the framework itself - for example, "mojito test framework" or "mojito test --self". I will make a separate issue for that.

@mojit0
mojit0 commented Sep 20, 2012

+1

@rwaldura

+1

@rwaldura

whack whack
thanks for the wakeup call
next Sprint candidate

@rwaldura

uhm, maybe not next Sprint -- seeing how it's pretty full as it is -- but soonish, I agree.

@rwaldura

We've been talking about revamping the CLI for a while now. Things we want to do:

It's an area that's ripe for change. I'm going to bundle all these up into a future Sprint in Q4.

@isao isao was assigned Jan 29, 2013
@caridy
caridy commented May 17, 2013

@isao should we move this to cli?

@isao isao closed this May 21, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.