When a new class is created, it is invalid posix text file

[bdovh]

Summary

When using SFDX CLI or VS Code extenstion to create a new class, it is created as invalid posix text file since it is missing the final linebreak.

Steps To Reproduce:

1. Create a new class. Notice it doesn't have the final linebreak.

Expected result

By the posix definition of line,
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

3.206 Line
A sequence of zero or more non- characters plus a terminating character.

By the posix definition of text file,

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403

3.403 Text File
A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the character. Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.

So I would expect a new class to be created with newline break in the end of the file

Actual result

Actually new class is created without newline break in the end of the file

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)

• If you are using sfdx

  • Run sfdx version --verbose --json

• If you are using sf

  • Run sf version --verbose --json
    {
    "cliVersion": "sfdx-cli/7.197.8",
    "architecture": "darwin-x64",
    "nodeVersion": "node-v18.15.0",
    "osVersion": "Darwin 22.3.0",
    "shell": "zsh",
    "rootPath": "/Users/bdovh/.local/share/sfdx/client/7.197.8-077a68b",
    "pluginVersions": [
    "@mshanemc/plugin-streaming 1.1.7 (user)",
    "@mshanemc/sfdx-sosl 1.1.0 (user)",
    "@oclif/plugin-autocomplete 2.1.8 (core)",
    "@oclif/plugin-commands 2.2.13 (core)",
    "@oclif/plugin-help 5.2.9 (core)",
    "@oclif/plugin-not-found 2.3.23 (core)",
    "@oclif/plugin-plugins 2.4.4 (core)",
    "@oclif/plugin-search 0.0.15 (core)",
    "@oclif/plugin-update 3.1.10 (core)",
    "@oclif/plugin-version 1.3.2 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.33 (core)",
    "@oclif/plugin-which 2.2.18 (core)",
    "apex 2.2.12 (core)",
    "auth 2.7.12 (core)",
    "community 2.2.9 (core)",
    "custom-metadata 2.1.12 (core)",
    "data 2.3.10 (core)",
    "deploy-retrieve 1.8.12 (core)",
    "evergreen 0.34.0 (user)",
    "evergreen-build 0.20.2 (user)",
    "info 2.6.6 (core)",
    "limits 2.3.12 (core)",
    "org 2.6.12 (core)",
    "packaging 1.16.5 (core)",
    "schema 2.3.7 (core)",
    "settings 1.4.4 (core)",
    "signups 1.4.12 (core)",
    "source 2.10.2 (core)",
    "telemetry 2.1.3 (core)",
    "templates 55.4.7 (core)",
    "trust 2.4.7 (core)",
    "user 2.3.8 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "@salesforce/sfdx-scanner 3.11.0 (user)",
    "sfdx-cli 7.197.8 (core)",
    "shane-sfdx-plugins 4.43.0 (user)"
    ]
    }

Additional information

This brings issues when processing by posix text processors like awk, sed or others.

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[git2gus]

This issue has been linked to a new work item: W-13147281

[mshanemc]

I agree with you about the what the standards say.

The challenge is that metadata API retrieves from the server are also OFTEN missing the newline (we saw this while testing ApexClass), resulting in a lot of spurious git status and conflict noise.

I think this is more of a job for a linter/prettier to ensure all files have the ending you expect.

do you have an example of

This brings issues when processing by posix text processors like awk, sed or others.

[bdovh]

do you have an example of

This brings issues when processing by posix text processors like awk, sed or others.

Yes, I do.

https://stackoverflow.com/questions/76163376/can-i-prevent-awk-from-adding-extra-line-break-in-the-end-of-the-file

For example, I try to use some text processor to edit the file. By default, posix text processor append a new line in the end of the file following the posix standard. If I have 200 files, this brings 200 irrelevant file changes in my repository which I want to avoid.
Now if I deploy those metadata files to scratch org or sandbox and developer edition org, and then retrieve them again, they will be missing the terminating newline again, and now I will have another200 irrelevant file changes in my repository again....

[bdovh]

I was told there some a similar issue opened #970 two years ago but it was never fixed or resolved

[mshanemc]

followup on this--after some discussion and feedback from customers, we've decided the templates will be handled this way:

"the template should create whatever a retrieve from the org/metadata API would respond with" with the goal of minimizing "nuisance changes" that show up in tracking and git diffs. So you'll see some templates changing soon. Not all will end with an empty line.

If you want your codes styled in some other way and are ok dealing with the noise/diffs, you should use a linter for that.

And if you have some metadata that doesn't retrieve with empty lines, I encourage you to open support cases about those so the metadata team can make that change.