Nativescript: installing @next android platform will install dev-dependancies

Created on 27 Apr 2016  路  8Comments  路  Source: NativeScript/NativeScript

Did you verify this is a real problem by searching

yes

Tell us about the problem

When installing the platform it installing the main/master package.json developer dependencies;

    "devDependencies": {
            "babel-traverse": "6.7.6",
            "babel-types": "6.7.7",
            "babylon": "6.7.0",
            "filewalker": "0.1.2",
            "lazy": "1.0.11"
    }

I don't believe these should be being installed...

Which platform(s) does your issue occur on?

Windows -> Android platform

Please provide the following version numbers that your issue occurs with:

tns info reports everything is 2.0

Please tell us how to recreate the issue in as much detail as possible.

tns create test
cd test
tns platform add android

-- Check the screen output or the node_modules folder.

All 8 comments

Please note this appears to only be an issue on Android. My _tns platform add ios_ did not install any extra modules.

Those pacakge are now required for building android with {N} 2.0.
@Plamen5kov may be can give some more info on this.

Really, that seems strange that the Android side would need to parse the straight JS code where the iOS side does not. I'm looking forward to understanding why...

Any chance we can get these moved to be global as part of the TNS command rather than being installed in every single project also?

Do these get bundled in the .apk? I've not checked, I will later but if someone sees this before :smile: thanks

@bradmartin I double checked and these are NOT coming along for the ride, so their is no concern there...
Now as to its reasons, I decided to be a glutton for punishment and deleted them right after it installed them just to see what would fail. :grinning:

It appears it is used to build static bindings; does the mean that by default android now uses Static bindings?

@NathanaelA

  • Any chance we can get these moved to be global as part of the TNS command rather than being installed in every single project also?
  • it's a great idea, we will talk about it
  • Really, that seems strange that the Android side would need to parse the straight JS code where the iOS side does not.
  • The android runtime has very different logic for creating the counterpart classes and that requires bindings. These bindings need to be generated one way or the other. Before 2.0 all bindings were created at runtime by the runtime binding generator and currently we moved that logic to "build-time" instead of "runtime", which helps for the initial loading time. There is one more advantage to the static binding generator:

You can now declare classes in the android manifest and we will take care of creating them for you at build time. This wasn't possible before because it was too late to generate declared classes in the AndroidManifest.xml at runtime. I won't go into too much detail here, because I will write a blog post that will explain the perks of the static binding generator.

  • It appears it is used to build static bindings; does the mean that by default android now uses Static bindings?
  • Yes, the static binding generator is now turned on by default. We had it as an experimental feature for several releases, and 2.0 was the right time for us to put it in production.

@bradmartin

  • Do these get bundled in the .apk?
  • No the dev dependencies are not packed in the final .apk file. You can thank @Pip3r4o for that.

Thanks for the clarification and verification that it is static binding related code. That fully explains why Android needs it and iOS doesn't.. And I look forward to the blog post!

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings