New design of navigation bar and footer

I updated the navigation bar and the footer.. Please comment on the design before anything is implemented. Thanks!

The header was simplified and the footer has been updated to something similar.


www/caddy: Description Fields are optional now

At no point in the model relation fields they are the only display, making them non required for functionality. There are always multiple sprintf references.
The SafeDelete function shows UUIDs in the bootstrap dialog, which users can enable in the bootgrids by adding the optional field for them. The description is nice to have, but not necessary. It will just give users who fill out descriptions a better experience, but not by much.

This helps reducing the steps necessary to create new entries. It was an annoyance, also for me, but I just recently revisited this from feedback here: https://github.com/opnsense/plugins/issues/4095
EDIT:
The required description came from a time in the plugin, when they were the only references for model relation fields. But by now this has changed completely.

Merged, thanks!


Merge new chunks with chunks in the existing stats file.

I ran into the issue of using multi-compiler mode in webpack, and in such a case, I'd want to be able to use the same webpack-stats file. Currently, the bundle tracker plugin will overwrite whatever was previously in the stats file.

One thing you missed is the file content might be an error or in "loading" state. When that's the case you need to overwrite the file as extending the error keys will just break the expectation.

I addressed @SBoudrias concerns by first trying to read the contents of the existing stats file, parsing the content, merging the chunks from the file with the newly generated chunks, json stringifying the result, and then writing it back out to the output file.
In addition, if the existing stats file has an error status, we just ignore it and overwrite the existing content with the new content.

@owais any news on this PR? We're relying on this fix for our product and would prefer to not maintain a fork forever.

The stats file is supposed to always represent the output of a single build. Appending contents from multiple builds could have weird effects in most of the clients. Most users use multiple instances of the plugin to generate multiple stats files and then write a wrapper to load the files in the clients to work with a more complicated build process.

(sorry for the late response; have been very busy lately)

Our use case here is i18n. We're outputting our JS build in multiple languages. If you take a look at how webpack i18n plugins works, you'll see that we're effectively creating one build per locale: https://github.com/webpack/webpack/tree/master/examples/i18n
FWIW, this is also not multiple config files, it's a single file where module.exports = [{...en_US_config}, {...fr_CA_config}, ...etc]
Creating a bundle-tracker manifest file per locale definitively is not a solution.
For your existing users, nothing is breaking. They use one config and the same bundle key will be overwritten for each webpack run. Errors still wipe the files, etc. If they're using multiple webpack config, then they're using multiple config files already as using a single one is currently broken/non-workable.
The only case I can see where this change would have unwanted side effect is if someone is committing the bundle-tracker output files to their repository. In that case, if they're to change a bundle key, the old key would stay in the file. That being said, this wouldn't break anything for them as the old key is not used anymore, and also that key would disappear the first time the webpack build errors out (which happens pretty often in development mode).
So as you see, merging output configs is:

Necessary to allow support for i18n
Would imply no breaking change for current users

As such, I believe we can admit this is a safe change forward. If you're not convinced this wouldn't impact current user, then just bump a major version and we're good to go.

@owais any news on this? If you don't intend to merge please close the issue, otherwise we're still hoping to get this in.
Webpack officially support multi configs https://webpack.github.io/docs/configuration.html#multiple-configurations and it'd be nice to have some kind of support for it here too :)

Hey Simon, I'm still not sure about merging output of multiple builds into a single stats file. If we could find a way to get combined output of a single run/build of webpack even if it uses multiple configs in the same run, I think that would work.
I want a single run/build of webpack to completely replace the previous build's metadata. It's not about replacing existing keys. Presence of keys that are no longer valid is a problem as well as it presents a completely wrong information to clients.
So, if we can figure out to always replace an existing stats file with a new one with every build, I can accept that. This would solve i18n where multiple "configs" are present in same webpack config file and 1 run of webpack builds them all.
If webpack API does not make that possible, another option is to something like https://github.com/stedolan/jq or https://www.npmjs.com/package/json-merge, and add these tools to the build process after webpack runs. This would let you merge all the stats files into a single one without compromising promises webpack-bundle-tracker makes. This can be turned into a webpack plugin as well. It would run after every build finishes and "reduce" the resultant stats file into the main one. It would work just like a reduce function.
Yet another option is to add functionality to webpack-bundle-tracker to accept a callback that'll let users annotate or diff the stats.
Something like
// user webpack config
var beforeWriteCallback = function(statsFilename, stats) {
     // read from statsFilename and merge with stats json object
     return stats;
}
...
...
...
      new BundleTracker({filename: './assets/webpack-stats.json', beforeWrite: beforeWriteCallback})

// webpack bundle tracker
stats = this.options.beforeWrite(outputFilename, stats)
fs.writeSync(..)

I suppose the 3rd option to add a callback should work just fine for everyone.

FWIW, other similar plugin like https://github.com/kossnocorp/assets-webpack-plugin do support webpack multi-config without extra steps.

var assetsPluginInstance = new AssetsPlugin()

module.exports = {
    // ...
    output: {
        path: path.join(__dirname, "public", "js"),
        filename: "[name]-bundle-[hash].js",
        publicPath: "/js/"
    },
    // ....
    plugins: [assetsPluginInstance]

Nice solution. It let's you use a single instance of the plugin. We can do that as well. A single instance would cache stats in memory and write combined stats. It would produce exactly 1 stats file per build but still support multiple configs in same file. This is also very much acceptable. To make this happen, we just need to store the stats received from webpack on the instance itself and then in our webpack config pass on 1 instance to all configs.
Thanks for pointing out.

@owais sounds like a reasonable solution. It's unfortunately not working ATM.

webpack-bundle-loader will need to be patched to support it. I can do that 3-4 days later but feel free to send a PR my way if you get time to implement it

@SBoudrias @ayc92 Checkout https://github.com/owais/webpack-bundle-tracker/pull/16
I'll release a new version to npm if it works for you. You'll have to use a single instance of bundle tracker to enable updating versus overwriting.

Solution outlined in comment https://github.com/owais/webpack-bundle-tracker/pull/11#issuecomment-258566529 has been rolled out to NPM in version 0.1.0