A proposal for for an alternative to fetcher ... need your thoughts and suggestions to complete it

[ghost]

I'm writing to ask for your suggestion on the best way to integrate a bridge between a bower_components and the vendor folder. Unfortunately, fetcher does not work for us. Please read on.

Our goal is to prevent the Solution Libraries, hereon referred to library(ies), from being committed to our source repository, while being able to retrieve them seamlessly for maven-centric UI construction workflows, which is a corporate requirement. This means that these libraries must be installed seamlessly using our maven workflow and that a UI software engineer can seamlessly add/update libraries.

I have opted for a bower-centric approach, spiced up with concepts borrowed from the fetcher architecture. The rational for this lies in my belief that, in the long term, we will use bower, or a similar manager; hence, I prefer the idea of building a bridge between bower and the vendor folder, rather the bypassing the library repository altogether; in fact, ideally, linemanjs would enable us to name the desired library component(s) straight out of their local bower repository.

The solution elements include:

1. bower, our library manager.
2. _bowercomponents, a local folder where bower installs the local libraries.
3. a .gitignore file including a configuration to ignore _bowercomponents.
4. bower.json, a file used by bower, library registry, to describe the libraries in _bowercomponents.
5. vendor, a folder used by linemanjs to host the solution's libraries and build the solution.
6. maven configuration, to trigger bower's installation of the local libraries during full solution builds. We use the maven-exec, it works fine.
7. bridge, a grunt task populates vendor with the configured library elements stored in the _bowercomponents folder.
   1. WE ARE WORKING ON THE BEST WAY TO INTEGRATE THE BRIDGE TASK ON OUR WORKFLOW; YOUR THOUGHTS AND SUGGESTIONS ARE WELCOME

The developer workflow is as follows:

1. To add a new library
   1. Find the desired library using bower search
   2. navigate to app folder
   3. run bower install —save to:
   4. add the library reference to bower.json.
   5. add the library to the _bowercomponents folder.
   6. update the bridge configuration to include the library element(s) to be copied from the library's _bowercomponents to the vendor's folder.
2. To update an existing library to a new version
   1. navigate to app folder
   2. run bower install #version —save to:
   3. update the library reference ing bower.json.
   4. update the library in the _bowercomponents folder.
3. To add files from an existing library to the solution
   1. update the bridge configuration to include the library element(s) to be copied from the library's _bowercomponents to the vendor's folder.
4. Use the bridge task to refresh the vendor folder.

We have two outstanding workflow and technical questions with respect to the best way to integrate the bridge task into our UI software engineering workflow. The outstanding questions are:

1. How to integrate the bridge task into the maven build. Presently we use the lineman-maven-plugin to clean and populate the dist folder used by maven to build the war file, it works really well. Ideally, I could piggy back on it; alternatively, our options are: a) use the maven-exec-plugin to trigger the bridge task. You might have a third, fourth, or even fifth solution, they are all welcome!
2. How to integrate the bridge task into the UI software engineer workflow, once s(he) adds/updates a library. Note that at this point the UI software engineer will have done a full build on her/his sandbox and have the bower_solutions / vendor folders properly populated, with the only discrepancy being that the newly added/update library element(s) not being in the vendor file.

Thanks in advance for your thought and suggestions!

Regards

[jasonkarns]

All the complications that bower introduces is precisely why fetcher was created. One of your requirements–preventing libraries from being committed to our source repository–exposes one of the biggest flaws in bower. Bower does not guarantee that the bytes on disk from library X will be the same between multiple bower installs. Hence, we have found that keeping vendor libraries in the source repository is a better alternative to ensure that multiple builds of the same app result in the same bytes. Further, since bower does not support or resolve nested dependencies, dealing with version conflicts remains a problem that must be resolved manually. Using fetcher to download vendor libraries ensures that this concern is not ignored or hidden from the developer.

In our use, we have found that vendor libraries are updated so rarely that managing them manually is largely a non-issue. And the primary function that bower excels at (making it easy to pull down libraries) is accomplished neatly with fetcher.

The final annoyance with bower, as you are experiencing, is that bower largely functions by pulling down the entire git repository of a library. There are numerous solutions to this problem that can be used or repurposed. As lineman itself is built on grunt, I would recommend looking into these tools and hooking them into lineman's pipeline. This would allow you to skip fetcher and mostly ignore vendor as well. There also exists lineman-bower for integrating the bower install step into the lineman build pipeline.

Whether you use the grunt plugins listed above or not, you can just use lineman's files configuration to pluck out the files from bower components that need to be compiled into the final bundle.

(for more reading on some of the issues with bower: http://gofore.com/ohjelmistokehitys/stop-using-bower/)

[ghost]

Thanks for the thoughtful reply. I'll study your recommendations and report back when the work is done.