The Gradle™ Way to include javaScript client projects in JVM apps

An approach that I’ve recently found that I seem to like is here:

The main setup:

1. There’s a shared multiplatform project that outputs both .jar for the server and .js for the frontend.
2. A frontend project is just a straight browser SPA project - as in, it builds a single UI page for right now. I could see this being broken down into different webpack builds.
3. A backend project is just a Spring Boot project.

The main trick is that the backend uses processResources to grab the output of the frontend project.

	processResources {
		dependsOn(":frontend:browserWebpack")
		from(project(":frontend").projectDir.resolve("src/main/resources")) {
			into("static")
		}
		from(project(":frontend").buildDir.resolve("libs/spring-kotlin-fullstack-frontend.js"))  {
			into("static")
		}
	}

So here’s just an example of deploying the SPA as part of a Spring Boot project, as an “embedded resource”. Which, to be honest, isn’t always what you want to do, but, can be handy for quick and dirty internal project things.

What I like is that the real edit and debug cycle is provided solely within the frontend project. You don’t launch it within the backend really, until you’re doing integrated testing. There’s a task called :frontend:run that actually launches a special webpack dev server. This is slick.

This is where my earlier approach kind of failed, I was not really separating the javaScript frontend platform bits from the JVM backend bits. Really, it’s just a dependency that happens to deploy as resources. So processResources makes sense - but only for the final build. Otherwise, you probably want fancy webpack edit/debug cycle.