Versioning file format configuration

[Seikyo]

Hello,

Sorry if it is not the right place for this recommandation.
We are trying Webpack Encore and wanted to avoid having double "." in the output filename when using versioning assets and let the manifest file out of the web (or public) folder.

First, here is how we could resolve this issues currently as it may come in handy for others :

const Encore = require('@symfony/webpack-encore');
const ManifestPlugin = require('@symfony/webpack-encore/lib/webpack/webpack-manifest-plugin');
const ExtractTextPlugin = require('extract-text-webpack-plugin');

Encore
// (...) Your Encoreconfiguration

// export the final configuration
let config = Encore.getWebpackConfig();

// JavaScript output file format
config.output.filename = '[name]-[chunkhash].js';

// Assets (fonts and images) output file format
for (let i = 0; i < config.module.rules.length; i++) {
    let rule = config.module.rules[i];
    if ('options' in rule && 'name' in rule.options) {
        rule.options.name = rule.options.name.replace('.[hash]', '-[hash]');
    }
}

// WebPack plugins configuration override
for (let i = 0; i < config.plugins.length; i++) {
    let plugin = config.plugins[i];

    // Custom manifest path
    if (plugin instanceof ManifestPlugin) {
        plugin.opts.fileName = "../../data/manifest.json";
    }

    // StyleSheets output file format
    if (plugin instanceof ExtractTextPlugin) {
        plugin.filename = '[name]-[contenthash].css';
    }
}

I think it would be really nice to be able to configure this as an Encore.setVersioningFileFormat() that would take an object with extension as key to configure the default formats :

Encore
// (...) Your Encoreconfiguration
    .setVersioningFileFormat({
        js: '[name]-[chunkhash].js',
        css: '[name]-[contenthash].css',
        rules_suffix: '-[hash]',
    )

That object could be preset with current static values and implemented as :

@symfony/webpack-encore/lib/config-generator.js

// Currently
${this.webpackConfig.useVersioning ? '.[hash]' : ''}
// Could be 
${this.webpackConfig.useVersioning ? this.webpackConfig.versioningFormats.rules_suffix : ''}
...
// Currently
filename: this.webpackConfig.useVersioning ? '[name].[chunkhash].js' : '[name].js',
// Could be 
filename: this.webpackConfig.useVersioning ? this.webpackConfig.versioningFormats.js: '[name].js',

@symfony/webpack-encore/lib/plugins/extract-text.js

// Currently
 filename: webpackConfig.useVersioning ? '[name].[contenthash].css' : '[name].css',
// Could be
 filename: webpackConfig.useVersioning ? webpackConfig.versioningFormats.css: : '[name].css',

Thanks for the work it was really nice to play with.
If there is a better place to submit this recommandation please let me now.

[weaverryan]

I think this is a very sensible proposal :).

@Seikyo You mentioned you also changing the path to manifest.json. Probably that would be best done with a:

configureManifestPlugin(function(options) {
    options.fileName = '../../data/manifest.json';
})

[Lyrkan]

I started working on this but I'm a bit hesitant about how that method should actually be called.

At first I was going for:

Encore.configureVersioningFilenames({
    js: '[name].[chunkhash].js',
    css: '[name].[contenthash].css',
    images: '[name].[hash:8].[ext]',
    fonts: '[name].[hash:8].[ext]'
});

But since #110 the hash is always included for images and fonts so it may seem odd to have to call a *Versioning* method when the versioning is possibly disabled. Calling it something like Encore.configureFilenames() would not work either unless we make it so it changes the js and css filenames even if versioning is disabled.

Edit: actually we could probably just ignore js/css properties if versioning is disabled. I don't see a reason why people would want to modify these names in that case.

[Seikyo]

@weaverryan
Thanks a lot for the suggestion, i am kind of new to webpack

@Lyrkan
As we talked internally, our worry was more on the double "." that may cause unexpected mimetype or handler mismatch with some HTTP servers.
About the #110 issue after reading your explanation it seems to me that static assets are now a complete separate feature from the Versioning.

I like your idea of being able to configure both non versioned and versioned files so here is another suggestion :

function configureFilenames(default, versioned){};

Encore.configureFilenames({
    js: '[name].js',
    css: '[name].css',
    images: '[name].[hash:8].[ext]',
    fonts: '[name].[hash:8].[ext]'
}, 
{
    js: '[name].[chunkhash].js',
    css: '[name].[contenthash].css',
});

We keep the configureFilenames but let it have two arguments. The first for non versioned and static files. The second for versioned files.
As I did not follow up maybe static assets should be separated as well.

Edit: my bad i thought thatconfigureManifestPlugin method was already available and I was actually searching for it as a replacement. No complaints about the suggested implementation on my side.

[Lyrkan]

Hi @Seikyo,

I'm not sure we need these two parameters in configureFilenames, it may not be intuitive enough for users (e.g.: if I use versioning, do I need to declare a default name for js and css? if not why do I need the second parameter?).

I think we should probably go with one of these:

• check if the method has been called with an object containing a js (or css) key and use it as a name no matter if the versioning is enabled or not. If the parameter doesn't have a js (or css) key then use the current behavior.
• ignore js and css if versioning is disabled (so it'll use [name].js in this case, which shouldn't be an issue)

[weaverryan]

I like your first option: a single argument, and we always use what the user sends us. So, if they send us a js key, we 100% of the time use that, regardless of whether versioning is enabled or not. We can/should warn against this in the docs for this method - i.e. (if you have an enabled versioning, make sure your js filenames contain [chunkhash] and css filenames contain [contenthash]....

Another alternative is simply to switch from . to - in the filenames. It could be that this setting really shouldn't need to be configurable, and that I chose a bad default in the first place (and so the fix is to change that default). Can we think of any other case where someone would care about their filenames?

[Seikyo]

Since I am not a frontend expert, i think being able to override default hard coded values would allow users more flexibility for whatever reason may come. I do not think the . was a mistake for most people.

I am fine with the first option too. Thanks for the time and efforts.

[Lyrkan]

Following the discussion on #136 I'm going to work on a PR for the 1st option with these default settings:

With versioning enabled

• js: [name]-[chunkhash].js
• css: [name]-[contenthash].css
• images and fonts: [name]-[hash:8].[ext]

Without versioning

• js: [name].js
• css: [name].css
• images and fonts: [path][name].[ext]

Let me know what you think (maybe we should also include [path] for the versioned images/fonts?)

[weaverryan]

+1

I think the defaults in all cases should match what we have now (unless the discussion in #136 makes us decide to change those defaults). That would mean no path but always a hash for images/fonts

[weaverryan]

Yea, I just read more on #136. I still think the hash should appear in the URLs for images/fonts by default. So, to fully disable versioning, you would need to call this method without the hash. I agree with you that the collision of font/image filenames is a more common issue than needing to keep old assets present.

I don't agreee yet with having 2 sets of config for versioning on vs off, but we could discuss that better when there is some code to look at :)

[francoisdelage]

@Lyrkan Enabling versioning by specifying a [whatever]hash in the file name sounds good for me too