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.

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

Removing "active" Key in Sessions File (Source Control Issues) #16

Closed
webia1 opened this issue Aug 19, 2024 · 3 comments
Closed

Removing "active" Key in Sessions File (Source Control Issues) #16

webia1 opened this issue Aug 19, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@webia1
Copy link

webia1 commented Aug 19, 2024

Dear Terminal Keeper Development Team,

First and foremost, thank you for creating such a fantastic extension. We rely on it daily, and it has greatly enhanced our workflow. Our teams work within an Nx MonoRepo, developing different apps and running various sessions.

However, there is a particular issue that has caused some frustration among team members. Every time a new session is started, the value of the "active" key (e.g., "active": "team-a-app-foo") is modified. Since the .vscode/sessions.json file is version-controlled, when another team submits a pull request, this value is replaced by the key of their own session (e.g., "active": "team-b-app-bar"). This results in frequent, unnecessary pull requests that only reflect this change, driving some of our colleagues to distraction. 🫣😇

As the Architect overseeing this process, I wanted to inquire whether the "active" key is truly necessary? Would it be possible to remove it entirely? Ideally, the sessions file should only be modified when new session configurations are added or existing ones are updated, rather than each time a session is started by a different team.

I hope my query is clear and makes sense. Your consideration of this request would be greatly appreciated.

Thank you very much in advance for your efforts.

Best regards,..

@nguyenngoclongdev
Copy link
Owner

@webia1 First of all, thank you for your feedback. It feels like you sent me a gift! I truly appreciate it. Even though it's small, it motivates me to create more great tools for the community.

Now, regarding the issue you raised, let me briefly explain the "active" field. This field is used to store information about the last active session. We use it to determine which session will be activated when you start VSCode.

To address your concern, you just need to set the "activateOnStartup" option to "false." This way, the terminal session won’t start on startup, and we won’t update the "active" field anymore.

Please give it a try with the latest version, v1.1.21.

Thank you!

@nguyenngoclongdev nguyenngoclongdev added the enhancement New feature or request label Aug 21, 2024
@nguyenngoclongdev nguyenngoclongdev self-assigned this Aug 21, 2024
@nguyenngoclongdev nguyenngoclongdev pinned this issue Aug 21, 2024
@webia1
Copy link
Author

webia1 commented Aug 21, 2024

Dear @nguyenngoclongdev, thank you for your thoughtful feedback.

You mentioned: "Now, regarding the issue you raised, let me briefly explain the 'active' field. This field is used to store information about the last active session. We use it to determine which session will be activated when you start VSCode."

For our use case—multiple independent teams from different departments or countries working on several apps within an NxMonoRepo—we would prefer that the "menu" for selecting a session is displayed every time VSCode is launched or reloaded, as it was previously.

This allows users to choose their session (which may involve multiple interconnected apps, such as an Angular frontend, a NestJS middleware, and a Git terminal in the same session) without any updates being made to sessions.json, which needs to be versioned.

While automatically starting the last session may be convenient for a single app development, it becomes an obstacle when multiple teams need to start various interdependent apps (with all teams working within the same NxMonoRepo).

In such cases, the active session from another team may need to be manually terminated and the desired session started, which can be cumbersome, especially if a previous merge request has already overwritten the active field.

For this extension to be suitable for enterprise environments (with international, globally distributed teams, multiple apps, and several departments):

  1. A previous or different session must not make changes to sessions.json, which needs to be versioned.
  2. If a team wants to automatically start a session, it would be better to configure this in settings.json (e.g., "start automatically and select this session for my team, or just for me"). This way, each team or team member can use its own workspace settings without interfering with others.

In other words, sessions.json should only list the sessions, while additional settings should be located in the workspace settings (which ideally are not versioned and therefore placed in .gitignore).

This approach would ensure that sessions.json remains clean, with changes only made when a new session configuration is created or an existing one is modified. From an enterprise perspective, it would make sense to separate sessions from their configurations.

BTW: Even if the workspace settings (settings.json) are versioned (as they currently are), and a team member changes a setting that annoys everyone else, that person will face the wrath of their teammates. We've already established a workflow and contingency plan for such situations. Currently, as the architect who introduced this extension, I’m the one catching all the heat (a bit exaggerated, of course).

In summary: The session selection should be displayed at each start or reload of VSCode, and once a team or team member selects the desired session configuration, it should be started without making any changes to sessions.json, which is versioned with the entire workspace.

This way, everyone on our side would be happy, and maybe we can also make somehow sure that you’re a bit happier too :)

Best regards,..

@nguyenngoclongdev
Copy link
Owner

nguyenngoclongdev commented Aug 22, 2024

@webia1 Thank you very much for your comments!

In the latest version (v1.1.23), we’ve updated the extension to allow you to set the "active" fields from the user configuration.

To avoid affecting previous users of Terminal Keeper, I’ve implemented a priority order for setting and updating. If you have a configuration in your user settings, we will prioritize reading and updating from there. If there's no configuration information in the user settings, we will read and update from the sessions file.

I hope this update will make your work easier!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants