You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Get latest application package for current specified configuration
When we try to get the latest application package for device/emulator, we check the build output directory and get latest available .apk/.ipa. However this is not always correct as sometimes we do not build the app. Consider the following case:
* tns build android --release
* tns build android
* tns build android --release
At the last point, the build will not be executed, as there are no changes. However the last built .apk is from the debug build (we have release .apk, but it's older). So in case we try to get the last build output from last operation, CLI will return the debug.apk
Fix this by checking the current build configuration and get the latest result by using it. For iOS respect the expected output - is it for device or for simulator as the output is different.
* Fix isValidNativeScript project
The isValidNativeScript project method is used in Fusion. However the implementation is not correct. Fix it to have correct behavior.
In order to fix it, modify projectData.initialize method - there's obsolete code for migration from .tnsproject to package.json - we do not need it anymore, so remove it.
Also fix a case where failing builds do not fail the build process (incorrect argument passed to childProcess.spawnFromEvent).
Update documentation for PublicAPI.
* Throw correct error when build for iOS in non-interactive terminal
Also in case CLI's executed in non-interactive terminal and there's no DEVELOPMENT_TEAM set, tns build ios --for-device fails with message "Console is not interactive and no default action specified" which does not give any info to the users.
So in this case add more descriptive error message.
* Fix local builds when CLI is required as lib
When CLI is required as library, the `$options` dependency is not populated. However the projectChangesService relies on it in order to determine if the project should be prepared/built.
When CLI is required as library and you change only the build configuration (debug/release), the project is not rebuilt. However when you use the CLI and try the same, a new full build is triggered.
Fix this by parsing required boolean flags to projectChangesService and exclude `$options` from its implementation. This way local builds will work in the same manner both from command line and when required as library.
Steps to reproduce the problem:
* use CLI as lib
* create local build for android in debug configuration
* create local build for android in release configuration - you'll notice gradle clean is not called at all and also in the `<project dir>/platforms/android/build/outputs/apks/` there are both debug and release apks. This should never happen when changing configurations.
* Pass buildConfig when getting path to last build output
Pass the whole buildConfig object when getting the path to the last build output. This required changes in debug services and TestExecutionService.
Also change the args of cleanProject method - the `options` passed to `gradle` are now determined in the method itself instead of passing them from the caller.
This way we'll not require "android-23" (the default one set in build.gradle) when we miss to pass the required options.
*`isValidNativeScriptProject(projectDir: string): boolean` - Checks if the specified path is a valid NativeScript project. Returns `true` in case the directory is a valid project, `false` otherwise.
CLI is designed as command line tool and when it is used as a library, it does not give you access to all of the methods. This is mainly implementation detail. Most of the CLI's code is created to work in command line, not as a library, so before adding method to public API, most probably it will require some modification.
118
144
For example the `$options` injected module contains information about all `--` options passed on the terminal. When the CLI is used as a library, the options are not populated. Before adding method to public API, make sure its implementation does not rely on `$options`.
this.$logger.info("No .ipa, mobile provision or certificate set. Perfect! Now we'll build .xcarchive and let Xcode pick the distribution certificate and provisioning profile for you when exporting .ipa for AppStore submission.");
0 commit comments