| 12 May 2024 |
 bjaglin | * Hey! Indeed, --check only returns 0 when there is no ERROR diagnostic nor pending rewrite. There is no way to have a "fatal warnings" behavior with the CLI at the moment. I suggest you open a GitHub issue to discuss semantics. Happy to provide pointers to help you implement it once we've agreed on that. | 17:10:17 |
| bjaglin | * Hey! Indeed, --check only returns 0 when there is no ERROR diagnostic nor pending rewrite. There is no way to have a "fatal warnings" behavior with the CLI at the moment. I suggest you open a GitHub issue to discuss UI/semantics. Happy to provide pointers to help you implement it once we've agreed on that. | 17:10:45 |
|  Javier M joined the room. | 20:02:18 |
| 13 May 2024 |
|  satorg joined the room. | 00:01:24 |
| 15 May 2024 |
|  kawaxte joined the room. | 07:09:19 |
| 16 May 2024 |
 .sandwichwizard | š thanks, just opened https://github.com/scalacenter/scalafix/issues/2000 | 12:26:35 |
| .sandwichwizard | I'm also curious if there's a way to disable the UnusedScalafixSuppression warnings from the CLI?
for context, I'm writing a pre-commit hook that will only run syntactic rules for the sake of speed (all rules are run CI), so sometimes a suppression appears unused because it's for a semantic rule | 12:50:18 |
|  rohith_02_ joined the room. | 14:22:10 |
|  sake92 changed their display name from sake92#0 to sake92. | 15:10:19 |
| 17 May 2024 |
|  Vlad changed their profile picture. | 22:00:48 |
| 19 May 2024 |
|  bste_ joined the room. | 22:20:34 |
| 20 May 2024 |
|  jwgcooke joined the room. | 16:07:14 |
|  balmungsan3 joined the room. | 18:04:54 |
| balmungsan3 | scalafix + metals + vscode formatting sbt files using Scala 3 syntax.
Today I realized that after adding this setting to my vscode profile:
"editor.codeActionsOnSave": {
"source.organizeImports": "explicit" // "always" | "never"
}
When editing a sbt file, after closing it, the OrganizeImports rule of Scalafix would get applied and it would modify my imports using the Scala 3 targetDialect (as defined by my .scalafix.conf file).
I would like to be able to configure some fileOverride rules, similar to scalafmt to force the Scala 2 dialect on sbt files.
I wonder if auto would already do that? But I am wary of using that given that it doesn't work for cross-compilation, so even if it would work for the current app I am working on, this issue may happen in the future again. | 18:04:55 |
| balmungsan3 | 18:04:55 |
| 21 May 2024 |
 matthiasberndt | Why? Newer Scala 2 versions support the Scala 3 import syntax, so you should be able to migrate it | 08:28:06 |
| matthiasberndt | But I wouldn't recommend organising imports on save anyway. It slows things down and it doesn't work when your codebase doesn't compile and then you get annoying error messages and whatnot. And of course āorganized importsā provide precisely zero business value, so any amount of time spent on imports is wasted. | 08:33:14 |
|  jypma changed their display name from netwa1ker to jypma. | 13:16:19 |
| balmungsan3 | I don't want to use Scala 3 syntax on a Scala 2 file.
Also, while it does support .* rather than ._, there seems to be issues with aliases. | 15:49:23 |
| balmungsan3 | CI will check for formatting, including import order.
The less I have to remember to run a format action before commiting and pushing, the better. | 15:50:08 |
| balmungsan3 | And of course āorganized importsā provide precisely zero business value, so any amount of time spent on imports is wasted.
Whatever you say | 15:50:29 |
| matthiasberndt | It's not Scala 3 syntax if it can be compiled with Scala 2 š | 15:51:00 |
| balmungsan3 | Anyways, it seems I should open a issue with this if I want it to recieve attention? | 15:51:33 |
| matthiasberndt | So disable that check, it doesn't provide value | 15:52:01 |
| balmungsan3 | Whatever you say x2 | 15:52:32 |
| matthiasberndt | There is no issue here, the syntax that it generates works | 17:08:25 |
| 22 May 2024 |
| bjaglin | There is no fileOverride feature at the moment, and it was never requested, so I am unsure it's worth the complexity.
I wonder if auto would already do that? But I am wary of using that given that it doesn't work for cross-compilation, so even if it would work for the current app I am working on, this issue may happen in the future again.
If you don't want to force Scala 3 dialect on all files, you should use either: Auto if your project does not cross-compile, or StandardLayout (the default) if it does. It won't cover all use-cases but hopefully most of them. | 00:04:45 |
|  im_bharadwajj joined the room. | 08:54:35 |
|  dos65 joined the room. | 11:42:29 |
| balmungsan3 | Auto doesn't work. | 16:22:12 |
