Update package.json file to have proper platforms key

[NathanaelA]

Your package.json file is missing the proper nativescript.platforms key for proper installation.

[maknz]

Those keys aren't necessary and can be omitted (the package installs fine). Many packages omit them, I imagine because they don't support npm style version constraints, only absolute versions.

[NathanaelA]

Two reasons:

1. When the windows runtime comes out in the next version; TNS will assume it supports it... I assume it doesn't but you have told TNS that it does!
2. If you want the cool android/ios icon to show up on your package on http://plugins.nativescript.rocks, it uses those keys to figure out what platforms for icons to use. Eventually at some point in the future if the plugin doesn't have any icons, it won't be displayed.

[maknz]

Here is an excerpt from the package.json file of a random package from your plugin website:

  "nativescript": {
    "platforms": {
      "android": "1.5.0",
      "ios": "1.5.2"
    }
  },

The problem I have with this is that this package doesn't support NativeScript 1.6? What we'd want to do is specify ^1.5.2 so that it covers 1.5.2 and above. Can we specify a wildcard * instead of a version number? I've never seen any examples of {N} packages using anything other than absolute versions in those keys, which isn't suitable.

I haven't seen any docs on what values are supported in those keys either.

So instead of guessing what the behaviour of having an absolute version number is when a new version comes out, we just didn't include those keys at all.

I've pinged the {N} peeps on Twitter to see if they can clarify correct usage.

[NathanaelA]

Nah, you don't need to put the ^ in it. (In fact I'm not sure what it would do with that, the NS version parser might crash on it.).

From my tests, It currently means it supports Android v1.50 and higher. And ios v1.5.2 and higher.

Before I understood how that field worked, I used it to track my own internal version numbers for each platform. And you might still find some of my plugins with "0.0.1" for both of them. :grinning:

I finally figured out how that field worked because I tried to install a plugin where the author accidentally put "1.5.2" in both fields; and Android didn't have a 1.5.2 runtime, so it threw a multiline warning (although it let it install it).

[NathanaelA]

But if you get any clarification, please let me know. I would love to know if I'm advising people wrong on it... :grinning:

[rosen-vladimirov]

Hey guys, I would like to share some information about plugin's nativescript key. NativeScript CLI treats every npm package, which has the nativescript key in a different manner than other npm packages. As you know, your NativeScript plugin may have some special files (include.gradle, Podfile, etc.) in the platforms/<platform>/ directory. CLI process these files in a specific way. In order to understand that this package has some files that has to be processed in a specific way, we check the package.json and search for the nativescript key. So consider the existence of this value as: "this is nativescript plugin, not regular npm package". The values inside nativescript key are read by CLI. They can contain the following information:

"nativescript": { 
    "platforms": {
        "ios": "1.5.0",
        "android": "1.5.0",
    },
    "variables": {
        "APP_NAME": {
            "default": "myName"
        },
        "MY_VAR": { }
    }
}

The platforms key defines the minimum versions of each runtime that is required in order to use the plugin. It should be valid version. In the example above, the plugin could be used with any version of runtime that is equal or higher than 1.5.0 - 1.5.1, 1.6.0, 2.0.0, etc. When you add the plugin via tns plugin add <name> CLI will check the currently added runtime in your project and will notify you in case the plugin cannot be used with your version. The variables section defines the plugin variables that each app must set in order to use the plugin. Again, when using tns plugin add <name> CLI will check the package.json and will ask the user to set values for this variables. The values are written in project's package.json. Each variable can have default value, which is used in case the user had not specified value.

So basically the idea of nativescript key is to add information that is processed in a special way from NativeScript CLI.

[NathanaelA]

@rosen-vladimirov - Awesome thanks for confirming the way that key works. That does match what I have seen. I am also using that same platforms key to show which icon on the http://plugins.nativescript.rocks site.

[maknz]

Thanks @rosen-vladimirov. The only problem I foresee is what when/if NativeScript 2.0 comes out, which I would assume would have many breaking changes, then our package would be considered valid (it's above 1.5.2 or whatever) but it might break -- the same argument for our package being considered valid automatically for Windows when we don't specify the keys. No biggie, but worth mentioning.

[rosen-vladimirov]

@maknz thanks for sharing your concerns. I'll discuss them with the team and we'll see what can be improved in the current implementation.

[rosen-vladimirov]

I've added a new issue in NativeScript CLI, you can share your opinion there: https://github.com/NativeScript/nativescript-cli/issues/1530