Cordova module support

131 views
Skip to first unread message

Arzhan Kinzhalin

unread,
Jul 24, 2015, 4:50:03 PM7/24/15
to tern-dev
Hi;

I'm looking into supporting code hinting for cordova [1] modules. This is a question for guidance as to what would be a proper way and if my idea of how it should be supported is correct. I'd appreciate any input on the matter.

Let me take geolocation plugin [2] as an example. I'll be simplifying for the sake of discussion. Most of the cordova plugins has plugin.xml [3] which, in case of geolocation, specifies the JS module file www/geolocation.js and a "mount point" global navigator.geolocation:

        <js-module src="www/geolocation.js" name="geolocation">
           
<clobbers target="navigator.geolocation" />
       
</js-module>


The module itself, in turn, has special format: it does not wrap the code in define() and it uses modules.exports to export its API. In geolocation [4]:

// ... SKIP majority of the code for brevity


// Returns a timeout failure, closed over a specified timeout value and error callback.
function createTimeout(errorCallback, timeout) {
   
// ... SKIP the implementation for brevity
}


var geolocation = {
    lastPosition
:null, // reference to last known (cached) position returned


   
// ... SKIP the API def for brevity
};


module.exports = geolocation;


When injecting the plugin, cordova would wrap the module in it's own define() and load it at navigator.geolocation.

Apparently, there's no straightforward way to handle cordova plugins with tern (I'm specifically looking to condense them). Condense would produce a module definition, but it would be ignorant of the fact that only geolocation object is exported. Resulting definition would be hinting for (referring to the code snippet above) createTimeout and geolocation as they were globals. While at runtime createTimeout will be unavailable and geolocation will be at navigator.geolocation.

So, there are a couple of solutions I could think of:

1. [Hacky] Post-process the def output after condense to transform it to the "right" API.
2. Create a plugin, similar to requirejs or node, to support cordova module format and "mounting points" and other modifiers which could be applied via plugin.xml. Many similarities with CommonJS modules make node plugin a good starting point. However, the plugin is completely different runtime (WebView on a mobile platform) and should be separate.
3. [Not nice] Modify node plugin to support cordova modules.

IMO, 2) is the best option and it is what the tern architecture dictates to do. Is this the right conclusion?

Also, Marijn, would you consider taking cordova support to "core" tern plugins when it's done?

Thank you,
Arzhan

-- 
// kai

Angelo zerr

unread,
Jul 24, 2015, 9:40:49 PM7/24/15
to Arzhan Kinzhalin, tern-dev
Hi Arzhan,

Please see https://github.com/vrubezhny/tern-cordovajs It should be cool if you could improve it.



Regard's Angelo

--
You received this message because you are subscribed to the Google Groups "tern-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tern-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marijn Haverbeke

unread,
Jul 25, 2015, 4:56:19 PM7/25/15
to Angelo zerr, Arzhan Kinzhalin, tern-dev
So yes, do #2, but if at all possible, don't reinvent it but work with
Angelo's code. Also, nope, I am not interested in taking this into the
core distribution (since that tends to make me responsible for
maintaining it, and I have more than enough to do).
Reply all
Reply to author
Forward
0 new messages