Add fallback-scala-version configuration option
#494
Conversation
dos65
force-pushed
the
fallback_scala_version_configuration_option
branch
from
38b82e1
to
6126fec
Compare
| "2.11.12", | ||
| "3.0.0-M3", | ||
| "3.0.0-M2", | ||
| "3.0.0-M1" |
There was a problem hiding this comment.
Let's add at least in the main Metals repo docs/contributors/releasing.md information that we should update this list.
There was a problem hiding this comment.
Added to the same PR - commit
dos65
force-pushed
the
fallback_scala_version_configuration_option
branch
from
caa9ffd
to
a00c06e
Compare
package.json
Outdated
| }, | ||
| "metals.fallbackScalaVersion": { | ||
| "type": "string", | ||
| "default": "", |
There was a problem hiding this comment.
We should not have any default, otherwise I think empty string will be sent to the server.
There was a problem hiding this comment.
Thx, I forgot to remove it.
By the way, I remembered that there is a minor issue with this selector.
What do you think about adding an option that will be called default?
There is a logic that tries to select the highest Scala version from build targets.
It applies in case if this property is empty. But enum type doesn't allow you to choose empty so there will be no way to clean up this property.
There was a problem hiding this comment.
Maybe something like automatic ?
There was a problem hiding this comment.
Added automatic.
Also mentioned it in the description section. @ckipp01 could you check grammar there one more time?)
There was a problem hiding this comment.
Sorry, late to the party on this. I hate to say this now, but what happens if you just don't have a default, what does VS Code send? In some ways, even if it is an empty string, I'd almost rather that, and instead have Metals just filter out an empty string. Mainly because now in this meaningful list of Scala versions we have a random automatic. It's not the worst, but just treating "" as None on the Metals side instead of introducing another value makes more sense to me. It's not a hill I'll die but just my two cents.
EDIT:
The
automaticvalue means that the Scala version for these files might be inferred as the highest supported Scala version from your project build definition
I even more so think this after reading it, mainly because this is a bit confusing. It's not the grammar, but rather an extra layer that we are adding that I don't think is necessary. Because what does "highest supported Scala version from your project build definition" really mean to someone new to Scala? Does this mean that if I have set 2.12 set for one module and 2.13 set for another, you'll choose 2.13? I'm just afraid that this may cause confusion. wdyt?
There was a problem hiding this comment.
@ckipp01
In VS Code enum option can't be manually edited. So automatic value solves the problem when you might decide to set None value back. Otherwise, you will have to manually edit .vscode/settings.json.
It might represented be as "" but I'm afraid it will more confusing than automatic or smth like that.
Unfortunately, there is no way to specify how options should be rendered in VS Code selector. Only plain values.
Does this mean that if I have set 2.12 set for one module and 2.13 set for another, you'll choose 2.13? I'm just afraid that this may cause confusion
Yes, it will select 2.13.
I don't think that is confusing because most of the users use a single Scala version per project and will never face the need to change this option.
There was a problem hiding this comment.
Yea I see what you mean.
So given the following situation where I have 2 build targets, one a Scala 3 and one Scala 2 one. I create a standalone Ammonite script at the root of my project and have this set to automatic, what version of the compiler will I get for that standalone file?
There was a problem hiding this comment.
For an Ammonite script, it will be Scala 2 because it doesn't support scala 3 yet.
For a worksheet or scala file, it will be Scala 3
dos65
force-pushed
the
fallback_scala_version_configuration_option
branch
from
a00c06e
to
75d3b57
Compare
Co-authored-by: Chris Kipp <ckipp@pm.me>
dos65
force-pushed
the
fallback_scala_version_configuration_option
branch
from
f891946
to
310e306
Compare
…rn/types/node-18.7.15 chore(deps-dev): bump @types/node from 18.7.14 to 18.7.15
An addition to scalameta/metals#2417