Skip to content
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

Merged
merged 3 commits into from
Dec 30, 2016
Merged

Add VSCode settings.json file. #330

merged 3 commits into from
Dec 30, 2016

Conversation

rkeithhill
Copy link
Collaborator

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.

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.
@rkeithhill
Copy link
Collaborator Author

BTW the sort alias fixup is essential on Linux/macOS as sort is not defined as an alias. So invoking sort actually invokes the native sort utility on those platforms.

@rkeithhill rkeithhill merged commit fdae331 into dahlbyk:master Dec 30, 2016
@rkeithhill rkeithhill deleted the rkeithhill/add-vscode-settings-file branch December 30, 2016 01:16
@dahlbyk
Copy link
Owner

dahlbyk commented Dec 30, 2016

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).

@rkeithhill
Copy link
Collaborator Author

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).

@dahlbyk
Copy link
Owner

dahlbyk commented Dec 30, 2016

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/.

@rkeithhill
Copy link
Collaborator Author

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. :-)

@rkeithhill
Copy link
Collaborator Author

BTW do you have an opinion on whether we should set the charset? utf-8?

@dahlbyk
Copy link
Owner

dahlbyk commented Dec 31, 2016

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.

@rkeithhill
Copy link
Collaborator Author

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?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants