Add export --json option

[MaciejG604]

No description provided.

[Gedochao]

NIT it'd be good to extract the refactor changes to a separate NIT commit
aside from the nitpicks, LGTM

[MaciejG604]

After consideration I think this PR should focus on exporting basic information about the project and mostly on what has been requested, so the list of dependencies and resolvers. The discussion on the cross-compilation for platforms and scala versions should be moved to a follow-up issue.

For now the export --json result contains the following information about the project:

• projectName
• scalaVersion that's visible in the Main scope
• platform only one that's visible in the Main scope
• scalacOptions
• scalaCompilerPlugins presented as Strings with ':' as delimiters
• scalaJsVersion that's visible in the Main scope, only if the platform is JS
• scalaNativeVersion that's visible in the Main scope, only if the platform is Native
• mainClass
• extraDecls contains jsModuleKind information
• scope specific infromation:
  • scopeName, e.g. "main", "test"
  • sources list of subpaths to the source files
  • dependencies presented as Strings with ':' as delimiters
  • resolvers presented as URL for Maven and ivy:pattern for Ivy
  • resourceDirs
  • extraDecls contains custom jars added to the project

Follow-ups to consider:

• cross-compilation
• resolver authentication

[MaciejG604]

@fthomas, @ckipp01
Is this format okay?

[ckipp01]

Is this format okay?

Just took a look. Really happy you're working on this! One thing I did notice though, which @prolativ already mentioned is that I like the more structured output than the concise string. By doing the concise string you're now forcing every consumer of this output to have to both know how and to manually parse that output to their needs instead of having it already structured. I'm not really sure what the benefit of the concise string is. Having it structured like you originally had it is much more flexible imo.

[prolativ]

1. Showing only the configuration for the current/default platform seems reasonable. We could later (as an independent improvement) add --cross flag to return a json list/object with configurations for different platforms and scala versions.
2. One can have different scalacOptions for main and test so these should be split. I assume this is true also for scalaCompilerPlugins
3. is extraDecls supposed to be dependent on the platform (e.g. can it hold some options for scala-native?) or is it scala-js only? In the latter case why isn't it called explicitly jsModuleKind? And why is this property both top-level and separately for main/test?
4. If we specify scalaJsVersion and scalaNativeVersion, shouldn't we also include e.g. the version of js itself or JVM, if it's specified explicitly?
5. Maybe scopes should be a Map rather than a list? Then scopeName wouldn't be necessary and extracting a desired scope from the json structure would be easier

[MaciejG604]

@prolativ

• is extraDecls supposed to be dependent on the platform (e.g. can it hold some options for scala-native?) or is it scala-js only? In the latter case why isn't it called explicitly jsModuleKind? And why is this property both top-level and separately for main/test?

I would delete this field altogether and leave scala-j/scala-native options for follow-up PRs if needed. WDYT?

• If we specify scalaJsVersion and scalaNativeVersion, shouldn't we also include e.g. the version of js itself or JVM, if it's specified explicitly?

By "the version of js itself" do you mean Scala.js ECMA Script version?

[MaciejG604]

[UPDATE]
Added structured dependency json objects, moved scalacOptions and scalaCompilerPlugins to scopes.
Added jvmVersion and jsEsVersion field.

For now the export --json result contains the following information about the project:

• projectName
• scalaVersion that's visible in the Main scope
• platform only one that's visible in the Main scope
• jvmVersion only if declared explicitly
• scalaJsVersion that's visible in the Main scope, only if the platform is JS
• jsEsVersion only if declared explicitly
• scalaNativeVersion that's visible in the Main scope, only if the platform is Native
• mainClass
• scope specific infromation as a map of (scope name -> following information):
  • sources list of subpaths to the source files
  • scalacOptions
  • scalaCompilerPlugins as structured json
  • dependencies as structured json
  • resolvers presented as URL for Maven and ivy:pattern for Ivy
  • resourceDirs
  • customJarsDecls contains custom jars added to the project

Follow-ups to consider:

• cross-compilation
• resolver authentication
• scala-js/scala-native options

[prolativ]

LGTM in general.
Personally I'm not a big fan of jsEsVersion, because:

• this name is not very intuitive IMO
• ECMAScript seems to be the standard of the language rather than its implementation but for JVM we can specify that we want to use e.g. --jvm adopt:1.8.0-232 specifically rather than just --jvm 8.
  But at least it seems consistent with the name of the command line option

[kubukoz]

Just curious, what was the motivation for this change? I like it, might be very useful for packaging in Nix, just wanted to know what other usecases you had :)

[tgodzik]

The main use case we were thinking about is Scala Steward support, since there was a suggestion that export to sbt might be used as intermediary, which scared me a bit 😅

[fthomas]

That suggestion turned quickly into reality: scala-steward-org/scala-steward#2933 🙈 🤣