Put project related configuration/files into .config directory

[ghostbuster91]

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

I propose scala-cli relocates its project-specific files from the root .scala-build/ folder to .config/scala-cli/. This would hugely reduce clutter in the project's root directory.

A great example for this is the Mill build tool. By default, Mill uses:

• .config/ for its settings
• out/ for its build output

Crucially, Mill's output location is flexible; a user can set the MILL_OUTPUT_DIR environment variable to redirect build artifacts to a location like .local/state/mill/, separating volatile state from project configuration.

Describe the solution you'd like

Scala-cli could adopt a similar model. This change would make project directories cleaner and follows a proven, well-regarded XDG pattern.

Suggested migration path To ensure a smooth transition for existing projects, scala-cli could perform a one-time automatic migration.

• on the first run in a project, scala-cli would check for a .scala-build directory in the root. If found, it would automatically move the entire .scala-build directory to the new .config/scala-cli location

• for all new projects, scala-cli would simply use the .config/scala-cli/ path by default

Additional context

Further Reading

• the .config Initiative: The source and discussion for the project-local .config standard https://github.com/dot-config/dot-config.github.io

• Scala and the XDG Standard: An article discussing the broader benefits of applying these directory standards within the Scala ecosystem https://rlemaitre.com/articles/scala/scala_xdg

Acknowledgements to @matejcerny for their assistance in describing this issue.

[majk-p]

The link to scala_xdg article is broken, here's the correct one: https://rlemaitre.com/articles/scala/scala_xdg

[Gedochao]

Hey, so. The idea in and by itself is a good one.

However, we just don't have the capacity for the Scala internal team (or, in the case of Scala CLI, me) to work on this in the predictable near future. This is especially the case, since we'd need to implement the support for this (with a migration period in mind) in a number of places of the ecosystem (not just CLI, but also IDEs and stuff).

Another note, please do remember that some pieces of the toolchain will likely not abide this. VS Code will keep putting stuff in .vscode regardless what we do. Similar with Cursor and .cursor, Claude and .claude, IntelliJ and .idea, the list goes on.

That being said, I'm okay with going ahead with this if anyone is willing to help. External contributions are welcome.

[Gedochao]

Were someone to work on this on the CLI side, some requirements off the top of my head:

• modify the BSP (Build Server Protocol) spec under https://build-server-protocol.github.io/docs/overview/server-discovery (or https://github.com/build-server-protocol/build-server-protocol ) to allow for the .bsp connection files to be in a different spot (as well as where they are now, since we'd have to support both in the migration period)
• changes should be behind an experimental flag, say --dot-config-workspace
  • there should be a config sub-command experimental key to configure the same, say dot-config-workspace, set to false by default
  • an environment variable should also be in place, say SCALA_CLI_DOT_CONFIG_WORKSPACE, reading boolean
• the implementation itself would likely
  • change the default location for the --workspace override
  • still allow to override with --workspace
  • move the expected spot for the .config directory according to the project.scala file location
  • setup-ide and other build commands should automatically detect when to regenerate the BSP connection files with this setup
  • do keep in mind that there might be some pieces of the CLI which may be brittle when this change is put in place, so I'd cover this with a lot of tests, as both the current status quo and the new location for everything would have to be supported at one time
  • there are likely edge cases I haven't thought of immediately.

I hope this helps. Feel free to ask me for guidance when tackling this.