Use npm's semver rules for plugin's nativescript key

[rosen-vladimirov]

Problem with plugins verification with runtimes

Currently each NativeScript plugin must have nativescript key in it's package.json and define the minimum required version of each supported runtime. The structure is :

"name": "my-plugin",
"version": "1.0.0",
"nativescript": { 
    "platforms": {
        "ios": "1.5.0",
        "android": "1.5.0",
    }
}

When tns plugin add my-plugin is executed, CLI checks the values against current runtimes versions and informs the user if a plugin cannot be used with current version. However CLI uses the specified version in the plugin as minimum required. So for example in case the project uses tns-android 1.6.0, 1.6.2 or even 2.0.0 for example, it can use my-plugin. This makes it really hard to control the versions against which the plugin is tested and verified by the plugin author.

Suggested solution

Do not reinvent the wheel! Use semver rules for the nativescript key in package.json, for example:

"name": "my-plugin",
"version": "1.0.0",
"nativescript": { 
    "platforms": {
        "ios": "^1.5.0",
        "android": "~1.5.0",
    }
}

This way in case the project targets android 1.5.2, the plugin can be installed, but in case it targets 1.6.0, the plugin will not be available. More information for the version ranges: https://docs.npmjs.com/getting-started/semantic-versioning#semver-for-consumers

Breaking change

In case we implement this idea, all plugins, which currently has nativescript key inside their package.json, will not work, as the values: "1.5.0" will mean - can work with this version only.

[rosen-vladimirov]

I would like to hear the opinion of plugins authors. What do you think @NathanaelA, @enchev , @maknz

[rosen-vladimirov]

Ping @tjvantoll , @EddyVerbruggen , @sitefinitysteve, @bradmartin, @AntonioCuevaUrraco, @hdeshev , @vakrilov , @PeterStaev, @alexziskind1, @emiloberg, @PanayotCankov , @TobiasHennig What do you think guys?

[sitefinitysteve]

In favor... Better now than later

[enchev]

:+1:

[PeterStaev]

:+1:

[tjvantoll]

I’m in favor, however, I think we’ll need to have a grace period where the CLI interprets a specific version number—e.g. "1.6.0"—the old way. This will give plugin authors time to migrate, and also prevent having a CLI release that instantaneously breaks all plugins.

[NathanaelA]

This would definitely solve some issues.

[NathanaelA]

@sitefinitysteve @enchev @PeterStaev @tjvantoll part of this issue is raised because of issue (https://github.com/NativeScript/android-runtime/issues/93) any of you want to weigh in on the ability to get a runtimeVersion at runtime? We are debating the best ways to handle certain issues.

[teobugslayer]

I second @tjvantoll that we need a grace period. I have another idea - to introduce a flag to explicitly say which behavior do you need - the old or the new. We clearly communicate that this flag will be supported for say 2 versions and then leave only the new code.

[PeterStaev]

@NathanaelA although I see your point in the other issue about detecting runtime version, I think I would never want to add conditional code by version in the plugin code. Otherwise it will become rather messy to manage. I would rather update the plugin to work with the current runtime version. Then it is up to users, utilizing that plugin to know which version of the plugin they want to install and which is compatible with their runtime. Another idea would be to change the tns plugin add command to check the published versions of a plugin, read their config and find the best suited version for the project's runtime version.

[maknz]

:+1:, sucks that it will be a breaking change but better in the long term.

[tjvantoll]

I second @tjvantoll that we need a grace period. I have another idea - to introduce a flag to explicitly say which behavior do you need - the old or the new. We clearly communicate that this flag will be supported for say 2 versions and then leave only the new code.

I’m not sure a flag is necessary, because I don’t really see any harm with treating an explicit version number like we do today for the grace period. In practice, once the new semver rules are in place, there’s basically zero reason to use an explicit version number in a NativeScript plugin—you’d absolutely always want a range of some sorts. Therefore, the only harm I can see with leaving the old behavior in place is the potential to confuse new plugin authors temporarily, but I think as long we update the docs to default to a logical semver range we’ll be fine.

[bradmartin]

:+1:

[TobiasHennig]

:+1:

[AntonioCuevaUrraco]

:thumbsup:

[EddyVerbruggen]

Just trying to understand the implications:

If I change the version in my plugins today to say ~1.5.0 would that mean users of the current tns CLI won't be able to use the plugin? I'm not sure minimum version ~1.5.0 currently matches anything.

If that breaks usage with the current CLI, then plugins can only be upgraded after the new CLI algorithm has been implemented and released, and when it is NO ONE (using plugins) will be able to use those plugins. Until the plugin versions have been updated to no longer exactly match a specific version.

[rosen-vladimirov]

I think much better approach is to have runtimes as dependencies/devDependencies in the application instead of reinventing the wheel with additional keys and rules for package.json: https://github.com/NativeScript/nativescript-cli/issues/4511