How to plug in webpack 2.0 into phoenix 1.3.0-rc

I made a screencast to show the functionality to which I’m referring. This was done on my slow MacBook (and the screencast recording made the rebuilds much slower).

When I looked at Brunch, it could not do hot module replacement. Maybe I missed it. If it can do the functionality of Webpack HMR that’s in the screencast, please let me know.

1 Like

https://www.npmjs.com/package/hmr-brunch :slight_smile:

Everything in Brunch is a plugin, and that is an old one. :slight_smile:

1 Like

I had no idea! Thank you for the education… I’ll check it out on the next project.

1 Like

I’ve have a starter Phoenix repo implementing Webpack, React (with Hot Module Replacement) and Stylus. I’ve updated it to use Phoenix 1.3 and Webpack 2, yesterday.

Improvements and pull requests are of course welcome: https://github.com/odiumediae/webpacker

10 Likes

Just great! Thanks a log @Letmecode. I managed to fix finally my installation, thank you very much!

What a nice setup :slight_smile:

I’d like to step further with this one :wink:

3 Likes

I’m glad I could help.

That other setup looks great, and GraphQL is particularly nice, but it hasn’t been updated for a while, as it seems, and Webpack is still version 1, so it’s not for me, but it shouldn’t be too hard to update.

1 Like

Hey, I created this repo https://github.com/yordis/phoenix_assets_webpack

Normally I understand how Webpack works and I replace it every time I create a Phoenix project :smiley: and this is phoenix 1.3 ready actually

6 Likes

I would love to use if the setup was not using React/Stylus but VueJS 2.

Webpack 3 was just released. It was my introduction to Webpack, but all that needs to change on the Phoenix side is @idi527’s post. The docs on Webpack are pretty good. I don’t run any client-side JS framework. I just wanted the features Webpack provides – tree-shaking, hot module replacement, and better maintained plugins than those built for Brunch. I read and followed the guides here: https://webpack.js.org/

This is using laravel-mix, which includes support for .vue files.

By far the biggest issue witih Brunch at the moment is that it isn’t really being maintained. The latest updates to the primary Brunch repo were committed seven-ish months ago, while webpack is updated daily.

The maintenance schedule itself isn’t such a problem, except that most of the plugins, also, don’t seem to enjoy any kind of maintenance either. I’ve had to personally go in and update four or five different brunch packages to reflect modern package versions, some which required complete dependency swap-outs, just to use them with other current packages in my npm package build.

Brunch seems like a great tool on the surface, but I’d love not to have to become its maintainer in order to rely on it. Webpack has a much, much more active community around it, and as such should probably be a candidate for being integrated by default in Phoenix 1.4+.

3 Likes

I do love Brunch’s speed, but that’s probabky the only thing I like about it. The docs are extrememely sparse and the plugins often fail subtly. But maybe for something like Phoenix it’s good enough for a default. Swapping it is pretty easy too :slight_smile:

2 Likes

I suspect the biggest hurdle to universally employing webpack as the asset pipeline is for projects relying heavily on EEx - which at the moment still seems to be a common dependency for Phoenix projects (as far as I’m aware there isn’t anything like an eex-template-loader).

@tmbb: the speed is great, and honestly I’m just building out a webpack branch on a project that I’m working on and have yet to test the speed in comparison. Indeed the docs aren’t great, I haven’t really experienced any flat-out failures though.

Also, maybe it’s just the very plugin-oriented architecture that brunch takes, and just the number of packages available compared to webpack, but I find myself often needing to roll my own plugins, or lean on micro-plugins with no tests available elsewhere in the community to acheive more advanced build tasks.

I’m running a modernizr js builder in my build cycle, and even though I was able to use the preload() hook, I needed the before-brunch plugin to run an npm command out of the box. It seems like it shouldn’t have been so difficult to achieve what seemed like a trivial addition to the overall build cycle.

There were a couple of such instances where I just looked for webpack plugins in edge cases where I happened to be connecting odd tools in the js or css worlds together, and there were in almost all instances multiple plugins available for the same purpose.

If the goal of phoenix is to offer a more complete, robust, easily-maintainable end-to-end platform out of the box, I don’t see how it will be able to stick with brunch long-term, unless the mentality is that the front end is supposed to be a more extensible, hands-on experience for the developer.

Either way, it seems that the two paths are inherently going to be brunch or webpack, and I don’t see a compelling reason to offer default generators for buliding an app with one and not the other.

Additionally, though I think npm is overall a much better build tool than yarn, I could imagine people wanting to use yarn out of the box. Because there isn’t too much documentation on using yarn with webpack with phoenix (indeed there’s only one example app on the web of an end-to-end web app with both Phoenix 1.3 and Webpack 3).

Maybe it’s a seperate project, but it may be worth considering generators for just one or two more of these best-of-breed build tools to make things easier on newcomers, and show them that there are multiple options for front-end management in Phoenix.

@peerreynders: maybe we’re talking about different things here, but to my knowledge regardless of how the front-end build is being handled, EEx rendering would still happen from the Phoenix.Html hex package and phoenix_html npm packages respectively. Does that sound right?

1 Like

What does EEx have to do with Webpack, Brunch or any other frontend solution? EEx templates are just functions that generate strings right?

1 Like

Maybe I simply haven’t gone down the Webpack rabbit hole deep enough. But to put my current understanding in simple terms:

  • Webpack’s use-case is geared completely towards JavaScript rendered pages - either in the browser or through JavaScript server side rendering. It wants to bundle everything, your JS, CSS, images, etc - and to get it’s dependency graph it looks at all of it.

  • EEx is Elixir server side templating as it was done in the pre-Node.js days and Brunch largely supports the needs of that style of (JQuery-era) web development. You manually decide what goes where and you decide how simple or fancy your setup is.

As far as I can tell EEx (Elixir) and Webpack (JavaScript) don’t easily mix as they represent totally different styles of web development. Now it may be possible to use EEx templates with Webpack but that would have to be entirely on Webpack’s terms and I doubt that there would be much value that EEx templating features could bring to the table.

People using Webpack with Phoenix typically are using React or Vue.js and therefore see no need for EEx features. But there still seems to be a significant audience for using Phoenix and server side templating with EEx - and I have yet to discover how Webpack could be coerced to support that style of web development - I suspect that for that scenario using Brunch is simply easier.

Ultimately Webpack may be too specialized (opinionated?) to become a universal default.

Hey @peerreynders: I guess I’m still kind of confused about your use case. It seems to me that EEx is just as mutually exclusive to Webpack as it is to Brunch. You could just as easily use Webpack just to bundle your client-side assets as you could use brunch to do that. To my understanding, In neither case would you need to obstruct Phoenix’s ability to render eex or haml, etc. in order to also serve assets out of webpack.

To clarify, to my understanding the fact that webpack is able to render server-side javascript does not necessarily suggest that it has to render all server-side assets. Does that make sense? This may be an incorrect presumption, but I’ve already begun integrating Webpack into an existing Phoenix application in lieu of Brunch and don’t see any signs that Webpack will require me to obstruct or alter my server-side template rendering.

For the record I’m using a combination of html rendered through HAML, EEx (where I’ve actually found some bugs in the phoenix_haml and/or calliope parsers), and a substantial set of front-end react templates with some animation support from both jquery and vanilla javascript.

Either way, I’m going to be working on this more early next week so I’ll report back with my findings on getting all of this running through webpack, vs its current setup, which is a brunch build.

You ‘could’ take EEX’s template output and run it through ElixirScript or so to get javascript. Would not be as efficient as in Elixir (at all), but eh…

1 Like

That’s probably the case. Without explicit setup webpack won’t even touch anything html and for vuejs I know for sure it can quite happily work in conjunction with server side rendered markup. Even things like webpacks hot reloading are in the end just: load your javascript file from the webpack started server instead of the phoenix one. That’s easy to do with eex. While I fully understand the decision to use brunch in phoenix webpack could handle it’s tasks just as well.

The difficulty I see with running webpack as default is rather that I’ve yet to see a webpack setup which does work out of the box in such a general/baseline fashion as brunch (the closest I know would be laravel-mix). With brunch you just add a file to the right folder and it will be bundled. That’s not highly controlled, but damn simple. For webpack there are so many features and ways to do things, that it’s probably quite hard to generalise things without creating a ton of additional work – just for the assets pipeline.