+1 if check_reqs are kept in the platform repos, currently check_reqs is a
platform concerned
if it's available from CLI it will be just a proxy to the platform
check_reqs.
if don't keep it in the platform repo, and add this logic to cli repo, we
will need to maintained a list of reqs for each platform, for each version
of each platform.
This is the reason why it was removed from cli and just is present in the
platform repo/code
On Mon, Apr 13, 2015 at 5:13 PM, Josh Soref <jso...@blackberry.com> wrote:
> 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.
>
--
Carlos Santana
<csantan...@gmail.com>
