About dev.bundle and prod.bundle

(first post here in the new forum :wave:)

Hi,

It is my understanding that dev.bundle is a file that can be committed into git. However it is not clear what makes the dev.bundle change ? It appears that each time i remove it and regenerate it, a different binary file is generated even though no code changes were made.

Same for the prod bundle. We had an issue in the pipeline where the pages looked all distorted. Problem was fixed when i regenerated the prod bundle. I assumed it was because someone added a bit of css in the theme and did not regenerate the prod bundle?

So, at what point should we regenerate these bundles? Is it css changes? Is it the addition of an add-on ? The vaadin build does not seem to know exactly either sometimes, and only by forcing a regenerate will things work again. This makes me believe that we should not push the prod.bundle into git, and the build pipeline generate it each time. All devs work in development mode anyway with hot reload.

How are other teams handling these bundles?

Thanks,
Jorg

It is “something that forces the front-end build to be triggered”. Those bundles are essentially cached output of Vite build that Vaadin does for your. I have now learned to avoid that pretty long some I’m happy :-)

Note that it is optional to commit those. By committing them you can avoid front-end build your self on “clean install” and you colleage might survive even completely without triggering Vite build or event toolchain installation.

And then the answer what triggers re-build (might not be complete list):

  • Vaadin version update
  • Touching stuff that is optimized into the front-end bunde
    • Doing somethign with LitTemplates
    • Adding Javascript with @JsModule or @Javascript (in some cases). Note, that with “context://foobar.js” you can bypass the bundle. I try to use that with most add-ons these days. Although a bit less optimal for front-end bundle, much nicer as front-end generation can be avoided altogether.
    • @CssImport (trick: use @Stylesheet & context:// → no front-end build even if CSS changed)
  • Updated/addition/removel of an add-on, that contains clien-bundle extensions (like the ones above)
1 Like

Thanks Matti, that helps a bit though these bundles still remain a mysterious.

Since the bundle generation has been an issue every now and then, i think we will just remove them from git alltogether. We don’t have any customized stuff, just a few add-ons (viritin for example :-) and a couple of css files. And with hot code reload, server restarts are quite rare so that’s not an issue either.

If you don’t need the bundles (I don’t use them) you can disable them:

development configuration


<configuration>
  <frontendHotdeploy>true</frontendHotdeploy>
</configuration>

production configuration


<configuration>
    <forceProductionBuild>true</forceProductionBuild>
</configuration>

Well, how do i know if i need the bundles or not? These things are a mystery to us :thinking: I’ld be glad to not generate them if you say we don’t need to. I thought these were an essential part of a Vaadin application.

They are optional and are meant to enhance the productivity for easier on boarding, less tooling and probably faster start ups in development mode (no vite running) if you restart your application often while developing java only (without much styling changes)

Because of their nature to pre-compile everything once, it allows typical flow developers to start / develop their application without worrying about the Javascript stuff and share that even with colleagues without proper tooling installed.

More information can be found here Development Mode | Configuration | Vaadin Docs

Edit: Acceptance Criteria of the Features:

1 Like

For production bundle, I would not add it on git since you need to build it only in production mode. I would always let the CI build it. Most of the time you don’t need it in your machine.

For the bundle in development, if you are doing a lot of changes in your javascript files or in the pom.xml. That won’t help you since it will always be rebuilt (or should be).

If you are changing only Java code or CSS, then the development bundle will reduce the start time. Especially for the first time (no node_modules, nothing to download) so that’s really nice for people who are developing on the application once a week.

Normally it should automatically detect any changes and you shouldn’t have an outdated dev bundle. There might be some issues (for example if you remove an addon I don’t know if the devbundle is refreshed).

So my normal setup is:

  • use the devbundle
  • when something looks completely wrong, run mvn clean vaadin:clean-frontend

I don’t need that much the second step.

Thanks for the insights, i’m going to adapt our strategy accordingly.

It would indeed be really nice if the tooling would tell more why a front-end bundle is needed (in the first place or re-building). Then more people could get rid of both the bundles and the front-end build. I was recently trying to figure out why that was happening in one of my own projects and the reason was one CssImport that was (thanks to recent theme improvements) now possible to replace with StyleSheet.