search

sbt / sbt-jshint

Allows jslint to be used from within sbt. Builds on com.typesafe:webdriver in order to execute jslint.js along with the scripts to verify
Other
21 stars 20 forks source link

java.lang.IllegalArgumentException: runOps function returned results for unknown ops #33

Closed mberndt123 closed 8 years ago

mberndt123 commented 8 years ago

Hey,

I got the above error message in a rather big and complex project. But I have reduced it to a very minimal sbt project and prepared a tarball for that. If you run sbt foo/web-assets:jshint inside the archive's root directory (minimal-sbt-jshint-fail), it will display the above error message.

minimal-sbt-jshint-fail.tar.gz

huntc commented 8 years ago

Can you please provide a link to a gist instead.

mberndt123 commented 8 years ago

No, gists can't have subdirectories apparently.

Anyway, I just discovered that there is a way to attach files after all, so I've attached the tarball to the original report. Of course you could have just used the base64-encoded tarball I provided in the first place and already be fixing the bug, but oh well...

huntc commented 8 years ago

...or you could also be fixing the bug... ;-)

mberndt123 commented 8 years ago

OK, here's what I found.

sbt-web has a method called syncIncremental. What it does is take a bunch of operations (of type "Op", which is an unconstrained type parameter) from an sbt-web plugin and check which of these operations actually need to be run due to changed inputs. For sbt-jshint, Op seems to be a String containing the path of the file. Then sbt-web tells the sbt-web plugin to run the required subset of the operations, and the sbt-web plugin returns a Map[Op, OpResult], which essentially tells sbt-web which files were read and written by which operation. The map's keySet is of course supposed to be a subset of the Set of operations that sbt-web told the sbt-web plugin to run, and sbt-web enforces that, leading to the above error message. The reason it's not is that in the resulting Map, the key is an absolute path, while in my configuration, web-assets:sourceDirectory is a relative path. So sbt-jshint (or maybe SbtJsTask, I'm not sure) transforms relative paths into absolute paths and it all breaks down.

Now granted, it may not have been a good idea to use relative paths in the first place. But I think this situation should nevertheless be handled correctly. The error message makes it quite hard to figure out what's really going on…

huntc commented 8 years ago

Thanks heaps for the PR. It has been a while since I was involved with the JS task authoring, but I have a sneaky suspicion that absolute paths were used deliberately. I think that the current dir can change depending on sbt's context when running tests. Can you try your fix with "fork in Test" enabled/disabled?

mberndt123 commented 8 years ago

It doesn't matter whether they're relative or canonical, all that matters is that it's consistent… Canonical paths probably work better in some situations (for instance if you sometimes run sbt inside the subproject directory), so I've created a new pull request that does it the other way around.

mberndt123 commented 8 years ago

So, any chance this can be merged?

huntc commented 8 years ago

Sorry, been busy. Will try to get to it today.

huntc commented 8 years ago

Thanks!

huntc commented 8 years ago

I tried releasing this evening but it failed... I shall try again tomorrow.

huntc commented 8 years ago

Released as 1.1.4. Thanks again.