You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 31, 2023. It is now read-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds a new feature to the VSCode extension. It allows to watch changes to the rome.json file and when new changes occur, a listener sends a request. The server will listen to this request and will update the workspace settings.
I also added and change some logs, and used the debug trace instead. Our filter used the DEBUG level.
My main concern is around naming where there is a mix between "Settings" and configuration
I can see the confusion that settings and configuration can cause, and I think it could make sense to normalize the naming convention. Although, these two different names allow us to create a distinction:
the concept of configuration belongs to the users: user-friendly data structure, data structure we need to serialize/deserialize
the concept of settings belongs to us developers - and the Workspace, where the configuration is actually transformed into another data structure that fits the needs of Rome's infrastructure. An example is the "globals": [""] field, which is transformed into a Matcher data structure
If we decided to normalize the naming convention, we might risk to lose this distinction. What do you think? How can we improve this division?
My main concern is around naming where there is a mix between "Settings" and configuration
I can see the confusion that settings and configuration can cause, and I think it could make sense to normalize the naming convention. Although, these two different names allow us to create a distinction:
* the concept of configuration belongs to the users: user-friendly data structure, data structure we need to serialize/deserialize
* the concept of settings belongs to us developers - and the `Workspace`, where the configuration is actually **transformed** into another data structure that fits the needs of Rome's infrastructure. An example is the `"globals": [""]` field, which is transformed into a `Matcher` data structure
If we decided to normalize the naming convention, we might risk to lose this distinction. What do you think? How can we improve this division?
Oh, I wasn't aware that these are two different things. It may then make sense to keep the distinct names.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a new feature to the VSCode extension. It allows to watch changes to the
rome.jsonfile and when new changes occur, a listener sends a request. The server will listen to this request and will update the workspace settings.I also added and change some logs, and used the
debugtrace instead. Our filter used theDEBUGlevel.Test Plan
I manually tested the feature