Vaadin components no longer render after update to 14.1.27

I currently have about 18 different views in the application I’m developing. I decided to update from Vaadin 14.1.18 to 14.1.27 when I added the newest view. After the update, I noticed the login page wasn’t rendering correctly. I tried a mvn clean install which didn’t help. I reverted to 14.1.18 which also didn’t help. I’ve tried deleting target, node_modules, package.json, and package-lock.json which also didn’t help.

I’ve attached a couple of the page views to illustrate what I mean by not rendering correctly. It looks like that only thing rendering on the page is the text that’s the label for some of the components. The first screenshot is the login page. Sign In, Forgot Password, and New User are the labels on the 3 buttons on that page. The labels for the username and password TextFields don’t get rendered. And, of course, nothing else gets rendered either.

About 50 min after I started the app, I got the following message in the terminal which is something I’ve never seen before. Other than that 1 message, there’s no indication that anything has gone wrong. No other warnings or errors.

2020-05-02 22:01:55.725  WARN 760 --- [alina-utility-2]
 com.vaadin.flow.server.VaadinSession     : A VaadinSession instance not associated to any service is getting unbound. Session destroy events will not be fired and UIs in the session will not get detached. This might happen if a session is deserialized but never used before it expires.

Please tell me someone at Vaadin understands what’s happening. I can’t do any development with Vaadin not working at all.



The error is related to this add-on: Full calendar

As a workaround, you can add @NpmPackage(value = “moment”, version = “2.24.0”) on the route where you are using the calendar or on the main Route Layout.
This will use the exact version of moment (the add-on uses ^2.24.0 and 2.25.x seems broken and was upgraded 3 days ago).

Here the error:

Can you attach the full log output for a clean build.
If you have the package-lock for a functional build stored having the diff against the new non working package-lock could give some insight in if some transitive dependency has updated to a broken version suddenly.

  • Mikael

My workaround, also requires to clean package-lock.json and target folder.

The other problem is that there is priority for the annotations (the workaround annotation and the component annotation). So it may not solve the problem.

Your workaround worked. Thanks! I would never have figured that out.

I didn’t have package-lock under version control, so there was no working version to compare against. Fortunately, Jean-Christophe’s workaround works for both 14.1.18 and 14.1.27 which means I can develop again :slight_smile: Thanks!