Skip to content

Create production-package.zip earlier in the process #5691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 17 additions & 29 deletions rewrite-javascript/build.gradle.kts
Original file line number Diff line number Diff line change
Expand Up @@ -157,54 +157,42 @@ val npmInstallTemp = tasks.register<NpmTask>("npmInstallTemp") {
val tempInstallDir = layout.buildDirectory.file("tmp/npmInstall")
inputs.files(npmPack)
.withPathSensitivity(PathSensitivity.RELATIVE)
outputs.dir(tempInstallDir)
dependsOn(npmInitTemp)

// Use a provider to defer evaluation until execution time
args = provider { listOf("install", npmPack.get().archiveFile.get().asFile.absolutePath, "--omit=dev") }
workingDir.set(tempInstallDir)
}

sourceSets {
main {
resources {
srcDir("src/main/generated-resources")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

callout: Should always avoid writing to the project directory as it can result in triggering tasks to run unnecessarily.

}
}
}

afterEvaluate {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

callout: Avoid afterEvaluate

tasks.named("licenseMain") {
dependsOn(createProductionPackage)
}
}

tasks.named<Jar>("sourcesJar") {
dependsOn("createProductionPackage")
exclude("production-package.zip")
}

tasks.named("processResources") {
dependsOn(createProductionPackage)
}

// Creates a production-ready package; writing it to `src/main/generated-resources` so that it will be included by IDEA
val createProductionPackage by tasks.register<Zip>("createProductionPackage") {
// Configure the tar output
archiveFileName.set("production-package.zip")
destinationDirectory.set(layout.projectDirectory.dir("src/main/generated-resources"))
destinationDirectory.set(layout.buildDirectory.dir("generated/resources/distributions/"))

dependsOn(npmInstallTemp)

// Reference the actual directory where npm packages are installed
from(layout.buildDirectory.dir("tmp/npmInstall")) {
from(npmInstallTemp) {
// Optionally exclude unnecessary files like package-lock.json, etc.
// exclude("package-lock.json", ".npmrc")
}
}

// Include production-ready package into jar
tasks.named<Jar>("jar") {
sourceSets {
main {
resources {
srcDir(createProductionPackage.destinationDirectory)
}
}
}

tasks.named<Jar>("sourcesJar") {
from(createProductionPackage)
exclude("production-package.zip")
}

tasks.named<ProcessResources>("processResources") {
dependsOn(createProductionPackage)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

callout: All of this is really a hack to make the IDE work correctly. The production-package.zip is a generated resource that would normally be included into the binary jar itself. Unfortunately, since IDEA doesn't generate the jar, but rather uses the raw classes and resources, we're stuck with forcing the production-package.zip to be generated earlier in the process than would typically be necessary, including it as a main resource for IDE support, and then having to filter it out of other tasks for which we don't want the generated binary to be included for.

Overall, not ideal by any means.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can probably get rid of the hack and just require any IDE tests to specify the path to the dist dir of the project when setting up RPC. I think that is acceptable.


tasks.named("integrationTest") {
Expand Down
3 changes: 1 addition & 2 deletions rewrite-javascript/rewrite/tsconfig.build.json
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,6 @@
"removeComments": true
},
"include": [
"src/**/*",
"test/**/*"
"src/**/*"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

callout: the tsc compiler isn't very smart, so what this was resulting in is the test/** sources being built twice which isn't desirable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd still need some more refactoring to get rid of this. The problem is that some integration tests fail without this. The tests aren't executed on CI, so I can also fix this afterwards.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a clarification, but as in the Java integration tests?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. They depend on a JS recipe which is in test. I will try to fix that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, so how would you feel about adding an NPM script to compile tests separate from the test and ci:test phases. Then we can wire a dependency from integrationTest to this new task. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we can take this thought a step further by using the jvm-test-suite plugin instead of the Nebula IntegTest plugin. With the jvm-test-suite plugin, we would be declaring a dependency upon the production outgoing artifacts which would result in the jar being built and more closely aligning the integration tests with what the real runtime environment would look like.

]
}
Loading