blacklight / nvim-http

An HTTP client for neovim inspired by vscode-restclient and the IntelliJ HTTP client
MIT License
87 stars 5 forks source link

Use a command for variables value #1

Open remche opened 1 year ago

remche commented 1 year ago

Congrats for the great work on this plugin !

Would it be worth considering to use a command for the json variables values ? ie something like :

{
  "dev": {
    "base_url": "http://localhost:3000",
    "jwt_token": $(gopass show pass/mytoken)
  },
  "prod": {
    "base_url": "https://foobar.eu-west.some-cloud.com",
    "jwt_token": "SECRET"
  }
}
blacklight commented 1 year ago

That's an interesting proposal, and I definitely see the use case. However, I'm a bit skeptical about the specific implementation for two reasons:

  1. It would break the JSON specification, and therefore the compatibility with the REST clients on VSCode, IntelliJ, Postman and the likes.
  2. It would open the doors to potential command injection, especially when the command can contain references to external variables - and let's not even get started on everything that can go wrong when parsing the command or injecting its output into the JSON...

Perhaps this could work better if implemented through standard shell environment variables. Two possible ways to implement it:

  1. The simple way - you run export jwt_token="$(gopass show pass/mytoken)" before running neovim, and the existing environment variables are joined to the lookup map, so you can use ${jwt_token} in your requests. Support for .env files is also on my roadmap, but I don't think it would solve your specific use-case - you need dynamic, not static variables.
  2. With custom pre-request scripts - defined either per-environment or on global level. Something along the lines of:
{
  "dev": {
    "__before__": "scripts/setup.dev.sh",
    "base_url": "http://localhost:3000"
  }
}

Then scripts/setup.dev.sh would look like this:

export jwt_token="$(gopass show pass/mytoken)"

This would actually be quite powerful because it would enable to run any custom logic before a request (not only variables), and it may also allow for an __after__ script that can e.g. cleanup things after a request.

How would you consider these options?

remche commented 1 year ago

@BlackLight thanks for the feedback, I totally agree that my proposed implementation is not relevant, it was more to get the idea.

In my workflow, the first and easiest implementation is the best : I use a "lightweight workspace manager" (https://github.com/jamesob/desk), in fact mainly a bunch of shell script setting environment variables. I can rely on this variables to pimp the JSON.