Vaadin 12 Production Mode breaks Material Theme

[evmatt]

When a production build of a Vaadin 12 application is made the material theme does not appear to be included in the WAR. When navigating to the application (any browser) the deployed application uses many Lumo CSS variables rather than the expected Material CSS variables. In the 'Network' developer tools tab 404 errors can be seen for the files frontend/bower_components/vaadin-material-styles/color.html and frontend/bower_components/vaadin-material-styles/typography.html.

In the project target/frontend/bower_components/vaadin-material-styles folder multiple files and an icons/ and mixins/ folder can be seen. These files include color.html and typography.html, among others. There are a number of HTML files in the mixins/ folder. However, when inspecting the frontend-es6/bower_components/vaadin-material-styles inside the WAR artifact almost all of these files are missing, the same goes for frontend-es5/. The only file in the folder is magi-p3-post.json. color.html and typography.html are among the missing files. The icons/ and mixins/ folders are present, but mixins/ is empty. I would expect that all of the files in frontend/bower_components/vaadin-material-styles/ would be included in the frontend-es6/ and frontend-es5/ folders when the project is built.

This has been observed when using Vaadin 12.0.0 and Java 1.8.

[pleku]

This is slightly related to https://github.com/vaadin/flow/issues/4944 but then again, this is not even that far.

I was able to test the bookstore starter in production mode with material theme yesterday. I was running jetty:run-exploded with production mode enabled. The issue there was that Material theme is not working with IE11.

@evmatt can you please provide an application that reproduces the issue ?

[evmatt]

I see. Is it likely that the fix for #4944 will also fix this? This issue was observed in Chrome, so I didn't see it as being the same transpilation-related issue. I apologise if I've raised an identical issue in that case.

I can't provide the application this issue was discovered with as it is a closed-source proprietary application. I attempted to replicate the issue in the Beverage Buddy App starter running production mode and the material theme. I changed the shared-styles.html to import the material theme color.html and typography.html as we have done in our application:

<link rel="import" href="../bower_components/vaadin-material-styles/color.html">
<link rel="import" href="../bower_components/vaadin-material-styles/typography.html">

Unfortunately I could not replicate the issue we are seeing. I did notice that when building the application starter a frontend/ folder was packaged in the WAR in addition to the frontend-es6/ and frontend-es5/ folders. It appears that for some reason this frontend/ folder is not included in the WAR during our build process.

In the 'Network' tab I can see that 404 errors are occurring because color.html and typography.html are being requested from themes/frontend/bower_components/vaadin-material-styles/typography.html rather than themes/frontend-es6/bower_components/vaadin-material-styles/typography.html as I would expect. It appears that the routing to the correct frontend folder is not occurring.

[pleku]

I changed the shared-styles.html to import the material theme color.html and typography.html as we have done in our application:

Instead of doing this, could you please use the @Material theme for the root layout since that is going to import the same things to the project. I think the imports you have in the template are probably the reason why it is not working.

[evmatt]

We have used the @Theme(Material.class) annotation on our root view to activate the Material theme. I have now removed those imports from shared-styles.html. We had thought these imports were necessary when using custom styles in shared-styles.html on top of Material due to the information on the theme website, this shared-styles.html is loaded in our root view using @HtmlImport. This has fixed the issue we were seeing with 404 errors on color.html and typography.html. However, the styling of the application still does not display correctly when viewed in production mode. After removing those HTML imports the same error now appears in dev mode, which did not occur previously.

I am also seeing an issue where the browser fails to load sw.js. I am unsure if this is connected. The specific error shown in the 'Network' tab is (failed) net::ERR_INVALID_RESPONSE.

[pleku]

Both colors.html and typography.html are included automatically by Flow when you've have added the material theme import in Java. Those are also included in the bundle file for production time.

Can you see from the chrome inspector if some Lumo styles are applied? You could try to exclude the vaadin-lumo-theme dependency to see if that is for some reason used and breaking things.

Sorry but I'm not sure what are you referring to with the errors, and it is quite difficult to find out what is the issue without being able to run the code.

[evmatt]

There are Lumo styles are being applied. After adding vaadin-lumo-theme as an exclusion under vaadin-core in the pom.xml I can see that Lumo styles are still being applied.

Using mvn dependency:tree I could see that there was a vaadin-lumo-styles WebJar dependency as well. I tried to add an exclusion for this, but doing that caused the build to fail on the gulp build_es6 task.

[pleku]

There are Lumo styles are being applied. After adding vaadin-lumo-theme as an exclusion under vaadin-core in the pom.xml I can see that Lumo styles are still being applied.

So something is importing the Lumo styles - if you don't have any Java or template file that has html imports for the Lumo frontend resources, those should never end up into the bundling process. And when you exclude the webjar and bundling fails, it is an indication that you have something in your project that is using/depending on Lumo. You should probably see 404s somewhere when running the app and the resources are not available.

Sorry, but until you can provide code that reproduces the issue, there is nothing that we can do. Until that I consider this an issue specific to your application. Please reopen the issue if you discover a root cause not dependent on your application and can also preferably provide the code to reproduce the issue.