Laravel-mix: Why did we need mix?

[rlewkowicz]

I don't know if this is the correct place for this question, but why this project? I'm honestly interested in why mix was decided to be needed. I ask this as someone who never really got past intermediate about a year ago and I'm now coming back. First there was Laravel Elixer which "simplified" gulp. Now you have Laravel Mix which "simplifies" web pack. What was wrong with elixer?

[nealstammers]

Laravel Mix takes a slightly different path to Elixir, hence a 'new' platform. Both products greatly simplify the process of building all your site assets.

Both tools can watch multiple files being changed, so you shouldn't need to specify every single one. But for example, if you're using SASS you should have one 'main' file in which you specify all other SASS files to include. Then, use Elixir or Mix to watch and compile just the 'main' SASS file. The great thing is that if ANY of the SASS files change, it will be re-compiled.

I'm not sure if this is a free video, but if you're a laracaster you could watch this for more info:
https://laracasts.com/series/whats-new-in-laravel-5-4/episodes/3

The forum would be a good place to add questions like this on too.
https://laracasts.com/discuss

Cheers, N.

[adiachenko]

@rlewkowicz I haven't used Elixir much, but from my experience with creating build pipelines, the problems are as follows:

• Elixir is still using Webpack under the hood (surprise) by utilizing webpack-stream interface that is no longer maintained and has a plethora of issues on it's own
• Elixir had way too many dependencies. There was a lot of cases prior to version 5 or 6 (before browserify setup was simplified and then dropped from the main repo) where it didn't even install on some systems (Windows being the main suspect) due some dependency failing for some obscure reason
• Elixir was too hard to meaningfully customize. There was no single point of truth like the current setup/webpack.config.js that you can tweak to your needs
• Elixir was too hard to maintain. It was a voodoo with internals that I can barely understand. laravel-mix is much more simple and readable.

Anyway, I am glad that Laravel officially ditched that Gulp monstrosity and I can now sleep soundly knowing I don't need to deal with it's issues or maintain my own webpack boilerplate.

I'm already using laravel-mix and I have a much better experience with it.

[JeffreyWay]

I just don't want to manually enter a path for each mix. I feel like that's gross.

You're right. It feels gross, because you shouldn't be doing it that way.

This is great if I want to watch one file and compile that to one output file. Who does that?

Most people.

Even more whats wrong with just gulp?

Well, for that matter, why do you even need Gulp? Just wire it up all yourself.

There's always an objective. What problem did this aim to solve, or whats the ideological objective?

Maybe build up a Gulpfile from scratch that does everything Mix does, and then let's compare your version versus the webpack.mix.js file that ships with Laravel.

Cause yea right trying to use non standard pre and post processors with mix), or mix.

I don't know what you mean by non-standard pre-processors. There's no need for you to pass a glob to fetch all Sass or JS files within a directory. You can't ensure the order, and it's just not needed. Point to a single entry Sass file, and, there, you can import any partials that it requires.