New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for v1.0 #730

Closed
olafurpg opened this Issue Feb 11, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@olafurpg
Member

olafurpg commented Feb 11, 2017

Scalafmt v0.1 came out in March 2016. Here are some stats in January 2017

  • 3 maintainers (including myself)
  • 40 contributors
  • ~10k downloads from Maven last month alone
  • ~1k fat jar downloads from github releases last month alone
  • IntelliJ plugin is at ~23k downloads in total, with >6k installs on the latest 0.5.x series
  • 56 releases (!!)

It's been a really great year, and I'm super thankful for everyone who has been involved in the project so far. I have enjoyed it a LOT and I look forward to continue working on scalafmt.

The formatting output is fairly stable now (big changes like in v0.5.0 to the default style typically provide fallback config for old styles). I think now is a good time to start thinking about releasing v1.0.

I saw somewhere on the interwebs.

If you want to go quickly, go alone. If you want to go far, go together

I admit it's a bit cheezy, but it does strike a chord with me.

These are organizational things I'd like to get done first

  • Move the project under the umbrella of scala.meta. I've discussed about this with @xeno-by and we both believe this is a good idea
  • Publish under org.scalameta instead of com.geirsson
  • Move docs to scalameta.org/scalafmt
  • publish docs on merge into master
  • Automatic releases on push tag
  • remove unsupported/dangerous options (e.g., bestEffortInDeeplyNestedFunctions, binpack.defnsite)
  • #875
    I'd be interested to hear what people think.

@olafurpg olafurpg added this to the v1 milestone Feb 11, 2017

@olafurpg olafurpg changed the title from Roadmap for v1 to Roadmap for v1.0 Feb 11, 2017

@pjrt

This comment has been minimized.

Show comment
Hide comment
@pjrt

pjrt Mar 3, 2017

Collaborator

Something that has been bugging me, and maybe 1.0 is the place to do this: do we want Scalafmt to be a fine-grain or an opinionated, holistic auto-formatting tool?

  • The tool started fine-grain: things like how many spaces to indent stuff to and whether to put a new line here or there.
    • Advantage: You can pretty much make your own style
    • Disadvantage: Confusing UI since settings might conflict with one another
  • Now we have some settings that throw all of that away and do a holistic approach, like the oddly named verticalMultilineAtDefinitionSite.
    • Advantage: It becomes clearer what you code will end up looking like and there are no conflict
    • Disadvantage: If you don't like it, well tough luck.

Currently we are supporting both of these approaches which can cause even more confusion. I'm on the camp of "full, holistic" reformat where we don't give the option for stuff like how many indents to make on a given closure. Of course we can still support different holistic styles for different sections (verticalMultilineAtDefinitionSite vs binPackedParamGroups <- made up). But I'm also aware that we will start getting a lot of "why not this!? Please make a setting for this?!".

Collaborator

pjrt commented Mar 3, 2017

Something that has been bugging me, and maybe 1.0 is the place to do this: do we want Scalafmt to be a fine-grain or an opinionated, holistic auto-formatting tool?

  • The tool started fine-grain: things like how many spaces to indent stuff to and whether to put a new line here or there.
    • Advantage: You can pretty much make your own style
    • Disadvantage: Confusing UI since settings might conflict with one another
  • Now we have some settings that throw all of that away and do a holistic approach, like the oddly named verticalMultilineAtDefinitionSite.
    • Advantage: It becomes clearer what you code will end up looking like and there are no conflict
    • Disadvantage: If you don't like it, well tough luck.

Currently we are supporting both of these approaches which can cause even more confusion. I'm on the camp of "full, holistic" reformat where we don't give the option for stuff like how many indents to make on a given closure. Of course we can still support different holistic styles for different sections (verticalMultilineAtDefinitionSite vs binPackedParamGroups <- made up). But I'm also aware that we will start getting a lot of "why not this!? Please make a setting for this?!".

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Mar 5, 2017

Member

That is a great point @pjrt. My view is that scalafmt should be opinionated and provide a unified formatting look across source files. Most users should only have to configure style = x and maxColumn = N and continue with their lives.

Is there anything in particular that you would like to change to make scalafmt more opinionated/holistic? For example, we could removesome sections from the online configuration docs https://olafurpg.github.io/scalafmt/#Configuration

I would argue that scalafmt is already quite opinionated. The only places where the users controls lines breaks is

  • "config style", so it's possible to format argument lists like this
List(
  1,
  2
)

even though it could fit within the max column setting.

  • infix applications, after having spent a significant amount of time trying to come up with schemes to automatically chose nice line breaks for infix applications I simply gave up. I still hope to fix this for common operators like &&/+, but I think it is the right long-term choice for arbitrary DSL operators. I think the AvoidInfix rewrite from @ysusuk helps to minimize unwanted infix operators.

  • blank lines, maybe we want to force extra blank lines before top-level methods, but I'm personally leaning towards respecting whatever is in the source.

Member

olafurpg commented Mar 5, 2017

That is a great point @pjrt. My view is that scalafmt should be opinionated and provide a unified formatting look across source files. Most users should only have to configure style = x and maxColumn = N and continue with their lives.

Is there anything in particular that you would like to change to make scalafmt more opinionated/holistic? For example, we could removesome sections from the online configuration docs https://olafurpg.github.io/scalafmt/#Configuration

I would argue that scalafmt is already quite opinionated. The only places where the users controls lines breaks is

  • "config style", so it's possible to format argument lists like this
List(
  1,
  2
)

even though it could fit within the max column setting.

  • infix applications, after having spent a significant amount of time trying to come up with schemes to automatically chose nice line breaks for infix applications I simply gave up. I still hope to fix this for common operators like &&/+, but I think it is the right long-term choice for arbitrary DSL operators. I think the AvoidInfix rewrite from @ysusuk helps to minimize unwanted infix operators.

  • blank lines, maybe we want to force extra blank lines before top-level methods, but I'm personally leaning towards respecting whatever is in the source.

@ysusuk

This comment has been minimized.

Show comment
Hide comment
@ysusuk

ysusuk Mar 6, 2017

Collaborator

you put a great points guys! shall we maybe integrate some monitoring/statistics into scalafmt and find out, if users agree to send us the info, what features/configs are used and hide/remove all unused one?

Collaborator

ysusuk commented Mar 6, 2017

you put a great points guys! shall we maybe integrate some monitoring/statistics into scalafmt and find out, if users agree to send us the info, what features/configs are used and hide/remove all unused one?

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Mar 6, 2017

Member

@ysusuk although I agree it would be nice to have those statistics, I am not sure the work required to collect the data outweighs the required effort.

Member

olafurpg commented Mar 6, 2017

@ysusuk although I agree it would be nice to have those statistics, I am not sure the work required to collect the data outweighs the required effort.

@pjrt

This comment has been minimized.

Show comment
Hide comment
@pjrt

pjrt Mar 13, 2017

Collaborator

The scala style guide recommends extendSite to be 2, we currently have it set to 4 by default.

Collaborator

pjrt commented Mar 13, 2017

The scala style guide recommends extendSite to be 2, we currently have it set to 4 by default.

@olafurpg

This comment has been minimized.

Show comment
Hide comment
@olafurpg

olafurpg Jul 9, 2017

Member

I just released v1.0.0 which was identical to v1.0.0-RC4.

Member

olafurpg commented Jul 9, 2017

I just released v1.0.0 which was identical to v1.0.0-RC4.

@olafurpg olafurpg closed this Jul 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment