We have a settings.ts module which abstracts the vscode settings interface, to gain important features such as type-checking, validation, and error handling.
The vscode globalState interface is very similar to the vscode settings interface, and has the same limitations and potential for bugs: the data is user-defined and arbitrary, thus the types are unknown and must always be runtime-checked, which is a verbose and often overlooked step.
justinmk3
commented
2 months ago
Problem
We have a settings.ts module which abstracts the vscode settings interface, to gain important features such as type-checking, validation, and error handling.
The vscode globalState interface is very similar to the vscode settings interface, and has the same limitations and potential for bugs: the data is user-defined and arbitrary, thus the types are unknown and must always be runtime-checked, which is a verbose and often overlooked step.
Examples:
redshiftState.tshttps://github.com/aws/aws-toolkit-vscode-staging/pull/1034/filesaws.lastUploadedToS3Folderhttps://github.com/aws/aws-toolkit-vscode/pull/3183/filesExtensionUseclass https://github.com/aws/aws-toolkit-vscode/pull/3634/filesSolution
globalStatewrapper, similar tosrc/shared/settings.ts.redshiftState.tsmodule into the centralizedglobalStatemodule.License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.