CLOVIS
10/01/2023, 2:12 PMbuild/js/packages/<module-name>/
. However, Gradle refuses to execute it, because:
- Gradle detected a problem with the following location: '[…]/build/js/packages/example-simple'.
Reason: Task ':[…]' uses this output of task ':jsBrowserProductionWebpack' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
The task I'm creating does not do anything other than create a configuration file in that directory. In fact, it could just create the directory itself even if it didn't exist. There's no reason for that task to depend on :jsBrowserProductionWebpack
.
I guess if the Kotlin plugin exposed a task that creates the directory without doing anything else, I should depend on that one, but it doesn't seem so. How can I tell Gradle that these are truly unrelated?Alexander.Likhachev
10/01/2023, 10:55 PMOutputDirectory
as of a given task. That may break caching, up-to-date checks and the result depends on the execution order. That’s why you’re getting that message. Please describe your use case. Perhaps you could use some built-in ways to customise the result either you should consume the result of other tasks as input and create a modified copy that you will then use in your pipelineCLOVIS
10/02/2023, 7:53 AMvite.config.js
, tailwindcss.config.js
…). They need to be in the JS project's directory to be found by the build, which would be /build/js/packages/<project>
if I'm not mistaken.:copyCompiledFiles
that depends on :jsProductionExecutableCompileSync
. So far, so good, these are in fact the files I want to get.
Except, Gradle considers that directory as belonging to :jsBrowserProductionWebpack
:
A problem was found with the configuration of task ':[…]' (type 'Copy').
- Gradle detected a problem with the following location: '[…]/build/js/packages/example-simple'.
Reason: Task ':[…]' uses this output of task ':jsBrowserProductionWebpack' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
Possible solutions:
1. Declare task ':jsBrowserProductionWebpack' as an input of ':[…]'.
2. Declare an explicit dependency on ':jsBrowserProductionWebpack' from ':[…]' using Task#dependsOn.
3. Declare an explicit dependency on ':jsBrowserProductionWebpack' from ':[…]' using Task#mustRunAfter.
But none of these are what I want. My tasks do work on the output of the Kotlin compiler, without any Webpack involvement. I do not want to involve Webpack in this, as it will massively slow down what I'm doing, especially for the production build.Ilya Goncharov [JB]
10/03/2023, 2:57 PMKotlinWebpack
has only one @OutputDirectory
, which targeting not into this directoryCLOVIS
10/03/2023, 3:04 PM2-vite-build
(if it is deleted, see commit ace9d7785a99dd0404e036929680aa3abcce3936
)
• in examples/simple/build.gradle.kts
, remove the onlyIf { false }
for :jsBrowserProductionWebpack
• run ./gradlew -p examples/simple --include-build ../.. build
Keep in mind I'm a Gradle newbie, so maybe I'm doing something dumb… I don't see what it could be, thoughIlya Goncharov [JB]
10/03/2023, 5:58 PMbuild/js/packages/<package>
Usually it is okay, but webpack task has output file webpack.config.js
. That’s why Gradle detect that copy task wants to use webpack output (because webpack output is inside input folder)
What I recommend - to use in your Copy task, sourceTask
as input, not specific folder
Something like this
from(project.tasks.named(sourceTask))
into(destination)
exclude("node_modules")
But I can propose more.
In fact you can reuse build/js/packages/<package>
, with just producing vite.config.js
inside it (like KotlinWebpack does)
It helps to reuse node_modules
(without symlinks) and reuse content of kotlin
folder
I understand that you likely want to distinguish outputs of dev and prod task, but you can distinguish not directories (because you don’t have @OutputDirectory
) but just configs
Something like vite.prod.config.js
and <http://vite.dev|vite.dev>.config.js
, and run them via --config
- https://vitejs.dev/config/
BTW, good work with adopting vite, I think that it is good way of integrating, and thinking about separating webpack tool integration into separate plugin.CLOVIS
10/03/2023, 6:04 PMIlya Goncharov [JB]
10/03/2023, 6:07 PMkotlin
and one file webpack.config.js
among prod and dev variants, but I hope I’ll fix it)
So if there will be problem, please ping me, I’ll try to helpCLOVIS
10/03/2023, 6:32 PMonlyIf { false }
for the Webpack task, then the build starts to fail:
Could not resolve entry module "kotlin/index.html".
error during build:
RollupError: Could not resolve entry module "kotlin/index.html".
at error (file:///home/ivan/Projects/opensavvy/kotlin-vite/examples/simple/build/js/node_modules/rollup/dist/es/shared/node-entry.js:2287:30)
at ModuleLoader.loadEntryModule (file:///home/ivan/Projects/opensavvy/kotlin-vite/examples/simple/build/js/node_modules/rollup/dist/es/shared/node-entry.js:24881:20)
at async Promise.all (index 0)
And, most surprising: the build continues to fail, even if I re-comment the Webpack task, even if I clean the project, disable the build cache and the configuration cache.
To get it back to working, I have to revert the changes, re-comment the Webpack task, clean everything, then rebuild once without the build cache.
My only guess is that Webpack somehow modifies the Kotlin files in that directory, and somehow that gets remembered by the Gradle daemon in a way that survives cleaning and the build cache? It's strangeIlya Goncharov [JB]
10/05/2023, 9:35 AMYes, now we are copying compileSync output, and it is collection of files. So you can either changeCopy codeRollupError: Could not resolve entry module "kotlin/index.html".
vite.config.js
onto just entering index.html
or change destination of copying compileSync
onto destination/kotlin
CLOVIS
10/05/2023, 8:12 PM