Skip to content

Migrate request history and internal state storage to VS Code's globalStorage API #1441

Description

@ariellourenco

Hi team! First of all, thank you for building and maintaining this incredible extension. It is a staple in the workflow of millions of developers. I am opening this issue to start a discussion around adopting a more modern and standardized VS Code API for managing internal files, specifically the Request History data. Currently, the extension writes history files or internal configurations directly to user or custom home directories. Following modern VS Code extension design patterns ("good VS Code citizenship"), it is highly recommended to migrate these to the official ExtensionContext.globalStorageUri API.

Why migrate to globalStorage?

Using the native globalStorageUri provided by the VS Code API brings several major benefits:

  1. Zero System Pollution (Clean Home Directory): Users increasingly prefer that extensions do not create custom dotfiles or hidden folders directly inside their user profile root folder (~).
  2. Automatic Isolation: VS Code sandbox-isolates globalStorage exactly under the extension's unique ID (Huachao.rest-client). This guarantees no file name conflicts with any other system tool or extension.
  3. Permission Safety: globalStorage guarantees read/write permissions out of the box across Windows, macOS, and Linux, eliminating edge-case permission bugs without needing complex OS-checking logic (process.platform).
  4. Lifecycle Management: When a user uninstalls the extension, VS Code can cleanly manage or purge the associated globalStorage container, preventing leftover "digital rot" on the host machine.

Migration Path (Backwards Compatibility)

To ensure existing users do not lose their current request history, the activation sequence could check if the old legacy folder exists. If found, the extension can smoothly copy/move those historical JSON/text files into the new globalStorageUri path once, and then deprecate the old path.

I would love to hear your thoughts on this! If you are open to this enhancement, I would be more than happy to help draft a Pull Request to implement this migration.

Thank you for your time and consideration!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions