As it currently stands, this is a breaking change (appropriate label added).

Based on our current POR, we're okay changing the default on non-Windows platforms, but this shouldn't be changed (yet) on Windows until we've had the breaking change conversation. /cc @JamesWTruher

I understand that this currently breaks the git scenario, we just have to be thoughtful about this.

Are there plans to add UTF8-NoBom to powershell supported Encodings?
I.e. for Set-Content and friends.

Changing the most important scenarios is good, but it would be great to address the problem with encodings broader and consistently to help shape the conversation about breaking changes.

@vors UTF8noBOM is discussed in RFC 0020 DefaultFileEncoding.

New-PSSessionConfigurationFile uses EncodingConversion.Unicode too.

@vors: first, yes. We're adding that (and making it the default across the board on Linux). The hard part is what to do with Windows (change the defaults? leave a legacy enum value for the "traditional" disparate defaults?) Which is why I want to have the discussion.

@joeyaiello good point;
PR updated to change encoding only for non-Windows.

Is there an actual problem on Windows using UTF8NoBOM? If only English is used, it's equivalent to an ascii file and Windows tools handle that just fine and I expect that to be the majority of use.

Restarted AppVeyor due to MyGet connectivity issue

@anmenaga if you could sync with @JamesWTruher before merging this, that'd be awesome. Assuming the @PowerShell/powershell-committee votes to accept tomorrow, we want to move to UTF8NoBOM everywhere.

@SteveL-MSFT

Is there an actual problem on Windows using UTF8NoBOM?

Users can add non-English comments in the manifest.

@iSazonov absolutely, but I believe the majority of usage is English. Even with non-ascii characters, my understanding is that notepad has heuristics to determine encoding to display it correctly. VSCode seems to support UTF8NoBom just fine.

notepad has heuristics to determine encoding to display it correctly

It seem works on last versions only not on Windows 7/8(?).

@joeyaiello Are you saying this is blocked on a sign off from @JamesWTruher ?

@joeyaiello @JamesWTruher Do we want to document the output format of Cmdlets?

@TravisEz13 yes and yes. I think the uber-point is that @JamesWTruher is doing so much work here, that it might get changed anyway (and it might just muddle his extensive notes).

Ultimately up to him, though. I just wanted to make sure everyone was on the same page.

Regarding docs though: heck yes. We'll have a Legacy value for Encoding, and that will be well-documented.

@anmenaga Also, as a PowerShell team member, you need to submit the PR to update the docs before I merge this. Please add a link to the PR here. Thanks.

For encoding changes, you might want to delay documenting as we expect big changes in this.

@TravisEz13

1. This PR in RFC repo was merged;
2. I've ran a search in PowerShell-Docs and didn't find any mentioning of encoding for New-ModuleManifest, so there is nothing to update there. Besides, this PR will be anyway overwritten by Jim's encoding work that is arriving soon.

@anmenaga Per the conversation in this PR, we want to add encoding documentation to the CmdLet docs.

@TravisEz13 Here is the doc PR: MicrosoftDocs/PowerShell-Docs#1405

My only issue here is that although this is a change that I agree with, I think that this is where I have concerns of this causing a disparate and inconsistent behaviour between all versions of PowerShell below v6 due to the fact that New-ModuleManifest is baked into the Microsoft.PowerShell.Core module.

I personally would much prefer to see that this update to the cmdlet gets released in a manner that fully supports being used on downlevel systems where PowerShell v6 is unable to be installed.

However the only real solutions that I can really see available to be able to make that to happen would be to

• Investigate the decoupling of a number of the cmdlets from the Microsoft.PowerShell.Core module into their own separate individual modules or a condensed updated singular module that has all the updates to any module in Microsoft.PowerShell.Core (not an overly fantastic solution) - similar in the idea put forward in Decouple the bundled modules to seperate Repo's #1979
• Look to recreate this cmdlet within the PowerShellGet module.
• Alongside the v6 updates look to release a completely updated and downlevel compatible version of the Microsoft.PowerShell.Core module to the PowerShell Gallery, which isn't really an overly viable solution either.

If this change could be easily replicated for downlevel versions of PowerShell I think that would be the best outcome all around.

@kilasuit Thanks for the feedback. I think most of the concerns raised would be best tracked in #1979 or a new issue.