Closed johndevs closed 4 years ago
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
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:
@JsModule
imports and combining them into a bundle filejettyRun
without compatibility modeAnd here is a non-comprehensive list of what is currently not working:
@CSSImport
works, but apparently Vaadin has decided not to use that for theming, no idea why)~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.
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) ?
@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 :)
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:
@NpmPackage
tovaadinClientDependencies
@JsModule