this capability is supported in npm (for which we base much of our plugin thinking and src) so technically I don't see much issue and the use cases are def there
On Mon, Mar 3, 2014 at 10:44 AM, Andrew Grieve <agri...@chromium.org> wrote: > There's definitely a security angle to this. E.g. You install a plugin and > now it's running code on your machine in a non-sandboxed way. Maybe could > warn before running the script for the first time, or show a badge on its > plugins.cordova.io page to highlight this. > > install hooks might make it harder to uninstall a plugin as well. > > > On Sat, Mar 1, 2014 at 6:47 PM, Jesse <purplecabb...@gmail.com> wrote: > > > I originally replied to the personal cc: version of this message I got. > > Here is what I said : > > > > It's a very interesting idea and would be powerful. > > My only concern is that Cordova apps can be built just by calling > platform > > create scripts, with plugins added by calling plugman directly. The hooks > > are very specific to cordova-cli builds. > > > > Another approach would be to add platform level hooks that plugins could > > subscribe to, maybe just pre-build and post-build. > > > > And plugman level scripts for install/uninstall > > > > Then possibly even cordova-cli hooks that just trigger the underlying > > functions. > > > > > > @purplecabbage > > risingj.com > > > > > > On Sat, Mar 1, 2014 at 10:39 AM, Sergey Grebnov (Akvelon) < > > v-seg...@microsoft.com> wrote: > > > > > Hi, I have an idea how we can add more flexibility to plugin developers > > > and would like to discuss it. > > > > > > Note, right now we have Application Developers - someone who use > Cordova > > > for developing applications and Plugin Developers - someone who creates > > > plugins so that Application Developers can use them. For Application > > > Developers we expose hooks so that they can customize their > > > build/package/etc process. I want us to provide similar sort of > > flexibility > > > to Plugin Developers so that they can go beyond of <source/>, > > <framework/> > > > tags and get mechanism to add custom installation, build logic > required > > > by a plugin. Example usage will include: downloading/compiling > additional > > > binaries, marking source file to be copied to output dir, changing > target > > > build platform, etc. At present time the steps described could be only > > > achieved by hooks manually added by Application Developer, but the > right > > > way is to allow Plugin Developer to expose this as part of plugin > > > definition. > > > > > > I personally like how npm-scripts[1] work so propose to introduce > > > additional <scripts> section in plugin.xml, for example > > > > > > <scripts preinstall="preinstall.js" postinstall="afterinstall.js" /> > > > > > > preinstall.js is called before plugman.raw.install(platform, > > platformRoot, > > > path.basename(dir), pluginsDir, options) and could be used to check > > system > > > requirements, download/compile required libraries, etc > > > > > > afterinstall.js is called after and could be used to add/configure > > > additional project references, etc > > > uninstall.js - for discussion, could be used for clean up, etc > > > > > > As for required parameters I think we should pass at least application > > > folder and target platform. > > > > > > Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm > > > EST) > > > > > > [1] https://www.npmjs.org/doc/misc/npm-scripts.html > > > > > > -Sergey > > > > > >
