So I've written up my plan for attacking this problem into a Google Doc I've shared for public comments:
https://docs.google.com/document/d/1fhwnIZ5TqwklGx71pLmfSghysls1S4_5ktEsjA9ac5Y/edit?usp=sharing tl;dr version is that on cordova prepare (the new fast first part of cordova build, copies www) we read all installed plugins for new XML tags that define the JS modules and where they should be exposed on window, and inject code into cordova.js to load the modules, and do the clobbering/merging/executing as necessary. This is a relatively modest new feature for the CLI that doesn't require any refactoring, and should be fast enough to run on every prepare/build without significant slowdown. I'm working on a prototype of this approach in a fork of the CLI. If you spot any problems with the approach, please comment on the doc or in this thread. Braden On Fri, Feb 8, 2013 at 4:45 AM, Brian LeRoux <b...@brian.io> wrote: > You know what. I'm super wrong. I was thinking in the context of a > native project and not a *cordova* project. > > The flaw in the thinking was that we were shipping only one file we > build leaving devs to include as they see fit. But whats really > happening is that we are generating a new file for every plugin > add/remove which will be different for each platform. If they move > that file around and include from a directory of their choosing we're > fucked. > > The difference here is the audience. A developer content to NOT use > our tools, and compose their own app for a single platform, say > Android, is going to have to figure out inclusion themselves. For us, > its a build time concern. Not magic. > > Consider: we are required to re-build every time a user adds/removes a > plugin. And if they move that generated file, again, we're fucked. > This is increasingly looking like a script inject....which we could > make configurable with config.xml so that it isn't too magical > feeling. > > We should talk about how the www install part works though. I wonder > if it would appropriate to propose a special folder in www for this > purpose. Like node_modules but without fugly underscores. > > > On Wed, Feb 6, 2013 at 4:01 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > For a project who's main language is JS, I'm a bit surprised that > injecting > > a script tag through DOM manipulation would put us into the "magic" > > category... > > > > Brian - Your sentiments about the development stack don't make sense to > me. > > The development stack is *the* job of CLI. We are prescribing a way to > set > > up your project so that it's easy to have an x-platform www directory, > and > > writing tools to make it easy to add/remove plugins. Is not "the > > development stack" *the* goal of CLI? > > > > This isn't a problem that we can "not solve". It's a problem that exists, > > and doing nothing *is a solution*. Here's the "do nothing" solution: > > - Let plugins put their .js file anywhere within the www/ directory (and > > hope that it doesn't clobber anything) > > - Have them write documentation to instruct users that they must insert > > their script tags into each of their .html files > > - Hope that users notice the instructions, and that they are correct, and > > that they don't mess them up > > - Hope that users can remember which JS files belong to what if they ever > > want to remove plugins > > > > Note that for our core plugins, we have 78 .js files just within > > lib/common/plugin. > > > > A variation on "do nothing": > > - Tell each plugin developer to come up with their own packaging system > > - Tell them to check in a pre-packaged version with every commit (or just > > on releases) > > - Tell them to write instructions for the manual steps involved in > adding / > > removing their plugins. > > > > I don't accept that this isn't a problem. If there are actually better > > alternatives, I'd like to hear what they are, and what the development > > workflow looks like for both the plugin users as well as the plugin > > developers. > > > > > > Anis - What sort of needs / requirements are you thinking of that won't > > work with the injecting script tags approach? Let's try and work through > > them. The same argument could be used to shoot down the entire CLI > effort... > > > > > > Andrew > > > > > > On Wed, Feb 6, 2013 at 6:27 PM, Joe Bowser <bows...@gmail.com> wrote: > > > >> I also disagree with automagically injecting the script tags. If > >> we're adding the script tags, we have the ability of adding the script > >> tags wrong, and breaking people's apps with magic. We have enough > >> trouble directing our users to use Cordova/PhoneGap without us trying > >> to make things more clever. > >> > >> On Wed, Feb 6, 2013 at 2:39 PM, Anis KADRI <anis.ka...@gmail.com> > wrote: > >> > I don't think we should be automatically injecting javascript tags. > >> > Instruct users to do so when they add a plugin by displaying the tag. > >> > Everyone has different needs/requirements. > >> > > >> > Also > >> > > >> > *"cordova plugin add file" > >> > - Download plugin files to project/plugins > >> > - Runs plugman to install native parts of the plugin. > >> > - Plugman will copy JS files listed into > >> > project/platforms/cordova-js/lib/...* > >> > * * > >> > *plugman supports installation by local-dir/git-repo/name. Names are > >> > listed/stored on an outside source. So I believe this step should just > >> call > >> > plugman with the name/git/local-dir. We've already agreed that all > >> plugins > >> > will have separate repositories, yes ?* > >> > > > > Which step are you referring to? Could you maybe write out the version of > > how things work that you're suggesting? > > > > > > > >> > * > >> > * > >> > *I also agree that plugin.xml should support dependencies and that we > >> > should update the plugin spec. **I like the requires-plugin tag but I > am > >> > not sure I like that js-symbols tag in plugin.xml though. **I am > confused > >> > about that "Exporting Module Symbols" section. An example would be > >> > appreciated.* > >> > > > > There's this example in the doc already: > > * > > > > <js-symbols> > > > > <defaults module=”cordova/plugin/file/requestFileSystem” > > target=”requestFileSystem”> > > > > <clobbers module=”cordova/plugin/network/connection” > > target=”navigator.connection”> > > > > <merges module=”cordova/plugin/file/FileEntry” target=”FileEntry”> > > </js-symbols>* > > * > > * > > And what symbol.js files look like is described in > > https://issues.apache.org/jira/browse/CB-2227 > > > > *Does this help? Is there something else you want an example of?* > > > >> * > >> > * > >> > *Anis* > >> > > >> > > >> > On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson < > bra...@chromium.org > >> >wrote: > >> > > >> >> I think it's fine to have the default behavior be to inject script > tags. > >> >> That will suffice for 90% of our users, probably more. If you fall > into > >> the > >> >> 10% that have some more complicated setup, we should provide a flag > like > >> >> > cordova plugin add --no-inject-js myplugin > >> >> that prevents us from doing it automatically, and you can do whatever > >> more > >> >> complex step you need to do. > >> >> > >> >> > >> >> Braden > >> >> > >> >> > >> >> On Wed, Feb 6, 2013 at 3:37 PM, Andrew Grieve <agri...@chromium.org> > >> >> wrote: > >> >> > >> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <f...@adobe.com> wrote: > >> >> > > >> >> > > > >> >> > > > >> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <agri...@chromium.org> > wrote: > >> >> > > > >> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <f...@adobe.com> > wrote: > >> >> > > > > >> >> > > >> I've added a few detail explanations to the document, but > moved > >> the > >> >> > > >> discussion to the ML. > >> >> > > >> > >> >> > > >> ---- > >> >> > > >> > >> >> > > >> > Should be easy to install / remove plugins (no need to > manually > >> >> > > >> >add/remove script tags) > >> >> > > >> > >> >> > > >> > >> >> > > >> I think adding/removing script tags is the way to go. > >> Concatenating > >> >> > all > >> >> > > >> javascript relevant to your project (cordova.js + any plugins > you > >> >> add) > >> >> > > >> makes it difficult to debug later on. WE'd have to get users > to > >> post > >> >> > > >> entire contents of their cordova.js file to determine what was > >> added > >> >> > and > >> >> > > >> what exists in there. With that in mind, I favor the packager > >> >> > approach, > >> >> > > >> which would require: > >> >> > > >> > >> >> > > > > >> >> > > >Very good point about concat making it hard to track bugs! I > >> wonder if > >> >> > > >there's a better way than requiring users to manually add the > tags > >> (we > >> >> > > >don't require them to manually add native files to their project > >> >> files). > >> >> > > > > >> >> > > >One thought is to have cordova-packer output source-maps. I > don't > >> >> think > >> >> > > >there's very good support for them in mobile browsers yet, but > we > >> >> could > >> >> > > >use > >> >> > > >them to manually map exception line numbers to file+line > numbers. > >> >> > > > > >> >> > > >Another idea is to use exec + special comment that is used in > our > >> >> > existing > >> >> > > >pkg/debug/*.js files. I don't think support for this is all that > >> great > >> >> > > >either though. > >> >> > > > > >> >> > > >Another idea is to have cordova.js inject a script tag for each > >> >> module. > >> >> > > >This may have an adverse effect on start-up time, but probably > no > >> >> worse > >> >> > > >than if the user manually adds all of the script tags > separately. > >> >> > Winner? > >> >> > > > >> >> > > I don't think the script tag is a giant issue, but I do think it > is > >> a > >> >> > > slipper slope problem to try and solve. What if the user has a > >> >> multipage > >> >> > > application? Do we then add script tags automatically to all > pages? > >> >> What > >> >> > > if the user only uses the plugin on specific pages? Etc etc > >> >> > > > >> >> > > >> >> > I'm suggesting that any page that include (manually) cordova.js > will > >> have > >> >> > it dynamically inject installed plugin JS files. Should work fine > in a > >> >> > multi-page app. We don't currently disable plugins on a per-page > >> basis. > >> >> Is > >> >> > this really an important use-case? If so, I'm sure we could figure > out > >> >> how > >> >> > to not inject script tags for plugins you don't want. > >> >> > > >> >> > >> >
