Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🔧🚗 Migrate setting value of codeFormatting.whitespaceAroundPipe (if present) to new setting codeFormatting.addWhitespaceAroundPipe automatically. #2689

Merged
merged 5 commits into from
May 12, 2020
Merged

🔧🚗 Migrate setting value of codeFormatting.whitespaceAroundPipe (if present) to new setting codeFormatting.addWhitespaceAroundPipe automatically. #2689

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4e6e6b9
Migrate setting value of codeFormatting.whitespaceAroundPipe to new s…
May 10, 2020
09dd00c
fix code analysis warnings
May 10, 2020
0ab07f9
add comment to getConfigurationTarget and rename it to getEffectiveCo…
May 10, 2020
c69d197
try use quotes around undefined to see if it fixes codacy warning
May 10, 2020
10185d2
Update src/session.ts
bergmeister May 12, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions src/session.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,8 @@ export class SessionManager implements Middleware {

this.promptPowerShellExeSettingsCleanup();

this.migrateWhitespaceAroundPipeSetting();

try {
let powerShellExeDetails;
if (this.sessionSettings.powerShellDefaultVersion) {
Expand Down Expand Up @@ -320,6 +322,18 @@ export class SessionManager implements Middleware {
return resolvedCodeLens;
}

// During preview, populate a new setting value but not remove the old value.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may want to do this for the next stable release as well since a lot of customers only use stable.

After the next stable version, we can remove the old setting.

Copy link
Contributor Author

@bergmeister bergmeister May 10, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's exactly what I try to say: add new setting during preview but leave old setting still there (people who switch between preview/stable or use settings synchronization). Just before the next stable or in the last preview, I'd modify to to additionally remove the old setting. Is that clearer? But it sounds like we are both on the same page.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think so. Can you capture this in an issue so we don't forget?

I'd even suggest adding a TODO with the issue number... That way if we all disappear, someone could pickup where we left off

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened issue #2693 and will add a comment

// When the PowerShell extension releases the RTM version, then the old value can be safely removed.
bergmeister marked this conversation as resolved.
Show resolved Hide resolved
private async migrateWhitespaceAroundPipeSetting() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you wanna make this more of a utility function that takes in the old an new setting?

That'll be handy in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather defer it to when it is needed as it might be a YAGNI.
Or maybe I should create an NPM package for it so that I can break the Internet later one 😂
https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/

const configuration = vscode.workspace.getConfiguration(utils.PowerShellLanguageId);
const deprecatedSetting = 'codeFormatting.whitespaceAroundPipe'
if (configuration.has(deprecatedSetting) && !configuration.has('codeFormatting.addWhitespaceAroundPipe')) {
const configurationTarget = await Settings.getConfigurationTarget(deprecatedSetting);
const value = configuration.get(deprecatedSetting, configurationTarget)
await Settings.change('codeFormatting.addWhitespaceAroundPipe', value, configurationTarget);
}
}

private async promptPowerShellExeSettingsCleanup() {
if (this.sessionSettings.powerShellExePath) {
let warningMessage = "The 'powerShell.powerShellExePath' setting is no longer used. ";
Expand Down
28 changes: 23 additions & 5 deletions src/settings.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -245,12 +245,30 @@ export function load(): ISettings {
};
}

export async function change(settingName: string, newValue: any, global: boolean = false): Promise<void> {
const configuration: vscode.WorkspaceConfiguration =
vscode.workspace.getConfiguration(
utils.PowerShellLanguageId);
export async function getConfigurationTarget(settingName: string): Promise<vscode.ConfigurationTarget> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to get where the setting is currently set, yes?

A small comment would be appreciated

Copy link
Contributor Author

@bergmeister bergmeister May 10, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it gets the scope (they call it ConfigurationTarget) from where the effective setting is coming from (workspace settings override user settings, hence why the order is important here). If someone defined the old setting on both levels, we only look at the one that determines the effective setting and change that one. I'll add a comment and rename the function to getEffectiveConfigurationTarget to make it clearer.

const configuration = vscode.workspace.getConfiguration(utils.PowerShellLanguageId);

const detail = configuration.inspect(settingName);
let configurationTarget = null;
if (typeof detail.workspaceFolderValue !== undefined) {
configurationTarget = vscode.ConfigurationTarget.WorkspaceFolder;
}
else if (typeof detail.workspaceValue !== undefined) {
configurationTarget = vscode.ConfigurationTarget.Workspace;
}
else if (typeof detail.globalValue !== undefined) {
configurationTarget = vscode.ConfigurationTarget.Global;
}
return configurationTarget;
}

export async function change(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function is functionally still the same , only the configurationTarget parameter has been optimized to match exactly the called VS-Code API underneath.

settingName: string,
newValue: any, configurationTarget?: vscode.ConfigurationTarget | boolean): Promise<void> {

const configuration = vscode.workspace.getConfiguration(utils.PowerShellLanguageId);

await configuration.update(settingName, newValue, global);
await configuration.update(settingName, newValue, configurationTarget);
}

function getWorkspaceSettingsWithDefaults<TSettings>(
Expand Down