Why are bower components installed in wwwroot

Question

It has been a while since I played with ASP.NET 5 so it was a surprise to me that bower components are now by default put in wwwroot\lib folder. This is the case because of the .bowerrc file:

{
    "directory": "wwwroot/lib"
}

In earlier releases the bower components are stored in the ./bower_components folder, which still makes more sense to me.

I would expect that I need a gulp/grunt (with wiredep for example) task to build and copy my JavaScript and CSS files into wwwroot folder.

Clearly I'm missing something, but I can't get my head around it or find any suitable information on this matter.

Why do I want all my bower components (including sources) in the `wwwroot\lib' folder, especially when deploying, and what is the desired workflow on deploying my Asp.NET 5 web application?

Answer 1

I think the reason the bower_components folder was abandoned and now uses wwwroot/lib is because no matter whether in dev or production static files need to live below wwwroot otherwise after every edit of a file you need to run taskrunner again to copy the file below wwwroot. It is a more efficient workflow if both the dev and production versions of the files live somewhere below wwwroot. that way you can edit and refresh the page rather than edit run taskrunner and then refresh the page.

What I suggest is make grunt process files into a different folder like wwwroot/js when creating minified/processed production versions of your files.

Then the wwwroot/lib folder could even be excluded from publish since only dev versions of library scripts would live there.

I'm thinking my own custom scripts which are not bower components should probably not live under wwwroot/lib so maybe I put the unminified ones under wwwroot/dev and process all production stuff under wwwroot/js so that in production I only deploy the wwwroot/js folder which has the production version minified/combined files. So basically we make our own bundles that way.

The new environment tags and and the script taghelper make it possible to easily point to different file locations for dev and production as seen in this example:

<environment names="Development">
    <script src="~/lib/jquery-validation/jquery.validate.js"></script>
    <script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"></script>
</environment>
<environment names="Staging,Production">
    <script src="//ajax.aspnetcdn.com/ajax/jquery.validation/1.11.1/jquery.validate.min.js"
           asp-fallback-src="~/js/lib/jquery-validation/jquery.validate.js"
           asp-fallback-test="window.jquery && window.jquery.validator">
    </script>
    <script src="//ajax.aspnetcdn.com/ajax/mvc/5.2.3/jquery.validate.unobtrusive.min.js"
           asp-fallback-src="~/js/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js"
           asp-fallback-test="window.jquery && window.jquery.validator && window.jquery.validator.unobtrusive">
    </script>
</environment>

So you have easy ways to use a cdn in production. Note that for non cdn files you cannot point anywhere other than wwwroot or some folder below that so having files in a bower_components folder outside of wwwroot is not a location where you can point to scripts so there is no point in putting files there.

When making script links to the dev version of my custom scripts I like to use the new taghelper attribute asp-append-version="true" which appends a hash of the file contents to the url ensuring that the previous browser cache is bypassed any time the file is edited or changed. And this happens without any need of running taskrunner, I just edit and refresh the page.

So in summary having all the scripts below wwwroot is a better workflow than having them elsewhere and needing to run taskrunner to move them after every edit. If you don't want to deploy all the extra cruft from below wwwroot/lib then process what you want into a different folder with taskrunner, the same as you would have to do if they were outside of wwwroot in a bower_components folder as they used to be in early betas. And exclude wwwroot/lib from publishing with publishExclude in the project.json of your web app.

Answer 2

They've been moved there because Microsoft was seeing a lot of confusion by .NET developers that weren't used to the new tooling. They simplified this for .NET developers by putting those components into wwwroot instead of needing to run a task to move them over. My source for this (and an explanation to change it to the previous behavior) comes from (MS employee) Scott Hanselman's blog post.