Bower installing dependencies as siblings instead of nesting?

[robdodson]

I think perhaps I'm using bower incorrectly and assuming it works similar to node_modules.

Basically Project A has a component.json file which installs everything to its components directory. So far so good.

Next I have Project B which depends on Project A. I assumed it would install Project A's dependencies inside a components dir inside of Project A. But it seems to install Project A's dependencies as siblings of Project A.

What I was expecting:

Project B/
    components/
        Project A/
            components/
                ... a bunch of components ...

What I get:

Project B/
    components/
    Project A
    ... Project A's components ...

On the one hand this obviously makes sense. You might say that some jquery plugin depends on jquery so they're installed as siblings. On the other hand, Project A expects its dependencies to be inside its components dir so this structure doesn't work...

Any ideas?

[satazor]

That doesn't make sense in the browser world simply because modules aren't self contained. What I'm trying to say is that most deps can't coexist at the same time. Take jquery for instance, if we allow both 1.7.1 and 1.8.2, one of them would overwrite each other.

[robdodson]

So is it possible for a project using bower to be consumed by another project using bower?

In my case Project A is a Bootstrap theme which uses Bower to pull down Bootstrap core. Its LESS files import components/bootstrap/less.

For instance:

@import "../../components/bootstrap/less/variables.less";

Now in Project B I want to use this bootstrap theme. So I add it to my bower file. But since it can no longer find bootstrap the LESS files blow up.

[satazor]

hmmm I now understand the problem.
The issue is that you are providing a theme that is not built yet (does not contain a single .css file with the precompiled stuff). This makes sense in some situations.

What bower could do is replicate a structure similar to npm but with some changes:

• The root components directory should still contain all the flatten deps
• All deps inside nested components should be a symbolic link pointing to the respective root components dep

e.g:

Project B/
    components/
        Project A/
            components/
               Project C (symlink to root Project C)
        Project C

[robdodson]

That's an interesting solution.

I think for now my best bet is going to be to build the theme, make that part of the repo and encourage my users to just use that. The built folder will pull in all the LESS files it needs.

edit

It might be nice, if I'm going to go the route of encouraging people to just use my build folder, to have the option to only download that folder when someone runs bower install. I guess bower-installer does this perhaps(?) but it could be useful as a built in option.

[satazor]

@fat @sindresorhus what's your toughts on this?

[robdodson]

at least having a devDependencies option would help. That way all of Project A's stuff won't end up in Project B.

edit

I see this is already in the works :D

#80

[cobbweb]

I have this problem too with different components that import LESS stylesheets from each other. For now after I run bower install I have to cd into components/my-theme and run bower install again so it installs Bootstrap at the right location.

[robdodson]

I wonder if you could use npm or grunt to execute those cd and bower install commands? Maybe the whole thing could be a big grunt or npm task of some kind? Not ideal but might work in the short term...

[cobbweb]

Yea I could automate quite easily from a grunt file. But I was hoping for a solution to be added into bower. @satazor's idea about nesting symlink components up the root level components is great.

Personally, I was thinking a different configuration field for those dependencies:

// my-theme/compontent.json
{
  "name": "my-theme",
  "directDependencies": {
    "bootstrap": "2.0.1"
  }
}

// my-app/compontent.json
{
  "name": "my-app",
  "dependencies": {
    "my-theme": "git://github.com/me/my-theme.git",
    "bootstrap": "2.2.1"
  }
}

Then in my-app when you run bower install you end up with:

• my-app/components/my-theme
• my-app/components/bootstrap
• my-app/components/my-theme/components/bootstrap

I think an issue with symlinking could arise based how I've configured above. my-app needs Bootstrap v2.2.1 but my-theme needs Bootstrap v2.0.1, so which version ends in my-app/components/bootstrap?

[satazor]

@cobbweb for each dependency, bower will find the most suitable one for the whole project (the highest that match all the packages semver ranges). In your case, if one app needs ~2.2.1 and a package needs ~2.0.1, bower will emit an error saying its impossible to resolve bootstrap dependency.

This approach is the better one for the web world, because as I said above, deps are not self contained and would overwrite each other or add duplicate code to the final application.

[satazor]

@paulirish @addyosmani @sindresorhus can you leave your thoughts on the symlink solution?

[necolas]

cc @angus-c

[robdodson]

if it's scary to have the symlink solution on by default perhaps it could be an advanced option?