Issue with sbt-web/sassify, sub-projects, and the Play dev server...

[mikesname]

Hi all,

I'm trying to update an app from 2.8.21 to 2.9.3 and while it's mostly pretty plain sailing I've come across an issue that's a bit of a blocker for me.

In a nutshell:

• my app uses SBT sub-projects
• it also uses the sbt-sassify plugin
• while I could change my SASS files and see the result in the browser with 2.8.21, in 2.9.3 I cannot

While changing the SASS assets does trigger a recompilation of the CSS, this does not seem to propagate from the sub-project to the root project. It only works if I do a full rebuild. At first I thought this was an SBT issue, but the latest SBT 1.10.0 and Play 2.8.21 works fine.

Does anyone recognise this issue, or have a sense if it's a Play thing, an sbt-sassify thing, an sbt-web thing or something else?

I have made a minimal project here to test things if that's of use: https://github.com/mikesname/sbt-sass-issue

[mkurz]

I would guess this could be caused by the fact that sbt-sassify 1.5.2 still uses sbt-web 1.4.x, whereas Play and basically all popular sbt-web plugins now use sbt-web 1.5.x. There is an open pull request which wasn't looked at by the maintainer yet: irundaia/sbt-sassify#53
Before there is no sbt-sassify release that is based on latest dependencies (=sbt-web 1.5.x) it's hard to tell what is causing this issue.

You could go ahead an build your own (or fork) sbt-sassify library with upgraded dependencies and see if then your problem still occurs.

[mikesname]

Thanks @mkurz, I'll try and figure that out. Seems like a likely culprit.

Update: I gave the open PR from @OlegYch a go locally, with the latest sbt-web (1.5.5) and unfortunately I'm still seeing this problem.

[mikesname]

I've done a bit more digging here and unless I've made a mistake this problem also affects at least sbt-less, sbt-uglify (both using sbt-web 1.5) and sbt-vuefy (on sbt-web 1.4), so perhaps it's a broader problem with Play 2.9 and sub-module projects? Worth a look perhaps, I am happy to put in an issue.

[mkurz]

Problem is caused by

• Use ClassGraph webjars/webjars-locator-core#28

Investigating...

[mkurz]

• A fix should land soon, see Asset changes in subprojects #12484 (comment)

[mkurz]

Everyone affected: You can fix this now by upgrading webjars-locator-core yourself until the next Play patch relase is out, see:

• Asset changes in subprojects #12484 (comment)

[mikesname]

@mkurz confirmed that this is working for me now, with -SNAPSHOT in my version. Many thanks for your work on this, I actually spent quite a while trying to understand what was happening here and did not get close to figuring out this webjars issue. 👍

Do you know if it's possible to get this working without -SNAPSHOT in the version, because I can see that catching myself and others out in future if not extremely well signposted?

[mkurz]

Currently, this will only work if the sub-project's version ends with -SNAPSHOT (case insensitive). The behavior of webjars-locator-core changed between Play 2.8 and Play 2.9, and it will not extract webjars that already exist, likely for performance reasons. Since the assets in a sub-project are treated like webjars and will be extracted to the root project, the snapshot workaround is currently all we can do to make this work. I was debugging the code and cannot really think of any other condition we could use to make webjars-locator-core aware that it should extract the webjar of a sub-project. sbt-webjar-locator-core does not know that the webjars it should extract are located within a (Play) sub-project.

I was thinking that maybe the webjar maintainer would accept a special system property like always_extract_webjars, which we could set in Play's dev mode so the webjars will be extracted no matter what. However, this is not really desirable, in my opinion, because if you have many webjars or webjars that contain many files, it would slow down dev mode unnecessarily, especially for people who do not use sub-projects (or don't store assets in their sub-projects).

For now, I would keep it as it is. Maybe there will be a better solution at some point. In my opinion, the solution is not bad, because usually, you are developing snapshots and only use stable versions for releases. Also, when releasing, you should start with a clean project anyway (where no target folders, etc., exist).

By the way, I recommend using https://github.com/sbt/sbt-dynver, which will set the version automatically for you based on git tags.