Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of kamrik@google.com designates
 209.85.219.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHYtTqkgivhk0KJbh_-ghC0BOC=CTk_ijmm8TZ23+fVbkr-jag@mail.gmail.com>
References: 
 <CA+GVa3b84-WzBe5BxcAKHS-Es0xJgktyuJGut5Qu5Y_SLcVjog@mail.gmail.com>
	<CAEeF2TdzeYY3T_Ybgx9y=Z6vEcNrFu8a3ZY_a3C=ryD+h9fOzg@mail.gmail.com>
	<CADVgkyNSf3HU-OxPF8rzfkXmpVsdFRKjMaghanMpVcQ_X7hCoQ@mail.gmail.com>
	<CABiQX1WFYwW_xB60XV846_dkiDyiVgsSakZ9GxypTmPSCg5u_g@mail.gmail.com>
	<CAHYtTqkgivhk0KJbh_-ghC0BOC=CTk_ijmm8TZ23+fVbkr-jag@mail.gmail.com>
Date: Mon, 18 Aug 2014 17:38:21 -0400
Message-ID: 
 <CA+GVa3ZFrbBw-mX85GKgucwDh6C5U=YxMEp_VY3wMCgbVLKtgw@mail.gmail.com>
Subject: Re: Cordova workflows based on build systems / task runners
From: Mark Koudritsky <kamrik@google.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=001a11c1d5fe9a44c50500ee30b0

--001a11c1d5fe9a44c50500ee30b0
Content-Type: text/plain; charset=UTF-8

Ok, submitted a PGDay proposal for this :)

Carlos, I had no particular point when starting this thread, just wanted to
share this experiment.

Michael, the hardcoded paths are mainly because I'm not using Cordova's
"create" and instead reproduce the cordova project dir structure by
symlinking, or alternatively by filtering via Gulp style streams into the
right dirs for cordova. This is first time I use gulp so I'm not sure if
this should be converted into a gulp plugin. Using it as boilerplate seems
pretty straightforward.


On Thu, Aug 14, 2014 at 11:08 AM, Carlos Santana <csantana23@gmail.com>
wrote:

> My grunt-cordovacli [1]  plugin works in a similar way, just using
> cordova-cli PAIs which I a year ago there was no cordova-lib APIs or gulpjs
>
> I can create a slushjs [2] using cordoval-lib just for fun :-), but I'm
> missing the point of this thread? Is the point to evaluate what could be a
> good set of plublic APIs for cordova-lib?
>
> [1] : https://www.npmjs.org/package/grunt-cordovacli
> [2] : https://www.npmjs.org/package/slush
>
>
>
>
> On Thu, Aug 14, 2014 at 10:07 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Certainly shows some rough spots of the CLI interface e.g.:
> > - Need to add plugins before platforms
> > - Need to chdir() before calling functions
> >
> > And yes - love that this makes cordova fit in more nicely with other
> parts
> > of an app's build system.
> >
> > One thing I wondered when reading it is if Cordova should have an api
> for a
> > bare-bones "prepare" step. E.g. - don't copy from root www -> platform
> ww,
> > but just copy in cordova.js & plugin files, assume that the user will
> take
> > care of putting everything else into the platform www/
> >
> >
> >
> >
> > On Wed, Aug 13, 2014 at 9:31 PM, Brian LeRoux <b@brian.io> wrote:
> >
> > > "Topic for a PGDay talk!" <--yes pls submit
> > >
> > >
> > > On Wed, Aug 13, 2014 at 5:31 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > > > :D So cool!
> > > >
> > > > If I understand correct, this is a combination of:
> > > > (a) using the cordova-lib node interface directly
> > > > (b) iterating node_modules and inferring the set of platforms from
> that
> > > > (c) plugins are listed explicitly since we don't use real npm
> > > > (d) treating www/ as the output of an initial gulp stream
> > > >
> > > > There are some hardcoded paths, but I guess thats just your sample
> > > > gulpfile.  Probably we would either publish a gulp plugin that takes
> in
> > > > args, or just leave this repo as boilerplate and let users tweak
> > > > accordingly?
> > > >
> > > > I've not played with Carlos' grunt based workflow, but wonder how
> > similar
> > > > that approach is.
> > > >
> > > > I think this could be a sweet workflow and find it encouraging to see
> > how
> > > > it could be thrown together.  Topic for a PGDay talk!? ;)
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Wed, Aug 13, 2014 at 6:18 PM, Mark Koudritsky <kamrik@google.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Inspired by several recent conversations on this mailing list I've
> > been
> > > > > thinking about a Cordova workflow based on some build system. As an
> > > > > experiment I've put together this  app using Gulp and cordova-lib:
> > > > >
> > > > > https://github.com/kamrik/CordovaGulpTemplate
> > > > >
> > > > > To try it out
> > > > > git clone https://github.com/kamrik/CordovaGulpTemplate.git
> > > > > cd CordovaGulpTemplate
> > > > > npm install
> > > > > npm install gulp -g  # if you don't yet have gulp installed.
> > > > > gulp recreate
> > > > > gulp build|emulate|run
> > > > >
> > > > > The important files are:
> > > > >   * package.json
> > > > >   * gulpfile.js
> > > > >   * src/config.xml (the cordova config.xml)
> > > > >   * src/www/  (copied as is from the default cordova www template)
> > > > > The whole cordova project dir is treated as a build artifact. It
> > lives
> > > > > under ./build (ignored by git and nuked by "gulp clean").
> > > > >
> > > > >
> > > > > Some benefits of this workflow:
> > > > >  - Cordova can blend in as just another tool in the app workflow
> > > > alongside
> > > > > stuff like Sass, template and CoffeeScript/Dart preprocessing etc.
> > > > >  - Can use any folder structure under ./src, the cordova project
> > > > structure
> > > > > is created under ./build by linking or copying from ./src (or by
> > > > filtering
> > > > > via transpilers).
> > > > >  - Platforms are listed as app dependencies in package.json. As a
> > > result,
> > > > > npm downloads them and platform version preferences are set just
> like
> > > > with
> > > > > any npm deps. (plugins are not treated this way, see comments in
> > > > gulpfile).
> > > > >  - No need to programmatically edit config.xml to store platform
> > list.
> > > > >  - As a bonus, people disliking XML can make a simple Gulp plugin
> > that
> > > > > would generate Cordova's config.xml from a more human friendly
> > > > > json/yaml/ini/whatever file ;)
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

--001a11c1d5fe9a44c50500ee30b0--