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
mojito test --self
mojito jslint --self
(copying from the issue referenced above)
@mojito: I'd be good with a default that works inversely to that. Seems to me the default should serve customer application needs first.
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.
thanks for the wakeup call
next Sprint candidate
uhm, maybe not next Sprint -- seeing how it's pretty full as it is -- but soonish, I agree.
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 should we move this to cli?