Why does each demo have its own copy of @nativescript/android and @nativescript/ios?
I can understand the case for @nativescript/webpack (it has its own executable binary, so maybe can't be hoisted), but what about @nativescript/android and @nativescript/ios?
Good question - there’s a postinstall hook in runtimes that last time I checked would cause issue when referenced but definitely try it and can see. It’s been awhile since I’ve tried referencing the runtimes like other dep’s.
I checked the package.json for those @nativescript/android and @nativescript/v8-ios (or whatever it’s called) and didn’t find any post install scripts there. The only one I could find was for the iOS JSC runtime, here: https://github.com/NativeScript/ios-runtime/blob/master/build/npm/inspector_package.json
I may be misunderstanding the repo setup, but maybe it’s no longer a problem with V8. I’ll try it out later.
So I tried it out. I made the following changes:
package.json configurations
package.json (in the root of the monorepo)
Under devDependencies:
"@nativescript/android": "7.0.1",
"@nativescript/ios": "7.0.6",
apps/demo-react/package.json
Under dependencies (not devDependencies, as it is in the template):
"@nativescript/android": "file:../../node_modules/@nativescript/android",
"@nativescript/ios": "file:../../node_modules/@nativescript/ios",
Successful clean
I deleted apps/demo-react/node_modules and apps/demo-react/package-lock.json and installed the runtimes at the base of the monorepo before running this clean command.
Successful build and run
No postinstall problems (given that I'm using the V8 iOS runtime). So I suggest that we could save a lot of space by hoisting these two!
Awesome!
Looks like although iOS was happy hoisting it, Android wasn't. And maybe there's a difference between ns run demo-react:ios and tns run ios. Haven't checked.
I got this error when trying tns run android after having hoisted dependencies: https://github.com/NativeScript/nativescript-cli/issues/5444
I suspect CLI's fragile algorithm for determining runtime version, detailed in that issue, is the only reason that the runtimes can't currently be hoisted, and the only reason that they strictly have to be devDependencies rather than dependencies.