Remove ../'s from bower_components paths

[silvenon]

This is my proposition for the bower_components mess. Instead of only fixing that, I went further and removed bower_components from URLs completely, because to me they are kind of verbose and potential issues with name conflicts seem unlikely enough.

So instead of:

<script src="../bower_components/modernizr/modernizr.js"></script>

we would have:

<script src="modernizr/modernizr.js"></script>

Same goes for Sass. No more ../../../../ sillyness.

Fixes #150.

[silvenon]

The verbosity of wiredep commands is increasing, but if we get #235 approved, we can apply the wiredep command with same options for both HTML and Sass.

[silvenon]

Also, this adds some additional time to the html task and probably styles task. But I would sacrifice speed for clarity in this case.

[austinpray]

I do not see any benefit to this whatsoever. If anything more verbosity is better, especially for first-time users. This is a generator, it should be as succinct and flexible as possible.

These paths are being managed by a robot anyway. Nobody is manually manipulating these.

[silvenon]

The logic of the ../bower_components path in HTML files is terrible. We're using the fact that ../ = / when we're already in the root, just so we don't trip up gulp-useref. We've had numerous issues about this subject and if we have to explain something many times, it's not a good design.

Also, when I'm debugging what wiredep injected in my file, I already know it's from Bower, so I don't need that ../bower_components prefix, it's clutter to me. The robot is managing them, but a human is reading them from time to time.

[Munter]

I do not agree with this change. All urls should always be valid file references. If you part with this, you add complexity for the reader because they have to make a mental leap each time they need to resolve an url. Verbosity does not equal complexity. Often times the opposite is true. And this change takes the generator more in the direction of setting you up with a static page generator than an actual webpage.

That said, the /../ url is an abonimation that should die a swift death. The solution is not to break all urls though. Instead bower_components should reside inside the web root. This would move the generator closer to actually generating a website that can be used even without the build step, thus further decreasing complexity. This is exactly what I did in generator-greenfield.

[addyosmani]

I'm +1 with @Munter about this adding complexity, but sympathise with the desire to simplify this setup. It's hard because bower_components absolutely does = clutter.

We opted for similar file path patterns to what you're suggesting for Polymer projects and whilst it makes sense for an experienced developer, you'll find it introduces cognitive overhead for beginners who just want to point to clear paths.

[silvenon]

Ok, I agree with you guys. I actually mainly want to remove the ../ abomination :D How about we then convert:

<script src="../bower_components/modernizr/modernizr.js"></script>

to:

<script src="bower_components/modernizr/modernizr.js"></script>

I don't think we have to move bower_components to app, though.

[silvenon]

Ok, now we have an inconsistency:

HTML:

<script src="/bower_components/modernizr/modernizr.js"></script>

Sass:

@import "bower_components/bootstrap-sass-official/assets/stylesheets/_bootstrap.scss";

/bower_components path crashes Sass, maybe load paths don't work that way. Do I remove / from HTML path as well?

[silvenon]

Ok, removed the inconsistency. Both now start with bower_components/.

This is ready for merging, if you agree, @eddiemonge @sindresorhus @Munter @addyosmani.

[eddiemonge]

seems fine to me 👍

[silvenon]

Rebased.

[silvenon]

By the way, this is now in sync with how generator-webapp does it.

[sindresorhus]

ignorePath: /^\.\.\//,

[stephenplusplus]

If just one ../ is being replaced, a string: "../" also works.

[sindresorhus]

I'm fine with this, but can you document the behaviour in the readme as it's a bit magic?

[silvenon]

As this is more philosophically-oriented, I would rather put it under docs/, not in the main readme.

[sindresorhus]

Yeah, sure. Just needs to be written down somewhere.

[silvenon]

Added the notes.

[sindresorhus]

Lgtm. Nice work @silvenon! :)