cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Proposal: hooks support for plugins
Date Tue, 22 Apr 2014 17:39:26 GMT
Passing in a reference is not a bad idea, though that implies that there is
a single top-level `cordova` object to reference.  Not sure if thats the
plan so far.. though it could be.

Probably easier to just support require() of cordova bits, but I'm not sure
how to get that to work.


On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b@brian.io> wrote:

> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the node
> > module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b@brian.io> wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts altogether and
> > > forcing modules as the way for hooks. Cross platform yada yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mmocny@chromium.org>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself?  (I was trying to call "cordova plugin ls" and ended
> up
> > >>> just writing my own crude inline implementation instead).  If the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> 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-segreb@microsoft.com> wrote:
> > >>>>
> > >>>>> +1, I will name it as 'context'
> > >>>>>
> > >>>>> Thx!
> > >>>>> Sergey
> > >>>>> -----Original Message-----
> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@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.
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message