Protect against `runtimePackage.version` returning null

[shirakaba]

Environment Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

• CLI: 7.0.11
• Cross-platform modules: 7.0.13
• Android Runtime: 7.0.1 (present in node_modules but tns info and tns doctor say "is not installed")
• iOS Runtime: N/A
• XCode Version: N/A
• Android Studio Version: 4.1.1
• Plugin(s): None

Describe the bug Build-time error, as documented fully, along with my environment setup, here: https://github.com/NativeScript/nativescript-cli/issues/4451#issuecomment-736152533

In a demo app made from the official NativeScript plugin seed, whenever I run tns plugin add ../../dist/packages/my-cool-plugin on my demo app, I get the nondescript error:

Invalid Version: null

... with no stack trace. I determined that this was from the semver package, as it was in the previous issue. Here's the output of a console.trace() a line before the thrown error:

    at new SemVer (/usr/local/lib/node_modules/nativescript/node_modules/semver/classes/semver.js:22:15)
    at compare (/usr/local/lib/node_modules/nativescript/node_modules/semver/functions/compare.js:3:32)
    at Object.gt (/usr/local/lib/node_modules/nativescript/node_modules/semver/functions/gt.js:2:29)
    at PluginsService.isPluginDataValidForPlatform (/usr/local/lib/node_modules/nativescript/lib/services/plugins-service.js:415:29)
    at PluginsService.<anonymous> (/usr/local/lib/node_modules/nativescript/lib/services/plugins-service.js:66:26)
    at Generator.next (<anonymous>)
    at /usr/local/lib/node_modules/nativescript/lib/services/plugins-service.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/usr/local/lib/node_modules/nativescript/lib/services/plugins-service.js:4:12)
    at action (/usr/local/lib/node_modules/nativescript/lib/services/plugins-service.js:65:83)

As I document in this comment, I think the root of the problem is that CLI can't find @nativescript/android even though I have it installed. Thus, runtimePackage returns { name: '@nativescript/android', version: null } here:

https://github.com/NativeScript/nativescript-cli/blob/6de0c3e513da0b91f4deef84748417a842c4bbf0/lib/services/plugins-service.ts#L805

To Reproduce From a demo project in the official NativeScript plugin seed, run tns plugin add ../../dist/packages/my-cool-plugin.

I'm not confident that it will reproduce for users with different environments to my own, however.

Expected behavior Plugin should install successfully and no error should be thrown at all. If an error is thrown, at least a stack trace should be presented. Above all, CLI needs to be able to find @nativescript/android when it is clearly present in node_modules.

Sample project Any project using the plugin seed.

Additional context

[shirakaba]

Followed it a bit further, but haven't put any debug in yet.

runtimePackage is determined by calling this.$projectDataService.getRuntimePackage().

So things could be going wrong either in getRuntimePackage() or getInstalledRuntimePackage():

https://github.com/NativeScript/nativescript-cli/blob/6de0c3e513da0b91f4deef84748417a842c4bbf0/lib/services/project-data-service.ts#L567-L655

[shirakaba]

Getting closer. It strictly expects the runtimes to be in devDependencies. Why is that?

https://github.com/NativeScript/nativescript-cli/blob/6de0c3e513da0b91f4deef84748417a842c4bbf0/lib/services/project-data-service.ts#L602-L616

Moving them into devDependencies, my error is now refreshingly different:

Invalid Version: file:../../node_modules/@nativescript/android

This is pretty fragile. Now I see why the plugin seed doesn't hoist dependencies.

Could we not have CLI find the version more robustly, e.g. by doing proper node module resolution and utilising the filesystem instead?

By fixing this, we'd likely become able to hoist the runtime dependencies in monorepos, saving many megabytes for everyone.

[farfromrefug]

@shirakaba just stumbled upon this and wanted to react on your point about saving data with monorepo. you can already "achieve" that with pnpm. I have been using it with N for years and it saves me literally Gb of data! thus saving my hard drive too!