Currently, after executing tns create, there are two package.json files - one in the root folder and one in the app folder. These two files are with almost identical content and it is confusing for the user which one to use.
What is the reason for this?

Hey @valentinstoychev ,
The package.json at the root is used to define the dependencies of the template, to persist some project specific information, etc.
The package.json in the app folder is coming from the template. It has several purposes:
That's the current workflow and the reason why we have two package.json's. Of course this can be changed, but we should take care to handle all of the above requirements, so everything will continue working in the same manner :)
I wouldn't say having two package.json files is confusing, since this has been the default workflow for more than an year and no one seems to have problems with multiple package.json files.
@rosen-vladimirov there are two problems:
package.json in the app folder contains mixed data - data for the template package and data for the application. The developer is not interested in the data for the template package. This is for our internal use only. We discussed with Plamen that this data can be deleted after tns create is executed. package.json in the app folder is not working. Which package.json he need to edit in order to set the proper dependencies? there is no single source of truth (when looking from customer perspective).Ultimately we will have only one package.json which will be application specific.
For the time being though in order not to make drastic changes to the way the CLI works we decided with Plamen to keep the two package.json files, but filter and remove the information that is misleading and not needed at runtime.
Currently most of the content in app/package.json like dependencies and devDependencies are needed when the project is being created. These properties can be removed right after the template is installed in the app/ folder, but some of the information like: v8-flags and main will need to stay, because we count on them to run the user application.
I would love to hear other opinions on this matter.
package.json instead of two?package.json files, would you prefer the on in app/ folder to be simplified?package.json files remain the same, but we provide comments that explain what each key is for?Semantically there should be only one package.json when you work on the app.
What would be the reason to have more than one in this case?
I think the real source of confusion stems from us duplicating (I consider that a bug) the dependencies, devDependencies, and other settings in both package.json files. If we get rid of that duplication, people will have no way to get their configs wrong.
package.json files can be used in package subfolders to point to default submodules like this:
https://github.com/NativeScript/NativeScript/blob/master/tns-core-modules/file-system/package.json
This is a well-known node feature and I don't see a problem with using it in app/package.json to configure the app entrypoint module.
That said the root package.json file should be used to configure dependencies, scripts, etc. app/package.json should contain just the entrypoint declaration. [1] To fix that (we currently copy package.json to app/package.json) we either have to add code for that in nativescript-cli, or, better yet, make our templates look like a full project (not just the app subfolder). That way we'll have an easy way to set up both package.json files.
[1] V8 flags belong to the root package.json IMO.
I personally, and some people who I interacted with (on presentations and support) were very confused by the multiple package.json files. On multiple occasions we edited the incorrect file, and then trying to guess why the build continue to fail. I vote to simplify the project structure.
@hdeshev If the V8 flags are declared in the root package.json how will they get into the APK? The Runtime reads this package.json upon initialization (app loading).
@teobugslayer I am all-in for making things easier, as long as we do not have some magical code in the CLI to cover a missing package.json file. And, as @hdeshev pointed, in the Node ecosystem it is perfectly fine each folder to have its own package.json, why would that bring confusion, given well defined rules where an entry belongs to?
I think @hdeshev summed it quite well in his reply. The current problem I think is this:
I think the real source of confusion stems from us duplicating (I consider that a bug) the dependencies, devDependencies, and other settings in both package.json files. If we get rid of that duplication, people will have no way to get their configs wrong.
This should be the first step that we need to do to fix the customer experience. Also @Plamen5kov suggested we add comments inside the package.json files, which will also a great addition and will help customers know the purpose of each file and key.
As we discussed after that we can have a discussion whether we actually need one or two package.json files, but for me this will be a very low priority and not the real problem. Lets focus on the real problem.
@atanasovg
@hdeshev If the V8 flags are declared in the root package.json how will they get into the APK? The Runtime reads this package.json upon initialization (app loading).
It will require some additional tooling to move those settings to some file in platforms/android/.../app, but I believe the increased visibility for those settings will make it worthwhile.
@valentinstoychev I totally agree that the two package.json's are confusing. I just wanted to summarize what's their purpose at the moment.
@Plamen5kov you cannot add comments inside package.json, it's not supported. You can add only key-value pairs, for example:
{
"name": "my-template",
"comment": "This package.json is used for..."
Please, have in mind that if PR: https://github.com/NativeScript/nativescript-cli/pull/2346 get merged, it will break the --copy-from option of tns create. Consider obsoleting and deleting this option: https://github.com/NativeScript/nativescript-cli/issues/2362.
Most helpful comment
I personally, and some people who I interacted with (on presentations and support) were very confused by the multiple package.json files. On multiple occasions we edited the incorrect file, and then trying to guess why the build continue to fail. I vote to simplify the project structure.