Have the CLI manage project properties

[tjvantoll]

This came up from a discussion in NativeScript/NativeScript#145.

Basically it would be nice to be able to configure properties about your app in either your app/package.json or your .tnsproject file, and have those changes propagate to the appropriate places in the platform-specific config files. All of these are things AppBuilder does with its .abproject file, and it would be nice to have a few of those in the NativeScript CLI. At the moment the four specific things I'm looking for are:

• Display name ("DisplayName" in .abproject).
• Id ("AppIdentifier" in .abproject)
• Version ("BundleVersion" in .abproject)
• Android version ("AndroidVersionCode" in .abproject)

id is already set in .tnsproject, but to my knowledge you can't configure the rest of these things without changing iOS/Android config files manually.

[Fatme]

Hi @tjvantoll,

You're completely right. Currently the user is not able to configure project properties without changing iOS/Android config files manually.
I've just added this as feature request.

[valentinstoychev]

This issue is related here: NativeScript/NativeScript#252 (comment)

[jlooper]

I'd like to be able to give my app a display name, set in package.json as TJ noted above. Is it possible to do just this, as a part of this issue?

[mikebranstein]

@teobugslayer are you expecting to incorporate this into a post 1.5.0 milestone? Thanks!

[teobugslayer]

@mikebranstein,

It looks like we won't be able to implement this functionality for 1.5. Can you tell us more details about why you need this functionality for 1.5? This will help us prioritize our tasks better.

[mikebranstein]

Thanks @teobugslayer. The primary motivator is convenience of not having to open xcode to specify these values. For non-native developers, I feel it's important to have the mobile development framework drive the configuration of the native platforms.

For newer mobile devs, they'll learn the native platforms in time, but reducing the time from cradle to grave on getting an app developed and accepted into the store is pretty important. I feel a larger portion of that is to get out of the native tooling as much as possible.

You'll get better adoption of the framework by making it dead simple. Right now, it's pretty good - I feel it's been the easiest to step into as a .NET developer. Your preference of conventions over configuration and a simple API is so compelling - hybrid (PhoneGap/Cordova) works, but it's so easy to end up with insane JavaScript files that are an unstructured mess, unless you're thinking and planning for that from the beginning.

Perhaps this could be a feature really pushed to appbuilder as a paid offering (although it would be nice to have a unified concept of affecting the native projects, so that appbuilding doesn't do this in a .abproject and nativescript does it in the package.json file).

[tjvantoll]

Thanks @mikebranstein.

I completely agree with you and I’ll just add one thing. Since you currently cannot place files like Info.plist and AndroidManifest.xml in App_Resources (although I have an issue to request that too 😀), the manual changes you make are done in files that live in platforms/ios and platforms/android. Files in these folder are generally not added to source control, and are also frequently rebuilt.

Therefore any changes you have to make to files in the platforms folder will inevitably get lost. For instance, every time I submit Groceries I have to remember to manually update my iOS display name because that’s stored in my Info.plist.

So in addition to helping non-native developers, this feature would also help developers use configuration variables that live outside of the volatile platforms folder.

[PanayotCankov]

Just to link #1118 here.

[ligaz]

We have been discussing this internally and we think the best way to manage those properties is to use the native platform configuration files (Info.plist and AndroidManifest.xml in App_Resources).

We can provide CLI commands like tns prop set DisplayName ... that will ease this process but ultimately those commands will edit the native configuration files.

We should consider obsoleting the id property currently present in nativescript part of the app's package.json. The id can be retrieved from the respected platform configuration file and can be specific for each platform.

[enchev]

At the moment you can configure anything for the app using Info.plist and AndroidManifest.xml in App_Resources folder and you do not have to edit anything in the platforms folder. What's the thinking now? Is this enough or we need something else?

Hey @tjvantoll @atanasovg @hshristov @PanayotCankov what do you think?

[tjvantoll]

@enchev I think we’re all set here. The already implemented solution is exactly what I was looking for when I created this issue. I didn’t realize this was still open actually 😄

Unless others have more requirements worth mentioning, feel free to close this issue.