Replies: 1 comment
-
I don't think it's too specific actually. It could be that a solution here could also help out in the situation a lot of Scala users have where maybe they have 100 build targets, but they cross compile 2.12, 2.13, 3, Scala JS, Scala Native, and JVM. Those 100 just became 900. That is a ton of duplication that the user maybe doesn't want or need when working on the project in their editor. So having a nice BSP way to handle what gets added or removed might be really nice. I wonder if we could mimic the way LSP does WorkspaceFolders, but instead of adding workspaces you just added or removed build targets. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
currently,
workspace/buildTargets
leaves the decision of what are the targets in the workspace to the server - in bazel-bsp we adopted project view files to make it work with monorepos (so in general u can choose what targets should be imported)i think that it'd be nice to move it to the protocol itself - make it possible to provide parameters (i dont know what exactly) to
workspace/buildTargets
or introduce another mechanizmwhat do u think? or maybe it's too build-tool-specific?
Beta Was this translation helpful? Give feedback.
All reactions