faugusztin commented on issue #1422: URL: https://github.com/apache/cordova-ios/issues/1422#issuecomment-2466680365
The [src/cordova/prepare.js](https://github.com/apache/cordova-lib/blob/master/src/cordova/prepare.js) file has a hooksRunner promise chain which calls in succession: - fires the before_prepare hook - restore.installPlatformsFromConfigXML (creates the platform structure from the default template files) - processing various options into an options object - restore.installPluginsFromConfigXML - installs plugins. This is where this use case fails, because for now, the config.xml is still the one from the cordova-ios template. Adding a plugin with a cocoapod dependency, which required a higher deployment target in this step causes Podfile to contain lower deployment target (as it is not yet written to config.xml, thus not picked up the Podfile.js logic), which then stops the process. - module.exports.preparePlatforms - this one actually updates the config.xml inside the platform/ios folder based on the root config.xml. - fires the after_prepare hook > I tried to take a quick skim through the JS code to find out when/where exactly root config.xml stuff is copied to the platform file, but didn't find it and can't remember the details. https://github.com/apache/cordova-ios/blob/master/lib/create.js#L78 in method provideProjectTemplate ther is a call for `fs.cpSync(this.options.templatePath, this.project.path, { recursive: true });` which does that task. > I saw a lot of stuff about config munging for `edit-config` and `config-file`, which obviously isn't safe to do before plugins have been installed. So if it's as simple as copying config.xml then it should be okay, but otherwise we might need to special case this particular preference during creation. Alternatively pod install shouldn't be called in the `restore.installPluginsFromConfigXML` step if it is initial platform creation, but i am unsure if that is even possible. But this could break someones plugin, if they would modify files downloaded by pod install in after_plugin_install or after_plugin_add (unsure how realistic this is, but it is an option), so not sure if this is a valid way to solve the issue. Last alternative is for callers of Podfile.js to pick minDeploymentTarget based on config.xml from root too, thus it would be 4 options: - (existing logic) pick deployment-target from platform/ios/App/config.xml - (new code) look at project root config.xml widget->preference[name="deployment-target"] - (new code) look at project root config.xml widget->platform[name="ios"]->preference[name="deployment-target"] - (existing logic) hardcoded default in Podfile.js (11.0 in cordova-iox 7.x, 13.0 in cordova-ios 8.x) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
