You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mark Koudritsky <ka...@google.com> on 2014/08/14 00:18:50 UTC
Cordova workflows based on build systems / task runners
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 ;)
Re: Cordova workflows based on build systems / task runners
Posted by Brian LeRoux <b...@brian.io>.
this is great / really like it / would be super clean to layer on from here
(frameworks, browserify, whatevs)
On Wed, Aug 13, 2014 at 3:18 PM, Mark Koudritsky <ka...@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 ;)
>
Re: Cordova workflows based on build systems / task runners
Posted by Mark Koudritsky <ka...@google.com>.
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 <cs...@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 <ag...@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 <mm...@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 <ka...@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
> <cs...@gmail.com>
>
Re: Cordova workflows based on build systems / task runners
Posted by Carlos Santana <cs...@gmail.com>.
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 <ag...@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 <mm...@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 <ka...@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
<cs...@gmail.com>
Re: Cordova workflows based on build systems / task runners
Posted by Andrew Grieve <ag...@chromium.org>.
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 <mm...@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 <ka...@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 ;)
> > >
> >
>
Re: Cordova workflows based on build systems / task runners
Posted by Brian LeRoux <b...@brian.io>.
"Topic for a PGDay talk!" <--yes pls submit
On Wed, Aug 13, 2014 at 5:31 PM, Michal Mocny <mm...@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 <ka...@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 ;)
> >
>
Re: Cordova workflows based on build systems / task runners
Posted by Michal Mocny <mm...@chromium.org>.
: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 <ka...@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 ;)
>