Controlling active environment programmatically

[wusawo]

Hi,
I have implemented an additional custom environment and variables provider local to my project by using the hooks provideEnvironments and provideVariables. There is a dependency between a custom environment and another environment (realized with the default httpyac environment functionality).
Is there a chance to additionally select (set active) the related environment when the vscode user activates one of my custom environments (by toggle environment command, codelens, environment window and so on). I have already tried to set context.httpFile.activeEnvironment from within provideEnvironments and provideVariables of my custom environment provider. The the toggle environment dialog was never updated accordingly; whereas the codelens environment was updated after some time / after some interaction. Also I am not sure if the variables of the related environment are loaded reliably because they are not shown in the variables window but with the show variables command.

Thanks for any hints

[AnWeber]

You've already gone relatively deep into my api. I am very pleased.
I think what you have in mind is relatively complicated to implement. You would need to fire a documentStoreChanged as this will update the CodeLens display. The easiest way would be to access my extensionApi (type) like I used it in httpbook. I would then register a callback on environmentChanged and subsequently fix the environment and trigger a new environmentChanged.

some copy pasted code with no warranty:-) can be used in .httpyac.js

const vscode = require("vscode");
if(vscode){
  const httpyacExtension = vscode.extensions.getExtension<HttpYacExtensionApi>('anweber.vscode-httpyac');
  if (httpyacExtension?.isActive) {
    const httpyacExtensionApi= httpyacExtension.exports;
    httpyacExtensionApi.environmentChanged((env: Array<string> |undefined) => {
       // ... fix my environment and rule the world code
     httpyacExtensionApi.documentStore.documentStoreChangedEmitter.fire();
   });
}

This solution works only for VSCode. I would additionally implement a parseEndRegion hook, which also checks the environments during parsing and corrects them if necessary. This would provide the functionality for the CLI as well.

To test if your change does work, you could view internal httpFile object in my debug tree provider.

[AnWeber]

@wusawo One more question, because I thought about it again. Why do you actually make new environments that are selected with instead of just reacting to the existing environments and adding your logic there. Several variable providers are allowed to supply variables for an environment at the same time, that would simplify the whole construct.

[wusawo]

@AnWeber sorry for my late response. Thank you for your additional thoughts
My idea is to use httpyac's environment concept for two things: runtime environments and test data sets

• runtime environment: describes simple properties like host names, ports, credentials etc. It refers to the typical environments like dev, test, qa, prod used for the degree of maturity of the code.
• test data set: describes a complex (persisted) data set that exists in a specific runtime environment. It is data needed for testing the system-under-test; it not only lives in the system-under-test but also in various neighbor systems wired together for a particular runtime environment. Because of this a test data set is specific to one runtime environment. Of course, for different test scenarios, multiple test data sets are meaningful.

That gives the following relationship:

 "runtime environments"          "test data sets"       
 realized by httpyac's           realized by custom     
 IntelliJ env provider           env provider           
                                                        
    +--------------+         +-------------------------+
    |              |         |                         |
    |              |     ----|---- testDataSetA        |
    |           ---|----/    |                         |
    |     prod1    |         |                         |
    |           ---|----\    |                         |
    |              |     ----|---- testDataSetB        |
    |              |         |                         |
    |              |         |                         |
    |              |         |                         |
    |     prod2 ---|---------|---- testDataSetC        |
    |              |         |                         |
    |              |         |                         |
    +--------------+         +-------------------------+

I liked the idea of creating a custom env provider for these test data sets. It allows building test data with complex (and even nested) objects and all available Javascript types (instead of only string values). It nicely integrates in the httpyac vscode UI. I can easily select testDataSetA via "toggle environment" command and also switch between different test data sets easily in vscode.

Meanwhile I was able to select the necessary runtime environment for a selected test data set by following your hint and implementing a listener for the environmentChanged event. It works even without retriggering a new event by httpyacExtensionApi.documentStore.documentStoreChangedEmitter.fire().
I am also able to filter valid test data sets for a selected runtime environment in my custom env provider.
I was struggling a bit with global variable state as the module httpyac.config.js is called multiple times by httpyac. Now i remember global state on the process object of node.js to cache the defined test data sets that I read from a custom json file.
I still need to gain some experience with this setup ;-)

BTW: I was wondering about the differences between the .json (.httpyac.json) vs. .js (httpyac.config.js) config files. Can both contain javascript code?

[AnWeber]

BTW: I was wondering about the differences between the .json (.httpyac.json) vs. .js (httpyac.config.js) config files. Can both contain javascript code?

In JSON Files no script usage is possible. Some developers prefer using json files because of security concerns. Webpack, Eslint, ... all provide options to allow only json configurations. I just mimicked this tooling.

I was struggling a bit with global variable state as the module httpyac.config.js is called multiple times by httpyac

httpyac.config.js is executed on every change in a http file (every parse). If I cache the script execution, I would need to detect updated configuration and script files. It was just too complicated for a minor win.