feat: add webpack plugin

[Tofandel]

#522 Revisited with a webpack plugin instead

Usage

const ZiggyWebpackPlugin = require('./vendor/tightenco/ziggy/webpackPlugin');
mix.webpackConfig({
  plugins: [new ZiggyWebpackPlugin('php artisan ziggy:generate')],
});

This runs the command passed to it before the compilation.
If running mix watch, it will also watch for changes in config/ziggy.php and routes/ to retrigger this same command which in turn will trigger a rebuild if those files are modified

[bakerkretzmar]

Thanks. I think this can be a lot simpler and I would rather let users set it up themselves instead of including it in Ziggy. I've added some documentation to make this easier for others to find.

[bakerkretzmar]

Never mind it was already there and I completely forgot 🤦🏻

[Tofandel]

I already pointed out to several problems with your code that makes it recompile way too many times even when not needed and every time it compiles it does it 2 times as well, with the update happening only the second time, which is a big issue as it can take up to 1 minute for changes to be reflected in a dev env.

Aiso, sorry but if we're supposed to build everything ourselves then what's the point of ziggy except being a documentation?

The point of plugins is to make those integrations easier and a single point of truth, otherwise every body makes his own things with bugs etc.. That doesn't get updates, needs maintenance on webpack updates and eventually you get fed up and start hating a good thing for not providing an integration to use it

[bakerkretzmar]

What are the issues you've run into with those examples? Am I attaching to the wrong hooks?

what's the point of ziggy

To provide a route() helper function in JavaScript that mirrors Laravel's as closely as possible. That's it basically. I think we do that pretty well, in large part because we have kept the scope of Ziggy pretty narrow and not added a ton of bells and whistles.

I have tried to build plugins/integrations with Webpack multiple times in other projects and it has always caused more problems than it solved and made me wish I hadn't bothered, so I'm especially sceptical of doing anything related to Webpack at all. But I also just don't think it's a big deal to run the artisan command manually once in a while, especially since on most projects I don't think route files are changing super frequently.

I'm not completely opposed to adding something like this, but because Webpack sucks to work with so much it has to be really, really simple, add as little code as possible, and be something that's going to be easy for me to maintain.

[Tofandel]

The problem is that by adding as a file dependency a file that is not actually a dependency of the bundle it creates a feedback loop, so the php file triggers a command and a rebuild of the whole bundle with the old files (because that's what a file dependency does in webpack), then the new file updated by the command gets picked up by the watchers and retriggers another build.
And this problem is made much worse because the generate command writes the output no matter what (something I addressed in this PR) so basically as soon as you're editing a php file 2 full compilations happen one after the other even though there was no change to the js output

This is something that can only be addressed by separate watchers than the main webpack watchers