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.
smime.p7s
Description: S/MIME cryptographic signature