-
-
Notifications
You must be signed in to change notification settings - Fork 801
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add VSCode settings.json file. #330
Add VSCode settings.json file. #330
Conversation
The settings file specifies trimTrailingWhitespace which is good for PowerShell scripts. Also specifies a path to a PSScriptAnalyzerSettings file. VSCode with the PowerShell extension will automatically lint the PowerShell scripts to find potential issues. I also took a whach at elminating some of the easy warnings to fix - like replacing aliases with full command names.
And a few more helpful ones as well.
BTW the |
I'm all for making sure we have a good experience in VSCode, since PS support seems like it's coming along quite nicely there, but for formatting rules we should prefer EditorConfig (VS Code extension). |
Possibly. I'll look into that later tonight. The nice thing about the VSCode rules is that it does no harm to other editors (other than loading an additional file). |
The idea behind an EditorConfig file is that everyone will have a consistent experience regardless of editor for the simple stuff like indent size, encoding, etc. Note also that VS includes native EditorConfig support as of 2017 RC1: https://blogs.msdn.microsoft.com/dotnet/2016/12/15/code-style-configuration-in-the-vs2017-rc-update/. |
Cool. That sounds like a good idea. Regarding VS for editing PowerShell, it might be lagging VS Code in some ways. I don't believe there is integration for the PSScriptAnalyzer (linter) or Pester (unit test framework). But Adam has done some great work on the PowerShell Tools extension for VS. Perhaps that is on FWIW, the PowerShell team is investing in the PowerShell extension for VS Code as the editor for PowerShell both on Windows and cross-platform. Part of the investment is in the PowerShellEditorServices which, like OmniSharp, can be hosted by other editors. Disclaimer: I'm likely heavily biased towards using VS Code because I'm a contributor/maintainer on the PowerShell extension for VS Code as well as PSES. :-) |
BTW do you have an opinion on whether we should set the charset? utf-8? |
I'm a-OK with VS Code bias - very impressed with it so far from a number of angles. (F# community is killing it with Ionide!) As for encoding, what has the PS community settled on? UTF-8 without BOM? I'm fine codifying that in EditorConfig, though I'm pretty sure GitUtils.ps1 is the only file with non-ASCII and I added a BOM to it just to be explicit. For others: #339 added a basic EditorConfig without charset. |
I prefer UTF-8 with BOM and I see that a number of the PowerShell built-in scripts have BOMs. But I've also heard that BOMs cause issues on Linux. Perhaps for now, we leave that setting out until such time we find it becomes necessary? |
The settings file specifies trimTrailingWhitespace which is good for PowerShell scripts. Also specifies a path to a PSScriptAnalyzerSettings file. VSCode with the PowerShell extension will automatically lint the PowerShell scripts to find potential issues. I also took a whach at elminating some of the easy warnings to fix - like replacing aliases with full command names.