@ed-g Do I need to install NPM for the project build?

I'm getting this when I run ./gradlew build or try to run the CLI Main.java from within IntelliJ:

> Task :main:installSnabbdom FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':main:installSnabbdom'.
> A problem occurred starting process 'command 'npm''

I'm on Windows 10 Home on this machine so I'm wondering if this is a Windows issue.

@barbeau

Oh right, the snabbdom update processes uses npm.

The git repository ships with a previously downloaded copy of snabbdom as main/src/main/java/org/mobilitydata/gtfsvalidator/viewer/snabbdom.browser.js

The purpose of the rollupSnabbdomUmd gradle task is to refresh from upstream so project maintainers don't end up with an outdated version of snabbdom over time, and to act as some executable documentation for how that file was originally made. This was my attempt to implement dependency management for the javascript side based on the gradle reference I was using, there might be a more idiomatic way.

If you want to skip it for the initial test, the line

    dependsOn rollupSnabbdomUmd

can be temporarily commented out of main/build.gradle

Thanks! What I don't understand, though, is why GitHub Action CI is passing and successfully packaging the app if I can't do the same with ./gradlew build or ./gradlew shadowJar on my local machine, which made me wonder if it's a specific Windows issue. Because you didn't configure the GitHub Action to have NPM installed, right?

Another related item is that we don't want unnecessary Gradle tasks to run on each build for performance reasons. Does generateViewerAssets need to run on every build? If so, could we limit the scope so it only runs if files in a particular package are changed? There are some examples of how to do this here - https://barbeau.medium.com/how-to-avoid-duplicate-code-for-similar-sdks-7e7812e67708.

@ed-g Could you merge the master branch into this PR? The CI should now run GitHub Actions on Windows as well which should help troubleshoot the above issue.

@barbeau

I've merged master into this PR. There was a minor doc conflict, I believe my merge makes sense there.

Another related item is that we don't want unnecessary Gradle tasks to run on each build for performance reasons. Does generateViewerAssets need to run on every build? If so, could we limit the scope so it only runs if files in a particular package are changed? There are some examples of how to do this here - https://barbeau.medium.com/how-to-avoid-duplicate-code-for-similar-sdks-7e7812e67708.

The task should be looking at $projectDir/js/snabbdom-umd/{package.json,node_modules} and not updating unless one these change (in other words, if the version is updated). On my machine it only runs once. However this is my first experience with Gradle and while I followed the docs as far as I could, there might be a better way to accomplish this.

Looks like the GitHub CI on Windows is failing with the same error I saw previously:
https://github.com/MobilityData/gtfs-validator/runs/6102573605?check_suite_focus=true

> Task :core:jar
> Task :main:installSnabbdom FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':main:installSnabbdom'.
> A problem occurred starting process 'command 'npm''

...but the Ubuntu build is fine:
https://github.com/MobilityData/gtfs-validator/runs/6102573447?check_suite_focus=true

> Task :core:jar

> Task :main:installSnabbdom

added 3 packages, and audited 4 packages in 2s

found 0 vulnerabilities

> Task :main:rollupSnabbdomUmd

> Task :main:generateViewerAssets

./node_modules/snabbdom/build/index.js → ../../src/main/java/org/mobilitydata/gtfsvalidator/viewer/snabbdom.browser.js...
created ../../src/main/java/org/mobilitydata/gtfsvalidator/viewer/snabbdom.browser.js in 183ms

So it does look like a Windows thing. https://stackoverflow.com/a/39070534/937715 says:

Also there is a better way of running node scripts and npm tasks in gradle. Check out the node-gradle-plugin for that. It is a neat wrapper over the exec task you are using.

So it would probably be better to manage npm using something like https://github.com/srs/gradle-node-plugin or https://github.com/node-gradle/gradle-node-plugin.

Excellent! I've swapped in gradle-node-plugin in Trillium-Solutions@4feba98 works on local, fingers crossed it works on Windows just as well.

It appears that rollup npm command expects bash to be available.

https://github.com/MobilityData/gtfs-validator/runs/6200904503?check_suite_focus=true

However my local copy of ./main/js/snabbdom-umd/node_modules/.bin/rollup is 100% a node script, so it's not clear to me what code is running here.

It appears to be a shell script to convert windows style \ path separators to unix style / path separators, is it part of github actions itself? The bash code shown will work on bash but not "classic' bourne shells such as /bin/sh since it uses the $( ... ) method for command output substitution.

I don't believe you should need this, configuring once in the root build.gradle should be enough

Uncertain. I think it wasn't running unless it was also defined in the sub directories. If I recall it was saying everything was fine, but not actually looking at the code under main.

I'm a little out of my depth and could use help/advice from a gradle java expert here.

Ok I've run some experiments.

You're correct in that we don't need both, but it turns out the one we need is ./main/build.grade.

What's needed in ./build.gradle is the spotless plugin version, but spotless (for whatever reason) won't look at .java files within ./main/ unless spotless is specifically configured within the main/build.gradle. This is different from how google-java-format works which is why it was confusing and took me a while to figure out (and how I ended up with redundant configuration here).

Made these changes in Trillium-Solutions@4feba98

@barbeau are you happy with the changes here?

@ed-g Do you think we could create another PR for the spotless task? We could discuss it there and then merge it if it's ready :) The code you provided looks good. It would be nice to test it on its own.