not a fan of upstream distros in the engine stanza

[pmuellr]

The example lists an engine named "worklight" in the stanza. Not a fan. Or maybe this is a bad example. I could see if a plugin WAS ONLY supported by worklight, we might want to let people know. But if it lists "cordova" as well, as this one does, then the worklight entry really just tells me which versions of worklight are compatible with versions of cordova, or something.

I think a better use case is if you imagine for a second, that you could use these plugins in node.js. In which case, yeah, I might want to list "node" in there with the appropriate versions, along with cordova.

But the worklight example doesn't do much for me. Worklight presumably will ship some # of versions that support some # of versions of cordova. And so I imagine that having just "cordova" entries will work for the "batteries included" plugins Cordova ships. For anything Worklight ships that ONLY runs in worklight, they would never put a "cordova" entry in there. For anything Worklight ships that DOES happen to run in worklight, they'd use just a "cordova" entry.

So, summing up, I think the example is bad. But I guess the general concept is good.

Curious to see how these engine stanzas have worked out for npm packages.

[alunny]

Yeah I'm of a mixed mind for using the engine element for anything other than specifying compatible versions of Cordova. That or something like Adobe® PhoneGap™ (cough), where a downstream distro may have capabilities that Cordova does not.

cc @mwbrooks and @filmaj to chime in when they have time

[filmaj]

+1 @pmuellr's suggestion of looking into how node has worked out with engines in package.json. Apparently @isaacs has recommended removing it altogether but there seems to be a bit of backlash.

Instead of figuring it out I will just leave the link here and go back to exploring Europe until next week :D kthxbye