Deploying a Custom Component Plugin
Authors:
Cameron Johns, Cille Schliebitz, Anita Gu
Changed on:
3 Feb 2025
Overview
This lesson covers the deployment process for custom component plugins. Unlike server-side plugins, component plugins are frontend JavaScript bundles that can be hosted on any web server. We'll explore the key steps involved in preparing your plugin for production, including versioning, bundling, and deployment, and how to reference the deployed plugin in the manifest document.
Key points
- Frontend Deployment: Custom component plugins are deployed as frontend JavaScript bundles, simplifying the deployment process compared to server-side plugins.
- Versioning: Versioning the bundle.js file (e.g., using Webpack's contenthash) is crucial for cache busting and ensuring updates are immediately reflected.
- Bundling with Yarn: The yarn run bundle command is used to create the production-ready bundle, which is placed in the dist folder.
- Web Hosting: The contents of the dist folder can be deployed to any web host.
- Manifest Reference: The deployed plugin is referenced in the manifest document via its URL.
- Multiple Plugins: Multiple plugins for a single project can be deployed to a single folder, with the folder path used in the manifest.
Unlike the OMX Workflow Framework where custom Rules plugins are required to be uploaded and activated within the Fluent platform, custom Component plugins are simple frontend javascript bundles that can be hosted on any web server, and referenced through the manifest document via URL.
There are a few things you should do when preparing to deploy your production ready plugin to your web host:
- Versioning
- Bundle
- Deploy
- Add your plugin reference to the Manifest document
Since browsers cache files, versioning of the
`bundle.js`
`contenthash`
Once you've configured your package.json file with plugin versioning, you can use
`yarn run bundle`
`dist`
To see more about how to version your plugins, go to Component SDK > Plugin Versioning.