[QUESTION] devServerInternal allowed me to not have to touch the config or .env file

[kylecotter]

While intentional or not, the devServerInternal config option let me set that to the Docker container running the Vite dev server and allowed me to leave useDevServer always set to 1 as it would automatically figure out if I was expecting a manifest.json or the devserver url. (I think because you were checking if the devserver responded)

This let me run the Vite dev script or the build script without any sort of .env or config file change on the Craft side.

With the removal of that setting, now I have to explicitly set useDevServer, which while manageable, means I can't just switch between a devserver or a production build locally. Maybe my desire is in the minority but figured I'd ask 🤷🏻‍♂️

Thanks for the work on this!

[khalwat]

With the removal of that setting, now I have to explicitly set useDevServer, which while manageable, means I can't just switch between a devserver or a production build locally.

Sure you can. Just set useDevServer to true for a devServer build and false for a production build... no?

[kylecotter]

Right, that works, but...

"useDevServer" => 1,
"errorEntry" => "/src/js/main.js",
"manifestPath" => '@webroot/dist/manifest.json',
"devServerPublic" => "https://hot-" . App::env('VIRTUAL_HOST'),
"devServerInternal" => "https://node:443",
"serverPublic" => App::env('PRIMARY_SITE_URL') . '/dist/',

previously, leaving this config in place, meant I never had to change anything to test a production build locally.

Did leaving 'useDevServer' => 1 all the time make sense? Probably not, hence why this functionality probably wasn't intended, but that setup meant I never had to edit an .env or config setting and I could start the dev server or run a build and it automatically figured out the path it needed.

[khalwat]

Yeah I was considering putting a checkDevServer flag in or such but went with the reduced complexity route.

I'll leave the issue open to see if anyone else wants to bring it back, too.

[kylecotter]

Sounds good, thanks!

Only reason I'd prefer a "no-change-necessary config" (whatever form that would take) is we have devs who come on to projects just to do certain backend work and don't need a front end dev server, just a working build.

Maybe this is less of a problem now that Vite's devserver doesn't set your MacBook Pro on fire like Webpack. But, being able to tell them "hey just run make build to get the front end" and that's it sounds easier for them.

[khalwat]

Gotcha. Yeah I like the fallback functionality, it also is nice if you accidentally somehow ship it to production with it useDevServer set to true as well

How are you liking Vite so far?

[kylecotter]

I'm loving the local dev experience and lack of convoluted webpack config needed.

I think I'm committed to sticking with it on at least one Craft project I'm working on.

I'm still using a minimal webpack config just to one-off run the favicon generator and create the twig partial.

Last thing I need to fully figure out is how to deal with src/images in the context of a Craft project. Mainly to use with Craft's svg function and the occasional one-off image that isn't a Craft asset.

But Vite and Tailwind JIT is :chef-kiss:

You?

[khalwat]

For the favicons, you probably can just run that directly rather than using webpack as an intermediary. All the webpack plugin does is call the npm favicons package anyway (it's just a wrapper).

For me yeah it's on the roadmap basically, but I need to sort out:

• Critical CSS
• Favicon generation
• Some other misc tasks that webpack does

Also keep in mind that Vite uses Rollup for the production build, so plugins may very well already exist:

https://www.npmjs.com/package/rollup-plugin-favicons

[khalwat]

Anyway yeah so far I'm really enjoying Vite -- just exploring the unknown unknowns and such :)

[khalwat]

Alright @kylecotter I added this in via 69c7902 & nystudio107/craft-plugin-vite@758d042

It's in the 1.0.4 plugin release. It's optional now, and disabled by default -- you enable it via checkDevServer and then it'll look at the devServerInternal URL.

[kylecotter]

You’re the best!