I’ve noticed that my flow application is failing to launch in dev-mode. Normally I compile and run using production mode, so I’m not sure when this started happening, but what I observe is something like the following:
2025-02-10T13:37:26,107 ERROR AvokeVaadinServletService.java:56 - Handling service exception
com.vaadin.flow.server.ServiceException: java.lang.IllegalStateException:
Failed to find the following css files in the `node_modules` or `/Users/mthome/rep/foo/browser/frontend` directory tree:
- ./styles/twincol-grid.css
- ./styles/twin-col-grid-button.css
- ./styles/multiselect-cb-hide.css
Check that they exist or are installed. If you use a custom directory for your resource files instead of the default `frontend` folder then make sure it's correctly configured (e.g. set 'vaadin.frontend.frontend.folder' property)
The first two of these “missing” css files happen to be from the flowing code twincolgrid add-on: The add-on definitely has the css files in its jar file, production mode has no similar problem, and manually adding css files to the directory it suggests doesn’t help.
This issues sounds related to GitHub · Where software is built but I thought I’d hold off reporting it without checking here first.
FWIW, I’m using Vaadin Flow 24.3.20, Spring Boot 3.4.2, Java 17, Gradle 8.7.
Well I’m using gradle, but, ./gradlew clean vaadinClean ; ./gradlew assemble then running will give me a few seconds of “building front-end development bundle” before getting the hard error:
2025-02-10T20:06:32,026 INFO FrameworkServlet.java:554 - Completed initialization in 1 ms
// I opened the web app here.
2025-02-10T20:06:38,735 INFO TaskRunNpmInstall.java:339 - Frontend dependencies resolved successfully.
2025-02-10T20:06:40,855 INFO TaskCopyFrontendFiles.java:65 - Copying frontend resources from jar files ...
2025-02-10T20:06:40,867 INFO TaskCopyFrontendFiles.java:114 - Visited 0 resources. Took 12 ms.
2025-02-10T20:06:41,113 ERROR DefaultErrorHandler.java:105 -
java.lang.IllegalStateException:
Failed to find the following css files in the `node_modules` or `/Users/mthome/rep/acjpa/browser/frontend` directory tree:
- ./styles/twincol-grid.css
- ./styles/twin-col-grid-button.css
- ./styles/multiselect-cb-hide.css
Check that they exist or are installed. If you use a custom directory for your resource files instead of the default `frontend` folder then make sure it's correctly configured (e.g. set 'vaadin.frontend.frontend.folder' property)
at com.vaadin.flow.server.frontend.AbstractUpdateImports.getCssLines(AbstractUpdateImports.java:492) ~[flow-server-24.3.21.jar!/:24.3.21]
at com.vaadin.flow.server.frontend.AbstractUpdateImports.process(AbstractUpdateImports.java:366) ~[flow-server-24.3.21.jar!/:24.3.21]
at com.vaadin.flow.server.frontend.AbstractUpdateImports.run(AbstractUpdateImports.java:153) ~[flow-server-24.3.21.jar!/:24.3.21]
at com.vaadin.flow.server.frontend.TaskUpdateImports.execute(TaskUpdateImports.java:75) ~[flow-server-24.3.21.jar!/:24.3.21]
at com.vaadin.flow.server.frontend.NodeTasks.execute(NodeTasks.java:342) ~[flow-server-24.3.21.jar!/:24.3.21]
at com.vaadin.base.devserver.startup.DevModeInitializer.runNodeTasks(DevModeInitializer.java:354) ~[vaadin-dev-server-24.3.21.jar!/:?]
at com.vaadin.base.devserver.startup.DevModeInitializer.lambda$initDevModeHandler$0(DevModeInitializer.java:295) ~[vaadin-dev-server-24.3.21.jar!/:?]
Interestingly though, it looks like the problem was that I had a spring property setting vaadin.original.frontend.resources=true that somehow wasn’t causing as much of a problem prior to 24.3.
frontend vs src/main/frontend: In my 24.3 (and prior) I used just frontend. In trying out 24.4+, I moved my frontend stuff to src/main/frontend. I will note that the current version of twincolgrid (2.9.5) seems to use frontend/
Vaadin Versions: 24.3.20 → 24.6.5 (trying various versions in between) show this same behavior. Note that I have other issues with 24.4+ but I don’t get that far in dev mode.
multiselect-cb-hide.css: I don’t know where this is coming from - it isn’t referenced in my code anywhere and I haven’t yet found it any of my dependencies.
vaadin.whitelisted-packages, yes though for 24.3 I converted to vaadin.allowed-packages. Twincolgrid seems to use whitelisted-packages, so maybe that’s what’s going on?
Edit: I added the twincolgrid package name to my own vaadin.allowed-packages but nothing changed.
Gradle assemble builds the artifacts without running regression tests - similar to mvn install except without the copying artifacts to the local repository. It is dead simple, works fine in production mode, and has worked properly since Vaadin 7 (at least).
A similar launch of a vaadin 23 dev mode build with the same gradle invocation also reports at the reports “visited 0 resources” at the same point, but works completely correctly:
2025-02-11T18:23:07,443 INFO TaskRunNpmInstall.java:202 - Skipping `npm install` because the frontend packages are already installed in the folder '/Users/mthome/rep/x/browser/node_modules' and the hash in the file '/Users/mthome/rep/x/browser/node_modules/.vaadin/vaadin.json' is the same as in 'package.json'
2025-02-11T18:23:07,443 INFO TaskCopyFrontendFiles.java:66 - Copying frontend resources from jar files ...
2025-02-11T18:23:07,444 INFO TaskCopyFrontendFiles.java:91 - Visited 0 resources. Took 0 ms.
For me, it fails with the same error also with Vaadin 23.
BTW, if I recall correctly, running in development mode from a Spring Boot fat JAR is not a supported scenario, because of how dependencies are packaged into the final artifact.
Also, starting with Spring Boot 3.2 they introduced the Nested Jar Support with the jar:nested URL protocol.
May I ask you what the reason to run in development mode from a fat JAR?
If you don’t want to start the application from the IDE, wouldn’t be gradle bootRun a valid option?
Mostly because it’s just been how I’ve been running it for a decade. I’m always surprised when such basic functionality stops working. Since my project has a number of nested projects with separate artifacts, I need to do ./gradlew :submodule:bootRun… That does seem to work at least.