Newlines in multiline string from JSON modules are emitted as escaped sequence incorrectly

[yfakariya]

Bicep version
0.28.1

Describe the bug
If we use JSON modules which have multiline string (valid ARM template json), the string is built with invalid ARM Template JSON.

For example, a JSON module declares following multiline string:

    "outputs": {
        "main": {
            "type": "object",
            "value": "[concat(
                'first',
                'second'
            )]"
        }
    }

When we import above module and run az bicep build, it will be expanded as following:

        "template": {
          ...
          "outputs": {
            "main": {
              "type": "object",
              "value": "[concat(\r\n                'first',\r\n                'second'\r\n            )]"
            }
          }
        }

The line of "value" should be:

              "value": "[concat(
                'first',
                'second'
            )]"

To Reproduce

1. Create valid ARM template file which uses multiline string.
2. Import the ARM Template as module.
3. Run az bicep build to build the bicep file.
4. Check built JSON file.

Additional context

I did not deploy above built template file, so it might be valid in actual ARM API even if I and vscode extension treat as error.

[jeskew]

Is the concern here about platform differences? Including unescaped newline literals in a JSON string is not valid according to the JSON spec, but you're right that both the ARM service and Bicep will accept such templates and just treat the newline literals as if they had been escaped.

One potential difference that springs to mind is that unescaped newline literals will be adapted to the platform default if you are using Git's autocrlf feature, whereas escaped line endings will be left as is. In the example provided, you are stuck with Windows line endings (\r\n) even if you check the Bicep file out on a Linux or OSX platform since the compilation happened on Windows. Whether that is a bug or feature depends on the use case, so I would have backwards compatibility concerns about changing this behavior.

[yfakariya]

Thank you for answer. I understand that escaped and unescaped literals are identical as multiline string literals in ARM template. So, I think that it is reasonable to emit escaped literals for multiline strings.

For your reference, my concern was following two things:

1. I dit not believe that escaped string literals would be treated as unescaped literals as multi-line string. I understand that escaped string literals will be treated as unescaped one.
2. I thought that it is better if the multiline string should be round-tripped in decompile-rebuild loop. Because I have a project to migrate existing ARM templates to bicep scripts and I want to confirm correctness of decompilation with re-build the decompiled .bicep files to .json files and check diffs. Imported templates with escaped string literals are noisy for that case. So I think that it is better if we choice to unescaped literals in built json.

[anthony-c-martin]

Thanks for the explanation! Bicep will preserve semantic equivalence according to the JSON spec, but there's no guarantee that the formatting (non-semantic) will be preserved.

I'm going to close this out, as it's behaving as expected, and I don't think we can reasonably change this.