Dev-dependency laravel-mix is deprecated and no longer actively maintained

Hey Jørn 👋
nice to see you in the issue queue, this one is a tough one to crack, I did consider Vite before and did some initial work there a while ago but seems quite complex and you might only manage to get it to work with a ddev config which adds to the onboarding process

here's a branched off version: feature/vite but the job is not done

Here's the README for it.
Give it a go maybe and let me know what you see

I tried this, but I couldn't get the HMR to work (and consequently, the dev mode through `npm run dev`). However, `npm run build` works, as far as I can tell.

Few things I noticed that could be stumbling points:

• In VITE_INTEGRATION.md, you have correctly given the path for .ddev/nginx/vite.conf. But the confusing part is that that directory doesn't exist. Instead, there is a directory called nginx_full. I tried placing the conf file there but it failed. I had to create the nginx directory and place the file there. A message about this would be helpful.
• In vite.theme, there is a hook_page_attachments_alter, which is the code that injects HMR. The function name is vite_page_attachments_alter but this won't get executed unless the theme name is vite. Once I changed this to my theme name, I started seeing Vite appear in my page (but HMR still didn't work). I suppose the function name should be radix_starterkit_page_attachments_alter

I am not an expert on Vite and so can't say what's going wrong here. I don't see any websocket connections nor socket or vite related messages in the console. I will pick this up later but if someone is trying this out, I hope the above will be helpful.

I'm bumping priority on this issue.

The reason is: https://www.drupal.org/project/radix/issues/3584633

"we are pinned on a 2 year old webpack release. we need to migrate to Vite soon given laravel-mix is really dead."

How can we move forward with the VITE integration:

Do we want to copy the current flow 1:1 in Vite before it can be released?

If not, can we define what it should do at minimum to become a viable option (for example compile all code but without BrowserSync support)

Where are we now and where can you use an extra pair of eyes / help / testing / feedback.

Thanks in advance!

That's a major migration, not an easy task. needs a lot of work which I don't have the time for. I hope I can manage it sometime soon but feel free to give it a go

Yes it would involve a lot of work.

To be honest I'm even wondering if Vite is the right fit here.

Vite's superpower is a browser-native dev server, which Drupal's PHP rendering makes irrelevant.

Have you looked at stuff like esbuild?

Esbuild's superpower is fast, simple bundling, which is exactly what Drupal themes need.

I think the migration would also involve a lot less work while you keep all the features you have now (+ it would work a lot faster than with laravel mix).

Hey Fons 👋
I would have been happy if we could get Vite to work properly with Drupal and Radix, but I assume your suggestion makes more sense, we should also consider Rsbuild maybe, that might fit better

I've done some experimenting with both Vite and esbuild here. I did get Vite working at a POC level, but there's a lot to it (100+ lines of code), including some ddev configuration and some strings specifically referencing our current sub-theme that make it less than ideal, in my opinion.

esbuild was basically a drop-in replacement. I agree with f0ns that it's probably the better choice here. I'm opening a MR that replaces mix with an esbuild configuration that should have feature parity with what mix was doing previously. Looking forward to feedback.

Thank you for your work on this!

I did propose esbuild as I saw it more as a "drop-in" replacement comparing to vite.

That doesn't mean I'm against a Vite workflow, I was just thinking out loud on a solution that would get us to get rid of a package that is not maintained anymore without having a major migration.

It's good to have that confirmed by someone else but the decision lays with the maintainers.

I just had a deeper look into the implementation and it looks good! Great work.

A few things that could strengthen the implementation:

Parallel SCSS compilation:

The current for loop compiles components sequentially. Wrapping in Promise.all makes it parallel with no added complexity, which becomes noticeable as component count grows.

This would make it a lot faster.

Sourcemaps

This is worth enabling, at least behind a --dev flag. Will make debugging compiled output a lot easier.

Watch mode

A chokidar watcher combined with an esbuild context (incremental rebuilds) makes the dev loop significantly faster than a full rebuild on every change. Not critical for a v1 but worth having on the roadmap if maintainers would decide esbuild is a viable option.

These are just suggestions as I went through a similar migration building my own theme.

I ended up with using native sass + PostCSS/autoprefixer in that project rather than esbuild-sass-plugin. This gives more control over deprecation handling and the autoprefixer pass. I must note that it's a bigger change though and probably out of scope for a drop-in replacement (just an FYI).

Great work guys, it would be nice if we can fine tune this further. Even though I would've liked to take a look at Rsbuild as well.
That aside I will review this during the weekend

Okay there were some issues and some of the functionalities were left off, I went on and fix everything on top of the MR, will fix some more stuff and tag a new release. Will keep it on the same 6.0.x since it is not a breaking change for the current functioning websites and I don't want to maintain two different branches

Thanks everyone for the help

Very nice! Thank you