cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <maj....@gmail.com>
Subject Re: Incompatible plugin should reject the build
Date Wed, 26 Jul 2017 19:50:10 GMT
OMG late to this thread but yes, this should fail and freakout. My
assumption is the same as the person who reported CB-12122 is: any
dependent plugins that fail constraint checking would bubble the
failure up the dependency chain. Unfortunately, the behaviour is not
_super_ explicit in the docs [1] - we should fix that. Currently it is
"The CLI aborts with a non-zero code for any plugin whose target
project does not meet the engine's constraints." To me that implies
fail+freakout, but we could elaborate on the wording here a bit more.

This issue is closely entangled with how to integrate certain plugins
into platform code, esp. if the plugin is a common dependency. In
particular looking at cordova-plugin-compat [2]. The decision in this
thread would determine whether future versions of core plugins that
currently depend on compat (camera, geo, and others) would need to
depend on compat forever, or could remove the dependency altogether.
If we keep current behaviour, future versions of e.g. camera need to
keep a <dependency> on compat. If we change the behaviour to fail and
freak out, we can remove the dependency after integrating compat into
cordova-android. Strict engine constraints would need to land in
plugins moving forward in either case.

I would also like to push for aligning cordovaDependency and <engine>
behaviour ASAP. As per our docs today [3], we already say "[the
cordovaDependencies] feature is intended to eventually replace the
engines element in plugin.xml." Do we have an issue filed to do that?

[1] https://cordova.apache.org/docs/en/latest/plugin_ref/spec.html#engines-and-engine
[2] https://issues.apache.org/jira/browse/CB-12730
[3] https://cordova.apache.org/docs/en/latest/guide/hybrid/plugins/index.html#specifying-cordova-dependencies

On Fri, Jun 2, 2017 at 12:15 PM, Kerri Shotts <kerrishotts@gmail.com> wrote:
> +1 Fail (I think principle of least surprise applies here; most devs would expect an
incompatible plugin to fail the build.)
>
> ~ Kerri
>
>> On Jun 2, 2017, at 12:15, Shazron <shazron@gmail.com> wrote:
>>
>> Consensus on this long stewing issue of 7 months?
>>
>> If you deleted the thread:
>> 1. Issue https://issues.apache.org/jira/browse/CB-12122
>> 2. Thread https://s.apache.org/ofqR
>>
>> +1 on engine check failing the build.
>> Questions that need answered: Does cordova-fetch on cordova@7 do this
>> already, like Simon said?
>>
>>
>> On Mon, Nov 7, 2016 at 6:34 PM, Simon MacDonald <simon.macdonald@gmail.com>
>> wrote:
>>
>>> I think an engine check should fail the build. If there plugin version
>>> they are trying to use will not work with the version of cordova or
>>> platform they are currently using in their project it should not
>>> build. Folks can screw up their semver in config.xml and end up
>>> pulling in a plugin version that doesn't work with the CLI they are
>>> currently using so stuff will just be horribly broken without them
>>> knowing.
>>>
>>> Also, I thought the new cordova-fetch was supposed to prevent this
>>> sort of thing?
>>> Simon Mac Donald
>>> http://simonmacdonald.com
>>>
>>>
>>> On Mon, Nov 7, 2016 at 8:24 PM, Shazron <shazron@gmail.com> wrote:
>>>> See https://issues.apache.org/jira/browse/CB-12122
>>>>
>>>> Right now if a plugin fails an <engines> check, it just warns. Should
we
>>>> make engine checks fail the build?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message