Remove v1 formatter

[shenglol]

The PR removes the v1 formatter from the codecase.

Will send another PR to remove the prettyPrinting feature flag given that the PR is already overloaded with many file changes.

Closes #11733.

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Test this change out locally with the following install scripts (Action run 7978058887)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 7978058887

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 7978058887"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 7978058887

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 7978058887"

[github-actions]

Test Results

    66 files   -     33      66 suites   - 33   21m 51s ⏱️ - 28m 17s
10 641 tests  -    395  10 640 ✅  -    396  1 💤 +1  0 ❌ ±0 
25 172 runs   - 13 707  25 170 ✅  - 13 709  2 💤 +2  0 ❌ ±0 

Results for commit c1f1fdc. ± Comparison against base commit 4e07d82.

♻️ This comment has been updated with latest results.

[shenglol]

Should probably merge this after the hotfix release is published.

[anthony-c-martin]

Did you make a decision on what the default width should be?

[shenglol]

Not yet, but I'm leaning towards 100 as an optimal value - 80 feels a bit constrained, while 120 might be too wide for those without high-resolution screens. I'll arrange for a vote during our upcoming Bicep community call to decide and will update the code accordingly.

[anthony-c-martin]

I'm slightly concerned that people may be opinionated about making the decision to automatically wrap vs preserving formatting.

For example, if I've chosen to write:

var foo = [
           'short'
]

I might expect the formatter to format it to:

var foo = [
  'short'
]

But this feels unexpected and possibly undesirable:

var foo = [ 'short' ]

Is there any ability to configure this behavior?

I'm probably more opinionated than most, but to give an example, I personally strongly dislike the lack of freedom over formatting that we have in our .ts files in the src/vscode-bicep project. I find a lot of the automatic formatting far less readable, and often unneccessary.

[shenglol]

Currently, no, but this is implemented for objects, and we can easily turn it on for arrays. Would you consider this a valuable topic to bring up for discussion at our upcoming Bicep community call?

[anthony-c-martin]

By the way, my point here isn't to say "my way is better", I'm just using myself as an example of "people can be have strong opinions about formatting".

[shenglol]

I think this may make more sense if we end up deciding to use a larger width (say 120) as it may lead to long single line arrays 🤔.

[anthony-c-martin]

Currently, no, but this is implemented for objects, and we can easily turn it on for arrays. Would you consider this a valuable topic to bring up for discussion at our upcoming Bicep community call?

Yeah, I think it definitely wouldn't hurt to bring up. I'm not sure what sort of usage the current formatter gets, so it's difficult to gauge how important it is.

[shenglol]

We could also introduce a setting to allow users to refine this behavior further. A useful feature might be the ability to split objects and arrays not just based on width, but also considering the quantity of properties or items they contain (e.g., always break an array if it contains more than 2 items).

[StephenWeatherford]

some comments

[shenglol]

Had an offline chat with @anthony-c-martin, and we agreed to reintroduce the v1 formatter after this PR is merged. We'll implement a new feature flag enabling users to revert to the v1 formatter in the Bicep CLI and Bicep VS Code extension, in case there are any overlooked regressions with the v2 formatter. This approach ensures a more secure migration strategy.