Maintainability of package.json on Vulcan updates

[ochicf]

So, either by cloning Vulcan directly or using the 2-repo approach, the own project's package.json dependencies become quite difficult to maintain when Vulcan needs to be updated.

This is specially true if the project has introduced new dependencies: package.json cannot be overwritten with Vulcan's, so the developer must manually select the updated dependencies from Vulcan and adding them to their project's.

I'm opening this issue to see how you're managing package.json on updates, and to discuss a good, easy and less painful way of doing it.

[ochicf]

I'll explain the approach we are using for a big project we have, and it saves some time and headeaches when we have to update (it still has some caveats though).

First, let's clarify some things:

• package.json located in the root in our project is the one that we are changing (that was originally Vulcan's)
• .vulcan/package.json will contain the package.json of the new Vulcan version
• the objective here is to get all the added/updated dependencies from .vulcan/package.json into the project's package.json

So, I wrote a script that will do that merge for me. I've placed it inside the .vulcan folder to mimic the prestart_vulcan.js script, and I named it update_package.js.

Now, to update package.json we copy Vulcan new version's package.json into .vulcan/package.json and then execute execute the script by running node .vulcan/update_package.js (must be run from the folder where the project's package.json is located). As stated above, this will merge dependencies from .vulcan/package.json into package.json.

Now, there may be some human intervention needed in this process. The merge will stop and throw an error if it finds incompatible semver ranges. For example, Cannot merge semver ranges "^2.0.1" and "^3.0.2" states that Vulcan has updated to version ^3.0.2 for a given package, so you will have to manually change that. This is a bit of a pain in the ass... but it is good for you because it forces you to check that you're not relying in the older version of that package.

The script is using @userfrosting/merge-package-dependencies, so the heavy lifting is done there. This is why I have no control in the incompatible semver ranges error (that, unfortunately, does not say the name of the package in the error).

I'll create a PR with the script.

[eric-burel]

From @Neobii this package could work betteri https://github.com/kellyselden/merge-package.json#readme