Remove unused dependencies

[depsimon]

axios is not used anymore.
I suspect this is a leftover of the original starter kit which uses axios.

autoprefixer is not used anymore.
It was used as as PostCSS plugin, but as it's been replaced by the Vite plugin it's not needed anymore.

[vanm]

Good find

[tnylea]

Right you are. Thanks to Livewire we no longer need Axios.

Appreciate it 👏

[taylorotwell]

I'm a bit curious if Echo would fail if Axios is removed.

[depsimon]

I'm a bit curious if Echo would fail if Axios is removed.

It should not as laravel-echo is not dependant on axios.
I just tested to be 100% certain, and I managed to get the messages broadcasted to the frontend. You can check it out on this branch with a valid PUSHER config in .env

[taylorotwell]

@depsimon did you try with a private channel that would hit the broadcasting authentication route?

[vanm]

I was curious to follow this thread and did some exploring:

Here's the docs for laravel-echo (now under Broadcasting in the main Laravel docs) and it does mention expecting axios to be imported (otherwise the implementor will need to configure sending their own headers).

Echo implements a pattern where it registers "third party request interceptors" so it can add the header to each request, and it looks for the existence of Axios (or alternatively, Vue.http, jQuery, or Turbo): https://github.com/laravel/echo/blob/f333d49d116fcd7302d1fd19815b6876ce542085/src/echo.ts#L159

So it's a soft dependency, in a way - and a documented one. If someone is configuring Echo, they will need to use either one of these libraries or send the header themselves. So, by including Axios in the starter kit, it enabled this sort of soft dependency to work for packages like Echo.

There's no right answer for what to do here, but it was interesting to follow Taylor's comments and see why Axios might be expected down the line.

Since this is a starter kit and there are many steps required in order to configure Broadcasting, there's a case to be made that the axios dependency doesn't need to be enforced in this starter kit and instead the implementor could make their choice down the line if they chose to install Echo. On the flip-side, Axios is useful and may make sense to include as a suggested front-end library, and has the benefit of meeting these downstream soft dependencies (it wouldn't make sense for Echo to depend formally on one of the many front-end libraries, so I understand why it implemented the "check and inject" pattern to play well with whatever the implementor decided. Since it's documented, it's not a huge mystery for those configuring Echo.

All that said, if Livewire itself also requires Axios and implements a similar pattern of injecting headers then it makes sense for this starter kit. If that’s the case, where would that be?

[vanm]

Some more cursory digging, since I've never looked at the Livewire code before I decided to take a peek:

Laravel Echo support is framed as optional for Livewire:
https://github.com/livewire/livewire/blob/403eb7dd518b837b9f99d599341883e28d9e489a/docs/events.md?plain=1#L412

If Echo is detected (window.Echo), the X-Socket-ID header is added to requests:
https://github.com/livewire/livewire/blob/403eb7dd518b837b9f99d599341883e28d9e489a/js/features/supportLaravelEcho.js#L4

So it seems like Livewire will play nice with Laravel Echo if the project decides to use it, and the header will be added.

Livewire itself uses the native window.fetch API to send requests, and does not rely on Axios.

It seems like people would only need to add Axios (or an alternative supported library) if they wanted to install Echo, and since Echo is not configured by default for this starter-kit (and the dependency is documented in the Echo installation guide), Axios could be removed from this project. If there's something else that's undocumented or I am missing something, let me know!