How to manage ASP.NET Core bundleconfig.json for multiple environments?

Question

What\'s the best practice for using the ASP.NET Core bundleconfig.json with development versus production environments? The prior bundler (BundleCollection) wou

Answer 1

I think I found my answer. I was about to create an HTML helper to read the bundleconfig.json for the development environment, but it appears I'm not the first one to think this was a good idea. Note that the .NET Core implementation is linked to at the bottom of the page

https://github.com/madskristensen/BundlerMinifier/wiki/Unbundling-scripts-for-debugging

Edit

For the .NET Core implementation, the reference to the bundleconfig.json was expecting it to be in a /Configs folder, which may or may not be the case in your project. For me, I just had it in the root of the project.

Edit

So this doesn't work if the source files are outside of the wwwroot folder. Having files outside of the wwwroot folder is completely reasonable, so I'm investigating having the html helper point to a path that will stream the files in debug mode

Possible Solution

Here's my evolution of the solution:

https://gist.github.com/rupe120/512a9eb837383963f80fd9ef4984eb15

Update

I modified my solution to use {*filePath} in the route definition, so there's now no need to encode the path

Update

I think this is the last major update I'll do. I replaced the static base route string with the outputFileName values from the bundleconfig.json. So now there's as many debug routes as there will be minified files and no fear what so ever of name collisions. Additionally you can see what files are included in which bundle when you're debugging, which I think is pretty cool.

Answer 2

I wouldn't exactly call this a best practice but the following works for me.

In the bundleconfig.json I prepare one bundle for development and one for production. Bundle for development is just concatenated text, which is easy to read and debug. Bundle for production is minified and may optionally include source map.

{
    "outputFileName": "wwwroot/script.bundle.js",
    "inputFiles": [
      "wwwroot/node_modules/popper.js/dist/umd/popper.js",
      "wwwroot/node_modules/jquery/dist/jquery.js",
      "wwwroot/node_modules/bootstrap/dist/js/bootstrap.js"
    ],
    "minify": {
      "enabled": false,
      "renameLocals": false
    }
  },
  {
    "outputFileName": "wwwroot/script.min.js",
    "inputFiles": [
      "wwwroot/script.bundle.js"
    ],
    "minify": {
      "enabled": true,
      "renameLocals": true
    },
    // Optionally generate .map file
    "sourceMap": false
  }

The point is, that production bundle use only development bundle. That way I have to keep only one list.

On the page, where JS is needed, I add tags for two bundles.

<environment include="Development">
    <script src="script.bundle.js" type="text/javascript"></script>
</environment>
<environment exclude="Development">
    <script src="script.min.js" type="text/javascript"></script>
</environment>

Answer 3

Im with Josh on this one, seems like madness having to maintain two lists. Has anybody come back with a better build in solution without using a MvcHtmlString helper!

"sourceMap": true

This enables debugging into your js in if enabled in the bundleconfig.json but I have noticed if you are going bundling it does not generate the maps correctly, references the combined and the each mapped file...

Smidge seems to provide this functionality - with a simple flag - debug="true"

<environment names="Development">
    <script src="my-awesome-js-bundle" type="text/javascript" debug="true"></script>
</environment>
<environment names="Staging,Production">
    <script src="my-awesome-js-bundle" type="text/javascript"></script>
</environment>

Webpack or gulp is the way to go - which one, that`s debatable.