Import Build everytime I open IDE when using sbt as build server

[vanhtuan0409]

Hi, I'm using metals with nvim-metals plugin and sbt as BSP server. I did notice that every time I open nvim, metals will require to import build again even tho I have sbt shell alive.

Is there anyway to speed up this as the Import process take quite sometime for me

[ckipp01]

Hey @vanhtuan0409! Can you tell me a bit more about your workflow?

Depending on the flow there shouldn't be a prompt to import your build every time unless something in your build definition has changed. Especially if you already have sbt running, when you open it with Metals it should simply connect, possibly need to reload if it detects a change, and then that's sort of it.

[vanhtuan0409]

I'm working on a monorepo with quite some customization on build.sbt

My workflow is that at the start, I will open a sbt shell (sbt -Dsbt.semanticdb=true -J-Xmx16G) and keep in running. Then I might open several nvim for coding. Some nvim might be closed and reopened along the way but sbt shell will never get closed

The issue is whenever I open a new nvim process. The Importing build kicked in as you can see in the image. According to metals logs. It will try to send workspace/buildTargets + buildTarget/scalacOptions + ... several build command over to sbt server. This happens even when I kept the sbt shell open and no build config is changed. I was expecting that this will only happen once

My metals config is in: https://github.com/vanhtuan0409/dotfiles/blob/master/config/nvim/lua/modules/metals.lua

[ckipp01]

Is it possible for metals to fetch build information from sbt without asking sbt to rebuild the target again?
I assume sbt should already have the build info already

So it sort of does. I just tested this as I was a bit curious and when the second instance connects it still needs to do the full BSP initialize process to connect. After it initializes there area "series" of request that do happen such as getting the build targets, scalacOptions, main methods, etc. I do see a compile request, but in theory it should be a noop, and that's what seems to happen when I try this with a small project as you can see here:

[Trace - 04:57:31 PM] Sending request 'buildTarget/compile - (8)'
Params: {
  "targets": [
    {
      "uri": "file:/Users/ckipp/Documents/scala-workspace/sbt-sanity/#sbt-sanity-build"
    }
  ]
}


[Trace - 04:57:31 PM] Received notification 'build/taskStart'
Params: {
  "taskId": {
    "id": "7",
    "parents": []
  },
  "eventTime": 1648051051656,
  "message": "Compiling sbt-sanity",
  "dataKind": "compile-task",
  "data": {
    "target": {
      "uri": "file:/Users/ckipp/Documents/scala-workspace/sbt-sanity/#sbt-sanity/Compile"
    }
  }
}


[Trace - 04:57:31 PM] Received notification 'build/publishDiagnostics'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/sbt-sanity/src/main/scala/Main.scala"
  },
  "buildTarget": {
    "uri": "file:/Users/ckipp/Documents/scala-workspace/sbt-sanity/#sbt-sanity/Compile"
  },
  "diagnostics": [],
  "reset": true
}


[Trace - 04:57:31 PM] Received notification 'build/taskFinish'
Params: {
  "taskId": {
    "id": "7",
    "parents": []
  },
  "eventTime": 1648051051666,
  "message": "Compiled sbt-sanity",
  "status": 1,
  "dataKind": "compile-report",
  "data": {
    "target": {
      "uri": "file:/Users/ckipp/Documents/scala-workspace/sbt-sanity/#sbt-sanity/Compile"
    },
    "errors": 0,
    "warnings": 0,
    "time": 10
  }
}

The full report comes back within the second. However I can imagine that with a monorepo with hundreds of targets this may add up. Either way, avoiding connecting multiple times should really help with this.

[vanhtuan0409]

I see. Usually, I open 1 nvim window per module I working on. This scoped down the fuzzy file search just for convenience. I will try to avoid this

Aside from this, is there anyway to speed up the process of getting buildTarget, scalacOption, etc...? Currently it take up to 10min for me to be able to start getting completion and go to definition. This make closing nvim and re-open it an expensive action

[ckipp01]

Aside from this, is there anyway to speed up the process of getting buildTarget, scalacOption, etc...? Currently it take up to 10min for me to be able to start getting completion and go to definition. This make closing nvim and re-open it an expensive action

That's indeed a long time. It's honestly a bit hard to tell without divining into your specific repo and understanding what's taking the most time.

[tgodzik]

Are you using the newest Metals server? There were some fixes for starting file watching. Otherwise it would be cool to optimize the import for your case for sure,

[vanhtuan0409]

Any great help from you guys :D thank you