Flow: In production mode, I would like to be able to use transpiled sources without bundling.

[SomeoneToIgnore]

Get https://github.com/vaadin/flow-demo/tree/master/demo-jquery-table project.

It downloads and transpiles resources without flow-maven-plugin.
Try to launch Jetty for this project in production mode and open the page.

Expected: the page opens.
Actual: an exception is thrown

The same situation will happen if bundling is disabled for any flow-maven-plugin usages.

This happens because of:
https://github.com/vaadin/flow/blob/3459055b2d6e4167d69f9ebb0dc94361d6fbce05/flow-server/src/main/java/com/vaadin/flow/server/startup/BundleFilterInitializer.java#L76

Need to allow using Flow when bundle is not found, just log a warning instead.

[Legioth]

Why aren't you doing like it says in that exception message: If explicitly want to do non-standard stuff, then you can set the original.frontend.resources parameter to true so that Flow will use whatever is in the appropriate frontend directory instead of trying to look for a bundle manifest?

[SomeoneToIgnore]

How am I supposed to get files from frontend-es5 directory then?

[Legioth]

Maybe we need an alternative parameter (or an alternative value for the same parameter) for that case.

The point is still that instead of silently disabling features in a way that is hard to debug, we provide explicit feedback so that the user can know how to fix things.

[paulroemer]

To sum it up: I agree, that not having bundling enabled will have a major impact on the application performance. It will not break it but it might confuse the developer that much that she assumes Vaadin is slow.
I would still vote for a simple warning instead of preventing the application to start but that is up to you. What I really need is an additional param telling Flow that all is fine to prevent the exception/warning.

[Artur-]

Just for the record: Why would you want to run an app in production without bundling?

[SomeoneToIgnore]

1. When you're using something else but flow-maven-plugin to bundle things as in https://github.com/vaadin/flow-demo/tree/master/demo-jquery-table
2. When you just start trying Flow and don't use anything but Flow as in https://github.com/vaadin/flow-demo/tree/master/demo-date-field
3. When you're fine with WebJars' performance
4. When you're investigating stuff in production mode, for instance, change the scripts etc.
5. Because you want to

[SomeoneToIgnore]

https://github.com/vaadin/flow/issues/4168

One more thumbs up for non-mandatory bundle manifest.

[johndevs]

@Artur- @Legioth If you are going to require people to use proprietary formatted files like the bundle manifest then please also document the specifics of how to generate the file.

It is not enough that one build tool can generate the file, users need to know how the file can be generated outside of using Maven as well. Currently it is a black box.

Until then I think the manifest should be optional.

[Legioth]

That manifest is required for efficient production usage. You can opt out from using it by setting the property mentioned in the error message if you're fine with bad loading performance on high-latency networks or if you handle bundling in some other way. But in that case, why do you use production mode at all?

I agree that it would be great if there would be documentation of the format, but for now you'd probably have to reverse engineer it.

[Legioth]

You can probably work around the limitation also by including an empty manfiest file (or maybe make it an empty JSON object, i.e. {}).

[johndevs]

The setting that the error message states is not a workable solution.

If I disable production mode I can't support older browsers (a must) and the other jetty specific configuration is not relevant, if I turn production mode on I most likely will not be deploying to Jetty, but to another server altogether (exception being Spring Boot, but also in that case you might be using Tomcat instead). Assuming everybody is using embedded jetty in production is not a valid assumption.

Besides, if I can work around the issue with an empty json file then why require the json file at all. Can't the framework then instead of throwing an exception instead generate the empty content if the file is missing and leave it to the user to decide if he wants the benefits of bundling or not? That is why polymer.json has the option to bundle or not, it is not something the framework should dictate.

[paulroemer]

Just for the records: Working around the issue with an empty JSON object is proved to work.

[oluwasayo]

I stumbled on this while debugging an application bug that only shows up after bundling (not minification but specifically bundling). So I want to debug my app transpiled but not bundled in IE11 and I'm unable to do that easily.

Personally I don't see the point of Flow preventing me to use this legit Flow Maven Plugin configuration (<bundle>false</bundle>). Why have this configuration at all when it's suggested by my IDE but unusable?

Additionally, I don't agree with the performance considerations here. It's my business if I don't want bundling performance, not Flow's. When I set <bundle>false</bundle> I knew exactly what I was doing. I also don't want to create an empty JSON file that will get wiped by mvn clean or have one mistakenly committed to my project sources, making all my builds unnecessarily slow.

[Legioth]

The performance consideration is not that we should make it impossible to cause bad performance, but rather to reduce the risk of causing bad performance by accident.

Completely leaving out vaadin-maven-plugin from your build is probably an accident, and should therefore IMHO trigger the current cautionary error that can be disabled by setting the property that acknowledges that omitted production building is intentional.

Adding <bundle>false</bundle> to your pom.xml is probably not done by accident. It should therefore IMHO, not cause the application to fail. This is extra relevant since the property to avoid the error also makes Flow ignore the transpiled files, which is the opposite of what you'd want.

Based on this, I'd suggest we update the production build setup so that <bundle>false</bundle> causes a dummy bundle manifest to be generated.