Cherry-pick commits for 3.3.1 #3216
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Make analytics-settings-service getClientId public * Allow tracking for multiple Google Analytic Projects * Add cross client custom dimensions * Add npmVersion and dayFromFirstRun custom dimension values * Update cross client analytics google tracking id * Remove unnecessary custom dimensions from the cross client project * Add doc and public method test
Changelog for 3.3
In case CLI is used as a library, the device logs are no longer captured after application is restarted. The problem is the newly added logic for Android devices that stops the logcat process when CLI calls `stopApplication` and starts it when `startApplication` is called. However, in `startApplication` there's a check if `$options.justlaunch` is false - only then the device log operation is started again. When CLI is used as a library, we have hardcoded the `justlaunch` option to true in order to prevent duplicate logs for iOS devices. So the solution to resolve Android logs issues is to remove the setting of justlaunch option. However, this caused the duplicate logs issue for iOS devices. Investigating it further, it turned out to be a memory leak when iOS device is detached. It's fixed in the submodule: In case iOS Device is detached, the `IOSDevice` instance is kept alive. The reason is the handler for device logs, that `IOSDevice` passes to `iOSDeviceOperations`. As `iOSDeviceOperations` is still alive, the `IOSDevice` instance is also alive. Reattaching the same device will cause duplicate logs. Detaching and attaching it again will lead to additional logs. In order to fix the issue, convert `iOSDeviceOpertations` to event emitter and emit event when there's data for logging. Each `IOSDevice` will add handler for the event and will do its logic. In case device is detached (i.e. `DeviceLost` event is fired in `DevicesService`), call a newly added method to the specific `IDevice` instance. It's purpose is to clean the used resource. For iOS device, this method will remove the handler for `devceLogData` event of `iOSDeviceOperations`.
In case any command fails, we execute help command in order to show the help content. This leads to multiple trackings, i.e. - user executes only one command, but in Analytics we see two commands. Instead of executing help command, introduce new method in htmlHelpService, that prints the help to the terminal and call it instead. Use the same method in the help command itself. Rename htmlHelpService to helpService - it has been incorrectly named from the beginning. Remove `helpTextPath` from staticConfig interface - this property is not used for more than 2 years. Introduce tests for `helpService` - get the tests from AppBuilder CLI.
In case we are unable to start the Analytics Broker process, CLI will fail. But analytics errors should not break user's workflow, so catch the error and ensure the actions will continue. Add tests to verify the behavior.
Currently CLI's configuration directory is used from `$options.profileDir`. When user passes `--profileDir <path>`, the `$options.profileDir` value is populated.
In case user does not pass anything, a default value is set. All services that require configuration directory use the `$options.profileDir`. However, this causes several issues:
- `$options` is intended for use only when CLI is used as a standalone command line. In case you are using it as a library, the `$options` object will not be populated.
- Unable to test local installations of extensions when CLI is used as library - there's no way to set the custom profileDir when using CLI as a library. So the extensions are always loaded from the default location.
In order to resolve these issues, move the logic for profileDir in `settingsService` and introduce a new method to get the profileDir. In order to ensure code is backwards compatible (i.e. extensions that use `$options.profileDir` should still work), modify `$options` to set the value of `profileDir` in `settingsService`.
Whenever you want to test local extensions you can use:
```JavaScript
const tns = require("nativescript");
tns.settingsService.setSettings({ profileDir: "my custom dir" });
Promise.all(tns.extensibilityService.loadExtensions())
.then((result) => {
console.log("Loaded extensions:", result);
// write your code here
});
```
Replace all places where `$options.profileDir` is used with `$settingsService.getProfileDir()`.
In case user executes: - `tns help` - we should show the default index.html help with all commands - `tns --help` - we should show the default command line help generated from index.md file with all commands This has been broken during changing html-help-service to help-service. Fix the default behavior and add tests for it.
In case you try using npm scripts that come with `nativescript-dev-webpack` and you also have `nativescript-unit-test-runner` in your project, the scripts hang. The problem is that `nativescript-unit-test-runner` has a hook that resolves `testExecutionService`. In its constructor it sets that analytics broker should not be disposed. However, this is incorrect - it should not be disposed only in case we execute tests with livesync enabled. In order to fix this, move the logic in the commands. This way the hook will not change the disposing of the analytics broker, so once CLI process finishes, analytics broker process will be disconnected and CLI's process will die gracefully.
Also update submodule, where the following change is applied:
Fix execution of hooks outside of process
In case you need a hook to be executed outside of process, you should place correct shebang at the beginning of the file and CLI should spawn it.
However, this is not working at the moment, as when CLI detects that the hook should be spawned, it just does nothing. The code is incorrectly placed inside the `if` for in process execution. This causes another issue - in case a hook returns a function, which returns falsey value, we decide the hook should be executed outside of process and spawn a new Node.js process to execute the hook. So we execute it twice.
Fix the if-else logic, so the hooks will work correctly.
rosen-vladimirov
requested review from
nadyaA,
Mitko-Kerezov and
TsvetanMilanov
|
run ci |
TsvetanMilanov
approved these changes
Nov 13, 2017
rosen-vladimirov
force-pushed
the
vladimirov/release-331
branch
from
790b360 to
7b8685b
Compare
|
Merging with red tests as the problem is in the test scenarios. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-picked in release: