Use of .httpyac.json

[asherber]

Really like some of the things you're doing with this extension!

I've got an .httpyac.json file that looks like this:

{
    "environments": {
        "$shared": {
            "variables": {
                "host": "www.example.com"
            }
        }
    }
}

I've tried putting this file next to my .http file, in the workspace root, in the .vscode folder, and in the env folder -- but my .http file isn't picking up the host variable. Where is this file supposed to go?

(As a side note, it would be nice if I could hover over variables in the .http file to see the resolved value, or an error if the variable can't be found. Currently, I have to submit the request and see the resulting error to suss out any problems.)

[AnWeber]

Here you can find an example how the use of a .httpyac.json would look like.
But unfortunately there is a bug. Currently the settings from the file are loaded but not used. I didn't notice it because I use .env files myself.

[asherber]

Thanks, I appreciate the correction on the format of the file, and I'll wait for the bug fix to hit the released version.

Can you please clarify where I should be able to put the file? Is it the same locations as for .env?

[AnWeber]

(As a side note, it would be nice if I could hover over variables in the .http file to see the resolved value, or an error if the variable can't be found. Currently, I have to submit the request and see the resulting error to suss out any problems.)

I've been thinking about this feature for a while, but I don't have an idea yet how to solve this without unreasonably high CPU and Memory consumption. The only way I can correctly determine all variables is to execute the request on every change in a http file.

• Variables defined in Javascript. Scripts loaded by require can also set variables.
• References to other responses, because here the return type is not known
• Environment variables loaded from e.g. Spring Config Cloud or Hashicorp Vault, which are different depending on selected environment (maybe cachable?).

I do not want to include this function only so half ready. vscode-restclient tries to implement this feature and has as a consequence the performance problems.

As a solution I have currently built in that you can display the current variables (command httpyac.showVariables). I will wrap this soon in a TreeDataProvider. I am open for good ideas.

[asherber]

Yes, I'm currently using rest-client but looking to switch because of all the goodies your extension offers. Intellisense evaluation of variables is one thing I do miss from rest-client; it lets me verify that I'm loading the correct values before I send the request. I understand that it's more complicated for your extension because of all the extra ways that variables can be set. 

How about something like a CodeLens link to display the variable values for the current request?

[AnWeber]

I will add a CodeLens link für the command httpyac.showVariables. I would have thought of CompletionItemProvider (better IntelliSense) as well, but just haven't gotten around to it yet.

[asherber]

Vielen Dank!

[AnWeber]

Es war mir eine Freude:-)

I have provided the update. Can you please also test it and give feedback?

Can you please clarify where I should be able to put the file?

.httpyac.js or .env are searched the directory tree upwards (till root). First found location is used.

[asherber]

Variable resolution with .httpyac.json seems to work as expected.

The 'show variables' link appears at the top of the file, and it doesn't take into account global variables in that file (or per-request variables). Is that the intent? I was picturing a link for each request, showing (as best as possible) everything in scope for that request.

'show variables' also opens an untitled document window, and then vscode prompts me to save when I close it.

[AnWeber]

showVariables just shows the current state of the variables. No code is executed during this process. You can simply execute the request and then view the variables.
An alternative would be to install httpyac on the command line and view the variables using {{debugger;}} (see docs).

I prevent the unexpected execution so explicitly, because I also create database entries in scripts, or combine writing services. However, in my cases I also have >80% of the variables in .env files and the remaining variables are generated in the same file, so it is easy for me to know the correct names. Do you dynamically create the variables in the NodeJs scripting part that it is difficult to know all the variable names present?

[asherber]

I understand about the limitations -- variables could come from anywhere, and you don't want to run all of the associated scripts in order to generate those.

All of my variables are either in .httpyac.json or in the .http file itself. With the 'show variables' link at the top of the file, I would expect at least that variables from the global section of the file would be evaluated. Instead, it looks like only json/.env variables are evaluated.

I think it would also be more useful to have this link for each request, and then to include in evaluation the per-request variables.

My goal is to be able to determine, before running a request, the values assigned to variables. This helps in troubleshooting, because it lets me see if maybe I've screwed up the inheritance chain. rest-client does this with IntelliSense for variables; I understand that you don't want to do this because of the overhead.

[AnWeber]

rest-client does this with IntelliSense for variables

rest-client does this, but you should have seen how many times I have got an breakpoint/ interrupt while debugging on my NodeJS PR (674). One keypress in the http file and +10 rechecking of the variables

I understand your concern. I have included exactly the command for troubleshooting. I run the request, and on errors I can look what variables are defined. You want to check the variables before sending and that makes sense for critical requests. I just don't quite like the way it works yet. I would rather implement the solution via DebugAdapater, but I don't have the time. Until then I'll implement my own command validateVariables, which prepares the request, resolves all variables but doesn't send the actual request them.

[AnWeber]

The command httpyac.validateVariables was rolled out with the new version.

[asherber]

Looks great, thanks!