bin/sh -c /Users/kim/Library/Developer/Xcode/DerivedData/Mindly-egaqylbrvuzzjcbyzzjgarrlwaio/Build/Intermediates/Mindly.build/Debug-iphonesimulator/Mindly.build/Script-304B58A110DAC018002A0835.sh PhaseScriptExecution Copy\ cd /Users/kim/ionic/mindly-app/rc-wip/platforms/ios = BUILD TARGET Mindly OF PROJECT Mindly WITH CONFIGURATION Debug = = BUILD TARGET CordovaLib OF PROJECT CordovaLib WITH CONFIGURATION Debug = SWIFT_OBJC_BRIDGING_HEADER = $(PROJECT_DIR)/$(PROJECT_NAME)/Bridging-Header.h HEADER_SEARCH_PATHS = "$(TARGET_BUILD_DIR)/usr/local/lib/include" "$(OBJROOT)/UninstalledProducts/include" "$(OBJROOT)/UninstalledProducts/$(PLATFORM_NAME)/include" "$(BUILT_PRODUCTS_DIR)" SHARED_PRECOMPS_DIR = /Users/kim/ionic/mindly-app/rc-wip/platforms/ios/build/sharedpchīuild settings from configuration file '/Users/kim/ionic/mindly-app/rc-wip/platforms/ios/cordova/build-debug.xcconfig':ĬLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YESĬODE_SIGN_ENTITLEMENTS = $(PROJECT_DIR)/$(PROJECT_NAME)/Entitlements-$(CONFIGURATION).plist Running command: /Users/kim/ionic/mindly-app/rc-wip/hooks/after_prepare/010_add_platform_class.js /Users/kim/ionic/mindly-app/rc-wipīuilding project: /Users/kim/ionic/mindly-app/rc-wip/platforms/ios/Mindly.xcworkspaceĬONFIGURATION_BUILD_DIR = /Users/kim/ionic/mindly-app/rc-wip/platforms/ios/build/emulator > ionic:serve /Users/kim/ionic/mindly-app/rc-wip The port was taken on the host 10.0.0.210 - using port 8000 instead In essence, -livereload is outright ignored. So now you have two platforms, and none of the two is being updated for changes. It looks like since v2.1.5, this conflict issue has been mitigated by disabling -livereload on ionic emulate.
Now what happens if you make a change to the /src source code ? Logically you end up with two conflicting builds : the one on the emulator is still based on the old code, while the one on the browser has been updated with the new code base.Can't see the need for the dev server when emulating. So now you have two different testing platforms.
If you think about it, this means that you are launching a full build for the emulator, and simultaneously spawning a separate dev server with -livereload ability.
In the end, what does it mean to type ionic emulate -livereload ? If ionic emulate -livereload sounds bad, maybe you could implement something like ionic emulate -watch ? A side note I strongly believe that the tooling would be greatly improved by adding the ability to streamline the coding/webpack/cordova process when testing against the emulator or the device.
Improving the dev toolsīut ultimately, if I run ionic emulate -livereload I don't expect changes to be pushed to the browser, do I ? However I do expect changes to be pushed to the emulator. It was always intended to be a parameter for the dev server, not for the cordova buids. That's why I think the -livereload terminology is confusing. However the problem is that while ionic emulate -livereload pushes changes to the browser, it does not push them to the simulator. it watches for changes in src/ and pushes them to www/ and then updates the browser. With hindsight I believe there is confusion about the -livereload terminology because ionic serve -livereload works exactly as expected, i.e. The first one deals with webpack (src/ -> -livereload is a parameter for the dev server
This means that building involves two different steps. I think the main point is : in Ionic 2 we are working off src/, not www/