Re: Incompatible plugin should reject the build

[Filip Maj <ma...@gmail.com>]

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 <ke...@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 <sh...@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 <si...@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 <sh...@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

Re: Incompatible plugin should reject the build

[Steven Gill <st...@gmail.com>]

Just created an issue for swapping to cordovaDependency from engine.
https://issues.apache.org/jira/browse/CB-13123

I agree that we should switch the behavior to fail. It would need to be a
major version of cordova. Chatted with Shaz & Simon and decided it would
make sense to add a flag to current cordova that allows plugin add to fail
if the dependency fails. So cordova@7 the default behavior will be skip the
plugin or dep that doesn't satisfy the requirement and fail will be behind
a flag. Once we hit cordova@8, we can swap the behavior so fail is default
and skip is behind the flag.

I will update https://issues.apache.org/jira/browse/CB-12122 with this
proposal.

Let us know what y'all think.

On Wed, Jul 26, 2017 at 12:50 PM, Filip Maj <ma...@gmail.com> wrote:

> 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 <ke...@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 <sh...@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 <sh...@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
>
>