cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Soref <>
Subject RE: Proposal: Expose check_reqs at the CLI level
Date Mon, 13 Apr 2015 21:13:05 GMT
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
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) []
> Sent: Monday, April 13, 2015 2:53 PM
> To:
> 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
> 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
> 1.       Have a way for the user to see if they have all dependencies
> 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
> could run all the checks, and show a summary of the issues so that the
> 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
> 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.

View raw message