# Where is the hot reloading dev site when using Vite?

**URL:** https://discourse.roots.io/t/where-is-the-hot-reloading-dev-site-when-using-vite/29126
**Category:** sage
**Tags:** vite, sage11
**Created:** 2025-01-19T18:35:18Z
**Posts:** 24

## Post 1 by @raffjones — 2025-01-19T18:35:18Z

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 :slight_smile:

---

## Post 2 by @Log1x — 2025-01-19T19:42:29Z

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

---

## Post 3 by @raffjones — 2025-01-19T20:03:35Z

Hi @Log1x - thanks for the reply.

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

 ![image](https://discourse.roots.io/uploads/default/original/2X/e/e86657dd6507265f02c64251c96e18cd5e22aab5.png)

---

## Post 4 by @Log1x — 2025-01-19T21:38:59Z

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. :cowboy_hat_face:

---

## Post 6 by @ben — 2025-01-20T15:22:02Z

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

---

## Post 7 by @raffjones — 2025-01-20T16:16:20Z

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`

 ![image](https://discourse.roots.io/uploads/default/original/2X/a/adc92edf9ae41533684598f57b04d00ebc7e4dc3.jpeg)

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.

 ![image](https://discourse.roots.io/uploads/default/original/2X/0/0db5a59ff82fff19639752f202cfa775578adb56.jpeg)

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.

---

## Post 8 by @ben — 2025-01-20T16:36:04Z

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 :pray:

---

## Post 9 by @ben — 2025-01-20T21:21:19Z

wp-admin builds should be fixed with [🩹 Dev server: fix WP dependency handling by retlehs · Pull Request #3207 · roots/sage · GitHub](https://github.com/roots/sage/pull/3207)

---

## Post 10 by @raffjones — 2025-01-20T22:11:29Z

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.

---

## Post 11 by @ben — 2025-01-20T22:52:43Z

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](https://github.com/roots/sage/pull/3208/commits/e4c1c5075b7f18f9892f8c35aa009e34a280a288)

---

## Post 12 by @raffjones — 2025-01-21T09:36:34Z

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](https://github.com/roots/sage/pull/3208)

---

## Post 13 by @csorrentino — 2025-01-21T18:38:06Z

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.

---

## Post 14 by @raffjones — 2025-01-21T19:09:07Z

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.

---

## Post 15 by @ben — 2025-01-23T05:22:36Z

> [@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

---

## Post 16 by @raffjones — 2025-01-24T11:07:42Z

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.

---

## Post 17 by @mensch — 2025-01-24T14:25:33Z

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.

---

## Post 18 by @raffjones — 2025-01-28T15:26:43Z

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.

---

## Post 19 by @Log1x — 2025-01-28T16:52:02Z

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

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>
```

---

## Post 20 by @ben — 2025-01-28T22:28:52Z

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

> <https://wordpress.stackexchange.com/questions/298762/wp-add-inline-script-without-dependency/311279#311279>

---

## Post 21 by @raffjones — 2025-01-28T22:45:14Z

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.

---

## Post 22 by @tay.lor.l — 2025-02-07T03:50:03Z

Hey just wanted to chime in on this one. Very interested in the tailwind v4 and vite work being done here!

I just spun up a new sage theme from dev-main and I’m also not seeing the hot reloading work when running npm run dev. (APP\_URL: undefined)

Where is the best place to find the latest updates to try and debug? Just dig through the PRs?

Cheers

---

## Post 23 by @ben — 2025-02-07T12:56:10Z

> [@tay.lor.l](#):
>
> I just spun up a new sage theme from dev-main and I’m also not seeing the hot reloading work when running npm run dev

Give us more insight into your setup and the workflow you’re trying. For example:

1. What URL are you visiting?
2. What file are you modifying?
3. What changes are you making to the file?

([See our guidelines](https://discourse.roots.io/t/how-to-best-ask-questions-on-this-forum/24582))

You’re also posting in a topic that’s already solved ([and has demonstrated a working workflow](https://discourse.roots.io/t/where-is-the-hot-reloading-dev-site-when-using-vite/29126/6)) — I’m gonna close this one out. Please make a new topic.

---

## Post 24 by @ben — 2025-02-07T12:56:16Z