Aspnetcore: Revisit default bundling behavior

[poke]

This is in response to the resolution in #20 and #89:

No plans to include bundling in the default template at this time. We will revisit in the future.

---

If you currently create a new ASP.NET Core application and you are not using an SPA-template (which uses Webpack for building), then you are in the unfortunate situation that the project appears to be using the bundling and minification feature yet that’s not what’s actually happening.

The following things are there:

• A bundleconfig.json is in the project root that is configured to produce the site.min.css and the site.min.js files.
• The wwwroot folder contains pre-built versions of those exact bundled files.

• The _Layout.cshtml contains environment tag helpers that switch to the minified bundles on non-Development builds:

  <environment include="Development">
      <link rel="stylesheet" href="~/css/site.css" />
  </environment>
  <environment exclude="Development">
      <link rel="stylesheet" href="~/css/site.min.css" asp-append-version="true" />
  </environment>
  
  …
  
  <environment include="Development">
      <script src="~/js/site.js" asp-append-version="true"></script>
  </environment>
  <environment exclude="Development">
      <script src="~/js/site.min.js" asp-append-version="true"></script>
  </environment>
  

So the user is made to believe that bundles are being created and that for production builds, those minified versions will be used automatically. Since minified files are also nested in the solution explorer, users are unlikely to actually look inside the files to verify that they actually do contain the desired contents.

Yet, the problem is that with Visual Studio 2017, Visual Studio Code, or when running dotnet from the command line, there is by default nothing that is actually consuming that bundleconfig.json file to generate those files. So users will end up with the default bundle files which contain mostly nothing.

Instead, users are apparently expected to do one of the following three things:

• Install the Bundler & Minifier VS extension to get the bundling done by Visual Studio
• Add the BundlerMinifier.Core NuGet package to get the dotnet bundle command.
• Add the BuildBundlerMinifier NuGet package to actually get a build task automatically added that will bundle the files automatically on every build.

By the indications mentioned above, the user is likely to expect this to work out of the box, just like everything in the templates already runs out of the box. Yet, they actively need to add a bundling method without being told to do so. The only thing that comes close to a hint is when you happen to open the bundleconfig.json in Visual Studio. Then, VS suggests you to look for “helpful extensions”, without actually clearly saying that this is in any way required. Not to mention that users that are not using VS are completely left in the dark.

So I would very strongly suggest that we actually do include the BuildBundlerMinifier package in the default templates, to make the bundling that is clearly configured and expected to work actually work. If we cannot do that since the package is not an “official” Microsoft package, then I would suggest to get rid of the bundling in the templates altogether.

[poke]

Also tangentially related to this: With #161, the templates got rid of the last instances of using Bower to add in client-side dependencies. Unfortunately, Bower did not get replaced by something that does this job, so the versions that are used in the templates are fixed now with no clear path on how to upgrade. So the user is left with solving that problem on their own which is not that simple and leaves multiple options to choose from.

If we were to use the bundleconfig.json and have it working as mentioned above, then we could also simply ship a package.json, get the dependencies through NPM and bundle them easily using the bundleconfig.json. That way we would have templates with an actually working and upgradable experience again.

[guardrex]

Let's cross-ref https://github.com/aspnet/templating/issues/67, since I'm asking about the client lib versions in that one.

[poke]

/cc @Eilon – I would appreciate your input on this if you have some time.

[DamianEdwards]

@poke thanks for the detailed write up on this. You're absolutely right, and this is an area we've struggled to nail down over the past few years due to the somewhat volatile nature of the beast in the industry. For the next update we're going to remove the bundleconfig.json from the templates (see https://github.com/aspnet/templating/issues/326) and add a comment to the top of the JS and CSS files pointing to our docs on bundling and minifcation techniques, while we further assess what our in-box solution will be for this in the future (it's complicated).

On the client library package management side, we're planning on productizing the "PackMan"/Client Library Manager prototype that's been shown by the web tooling team over the past couple of years, hopefully for release in an upcoming version of Visual Studio 2017 (15.7 if we're lucky).

[poke]

@DamianEdwards Thank you for the feedback and for your response!

While I’m a bit sad that we’re not going to ship a real solution with the templates then, I do appreciate that something is done to change the current (broken) state. And I totally agree that the client-side ecosystem is just too complex to handle properly in a template.

With PackMan, are you referring to this VS extension? That indeed does look like a viable alternative for people that are not already using npm to resolve dependencies.

[DamianEdwards]

@poke yep, that's the extension. That will essentially get rolled in to VS (with a few changes I'm guessing).

[mrlife]

@DamianEdwards Will this also come to Visual Studio for Mac?

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.