Polymer 3 support

[johndevs]

Due to the major re-writes in the Flow framework client side (https://github.com/vaadin/flow/issues/4561) from Webjars to NPM, the plugin will need to rewrite the handling of the client side dependencies.

The following major points need to be implemented:

• [x] Use annotation scanning instead of directory scanning to find HTML dependencies in production mode
• [x] Automatically add dependencies marked with @NpmPackage to vaadinClientDependencies
• [x] Support @JsModule
• [x] Implement main.js generation (https://github.com/vaadin/flow/issues/5339)
• [x] Support @CssImport
• [x] Add documentation to documentation site

[flefebure]

Hi, We have started a multi-modules Gradle project migration, from Vaadin 7 to 14 (huge jump) I have built the "gradle-vaadin-flow" plugin with your latest sources. Node tasks seem OK but I have a problem with the TranspileDependencies task.

We have custom Flow components annotated with @JsModule eg : @JsModule("./styles/shared-style.js") This resource is in projectRoot/frontend/

"TranspileDependenciesTask.removeInvalidModules" method fails on the File nodeDependency = Paths... line (Could not get unknown property 'canonicalPath' for task ':softbridge-viewer-v5:vaadinTranspileDependencies' of type com.devsoap.vaadinflow.tasks.TranspileDependenciesTask)

For testing purpose, I've removed our custom @JsModule in this case removeInvalidModules fails for the first Vaadin Polymer widget @vaadin/vaadin-accordion/src/vaadin-accordion.js

Plugin conf is : vaadin { version '14' compatibilityMode false } Can you guide us ? We are ready to participate

EDIT : exception about canonicalPath is fixed with :

-            File nodeDependency = Paths.get(appNodeModules.canonicalPath, m.split(SLASH)).toFile()
+            File nodeDependency = Paths.get(appNodeModules.call().canonicalPath, m.split(SLASH)).toFile()

Now I'm analysing Spring Boot issues and I'm not sure that our custom JsModule are correctly handled. I keep in touch

[johndevs]

Hi @flefebure ,

The support for JS modules and Polymer 3 is not nearly complete in master branch, there are still plenty of things that does not work.

Here is what currently works in master branch:

• Gathering @JsModule imports and combining them into a bundle file
• Npm package resolution with Yarn
• Webpack bundling
• Running the Vaadin 14 app with jettyRun without compatibility mode

And here is a non-comprehensive list of what is currently not working:

• No development mode is implemented (You have to run with vaadin.productionMode=true to get the node modules)
• ~Base theme (Lumo/Material) support is missing (@CSSImport works, but apparently Vaadin has decided not to use that for theming, no idea why)~
• Only tested on Linux (Windows/OSX fully untested and might not even work at this stage)
• Spring Boot support has not been tested and most likely will not work
• War/Jar packaging has not been verified to work
• No good error messages for Vaadin 10-13 projects has been added to help migration
• No documentation is available yet

My optimistic view is that we should have support for this by the end of the year, maybe some preview version a bit sooner than that. However, I can't really recommend doing anything for production with the plugin before most of the above listed things have been done.

[flefebure]

Hi @johndevs Thanks for the info FYI : https://github.com/vaadin/flow/issues/6306 FMI : your plugin project (I didn't dive in it very deeply) seems to have a structure a bit different of the Maven official plugin. Was not it straighter to structure it like a port of the Maven plugin (prepare-fontend and build-frontend tasks) ?

[johndevs]

@flefebure

The Gradle plugin follows the same concepts on a high level as the Maven plugin to certain a degree. However it cannot be one-to-one as Gradle works a bit different than Maven and the plugin needs to be structured in a way that best takes Gradle's features into use.

When it comes to project structure Vaadin likes to move around files more with the Maven plugin while I try to keep the Gradle plugin more stable and backwards compatible for longer periods of time. This usually means that the plugin will not support "new" features immediately but will make the upgrade process a bit nicer than the Maven plugin. For some people a stable upgrade path is more important than latest features, others might be willing to rewrite the whole project to get the new features. Unfortunately you cannot please everybody :)