Vite 5.0 Update

Do you face problems with Vite integration in WordPress? HMR doesn’t work? I was there too. I messed up a little bit by skipping the „read the documentation” part while upgrading Vite. But who reads the documentation first? 😅 Anyway, If you want to avoid my mistakes or you are searching for solutions to your problems, you must see this!

I’ve forgot about this! Load Scripts as Modules

In my previous video, I presented how to integrate Vite with WordPress. However, thanks to @jantack7186 observation, there was one important missing element: the need to load scripts as modules no matter if the development mode is active or not.

I have just forgot about this! It wasn't a problem in case of having just one script without external libraries, but for sure, It had to be fixed. So, I’ve moved the function which adds type=“module“ tags from the Vite integration class to Assets module, to ensure the loading of all theme assets as modules.

These changes have now been reflected in the original article so if you follow them, you should make it work without any problems.

Vite 5 Released! What Changes it Brings?

Vite 5 has just been released, and I want to send a big thanks to the team for their huge effort. You are amazing guys! This update brings performance improvement caused by adopting Rollup 4, increases the minimum node version to Node 18, focuses on cleaning up deprecated APIs, and includes several smaller enhancements.

If you’re interested in all the changes, you can check the detailed release notes. In this discussion, I’ll focus on aspects crucial to the WordPress workflow we defined in the previous article. Especially the ones that have broken my integration.

Let's start with upgrading Vite using the yarn upgrade vite --latest command.

#1 Vite CJS Node API deprecated

I’ll start with something small. CJS API has been marked as deprecated and it will be removed in future releases. It means that we should not use require(’vite’) anymore.

That’s not a problem, because we already use dynamic imports with import declaration but in the current setup, when executing the dev/build command, Vite displays a deprecation notice. It can be resolved by adding type: ”module” to the package.json file.

$ vite build
The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.
vite v5.0.10 building for production...
✓ 4 modules transformed.
dist/manifest.json           1.37 kB │ gzip: 0.33 kB
dist/uBgCxLf2.woff2         65.27 kB
dist/d0h2cOfx.css            3.23 kB │ gzip: 1.36 kB
dist/_CQrhhbQ.js             0.18 kB │ gzip: 0.17 kB │ map: 0.48 kB
dist/OQKw9U_W.js             0.18 kB │ gzip: 0.17 kB │ map: 0.48 kB
dist/js.cookie-Hg5VKEPt.js   1.46 kB │ gzip: 0.76 kB │ map: 5.86 kB
✓ built in 174ms
✨  Done in 0.47s.

#2 Manifest is being generated in .dist/manifest.json

Another important change involves the relocation of the manifest.json file, crucial for handling asset loading in our system after the build.

├── dist
│   ├── manifest.json

├── dist
│   ├── .vite
│   │   ├── manifest.json

In Vite 4.5 when manifest was enabled and set to true in the config, it was placed in the output directory, so it was /dist/manifest.json in our setup. After the upgrade, it is also wrapped in .vite directory ( /dist/.vite/manifest.json) so WordPress is not able to load this file anymore resulting in displaying build the code notice all the time.

To solve this, we should update the path to manifest file in the WordPress config or force Vite to place this file as earlier, directly to the output directory, by specifying the file path in thebuild.manifest key of vite.config.js to manifest.json. I've decided to set it in Vite because I don’t want to keep the public references to development infrastructure details in the production. Let’s call it a security risk.

export default defineConfig({
  build: {
    manifest: 'manifest.json',
  },
}

#3 Vite Client is now available within the base path

As you remember, to make up the integration, we had to load Vite client in WordPress when the development server was active to make up the HMR features work.

I couldn’t find any references to this in the release notes, but after updating Vite, the client was not available within the http://localhost:5173/@vite/client URL anymore. It started taking the base path that we’ve set into account so it became available with http://localhost:5173/wp-content/themes/footmate/@vite/client.

We need to reflect this change in the WordPress config and everything starts to work fine. I’m not sure if I missed something earlier, but with Vite 4, it is available directly at localhost. Can you let me know in the comments how it worked in your cases?

#4 Exit Code 1 with yarn

I couldn’t find any references to this issue too, but after the upgrade, I noticed that I no longer encounter errors when terminating the development process with cmd + c command. This issue might also be related to yarn itself, although I’m uncertain. Anyway, I’m glad that it functions fine now.

And that's all! I'm glad that there was no ready-to-use solution to my problem because I learned something new, and that's one of the most important aspects for me 🤌 I hope you enjoyed spending time with me and learnt something that will be useful for solving your future problems with your development process too. Please remember that all the changes we've made are available within the public GitHub repository.