Allow to set default NODE_PATH in extension for all NodeTasks

[lamba92]

Use case: when building a Kotlin/JS project, the Gradle plugin will create in rootProject build/js a yarn environment with all required modules in all subprojects (which is very handy). When running NodeTasks, it would be reasonable to set once NODE_PATH to said directory in NodeExtension and always rely on the Kotlin/JS dependency resolution.

And/or provide an extension like:

fun NodeTask.setNodeModulesPath(path: String) =
    environment.put("NODE_PATH", path)

fun NodeTask.setNodeModulesPath(folder: File) =
    environment.put("NODE_PATH", path.normalize().absolutePath)

[bsautel]

I am not sure I understand correctly how the Kotlin/JS plugin works. It downloads all the npm dependencies of all the subprojects thanks to yarn in the $rootProject/build/js, right? Does it also generate a package.json file? Which Node.js interpreter does it use?

[lamba92]

Exactly. A uber yarn workspace is created there with all the dependencies of all subprojects of the build and you can use that environment to do whatever you want. A packgage.json is created for each subproject with the Kotlin/JS plugin based on what dependencies you have imported and from where (a .klib with a Kotlin/JS compilation from Maven or an NPM module from, well, NPM), and recursively for each Kotlin/JS library imported.

I believe that the Kotlin/JS plugin redownlaods NodeJS somewhere the same way the gradle-node-plugin does, but gives no access to its tasks so a third party solution is needed to tinker with the output of the build like I need.

In my use case I need to webpack into a single file my application for NodeJS. I thought that NodeExtension.nodeProjectDir would be used as default NODE_PATH for all NodeTasks but it isn't!

If you want to see for yourself how the build process works for Kotlin/JS + Webpack, try running :examples:js-bot:productionWebpackExecutable or :examples:js-bot:developmentWebpackExecutable of kotlingram.

[deepy]

I think this might be possible to do already with execOverrides

But if we're going to start exposing common settings (like --registry and --frozen-lockfile) I think this should also get first-class support