Having a good developer experience is the key to improve productivity, satisfaction and the impact of our work. In the frontend world, Hot Module Replacement is a way to significantly speed up development, let’s talk about how we can apply this technique with FE Client Extensions.

It is not required, but highly recommended that you read Saving Cloud (SaaS) resources for FE Client Extension , as it covers concepts that will help you understand this own post, and also share the same project configuration. And again, I’ll explain this considering a project bundling with vite.

HMR in a nutshell

Quoting webpack’s documentation, Hot Module Replacement (HMR):

It allows all kinds of modules to be updated at runtime without the need for a full refresh.

In a FE Client Extension development, it means we can keep our editor and browser at each others side, not needing to redeploy our CXs, just saving our source code files and see the update going on on the browser window. Isn’t it a huge improvement in our development experience?

So let’s analyze our CX and see how that will work.

Reviewing CX structure

Looking at what we generate as an output, and what we defined in our client-extension.yaml, this is what we have: for each CX, we point its respective URL to a bundled .js file. And this is the case for deploying it to production/production-like environments.

As I mentioned before, if you want to go deeper on all the details of this setup, read the post I mentioned at the top.

Now , think about it, if we want a CX, in PROD, pointing to a concrete bundled file, what would be the more flexible thing to point it to, in a flexible environment, like the local-dev one?

🥁🥁🥁🥁🥁

The client-extension.dev.yaml file

If you thought, “