Run play framework in dev mode

tgodzik commented 2 years ago

Is your feature request related to a problem? Please describe.

Currently it's possible to run the Prod server for Play framework, however it's not possible for the dev mode, which would allow hot reload for your application

Describe the solution you'd like

Custom support for dev server that would reuse sbt mechanism (something around https://github.com/playframework/playframework/blob/fe4861300034eb0625867de3d33c4671635fc82a/dev-mode/sbt-plugin/src/main/scala/play/sbt/run/PlayRun.scala#L77) or maybe add a way to add an sbt task from metals (metals-vscode ?).

Describe alternatives you've considered

You can always run the server in sbt.

Additional contex

This poped up as in the conversation in https://github.com/scalameta/metals/issues/3575

Search terms

play framework support

tgodzik commented 2 years ago

We might also try to solve it via an internal mechanism here https://github.com/scalameta/metals-feature-requests/issues/96 (would be less effective that hot reload offered by the sbt plugin)

huntario commented 2 months ago

Found this via https://github.com/scalameta/metals/issues/3575

A solution for VS Code is to run sbt -jvm-debug 5005 in the integrated terminal. SBT will start and then you can run the dev server with run in the SBT terminal. Then attach a debugging session with the following launch.json using "Attach debugger". You can run the starter tests with "Launch Test" directly from the debugger

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "scala",
      "request": "attach",
      "name": "Attach debugger",
      "buildTarget": "root",
      "hostName": "localhost",
      "port": 5005
    },
    {
      "type": "scala",
      "request": "launch",
      "name": "Launch Test",
      "testClass": "controllers.HomeControllerSpec"
    },
  ]
}

Tested this out with the Play Scala starter - sbt new and selecting playframework/play-scala-seed.g8 - https://www.playframework.com/getting-started

This seems like a documentation issue rather than something that Metals needs to change. That said it is critical to offer a simple step debugging solution for a very popular Scala framework (Play) in a popular IDE (VSCode) that (I'm assuming) drives a great deal of Metals adoption.

It is (was) Saturday. I'm very motivated to move away from IntelliJ. My main motivation is 1) step debugging through Tests which has remained elusive for my project in IntelliJ, 2) avoiding a "switching cost" that I perceive from switching IDEs for different languages, and 3) getting out of a closed ecosystem and IntelliJ's absolutely abysmal documentation which is obviously written by committee. This gives me enough hope to try the setup for work, but it took way longer than it should have to verify if this was going to work and I almost rage quit on Metals/VSCode as a Scala IDE because of it.

All the information is there - https://scalameta.org/metals/docs/editors/vscode#via-a-launchjson-configuration - but it is decision fatigue inducing and I could never get "Launch Main" to work with Play. Frankly I don't care about that so much because the above two scenarios cover my use cases.

Maybe it's something that just needs to be covered on a community blog or something, but the obscurity of getting that simple config above nearly killed off my personal adoption of Metals. I hope this post helps if you were like me earlier today.

tgodzik commented 2 months ago

Good point @huntario We shoud for sure make it much simpler to start play server, though this is harder to figure out properly due to the fact how LSP works.

At the very least it should be much easier to discover for people. I will try figure something out.

scalameta / metals-feature-requests