Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect against runtimePackage.version returning null #5444

Open
shirakaba opened this issue Dec 1, 2020 · 3 comments
Open

Protect against runtimePackage.version returning null #5444

shirakaba opened this issue Dec 1, 2020 · 3 comments

Comments

@shirakaba
Copy link

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: #4451 (comment)

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:

return runtimePackage.version;

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
Copy link
Author

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():

public getRuntimePackage(
projectDir: string,
platform: constants.SupportedPlatform
): IBasePluginData {
platform = platform.toLowerCase() as constants.SupportedPlatform;
const packageJson = this.$fs.readJson(
path.join(projectDir, constants.PACKAGE_JSON_FILE_NAME)
);
const runtimeName =
platform === PlatformTypes.android
? constants.TNS_ANDROID_RUNTIME_NAME
: constants.TNS_IOS_RUNTIME_NAME;
if (
packageJson &&
packageJson.nativescript &&
packageJson.nativescript[runtimeName] &&
packageJson.nativescript[runtimeName].version
) {
// if we have a nativescript key with a runtime version in package.json
// that means we are dealing with a legacy project, and should respect
// that information
return {
name: runtimeName,
version: packageJson.nativescript[runtimeName].version,
};
}
return this.getInstalledRuntimePackage(projectDir, platform);
}
private getInstalledRuntimePackage(
projectDir: string,
platform: constants.SupportedPlatform
): IBasePluginData {
const runtimePackage = this.$pluginsService
.getDependenciesFromPackageJson(projectDir)
.devDependencies.find((d) => {
if (platform === constants.PlatformTypes.ios) {
return [
constants.SCOPED_IOS_RUNTIME_NAME,
constants.TNS_IOS_RUNTIME_NAME,
].includes(d.name);
} else if (platform === constants.PlatformTypes.android) {
return [
constants.SCOPED_ANDROID_RUNTIME_NAME,
constants.TNS_ANDROID_RUNTIME_NAME,
].includes(d.name);
}
});
if (runtimePackage) {
// in case we are using a local tgz for the runtime
//
if (runtimePackage.version.includes("tgz")) {
try {
const runtimePackageJsonPath = require.resolve(
`${runtimePackage.name}/package.json`,
{
paths: [projectDir],
}
);
runtimePackage.version = this.$fs.readJson(
runtimePackageJsonPath
).version;
} catch (err) {
runtimePackage.version = null;
}
}
return runtimePackage;
}
// default to the scoped runtimes
this.$logger.trace(
"Could not find an installed runtime, falling back to default runtimes"
);
if (platform === constants.PlatformTypes.ios) {
return {
name: constants.SCOPED_IOS_RUNTIME_NAME,
version: null,
};
} else if (platform === constants.PlatformTypes.android) {
return {
name: constants.SCOPED_ANDROID_RUNTIME_NAME,
version: null,
};
}
}

@shirakaba
Copy link
Author

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

const runtimePackage = this.$pluginsService
.getDependenciesFromPackageJson(projectDir)
.devDependencies.find((d) => {
if (platform === constants.PlatformTypes.ios) {
return [
constants.SCOPED_IOS_RUNTIME_NAME,
constants.TNS_IOS_RUNTIME_NAME,
].includes(d.name);
} else if (platform === constants.PlatformTypes.android) {
return [
constants.SCOPED_ANDROID_RUNTIME_NAME,
constants.TNS_ANDROID_RUNTIME_NAME,
].includes(d.name);
}
});

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
Copy link
Contributor

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants