I followed this recommendation from Figwheel:
Because our output files are going to be placed in the
target/publicdirectory by default and we want them to be served as static assets by the webserver we will need to add the
target/public) to our classpath.
Later, I tried to push my code via Ions. It seemed to hang. The only thing I saw in the output was the typical Maven dependency fetches. I waited ~30 minutes, then started to investigate CloudWatch logs etc. as recommended on this topic, but didn’t see anything. I also didn’t see either of the S3 directories mentioned by the Ions Reference created (
s3://$(datomic-code-bucket)/datomic/apps), like I expected on my first push.
I killed the push process and tried it again, thinking maybe I was just the unlucky victim of a weird network issue. Went to dinner. Came back. Still hung.
I noticed that I could push from the ion-starter repo, which led me down the path of isolating the relevant difference between that
deps.edn and my
deps.edn, and, as indicated above, it was the fact that I had “target” in my
When I did a
du -sch target, it reported 90G. Yikes! I think Ions got into a loop trying to add its build output to the build.
As a workaround, I changed Figwheel’s settings to use a different directory that isn’t included in the
:paths vector, then removed “target” from the vector. The push worked fine at that point.
I’m mentioning this here (1) in case it helps anybody, and (2) to provide to Datomic devs a (hopefully reasonable)
deps.edn scenario that leads to a rather frustrating first-time experience of Ions, in the hopes that avoiding this issue would be an easy improvement to avoid others the same frustration I experienced. Cheers.