Ionic-cli: `--prod` ignored since CLI 5.3.0 (Cordova/Angular)

[wilk-polarny]

Description:
Since upgrading to CLI 5.3.0, the ionic CLI will not run

ng run app:ionic-cordova-build:production

if being called with ionic cordova build ios --prod or ionic cordova build ios --configuration=production

Steps to Reproduce:

• Install the latest CLI
• Try to initiate a prod build
• Observe the CLI only calling ng run app:ionic-cordova-build --platform=ios

Output:

My ionic info:

Ionic:

   Ionic CLI                     : 5.3.0 (/Users/Wilk/.nvm/versions/node/v10.16.3/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.9.0
   @angular-devkit/build-angular : 0.801.2
   @angular-devkit/schematics    : 8.1.1
   @angular/cli                  : 8.1.1
   @ionic/angular-toolkit        : 2.0.0

Cordova:

   Cordova CLI       : 8.1.2 ([email protected])
   Cordova Platforms : ios 5.0.1
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 4.1.1, (and 5 other plugins)

Utility:

   cordova-res : 0.6.0 
   native-run  : 0.2.8 

System:

   Android SDK Tools : 25.2.2 (/Users/Wilk/Library/Android/sdk)
   ios-sim           : 8.0.2
   NodeJS            : v10.16.3 (/Users/Wilk/.nvm/versions/node/v10.16.3/bin/node)
   npm               : 6.9.0
   OS                : macOS Mojave
   Xcode             : Xcode 10.3 Build version 10G8

Other Information:
This was really a showstopper for us, as this bug breaks our production builds using the Ionic CLI. Downgrading to 5.2.8 seems to work.

[StormPooper]

This also happened to our build pipeline and downgrading to 5.2.8 fixed it for now.

[robin-huss]

I can confirm both the issue, and that downgrading to 5.2.8 'fixes' the problem.

[imhoffd]

Thanks for the report! Looks like I missed something. The fix will be released shortly.

[JamesJeffery-RM]

We've been experiencing this as well. Currently using ionic cordova build ios -c=production as a work around. I don't know if it does everything that --prod does, but it at the least uses our production environment config.

[l3ender]

This one really bit us. For our Ionic dependency we were using carot range on v5, so our application pulled in 5.3.0. Should we instead be locking to specific versions, or only tilde locking for patch releases only? Or would it still have been possible that a bug of this order would have been released in a patch version?

[wilk-polarny]

@l3ender this has been fixed for versions after 5.3.0

[l3ender]

Yes, I understand it's now fixed. However, since we built and deployed a version prior to the fix, I'm trying to get some more info on how something like this can be avoided in the future.

[wilk-polarny]

@l3ender , simple smoke testing? For iOS for example we usually do a manual test-flight (with our clients) before we push anything into production via MDM or the AppStore. This saved us from some possible embarassment numerous times before.

Cause even if it looks like a duck and quacks like a duck, it can still be your debug version or some abomination in a costume ;)

[l3ender]

@wilk-polarny How are you targeting ionic in your dependencies? Exact/tilde/carot/other?

https://docs.npmjs.com/misc/semver#tilde-ranges-123-12-1

[wilk-polarny]

@l3ender , we usually use fixed versions - except for global dependencies (which in our case caused the issues after we upgraded it on our machines - lessons learned here). Project dependencies are pinned, though, as we have to verify each dependency and its dependencies in regards to compatibility, licensing and so on.

For Ionic projects, we usually stick to the ionic starter project deps as a base (combination of ionic + angular + other deps) because those are "known to work".

Other people I know use caret ranges and obligatory package locks to ensure consistent builds across machines.

I would say, it also depends on the package you're pulling in and whether package maintainers/devs actually get it right and don't introduce breaking changes with minor or patch versions. No risk, no fun.