assetpack.def for different modes

[HEM42]

Today AssetPack by default looks for assetpack.def, suggestion here could to have AssetPack first look for

assetpack.production.def, then assetpack.def assetpack.development.def, then assetpack.def

I realise that you could just do some thing similar in your code:

my $file = sprintf 'assetpack.%s.def', $self->mode; $self->asset->process( $file );

Maybe even have AssetPack look for definitions for process() in the Mojolicious Config

[HEM42]

As requested an example on how the config could look:

{
  assetpack => {
    process => [
      app.css => [
        '! https://github.com/twbs/bootstrap-sass/raw/master/assets/stylesheets/_bootstrap.scss',
        'sass/main.scss',
      ],
      app.js => [
        'http://code.jquery.com/jquery-1.12.0.js',
        'js/app.js',
      ],
    ],
  }
};

I believe that in this case using a '!' instead of the '<<' makes it easier to distinct from when you dont want to parse the download but only us it as a dependency.

I also realise its clashes a bit with the current implementation in the def, but makes it easier to read

[jhthorsen]

Could you give me an example where the def file will be totally different in production and development? I have a case where I want the production version of vue.js while I want the development (with debug) while developing. Even so, I want the rest of the def file to be the same.

Also, which case does the config file fix that the def file doesn't? I don't really consider assets to be configuration, but rather something static which should not be easy to change by accident.

[HEM42]

As for difference from production vs developement, other than the example you gave, using different versions, debug vs. non debug versions of certain javascript modules, ember.js vs ember.debug.js as another example.

But I have also found that the minifier is not always doing the same job, as the available minified versions of most libraries / css.

I have one app, where using the minified versions vs non minified, actually cuts almost a 100k of both the final js and the final css file.

This is not a large application, using only a few extras aside bootstrap and dataTables.

Another application the difference is quite larger, where using the minified leaves a combined js at 1.7MB, using the non minified editions gives a combined js at 3.6MB file.

If you want I can send you the last example a def files.

[HEM42]

Also, which case does the config file fix that the def file doesn't? I don't really consider assets to be configuration, but rather something static which should not be easy to change by accident.

I dont see the config file solve any thing that the def file doesn't. But it leaves with less files to remember.

But I see your point, that js/css assets isn't configuration, but there would be other things in the config that you dont want to change by accident.

Just a suggestion, not something would be essential for further use of this.

[jhthorsen]

The Convos def file (link below) would benefit from inline prod/dev statements instead of two different files. The only difference between prod/test would be line 7: In my case, I would rather support something like this:

< http://vuejs.org/js/vue.js [mode=development]
< http://vuejs.org/js/vue.min.js [mode!=development]

https://github.com/Nordaaker/convos/blob/one-point-oh/assets/assetpack.def#L7

Do you have any input on this @jberger?

[jhthorsen]

I also thought about having a "master" file which would be merged with the development/production mode def files, but that doesn't work sine the order of files in the list is significant.

[jberger]

I think that first idea makes sense as long as it is easily implemented

[jhthorsen]

@jberger: Is the "first idea" the one @HEM42 writes about in the issue description?

There is one issue with the suggestion that I can't fix in a simple way: Files with double extensions are not easy to extract from DATA.

[jberger]

Sorry, my comment was terribly confusing. I mean i like the idea in https://github.com/jhthorsen/mojolicious-plugin-assetpack/issues/78#issuecomment-210893346

[jhthorsen]

Thank you @jberger

[jhthorsen]

So I'm going with my own idea because:

• It scratches my itch in Convos
• I can't easily include "assetpack.development.def" from DATA
• Seems like what you with sprintf() is pretty easy to accomplish within your own code