Where is the hot reloading dev site when using Vite?

[raffjones]

Previously bud would expose the site on http://localhost:3000 but this is not the case with the updated Vite version. I get nothing on that URL.

I see this in the terminal when running yarn dev (or npm run dev)

 VITE v6.0.7  ready in 112 ms

  ➜  Local:   http://localhost:5173/app/themes/chill/public/build/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

  LARAVEL   plugin v1.1.1

  ➜  APP_URL: undefined

Tried putting an APP_URL value in my .env to no avail. Tried the default Laravel port of of 8000 but again nothing.

Any clues? Docs are out of date as they are still all on bud. Thanks in advance

[Log1x]

Does hot reloading work if you just go to the normal URL while in dev mode?

[raffjones]

Hi @Log1x - thanks for the reply.

No - when I visit the normal URL it’s just unstyled HTML.

[Log1x]

Gotcha, just checking since Vite in this configuration will ideally not need a dev URL. I’m going to attempt to switch one of my projects over some time this week and will see if I can’t help squash any issues I come across.

[ben]

I have a Bedrock site setup on example.test with the dev-main version of Sage installed. Steps that work for me:

1. Run npm install
2. Run npm run dev
3. Visit http://example.test
4. Modify app.css or other theme files
5. The browser with http://example.test opened has been refreshed with my changes

[raffjones]

Thanks @ben - I followed these steps from scratch and found the source of the problem:

It is an issue with Brave browser. If shields are UP for the test domain, it shows unstyled HTML and nothing works. You need to disable shields for your test domains then everything works fine.

WIth Brave shields up on example.test

Once shields are removed CSS is correct as you can see - I am applying tailwind bg-black and text-white to the body and it works.

I can also confirm that hot reloading works perfectly when I make further changes to app.css.

There is an error about @wordpress/dom-ready not being found when loading the admin side, and no styles load in admin, but I guess they are different problems.

thanks again both @ben and @Log1x for your help.

[ben]

Glad you’re sorted! Thank you for the follow up.

I’m making a note to circle back on the wp-admin side of things, I had not tested that yet

[ben]

wp-admin builds should be fixed with 🩹 Dev server: fix WP dependency handling by retlehs · Pull Request #3207 · roots/sage · GitHub

[raffjones]

I noticed that if you run npm install then npm run dev without an intermediate npm run build you get this error:

npm run dev

> dev
> vite

node:internal/fs/utils:351
    throw err;
    ^

Error: ENOENT: no such file or directory, open 'public/hot'
    at Object.openSync (node:fs:590:3)
    at Object.writeFileSync (node:fs:2295:35)
    at Server.<anonymous> (file:///Users/stevejones/Sites/client/springboard/web/app/themes/spring/node_modules/laravel-vite-plugin/dist/index.js:103:14)
    at Object.onceWrapper (node:events:625:28)
    at Server.emit (node:events:523:35)
    at emitListeningNT (node:net:1857:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:81:21) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: 'public/hot'
}

Node.js v20.1.0

As soon as you run npm run build and re-run npm run dev it’s fine.

Can confirm the latest commit fixes the dependency error.

I’m not sure if I should have expecting the iframe styles issue to have been resolved with this new approach, but styles don’t load on the admin site when supplied via editor.css - fine on the front side.

[ben]

Thanks for the heads up and the feedback. I’m messing with some of the editor styling in the Tailwind v4 PR: ✨ Tailwind v4 by retlehs · Pull Request #3208 · roots/sage · GitHub

[raffjones]

Oh man, this is so close to being the dream solution to finally solving the iframe styles… I’ve moved the discussion over to ✨ Tailwind v4 by retlehs · Pull Request #3208 · roots/sage · GitHub

[csorrentino]

This doesn’t solve the issue of injecting styles into the iframe, but if it unblocks you, I would try a plugin that registers a very basic api version 2 block, while env is development (if using bedrock). Having any v2 blocks registered appears to disable the iframe editor.

[raffjones]

Hi @csorrentino - using an API v2 block is the approach I’ve been using for the entire lifecyle of bud.js but I am really hopeful that @ben can solve it once and for all (with hot reloading) without having to use this hack.

[ben]

@raffjones

This approach doesn’t actually work with the Sage 11 dev version either. If I install an API v2 block, load the editor, run npm run dev and make changes to editor.css the changes do not apply in the editor. The only way to see the changes is to run a full npm run build and fully manually reload the editor page.

If we end up having to do some sort of hack to enforce a non-iframed editor in dev mode, the setup in main right now (without Tailwind v4/#3208’s changes) will work

[raffjones]

Yes, apologies for not mentioning that if an API v2 block is present, the current Vite version does work with editor styles too.

I absolutely love this approach - flipping between localhost:3000 and mysite.test used to cause all kinds of problems and this is a joy to use now.

[mensch]

Agreed! Just started a new project with the Vite codebase and very happy with it so far.

Removing Tailwind doesn’t seem to be too difficult either. Most of the changes have to be made in the wordpressThemeJson function in resources/js/build/wordpress.js in addition to removing the config, packages and relevant imports.

[raffjones]

Related to this new Vite approach, how does one localize a script now that the Bud bundle('app')->enqueue()->localize method is gone?

setup.php now injects with the wp_head hook rather than wp_enqueue_scripts and I’m not sure how to go about it.

[Log1x]

I just moved it out of wp_head directly into the app layout using the @vite directive.

For a localize script in the current configuration, you’d need to either use a hook on wp_footer or handle it directly in the app layout or your footer component using the @js Blade directive like:

<script>
  var test = @js(['test', 'test2']);
  console.log(test);
</script>

[ben]

Inline script is preferred over localize (I’m still training myself to do this ), and if you really want to do things the WP way, you could follow this method:

wp_add_inline_script without dependency

[raffjones]

Ah - its always been the need for a dependency I don’t need that has put me off this approach. Being able to do it without does indeed sound like a nice way to do it going forward.