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

There are currently 2 package.json files after tns create #2301

Closed
valentinstoychev opened this issue Dec 2, 2016 · 12 comments
Closed

There are currently 2 package.json files after tns create #2301

valentinstoychev opened this issue Dec 2, 2016 · 12 comments
Assignees
Milestone

Comments

@valentinstoychev
Copy link

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?

cli

@rosen-vladimirov
Copy link
Contributor

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:

  • it allows us to have the templates published in npm.
  • it defines the dependencies and devDependencies required to use the template - nativescript-cli copies them to root's package.json during creation.
  • most important - this package.json is copied to native project and it defines the entry point of the application (`"main": "main.js"). At runtime this value is read and application is started from this point.

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

@Plamen5kov
Copy link
Contributor

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.

@Plamen5kov Plamen5kov self-assigned this Dec 8, 2016
@valentinstoychev
Copy link
Author

valentinstoychev commented Dec 8, 2016

@rosen-vladimirov there are two problems:

  1. The 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.

  2. Having the dependencies of the application listed in two different places is misleading and confusing to the developer. I personaly lost time figuring out why a dependency listed in the 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.

@Plamen5kov
Copy link
Contributor

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.

  • Would you like a single package.json instead of two?
  • If there are two package.json files, would you prefer the on in app/ folder to be simplified?
  • Would it be ok, if the two package.json files remain the same, but we provide comments that explain what each key is for?

@valentinstoychev
Copy link
Author

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?

@hdeshev
Copy link
Contributor

hdeshev commented Dec 8, 2016

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.

@teobugslayer
Copy link
Contributor

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.

@atanasovg
Copy link
Contributor

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

@valentinstoychev
Copy link
Author

valentinstoychev commented Dec 9, 2016

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.

@hdeshev
Copy link
Contributor

hdeshev commented Dec 9, 2016

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

@rosen-vladimirov
Copy link
Contributor

@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..."

@vchimev
Copy link

vchimev commented Dec 19, 2016

Please, have in mind that if PR: #2346 get merged, it will break the --copy-from option of tns create. Consider obsoleting and deleting this option: #2362.

@pkoleva pkoleva closed this as completed Dec 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants