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
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()`.
0 commit comments