Update Buffalo to use Webpack 3

[paganotoni]

Since webpack is moving to its 4th version it would be good to move Buffalo to webpack 3 (stable version) to be prepared to move to webpack 4 when this turns stable (or we decide is pertinent).

I've tried this locally and the changes are minor, and mostly related to some package versions given the syntax is the same.

[stanislas-m]

@paganotoni I do agree we should update, but please make sure we provide a migration "guide" for existing projects. It's not easy to follow the frontend hype, and some Buffalo users are just backend people using the default config for their pipeline. The best way might be providing a webpack generator (it means extracting the code from the new app generator, and call it as a sub-generation step), with an override option.

What do you think about this?

[paganotoni]

@stanislas-m I agree with you on the fact that some Buffalo users are backend people (including @markbates and myself), but I'm don't see how this would affect existing Buffalo applications, those apps have a working webpack 2 configuration installed that we will not change, it will continue working as it is today.

This change would have an effect on newly generated Buffalo apps, in which assets will continue working the same but will use a different version of webpack to achieve the same results.

[stanislas-m]

@paganotoni The thing is, the javascript world is moving really fast, and I've seen many js libraries dropping support for legacy versions. I agree it should continue to work as it, without any change.

The migration thing, in my head, is something for apps not finished yet: you started to write your app a while ago, but you don't want to recreate it from scratch to have the last buffalo-recommended-setup.

[paganotoni]

Yes, I think I've faced that issue with other features even in buffalo's generated Go files, it happened to me when i18n came in, as well as other small changes in the app.go file, and as with this webpack change, my app continued to work.

The strategy I've taken in such situations has been:

• look at a newly generated buffalo app for missing pieces
• add missing parts to my existing app
• ensure my test base passes

And I'm thinking in those situations what you've said could have been helpful, so, yes I think it would be cool to allow users to regenerate parts of the buffalo app also for reasons like:

• You ended up breaking x needed file
• Your generated version of a component is outdated (webpack in this case) and as a user, you see a benefit from upgrading (assets fingerprint would be a good example)
• You don't have X component and want to add it (moving from API mode to web mode or adding CI files)

Thanks for taking the time explaining all this @stanislas-m, I think this would be a great feature and I'm willing to help with it.

[stanislas-m]

@paganotoni I'm glad my point was relevant, but I still agree it's a specific use case. :)

To add more context, I work on project on my spare time, and when I have a missing feature, I fix (or ask for a fix in) Buffalo. When you work like that, the project can wait for months, and your project setup can be "obsolete". I'm not used to all the stuff in the frontend world, so I let the Buffalo project choose these bricks for me. That's why I came to this point.

The logical aim here, as you pointed it, is to provide generators for parts available as options in the new app generator. It's quite common to start a project, then make some choices after. In my opinion, it can be a good thing to have both options:

• You are pretty confident with the things you need, so you use the flags in the new app.
• You want to change later some choices: you create a more or less raw app (a new raw option, maybe?), then you choose the bricks you want to add.