Develop a public NativeScript plugin using the nativescript-plugin-seed

[00:00] First thing we want to do is clone the nativescript-plugin-seed. You can clone it to a folder matching the name of the plugin that you'd like to create, in this case, we'll call it NativeScriptClock.

[00:10] If we change into that directory, the first command we'll want to run is npm run post clone. This will ask a series of questions, the first being your GitHub username. In this case, I'll just provide my GitHub username, and then the name of the plugin, and in this case, it's just going to be called Clock.

[00:27] We exclude the nativescript- prefix here, because this is just the name of the files that we're going to use in the plugin, and not the name of the plugin itself that we're going to publish.

[00:36] In most cases, you'll want to answer yes to this question to make sure it initializes a fresh Git project. To finalize the setup, just run npm run setup. This will make sure that all the dependencies are installed for not only the plugin in the root directory, but also the dependencies in the demo app.

[00:53] If we take a look at the setup, out of the box, all the plugin related files are in the root directory, and it's pre-setup with a demo app inside this demo folder, with preconfigured scripts to compile your plugin fresh, and then run it against the demo app.

[01:09] It also comes with good defaults for your Git ignore, as well as the npm ignore file. However, as you develop your plugin out, you may need to tweak the npm ignore before you go and publish the plugin.

[01:20] If we take a look at the plugin files, starting at this common file, extending observable from the common class allows both Android and iOS implementations to inherit the notify API to send out events through that common interface.

[01:35] For example, we could call up the notify and set an event name, an dispatch out events from our plugin not only for Android, but also for iOS in the same way. This provides a consistent way to dispatch events out of both platform specific implementations, if needed.

[01:54] If we take a look at the scripts, let's take for example this demo.ios script. Let's run that to actually demo it in the iOS simulator. We see the iOS app run, and we see this alert that executes after our timeout here.

[02:08] There's a similar script to run on Android, and we can see the exact same behavior. That is all inherited from this common class, which gets executed in the constructor to set up this default message, and then this static success message sets up the timeout to alert within two seconds.

[02:26] If we look in the demo app's main view model, we'll see that we are just simply constructing the plugin class, and then setting an instance property message equal to that class message property.

[02:37] Whether you are building a view component plugin, or a service-level plugin, the seed provides a lot of conveniences to get going for both Android and iOS. To link to a CocoaPod, Android Arsenal, or Gradle lib, we could just create a platforms folder in the root, and then for iOS, we'd create iOS, and then a separate folder for Android.

[03:00] We would create our pod file for iOS, and for Android, we would normally create our include.gradle, and this is where we could drop these dependencies for iOS and Android to build and code against those native APIs in our plugin here.

[03:15] Once you have everything set up, and you've run your plugin against the demo app and things are looking good, when you go to publish, you'll want to make sure that your package file has a correct description for your plugin, make sure the version number is where you want it, and ensure this index typings file is updated per the typings that you want to be exposed.

[03:34] Out of the box, they're set up just empty, but you can take the declarations that are generated for iOS and Andriod and either merge or pick the exact typings you want to have exposed and publish with the plugin.

[03:46] Down below in the package file, make sure you have appropriate keywords for your plugin setup, the author name and email changed to represent yourself, and then you can run npm run build to do a fresh build of your plugin.

[03:59] Lastly, if you're logged in with npm, you can run npm publish to actually publish your plugin. Within a day, you would see your plugin show up on the official source for NativeScript plugins, at plugins.nativescript.org, as well as npmjs.com, you would see your plugin show up publicly.