Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CANpVHHwhdiCfXc0hdFVVn1nr8rj4K6_vWYXw2qptP4pSeOwbwg@mail.gmail.com>
References: 
 <CANpVHHwhdiCfXc0hdFVVn1nr8rj4K6_vWYXw2qptP4pSeOwbwg@mail.gmail.com>
Date: Wed, 2 Apr 2014 08:49:36 +1300
Message-ID: 
 <CADVgkyOtK3sYL0eeHv9WifRgXVK7HgXB1R-f7dUpf-=C3BSApQ@mail.gmail.com>
Subject: Re: About cordova js
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b10ca1fc931bf04f6007741

--047d7b10ca1fc931bf04f6007741
Content-Type: text/plain; charset=ISO-8859-1

So, this is a huge refactor, but its also a step in the right direction. In
order for this to mainline though we need everyone to buy into the
approach.

- Simplified code (just less of it in general too)
- Not maintaining our own module loader
- Enables npm dep workflows instead of inventing our own
- No double load or script injection
- Simplified plugin authoring (no weird clobbers logic in plugin.xml / just
use vanilla JS to achieve this)
- Optimized builds per platform (only build what a platform needs instead
of the kitchen sink)
- Future path to killing off cordova-js repo

What we need to make this happen

- Backwards compat: existing core plugins must work (thus must be tested)
- Tested on all platforms for 4.x release
- Well documented for new plugin authors (and migrating)

We need your feedback and concerns / once this starts rolling things will
break and we'll need to work together

(And big thanks Anis for taking this path to get us to this point)


On Wed, Apr 2, 2014 at 12:27 AM, Anis KADRI <anis.kadri@gmail.com> wrote:

> I've been working on an alternative build system for cordova-js over the
> last little while and I finally have something to share.
>
> TL;DR
>
> - cordova.js includes all the plugins (no more cordova_plugins.js and
> double plugin loading/mapping).
> - cordova-js is an npm module that is used by plugman to build the final
> javascript file with all the plugins bundled in.
> - All the existing plugins are backward compatible with this new build
> system without modification.
>
> As I briefly mentioned at our last Google Hangout, I use browserify to
> build the final cordova.js. For those of you who are not familiar with
> browserify [1], it is a tool that makes it possible to run node modules in
> the browser.
>
> I slightly modified the cordova-js code to remove the dependency on
> pluginloader and modulemapper as well as the initialization code.
> Everything else stays the same (common, platforms...etc). The reason I am
> able to keep the existing source is because I use a feature of browserify
> called "transforms" that allows me to modify each file before it is added
> to the bundle. The feature allows me to parse all the javascript files and
> map the old-style require() calls with node-js/browserify compatible
> requires(). Basically mapping all the old IDs with real file paths.
>
> I modified plugman/prepare to use cordova-js as an npm module dependency
> and build a cordova.js with all the plugins.
> clobbers/merges are supported as well. I am not sure what runs does but I
> am guessing it's code that should run onload? If that is the case then
> everything always runs onload with browserify (no need to require()).
>
> Some random thoughts for the future:
> - clobbers/merges/runs should be useless. plugins should clobber/merge if
> they want/need to. Each plugin can just be written as a commonJS module.
> - pluginloader/modulemapper will no no longer used.
> - cordova-cli shouldn't be impacted by this change?
> - each platform could have its own (exec/platform) JS and be an npm module
> (different thread currently open on the topic). We could then remove the
> platforms/ folder from cordova-js and only keep common/ and plugman could
> use it to build the final bundle. Since we talked about versioning
> platforms separately, this also allows us to version the javascript along
> with the platform?
> - We could actually leverage NPM dependencies for javascript modules.
> Native code will still have to be resolved but this could be a big win for
> js-only platforms.
> - Since we decided to ditch everything for node, I think browserify is a
> step in the right direction.
>
> Things to know:
> - I've only been testing on iOS. I suspect that all the web-based platforms
> such as blackberry10/firefoxos and especially Windows might be broken.
> - Right now, everything works just the way it used to. I just generate a
> cordova-b.js (a browserify version of cordova.js) that includes all the
> plugins but the old cordova.js and cordova_plugins.js are still there. All
> the cordova-js tasks are still there too, I just added a new one called
> compile-browserify that generates a browserify bundle.
> - I wasn't able to run mobile-spec because of outstanding iOS issues with
> XCode 5.1 :-(
>
> If mobile-spec tests pass and we all agree on using this new build system
> I'd like to:
> - Keep existing plugins, cordova-js code/structure as is for the next 6
> months and get rid of cordova_plugins.js in favor of just cordova.js.
> - 6 months from now: restructure cordova-js and move platform specific code
> to the platforms (maybe?) as well as update all the plugins to support
> browserify out of the box and rely on npm-style dependencies.
>
> If you want to check it all out, you can:
> - Look at the browserify branch of cordova-js if you want to analyze how
> the javascript is built. Specifically look at: compile-browserify and
> bundle-browserify tasks (and compare them to the original ones).
> - Look at the browserify branch of plugman and maybe run it with the device
> plugin (or any plugin other than contacts) on a freshly created project and
> include the generated cordova-b.js (in place of cordova.js).
>
> I consider this to be a big change so I would like us to address all the
> concerns before/if we move forward with it.
>
> Please share everything you have on your mind if you read this far and
> thank you.
>
> [1] https://github.com/substack/node-browserify
>

--047d7b10ca1fc931bf04f6007741--