[Anthony Martin (anthony-c-martin)]

See discussion in #146
Closes #4993
Closes #498
Closes #586

This PR changes the following:

• Allow functions to be split across multiple lines:

  var foo = resourceGroup(
    mySubscription,
    myRgName)

• Allow single-line object & array declarations (when used with commas):

  var foo = ['abc', 'def']
  var bar = {abc: 'def', ghi: 'jkl'}

• Allow mixing and matching of the above:

  var foo = ['abc', 'def'
    'ghi']
  var bar = {a: 'abc', b: 'def'
    c: 'ghi'}
  var baz = concat('foo', 'bar',
    'baz')

• Adds a code fix to switch between single- and multi-line declarations.

See Installing Nightly if you're interested in trying this out.

Here's a demo of this during the last community call: https://youtu.be/R6SyuRhTmmc?t=1145s

[Anton Sokolovskyi (antsok)]

Good stuff! Optional commas in arrays are great.
It can be used in decorators too, right ? @allowed(['slow', 'fast'])

please 🥇

[Anthony Martin (anthony-c-martin)]

Good stuff! Optional commas in arrays are great. It can be used in decorators too, right ? @allowed(['slow', 'fast'])

please 🥇

Yes it would work in decorators too

[Anthony Martin (anthony-c-martin)]

So I think the options here are:

1. Reject the implementation
2. Accept the implementation as-is
3. Accept the implementation, just for functions (no objects & arrays)
4. Accept the implementation, but block commas on multiline objects & arrays

I'm leaning most heavily towards option 4 - it's purely additive, doesn't introduce 2 different ways of multiline arrays/objects, but still gives us the option to introduce this in future if we want to.

[Anthony Martin (anthony-c-martin)]

I'm leaning most heavily towards option 4 - it's purely additive, doesn't introduce 2 different ways of multiline arrays/objects, but still gives us the option to introduce this in future if we want to.

We had a discussion on this today, and reached consensus on option 4, with code fixes to switch between single- and multi-line declarations. It leaves the door open to doing option 2 in the future if we get community feedback for it; whereas option 2 would be an irreversible decision.

The remaining open question was regarding the formatter. I've proposed just fixing indention and spacing without deciding whether a declaration should or shouldn't be multi-line. We had agreement on wanting to pick a sensible opinionated default, and wanted to discuss whether we should pick a more opinionated Prettier-like approach. Personally I feel like we're unblocked on this PR (with a basic formatter implementation), and can try to get feedback on a community call in the future on a more sophisticated auto-formatter.

[Shenglong Li (shenglol)]

Looks good! Just a minor suggestion.

[Ben Wilkinson (brwilkinson)]

Thank you for these improvements ✅

A few things, with some comments.

• Perhaps 1 or 2 of these may be interesting.
• Also some use cases, that I did not expect, however appear to be fine.

Before

1. "convert object to single line" code action

• not what I was expecting, however works fine

2. convert object to multiple lines

• looks good, it's just not indented.

then format

• now back to normal, with indenting

looks like convert to single line also puts different property values on new lines

it appears to build just fine

• this all seems to work well, in these use cases.
  

error messages

• I guess we can improve some messaging around the change i.e. I have to delete the comma.
  
  
  

• then format, works well