Add Prettier to TypeScript Projects with PreCommit Hook

Where you been?

If you haven’t heard of Prettier you are missing out on one of the best tools for the javascript community. I’ve been hanging around on the outskirts of adopting Prettier because I’m very focused on TypeScript projects and initially there was no support for TypeScript. That was until 12 days ago when 1.4.0 was published. So now I’m diving head in on all projects to default with Prettier support. I’ll keep this brief, so let’s dive in.

The Steps

First, we need to add a few packages to our project as dev dependencies. Run the following from your terminal:

npm install prettier lint-staged husky --save-dev

You can use yarn if you’d like instead of npm to install the dev dependencies.

Second, open your project’s package.json and add the following script and object for lint-staged

"scripts": {
  "precommit": "lint-staged"
"lint-staged": {
  "*.ts": [
  "prettier --write",
  "git add"

That’s basically all you need to do. Pretty simple, our precommit script will run lint-staged which will run the prettier command on the .ts files being committed.

Dismiss the Android SoftKeyboard Programmatically in a NativeScript App

Be Gone You Damn KeyBoard

If you’re like me you get really frustrated with apps that leave the soft keyboard open when you’ve completed some action that should have closed it. Maybe you completed a form and tapped a ‘Submit’ button, well that keyboard is pointless now so hide the thing please. There are some use cases where you don’t want to but oh well I’m going to tell you how to get rid of it when you want to in your code.

import * as app from 'application';

import { isAndroid } from 'platform';

* Hide the keyboard with a conditional Android platform check.
private hideKeyboard() {

   if (isAndroid) {
      try {
         let activity =;
         let Context =;
         let inputManager = Context.getSystemService(android.content.Context.INPUT_METHOD_SERVICE);
    inputManager.hideSoftInputFromWindow(activity.getCurrentFocus().getWindowToken(), android.view.inputmethod.InputMethodManager.HIDE_NOT_ALWAYS);
      } catch (err) {

The code is pretty simple and just uses the Android InputMethodManager service and calls the hideSoftInputFromWindow() method. Has worked great in my apps and hopefully it helps you out if you ever need to get rid of the keyboard in your Android NativeScript app.


Do NativeScript Plugins Add Weight to My App?


Something that comes up all the time during app development is the overall app size for the application. Well simple logic, the more you add the larger the app will be. Typically you want your app to remain light weight. In this post I just want to cover plugins and how they will affect your final app size.

I’m assuming you have some familiarity with NativeScript. If not, I encourage you to check it out for mobile app development. It’s in the same boat as React Native and Xamarin, not the same as Cordova based frameworks like PhoneGap or Ionic. At any rate, the NativeScript site can provide much better information about what it is and how it works than I can and it’s outside the scope of this post. So lets dig into a couple plugins and see how they will impact our app size.

We will look at two plugins for NativeScript, one that I built and maintain and another from Nathanael Anderson.

My plugin contains native Android and iOS dependencies, Nathanael’s plugin is just plain javascript and it contains many nice utility methods for accessing UI components in a NativeScript app. So with those two plugins you’re adding something extra to your app so it will simply increase the app size, but exactly how much weight does it add?

Plugin with Native Dependencies

Well there are a few ways to find out but I’m going to show a quick and simple route for both. Lets start with the plugin that is adding native android/iOS dependencies to our application first (color-picker plugin). If you look at the plugin source and find the library listed in the include.gradle located in the platforms/android/ folder here. You’ll find the dependency listed on line 11. You can copy the dependency `com.pavelsikun:vintage-chroma:1.2` and paste it into MethodsCount website and it will give you the stats on the library. Which should give you the following on your screen and tell you approximately how much ‘weight’ will be added to your Android application if you add this plugin (which consumes this native library).


Now for the iOS side, which is even easier if the library is coming from CocoaPods. This NativeScript plugin uses a library from CocoaPods and you’ll find that listed in the  PodFile here. If you go to the CocoaPods site and search for that library you’ll find it and the information you’re looking for. Here is the page for this library. On the right side bar toward the bottom you’ll find the size of the library. Below is a screenshot.


That’s it for the native dependencies, now we can look at the plugin that’s just adding some javascript, which in most cases you can expect to be fairly small in added size.

Plugin with javascript only

While we’re on this topic, a good plugin distributed to NPM should only have published the necessary files to NPM. The source files, package.json, and a license file if desired. Images and junk files should not be published to npm and if so, I suggest making a PR to the repo’s .npmignore file so those files aren’t published. This plugin from Nathanael does a good job of not shipping wasted files and the README, LICENSE, and files are really small in size so it won’t add much. What I’m most curious about is the actual javascript source file for the code, thanks to GitHub for easily finding that info out for any file. Just open the file on GitHub and in the top you’ll see the file size. Only 11.4 kb.


Reducing the Size

There are several ways to reduce the overall footprint of the plugins. You can manually delete files from the node_modules folders that you don’t need. Webpack is another option. If you want a simple hook to delete modules from the build there is a hook plugin for NativeScript from Markosko here.


Keep in mind there are other ways, you could open your file explorer and find the node_modules folder of your app and see how large the folder is for the plugin, this works only for the plugin itself. If the plugin is adding native libraries compiled into your app, this won’t work the same. You can use Android Studio to find out however, but I’m not going over that here.

Swift Runtime Size

I’ve been told by Nathanael Anderson that if the Pod for iOS uses Swift, it will add 6+ MBs for the Swift runtimes.


This should show you one approach to determine the weight that a plugin could potentially add to your NativeScript application. There are other options to determine the size and several options to reduce the application size. Before going to production you should strongly consider reducing the application size.

AHHH! This NativeScript plugin doesn’t work

Keeping this short and to keep myself from having to repeat these instructions all the time for developers trying to understand the Android and iOS build process and how you need to  download and compile certain things with apps. Mainly since NativeScript is not running a webview and you can’t drop a javascript file and start working with third party libraries without a build step.

Continue reading “AHHH! This NativeScript plugin doesn’t work”