There are some *disadvantages* to not sub-shelling out for hooks: - Harder to capture their stdio (certainly do-able though by swapping out system.std* for the duration of the hook) - Harder to handle script failures (e.g. if they throw an uncaught exception, we would like to be able to say "This hook script failed: foo.js") - Maybe this is doable, by storing a global exception-was-thrown callback? - Gives hooks the ability to mess up cordova's environment (although maybe the vm thing addresses this?)
Would like to see tests for these things added before we launch this feature. On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > +1, I will name it as 'context' > > Thx! > Sergey > -----Original Message----- > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com] > Sent: Tuesday, April 22, 2014 7:34 AM > To: dev@cordova.apache.org > Subject: RE: Proposal: hooks support for plugins > > On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote: > > module.exports = function(platform, projectDir, pluginDir, cmdLine) { > > console.log('hook.js: ' + platform); > > console.log('hook.js: ' + projectDir); > > console.log('hook.js: ' + pluginDir); > > console.log('hook.js: ' + cmdLine); > > > > Personnaly prefer: > > > module.exports = function(hookApi) { > > console.log('hook.js: ' + hookApi.platform); > > console.log('hook.js: ' + hookApi.projectDir); > > console.log('hook.js: ' + hookApi.pluginDir); > > console.log('hook.js: ' + hookApi.cmdLine);} > > Make it easier to pass other stuff in the future & using a sandoxed > hookApi object. > > >
