NativeScript 6.4 Has Just Landed

If there was an Oscar for Award for the Public - {N} 6.4 would have won it. Most of the features that are shipped as part of this release are either started or influenced by somebody from the community. We greatly appreciated everybody's involvement and for this iteration the team spent some time to polish and merge those in the framework.

Custom Webpack Configurations

Everyone who has had to modify their webpack.config.js knows how difficult it is to update the project after that. You have to manually merge the latest changes coming from the update with your local changes. The process could take a lot of time and cause you headaches.
Based on the idea of soarer1004, we’ve added an easy way to use custom webpack configuration in your project. You can now move all your custom code in a new file and point the webpackConfigPath property in nsconfig.json to this new file. It can either choose to include or disregard the original configuration coming from the plugin. More information is available in the docs.

Metadata Filtering

Up until now, NativeScript included all supported native entities in its metadata and app authors had no control over this behavior. This allowed app and plugin authors to freely call any native API from JavaScript and was perfect during app and plugin development. In some cases, however, having metadata for all the APIs is undesirable:

• There could be security implications involved and mentioning names of entities that shouldn’t be known in the metadata binary files could be unacceptable;
• App size could increase due to unnecessary metadata which is never used. In fact, only a fraction of what is available is actually called by an app, so most of the entities are actually needless.

To give developers control over what to be included (or not) in the generated metadata, we’ve implemented support for blacklisting and whitelisting symbols by their native names. To find out more about the feature and how to use it, you can refer to the Metadata documentation section.

When we enabled the filtering in {N}'s core modules for iOS, the metadata file got reduced from ~5.5 MB to ~1.2 MB per each CPU architecture (arm64, armv7). As for Android - from ~2.1 MB то ~1.1 MB. Actually we’ve been pretty conservative when deciding what to filter by default. So if you’re feeling adventurous you can try being more aggressive and share with us what you’ve achieved!

NOTE: For this feature to become straightforward and easy to use without having knowledge of your apps plugins’ internals, all plugin authors should start declaring their usage lists as documented in the article. Until then application authors willing to opt-in to the feature will have to be mindful of all used plugins’ needs when writing the rules.

3D View Transformations

A very special PR was merged in 6.4.0 release - 3D rotations are now available in NativeScript. It was quite a bumpy road so specail thanks to Hamdi Wanis and Ryan Pendergast for their hard work and dedication on this one!

New CSS Parser

In this release we have replaced the current CSS parser (https://github.com/reworkcss/css) with csstree (https://github.com/csstree/csstree) which is one of the fastest JavaScript parsers available. This will improve app performance depending on the amount of CSS used.

Pnpm Support in the CLI

As you know, currently NativeScript CLI supports two package managers - npm and yarn. With the growth of the JavaScript ecosystem, we get new approaches for managing dependencies every day. Thanks to the contribution of farfromrefug, now NativeScript CLI supports an additional package manager - pnpm. As stated in the docs, pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a single place on the disk and a hard link will put it into the node_modules where it should be installed.
You can set NativeScript CLI to use pnpm by executing:

tns package-manager set pnpm

After that, CLI will use pnpm instead of npm for all operations used to manage dependencies of application, like project creation for example.

NOTE: In case you callpnpm install manually, ensure you’ve passed --shamefully-hoist flag.

Support for WebAssembly in Android

WebAssembly is now officially supported on Android. Here’s an example of how we could compile, instantiate and execute a WASM module:

// #include <stdio.h>
// #include <sys/uio.h>
//
// #define WASM_EXPORT __attribute__((visibility("default")))
//
// extern double logarithm(double value);
//
// WASM_EXPORT int log(double value) {
//     return logarithm(value);
// }

let wasmCode = new Uint8Array([
    0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00, 0x01, 0x8b, 0x80, 0x80, 0x80, 0x00, 0x02,
    0x60, 0x01, 0x7c, 0x01, 0x7c, 0x60, 0x01, 0x7c, 0x01, 0x7f, 0x02, 0x91, 0x80, 0x80, 0x80,
    0x00, 0x01, 0x03, 0x65, 0x6e, 0x76, 0x09, 0x6c, 0x6f, 0x67, 0x61, 0x72, 0x69, 0x74, 0x68,
    0x6d, 0x00, 0x00, 0x03, 0x82, 0x80, 0x80, 0x80, 0x00, 0x01, 0x01, 0x04, 0x84, 0x80, 0x80,
    0x80, 0x00, 0x01, 0x70, 0x00, 0x00, 0x05, 0x83, 0x80, 0x80, 0x80, 0x00, 0x01, 0x00, 0x01,
    0x06, 0x81, 0x80, 0x80, 0x80, 0x00, 0x00, 0x07, 0x90, 0x80, 0x80, 0x80, 0x00, 0x02, 0x06,
    0x6d, 0x65, 0x6d, 0x6f, 0x72, 0x79, 0x02, 0x00, 0x03, 0x6c, 0x6f, 0x67, 0x00, 0x01, 0x0a,
    0x8d, 0x80, 0x80, 0x80, 0x00, 0x01, 0x87, 0x80, 0x80, 0x80, 0x00, 0x00, 0x20, 0x00, 0x10,
    0x00, 0xaa, 0x0b
]);

let importsObj = {
    env: {
        // javascript callback that will be invoked from the WASM module
        logarithm: Math.log
    }
};

try {
    let wasmModule = await WebAssembly.compile(wasmCode);
    let moduleInstance = await WebAssembly.instantiate(wasmModule, importsObj);
    let result = moduleInstance.exports.log(Math.E);
    console.log(result); // will print 1
} catch (e) {
    console.error(e);
}

V8 Update

One of the key parts to {N}'s performance in Android is V8. With the new release, the Android Runtime now uses V8 8.0. In this new version, there are several optimizations like OSR (on-stack replacement) and pointer compaction which lead to less used memory and CPU time. Other new features include support for optional chaining and the nullish coalescing operator.