The `nativescript.config.ts` is a central place to configure your project. It allows you to configure your project structure, application id, runtime related flags and more.

::: info Note about the `.ts` extension

:::

By default a config looks somewhat like the following

webpackConfigPath: string = 'custom-webpack.config.js'

A list of npm package names to ignore when attaching native dependencies to the build.

cli: Object = {}

Sets the package manager to use for this project.

android.discardUncaughtJsExceptions: boolean = true;

android.markingMode: 'none' | 'full';

android.maxLogcatObjectSize: number = 9999;

ios.discardUncaughtJsExceptions: boolean = true;

- `buildAndroidPlugin` - Builds aar file for Android plugin, runs during prepareNativeApp

- `buildAndroid` - Builds Android app

- `buildIOS` - Builds iOS app

- `checkForChanges` - Changes occurred during watch

- `install` - Application installed to device/emulator

- `prepare` - Compiles webpack and prepares native app in platforms folder

- `prepareNativeApp` - Preparing the actual native app, runs during prepare/watch hook

- `watch` - Setup watchers for live sync, runs during prepare hook

- `watchPatterns` - Setup watch patterns, runs during watch hook

- `__NS_WEBPACK__` - always `true` when building with webpack

- `__NS_ENV_VERBOSE__` - `true` when `--env.verbose` is set

- `__NS_DEV_HOST_IPS__` - an array of IP addresses of the host machine (the machine running the build) when in `development` mode, and an empty array in production mode.

- `__UI_USE_XML_PARSER__` - a flag used by NativeScript Core to disable the XML parser when it's not used

- `__UI_USE_EXTERNAL_RENDERER__` - a flag used by NativeScript Core to disable registering global modules when an external renderer is used.

In some cases, you may want to explicitly set which base config should be used.

const webpack = require('@nativescript/webpack')

For simple things, you can merge objects into the final config instead of using `chainWebpack`

- NathanWalker

JavaScript provides opportunities of immense scalability if architectured properly. One key word that often comes up in this department is **"code sharing"**. Over the years, several lessons have emerged around scalability with JavaScript in lieu of NativeScript in particular.

**The NativeScript TSC's 5 fundamental lessons about good code sharing**:

1. If you can share your code easily with other paradigms, other disciplines, other runtimes even, then you have a good code sharing approach that will continue to provide you and your team joy. No developer or team willingly gets into code sharing hoping to find themselves in a corner later. You always want to share now to more easily maintain and scale the code later.

3. A good code sharing approach should not have to introduce new file extensions purely for sake of sharability (outside of those naturally supported by the framework) to deal with. All team's organize code by folders naturally and the same should be matched with good code sharing approaches avoiding new file extensions and concepts that go beyond general code organization.

4. A good code sharing approach should clearly identify deployment/distribution lines as well as distinct platform separation allowing various shared code segments to have clear designated deployment targets allowing teams to control their own sophisticated build pipelines as they desire. Further the shared code should live within a thoughtful organizational structure that supports the ability to scale and adapt to future needs aside from the deployment targets that use the shared code.

5. Within the specific scope of NativeScript's viewpoint, JavaScript is the universal language which provides the opportunity to share code effectively and responsibly. An approach that is based fundamentally on the strengths of JavaScript (and inherently TypeScript) is a good code sharing approach.

**Pros:**

- It's centered around JavaScript/TypeScript (lesson 1 and 5 above)

- No custom file extensions to deal with (lesson 3 above)

- Nx splits up "apps" and "libs" clearly identifying deployment/distribution targets "apps" that consume shared code "libs" (lesson 4 above)

**Pros:**

- It's centered around JavaScript/TypeScript (lesson 1 and 5 above)

- No custom file extensions to deal with (lesson 3 above)

- Nx splits up "apps" and "libs" clearly identifying deployment/distribution targets "apps" that consume shared code "libs" (lesson 4 above)

- It builds upon @nativescript/nx to further scale it across more paradigms so it's a natural extension when needed if already working in Nx with @nativescript/nx

**Pros:**

- It's centered around JavaScript/TypeScript (lesson 1 and 5 above)

- No custom file extensions to deal with (lesson 3 above)

- Can link/share dependencies

**Pros:**

- It's centered around JavaScript/TypeScript (lesson 1 and 5 above)

- No custom file extensions to deal with (lesson 3 above)

**Cons:**

<DeviceFrame type="ios">

<img src="https://raw.githubusercontent.com/NativeScript/nativescript-app-templates/master/packages/template-master-detail/tools/assets/appTemplate-ios.png">

</DeviceFrame>

| Memory Profiling | :white_check_mark: | :white_check_mark: |

| Timeline and CPU Profiling | :white_check_mark: | :white_check_mark: |

::: warning Note

:::

For optimal results when using the Workers API, follow these guidelines:

- Always make sure you close the worker threads, using the appropriate API (`terminate()` or `close()`), when the worker's finished its job. If Worker instances become unreachable in the scope you are working in before you are able to terminate it, you will be able to close it only from inside the worker script itself by calling the `close()` function.

- Since worker threads have access to the entire native SDK, the NativeScript developer must take care of all the synchronization when calling APIs which are not guaranteed to be thread-safe from more than one thread.