Additional thought: This means that it doesn't make sense to test plugins in multiple Node.js versions as well, the best and fastest is always ok for plugins, correct?
-J Am Fr., 17. Mai 2019 um 07:49 Uhr schrieb Jesse <purplecabb...@gmail.com>: > > Sounds good to me. > Faster CI is better CI > > > On Thu, May 16, 2019 at 2:16 PM Jan Piotrowski <piotrow...@gmail.com> wrote: > > > None of the plugins have a `hooks` directory or anything else that > > looks similar. > > > > Is anyone aware of any script in the plugin repositories that is > > executed on the developer side? > > > > Otherwise I think we should be good to define adding and dropping > > Node.js versions as non-breaking for plugins. > > > > Best, > > Jan > > > > Am Sa., 11. Mai 2019 um 10:49 Uhr schrieb <raphine...@gmail.com>: > > > > > > Sounds like a good idea under the premise that our plugins really do not > > > contain any scripts that > > > are executed on the developer machine. > > > > > > But aren't there any core plugins that define hooks? > > > > > > Am Sa., 11. Mai 2019 um 10:03 Uhr schrieb Jan Piotrowski < > > > piotrow...@gmail.com>: > > > > > > > Currently our plugin CI uses the same version of Node.js as Tooling > > > > and Platforms, until recently 4.2 and now 6. > > > > > > > > But if I am not mistaken, our plugins do not contain any scripts that > > > > are executed on the developer machine, only JavaScript files that are > > > > run inside the app or native code. So it doesn't really matter what > > > > node version is used to run our plugin CI tests as it doesn't run any > > > > actual scripts (vs. with platforms, we have scripts that are actually > > > > run by the developer). > > > > > > > > Could we maybe just go to node 10 or 12 with our plugins right now? > > > > > > > > This would give as quite some time until we have to update our CI > > > > configuration again, and possibly also quicker installs and builds. > > > > > > > > Best, > > > > Jan > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org