82 lines
3.5 KiB
Plaintext
82 lines
3.5 KiB
Plaintext
---
|
|
title: Vite
|
|
label: Vite
|
|
order: 90
|
|
desc: NEEDS TO BE WRITTEN
|
|
---
|
|
|
|
Payload has a Vite bundler that you can install and bundle the Admin Panel with. This is an alternative to the [Webpack](/docs/admin/webpack) bundler and might give some performance boosts to your development workflow.
|
|
|
|
To use Vite as your bundler, first you need to install the package:
|
|
|
|
```bash
|
|
yarn add @payloadcms/bundler-vite
|
|
```
|
|
|
|
<Banner>
|
|
The Vite bundler is currently in beta. If you would like to help us test this package, we'd love to hear if you find any bugs or issues!
|
|
</Banner>
|
|
|
|
Vite works fundamentally differently than Webpack. In development mode, it will first pre-bundle any of your dependencies that are CommonJS-only, and then it'll leverage ESM directly in your browser for a better HMR experience.
|
|
|
|
It then uses Rollup to create production builds of your admin UI. With Vite, you should see a decent performance boost—especially after your first cold start. However, that first cold start might take a few more seconds.
|
|
|
|
<Banner type="warning">
|
|
In most cases, Vite should work out of the box. But existing Payload plugins may need to make compatibility changes to support Vite.
|
|
</Banner>
|
|
|
|
This is because Vite aliases work fundamentally differently than Webpack aliases, and Payload relies on aliasing server-only code out of the Payload config to ensure that the bundled admin JS works within your browser.
|
|
|
|
Here are the main differences between how Vite aliases work and how Webpack aliases work.
|
|
|
|
**Vite aliases do not work with absolute paths.**
|
|
|
|
In Vite, an alias will only match if the `find` property _exactly matches_ how you are importing your server-only file. So if you are importing a file with a relative path, i.e. `'../../my-module'`, and your alias is absolute, your alias will not work.
|
|
|
|
|
|
**Vite aliases do not get applied to pre-bundled dependencies.**
|
|
|
|
This especially affects plugins, as plugins will be pre-bundled by Vite using `esbuild`. To get around this and support Vite, plugin authors need to configure an alias to their plugin at the top level, so that the alias will work accordingly.
|
|
|
|
Here's an example. Say your plugin is called `payload-plugin-cool`. It's imported as follows:
|
|
|
|
```ts
|
|
import { myCoolPlugin } from 'payload-plugin-cool'
|
|
```
|
|
|
|
That plugin should create an alias to support Vite as follows:
|
|
|
|
```ts
|
|
{
|
|
// aliases go here
|
|
'payload-plugin-cool': path.resolve(__dirname, './my-admin-plugin.js')
|
|
}
|
|
|
|
```
|
|
|
|
This will effectively alias the entire plugin and work with Vite. If the plugin requires admin-specific code, then the `./my-admin-plugin.js` alias target file should reflect any changes necessary to the admin UI that the main server-side plugin performs.
|
|
|
|
### Extending the Vite config
|
|
|
|
The Payload config supports a new property for plugins to be able to extend the Vite config specifically. That property exists on the main Payload config under `admin.vite`.
|
|
|
|
It's a function that takes a Vite config, and returns an updated Vite config. Here's an example:
|
|
|
|
```ts
|
|
export const buildConfig({
|
|
collections: [],
|
|
admin: {
|
|
vite: (incomingViteConfig) => ({
|
|
...incomingViteConfig,
|
|
resolve: {
|
|
...incomingViteConfig.resolve,
|
|
// Do whatever you need here
|
|
}
|
|
})
|
|
}
|
|
})
|
|
```
|
|
|
|
Even though there is a new property for Vite configs specifically, we have implemented some "compatibility" between Webpack and Vite out-of-the-box.
|
|
|
|
If your config specifies Webpack aliases, we attempt to leverage them automatically within the Vite config. They are merged into the Vite alias configuration seamlessly and may work out-of-the-box. |