Closed izeau closed 9 years ago
Thanks again for helping out, @izeau! I'm not very interested in this option, however. We have the replace functions for projects with complex architectures to customize the behavior.
I'm seeing a lot of Bower tasks that work with main files, and I'm not fully sure I understand the use cases. For example, why does your project need to pull the main files out to public/lib? Presumably, public/lib gets shipped to production, in which case, you would likely want to minify and concatenate those scripts. There are many tasks that will take a block of script references and do the min/concat for you on command, so you never have to worry about how much extra junk is in a Bower package's directory.
Maybe if I understand better, I will understand the reasoning behind this feature. For right now, though, please pardon my fuzzyness!
I’ll try to explain, however please note that I’m not fluent in English and will probably be unclear at some point… Sorry about that.
For my projects, I usually put my (Jade) templates in views/
, my (JS & Stylus) assets in assets/
, and I install my Bower components in bower_components/
. However, I have a gulp build
task that will compile my views, and minify scripts and styles, and put everything in public/
. public/
holds the views, public/js/
the scripts, public/css/
the styles and public/lib/
the vendor files. The public/
directory is then served as my HTTP root.
Why don’t I concatenate vendor files with my files? Because vendor files are less likely to change than mine (especially during development), and the browser caches those (i.e. jQuery and AngularJS files are cached, I only need to reload my assets). Why don’t I put bower_components/
in public/
? Because there are lots of files that aren’t really needed.
The problem is that when I use wiredep to inject scripts, their paths are relative to views/
and bower_components/
, when I need them to be relative to /
and /lib
.
Once again, the routes
option is not necessary, since we can use the replace
functions to achieve the same behaviour. I just thought that some sugar could help there! :smiley:
You should try scaffolding an app with generator-webapp or generator-gulp-webapp. The workflow you'll see makes this stuff trivial.
Basically, your HTML file will look like this:
...
<!-- build:js scripts/vendor.js -->
<!-- bower:js -->
<!-- endbower -->
<!-- endbuild -->
<!-- build:js scripts/app.js -->
<script src="your/app/files.js"></script>
<!-- endbuild -->
</body>
</html>
When you run the build process, the build
block (which encapsulates the wiredep
block in the first example), will concat, minify, and output the file to the destination of your choosing. When you push your distribution folder to production, bower_components and all of your app files (in their non minified/concatenated form) will be left behind in your source directory.
This commit adds support for routes in the injected filepaths. Can be useful if a templating engine (Jade, HAML, etc.) is wired before compilation and output in another folder.
Without routes, the HTML files point to
../bower_components/<path>
, when I need them to point to/lib/<path>
.We can work this out with a custom replace function, but I think routes add some flexibility to this.