I'm +1 for `cordova doctor` and `cordova platform doctor {platformname}`.

The former should apply to all current platforms, the latter should support
doctoring for available but not added platforms -- if said platform were
specified.
And we should note in the documentation or `cordova doctor` that it may do
other checks -- e.g. linting the config.xml, warning about CSP, possibly
mentioning when a plugin is out of date -- just to indicate to people that
the behavior may evolve.

Not that this is more or less fixing a regression that we introduced when we
made `cordova platform add` not call check_reqs.

> -----Original Message-----
> From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> Sent: Monday, April 13, 2015 2:53 PM
> To: dev@cordova.apache.org
> Subject: Proposal: Expose check_reqs at the CLI level
> 
> Hi,
> 
> One of the main problems a lot of developers seem to have is the issue to
> setting up their machines for building various platforms. This came out
from
> the Stack overflow survey, and the number of questions on stack overflow,
> twitter. Etc.
> 
> I thought it would be helpful to have a check_reqs command exposed at the
> CLI level. This is similar to `brew doctor` or `appium doctor`. The idea
is
> 
> 
> 1.       Have a way for the user to see if they have all dependencies
(like
> JAVA_HOME or ANDROID_HOME) set up? This happens at build time, but
> moving it out to a CLI level command where you can run cordova check_reqs
> (or something similar) would be useful to the users.
> 
> 2.       Today, the build command shows one error at a time. The
check_reqs
> could run all the checks, and show a summary of the issues so that the
user
> can fix them all, instead of fixing one, running build, fixing again, etc.
> 
> What does the community think of this idea ? Can we implement a prototype
> and see if this is useful to our developers ?
> Note that this does not change or break existing functionality - it just
exposes
> the already existing check_reqs in the CLI. Build will continue to call
> check_reqs.
> 
> Please vote on this proposal, or raise any concerns you may have.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to