wrapper. And this time, it's completely that. There's really not that much logic going on behind the scenes. It's really just updating some configuration, and then the Webpack config file is referencing that configuration. And yeah, I'm thinking that this might be a good way to go. Because one problem I had with the old version of Laravel Elixir is that, yes, this is really useful. But then when people want to modify it, it gets a little tricky. When they say, well, how do I add my own Browserify transformer? Or how do I add support for this? And we would offer Elixir plugins, but it just nonetheless was always very, very tricky. So now, you can use this. But if you ever do need to dig in, you could just switch over to your Webpack file, find the setting. For example, maybe you need a

So now, you can use this. But if you ever do need to dig in, you could just switch over to your webpack file, find the setting. For example, maybe you need a new webpack loader. Well, you're no longer figuring out, well, how do I add a new loader to Elixir? You don't do that. You just switch over to your webpack file and add it here. And I think that's the best of both worlds. The 80% people who just want the basics, like versioning and JavaScript compilation and CSS compilation, can live within this file. But those who need to extend it and have special circumstances, again, can visit their webpack file. So what I'm working on right now—we may not even write code together, to be honest—what I'm working on right now is getting this file as intuitive as possible for folks,

working on right now—we may not even write code together, to be honest—what I'm working on right now is getting this file as intuitive as possible for folks, so that you can figure out, okay, what is the entry point? What is the output for this? What kind of rules should we offer out of the box? I'm going to assume view. We're going to assume Babel. We're going to extract CSS for you automatically. And that would be if you're using SASS. Or if you're using LESS, then we'll do the same thing. We'll have some resolvers. We'll set source mapping for you. Again, because Webpack can do this stuff for you out-of-the-box, as a result, Laravel Elixir just becomes so, so much simpler. There won't even be much to maintain, in fact. We have our plugins. So the plugins I've set up are Webpack notifications. So

Elixir just becomes so, so much simpler. There won't even be much to maintain, in fact. We have our plugins. So the plugins I've set up are Webpack notifications. So for example, let's run npm run dev. And you can think of this as like the new Gulp watch. Yeah, we can get notifications, which I still need to style. Next, one area where it gets tricky is that Webpack isn't totally a task runner. So like, if you just want to merge some files, like concatenate files and minify them, it gets a little tricky with Webpack, because it wasn't necessarily intended to do that. But I have added support for that, so that in your Elixir file, you could just say elixir.combine this array of files into, you know, the output. That would all work. And again, I'm just fetching the array that you

file, you could just say elixir.combine this array of files into, you know, the output. That would all work. And again, I'm just fetching the array that you provide me there. And for each time that you call elixir.combine, we will concatenate the files. And if we're in production, we will also minify the files. And also, there would be one for elixir.minify a file. That would be an option as well. Next, we write to a log. That's not very interesting. That's just for the server-side stuff. This, in fact, is where we extract CSS. And then we do some multiplication. But yeah, I don't even want you to pay attention to this too much, because that's the whole idea. As you scan this, probably as you're scanning this with me, your eyes begin to glaze over. And that's just one of the

brainstorm. So I may keep going and decide that's not going to work out after all. But I'm at least very, very encouraged. So where I'm working on this, let's go to my code directory. Right now I'm calling it Laravel Webpacker. Again, I'm not sure if it's just going to be the new version of Elixir. It would be incompatible, because the past version uses Gulp and Gulp transformers and things like that. This version, of course, would use Webpack. So maybe it would get its own name. Maybe it would be called Elixir Next. I'm not sure. But what I have is a special project that I'm pushing to NPM, which I am calling Laravel Webpacker. And here's all the various dependencies that would be required to do everything that we need to. Actually, not too bad, to be honest. And if we take

Webpacker. And here's all the various dependencies that would be required to do everything that we need to. Actually, not too bad, to be honest. And if we take a look at index.js, yeah. So here's kind of the cool thing. This ends up being Elixir. And if you've seen the old Elixir project, that was, you know, a dozen different files, and it was kind of confusing. This is so much easier, because again, I can delegate to Webpack. So we're looking at like 200 lines. There's just not that much going on here. It literally is a wrapper. So for example, module.exports, this would be like if you say, I want to compile JavaScript files, and I'm going to compile, you know, main.js. That's what allows for that. So when you call that method, all I'm doing is just parsing the file so that I can

files, and I'm going to compile, you know, main.js. That's what allows for that. So when you call that method, all I'm doing is just parsing the file so that I can figure out. So if I need the hashed file name, that's useful for versioning. So yeah, it's just basically parsing. So if you want Sass, then I parse the file. If you want to combine some files, then I just record it. And then from the Webpack file, it just reads from that. That's it. Very, very simple. And what's cool is, before I even publish this to NPM, what you can do is push it to GitHub, and then from any project, like I have a testing project, you can just do npm install, and then reference the GitHub URL. So for example, like if I switch over to GitHub, yeah, I could just copy that. And then during testing, I can

npm install, and then reference the GitHub URL. So for example, like if I switch over to GitHub, yeah, I could just copy that. And then during testing, I can just say, npm install that, and try it out. Or of course, you can use yarn if you have that installed. Next, another thing I've done is we're working with build scripts. So if we were to go to the package.json, and if, of course, this was ever part of Laravel, we have no idea if that's going to be the case. But if so, then something like this would be included. And what's nice about this is, you can take those long commands you have to run with all the options that you can never remember, and you just throw them into a script here. And that way, you can just take the equivalent of this. So like, if you would normally run