Improve caching behavior for tasks

[nigredo-tori]

webpack task

Current implementation of the webpack task only actually launches webpack if one the following changes:

1. Generated configuration files (package.json, scalajs.webpack.config.js).
2. Custom webpack configuration file (if any).
3. Entries generated by scalajs.

This is a major inconvenience in the following use cases:

1. If the custom config imports another file (for example if few configs reuse some base settings), webpack won't be launched if only the imported file has changed.
2. If the code imports some unmanaged resource (script or something else), webpack won't be launched.

There is currently no satisfactory way to circumvent this behavior. Here are a few ideas:

1. Expose a setting to allow appending to the list of files being checked.
2. Expose the same functionality without caching as a separate task.
3. Just disable caching for this task.

package.json generation

Current implementation only regenerates package.json if running with changed sbt Configuration (Compile, Test, etc.). This means that changing npmDependencies/npmDevDependencies won't trigger package.json update.

Possible solutions:

1. Append these settings to the hash in PackageJsonTasks.scala.
2. Hash the generated data instead of just using configuration name.

[julienrf]

For the webpack task, I would not disable caching because bundling times can be quite long. An improvement could be to take into account the scalaJSNativeLibraries for the hash. We could also introduce a monitoredResources key, similar to the one introduced by sbt-web-scalajs, but I wonder if there isn’t a more standard solution.

For package.json, indeed the caching mechanism used is wrong. What do you mean by “the generated data”?

[nigredo-tori]

@julienrf, scalaJSNativeLibraries only helps with *.js files - and webpack supports a lot more (this also reuses pre-existing key from another library, which is probably not a good idea). Webpack gives a lot of flexibility in collecting and mapping files, and we shouldn't put restrictions on it. At least not without an escape hatch.
A separate key for the monitored files would be a convenient and flexible solution, in my opinion, though it would place a burden on API user to collect the files (which doesn't look like an insurmountable problem). An alternative would be some combination of directory list with filtering, I suppose - something like unmanagedSourceDirectories/unmanagedSources/includeFilter/excludeFilter.

By "generated data" I mean the generated json string. Though simply concatenating all the relevant input to writePackageJson, and using it as a "hash" seems to do the trick here - and is extremely simple to implement. No need to prematurely optimize/generalize this at the moment.

[julienrf]

Thanks for detailed explanation. I think we should go with a key for the monitored files.

[dispalt]

This would be very useful for me too.