concept flat dependency tree in category javascript
This is an excerpt from Manning's book Front-End Tooling with Gulp, Bower, and Yeoman.
Bower uses the latter version for one good reason: in web applications, you don’t want to transfer the same package multiple times over the wire. If you install jQuery, use this version throughout the project. Also, browsers have a hard time handling the same software in two different places. The flat dependency tree is more suitable for front-end developers. Bower will alert the developer should version conflicts occur during installation. The developer then has the following choices:
The flat dependency tree is the direct opposite. Figure 4.5 shows a sample organization of the same structure described previously.
Figure 4.5. A flat dependency tree. Flat dependency trees make sure that just one version of a component is available. If some component requires another one (like B, C, and D, which are dependent on A), they all have to work with the same version of this component.
Instead of allowing multiple copies of a single component, each of them can exist only once in your project space. This ensures that you don’t have the same code or the same API provided redundantly. But this approach is prone to conflicts. Two components requiring the same dependency but with incompatible APIs will cause an error that can’t be solved without a user’s interaction. Usually, the user has to decide which of those components to use and will be informed of possible inconsistencies. Because flat dependency trees are Bower’s way of handling components, we’ll take a closer look at this topic in the next section.