Knoobie

> Did you investigate if excluding the react stuff makes a difference for the artifact size or does it only add extra client side dependencies to look after? I haven't...

> There are very good reasons (performance, build time, artifact/fron-end weight, security) to trim down your projects/builds to minimum, and now that gets more complicated than it'd need to. >...

Yes, that's why I'm excluding the react-components -> reduce SBOMs; which we have to publish in our internal artifactory for our security guys. (I have developed a custom maven plugin...

Probably off topic; just saying: In my opinion it's wrong to have everything in com.vaadin:vaadin - as example: spring boot also does not have everything in a single dependency. You...

"Simplified" version of a spontaneous suggestion: - com.vaadin:vaadin - the big ball of everything (not sure who needs it) - com.vaadin:vaadin-spring-boot-starter - com.vaadin:vaadin-flow-spring-boot-starter - com.vaadin:vaadin-hilla-spring-boot-starter - com.vaadin:vaadin-flow-spring-boot-starter - com.vaadin:vaadin-flow (includes...

> Would this seem like a good vision for the future? I would prefer this, but I'm probably not seeing the whole picture you guys are planning for the next...

> You know how sometimes the plugin's version is sometimes behind Vaadin Platform's. That sounds like a bug in your build. Both should always be the same.

Since 2x where the Gradle plugin was officially adopted, this shouldn't be a problem anymore. Now the release process looks simplified like this: 1. Flow including Spring, Maven and Gradle...

*thumbs up for the connector idea* This would allow the usage of `AbstractSinglePropertyField` and other important classes without cluttering the public interface.

See here https://github.com/vaadin/flow/pull/18680#discussion_r1507403653 why it's done like this