Hi Brad,
I like the thought process. I have no idea what npm does so I’m not comparing although I guess there is an argument to be made to be consistent unless there is a reason not to be (I’ve heard that Ortus tends to like conventions J ).
Here is what I’m trying to accomplish.
I am installing a package (Package A) via commandBox which is going to be a web-based app. The package installation handles placing the folders and files in the correct location and then fires a commandBox module (CBModuleA) for additional configurations like datsources, admin users etc. For safety’s sake, CBModuleA is going to be a dependency of Package A to ensure that it is installed along with the 4 other dependencies which may or may not be necessary. If CBModuleA is not there, the current postInstall will break.
At the moment there are two issues on the table:
<![if !supportLists]>1) <![endif]>If Package A’s postInstall script depends on 2 dependencies, it will fail after the first one installs because it will have 1 dependency but not the 2nd, correct?
<![if !supportLists]>2) <![endif]>Even if PackageA’s postInstall script only needs 1 of the dependencies, the postInstall Script will still run after each dependency is installed so the same configuration is run 5 times which, since it’s a wizard, makes for an irritated user even if nothing “breaks”.
I like your idea of the package being able to interact with the dependencies though.
What if there are two Life Cycle hooks –
<![if !supportLists]>1. <![endif]>postInstall which runs as is, after each dependency is installed
<![if !supportLists]>2. <![endif]>postAllDependencyInstalls which only runs once after all the dependencies are installed.
That way the package can still interact with all of the dependencies as they are installed but also be able to have a hook that can take care of all of the dependencies and only run once.
I don’t know if I’m making any sense but is that clear at least to start with?
Dan