Remove prune-juice and unused Cabal dependencies

[cprecioso]

Description

prune-juice is unmaintained, and they recommend to just use the -Wunused-packages GHC flag.

I did so and removed all the unused packages it flagged.

• Related Investigate if we can remove dev-tool.project #3306

Type of change

• 🔧 Just code/docs improvement
• 🐞 Bug fix
• 🚀 New/improved feature
• 💥 Breaking change

Checklist

• I tested my change in a Wasp app to verify that it works as intended.

• 🧪 Tests and apps:

  • I added unit tests for my change.
  • (if you fixed a bug) I added a regression test for the bug I fixed.
  • (if you added/updated a feature) I added/updated e2e tests in examples/kitchen-sink/e2e-tests.
  • (if you added/updated a feature) I updated the starter templates in waspc/data/Cli/templates, as needed.
  • (if you added/updated a feature) I updated the example apps in examples/, as needed.
    • (if you updated examples/tutorials) I updated the tutorial in the docs (and vice versa).

• 📜 Documentation:

  • (if you added/updated a feature) I added/updated the documentation in web/docs/.

• 🆕 Changelog: (if change is more than just code/docs improvement)

  • I updated waspc/ChangeLog.md with a user-friendly description of the change.
  • (if you did a breaking change) I added a step to the current migration guide in web/docs/migration-guides/.
  • I bumped the version in waspc/waspc.cabal to reflect the changes I introduced.

[pkg-pr-new]

Open in StackBlitz

@wasp.sh/wasp-cli

npx https://pkg.pr.new/@wasp.sh/wasp-cli@3929

@wasp.sh/wasp-cli-darwin-arm64-unknown

npx https://pkg.pr.new/@wasp.sh/wasp-cli-darwin-arm64-unknown@3929

@wasp.sh/wasp-cli-darwin-x64-unknown

npx https://pkg.pr.new/@wasp.sh/wasp-cli-darwin-x64-unknown@3929

@wasp.sh/wasp-cli-linux-x64-glibc

npx https://pkg.pr.new/@wasp.sh/wasp-cli-linux-x64-glibc@3929

@wasp.sh/wasp-cli-linux-x64-musl

npx https://pkg.pr.new/@wasp.sh/wasp-cli-linux-x64-musl@3929

commit: ade7b29

[FranjoMindek]

Can confirm for prune-juice.

Giving "weak" approval for that part.

Would love if it was explained how some packages got version restrictions? Not too up to date with cabal versioning. If it's trivial feel free to merge otherwise require someone else to review.

[cprecioso]

Would love if it was explained how some packages got version restrictions?

Basically, we had this situation:

lib my-lib:
  ...
  random-dep ^>= 4 -- this _is not_ used here

test-suite my-lib-tests:
  ...
  my-lib,
  random-dep -- this _is_ used here
             -- we don't set a version because we depend on `my-lib` so we inherit theirs

So when I removed the dep from my-lib, I had to move their version specifier to that same dep in my-lib-tests, in order to not lose any version constraint.