In the extension it seems that the httpyac root folder is always assumed to be vscode's root folder. So the extension looks for an env
folder, or a package.json
with httpyac
key, or a .httpyac.json
file there. I think this works fine in a lot of cases but it may break down in a few (ex: monorepo or strict hierarchical structure).
Example
I recently tried something like this:
|__ tests
|__ http
|__ env
| |__ .env
|__ requests
| |__ something.http
|__ package.json
In this structure, it seems the CLI will have no issues if run from /tests/http
as it will assume this is its root folder (I think), but vscode will only look in its own project root so that the options have to be configured there:
|__ tests
| |__ ...
|__ .httpyac.json
Personally I would prefer to keep everything in the /tests/http
folder in this case.
Suggestion
This works but if at all possible, it would be nice to do something like this for vscode:
- look into the current folder for config settings and defaults
- if not found, look one folder up
- until reaching vscode's project root (and then give up)
I realize this may be confusing to the extension if we have something like this:
|__ monorepo
|__ tests1
|__ env
| |__ .env
|__ requests
|__ .httpyac.json
|__ tests2
|__ env
| |__ .env
|__ requests
|__ .httpyac.json
When running something from tests1
no problem.. tests1
's settings will apply, but then when running something from tests2
perhaps vscode-httpyac will not be sure what to do (which environments to show and/or apply). If it is possible to namespace and fully isolate when 2 or more configs are found this would be my preference, so that anything from tests1
is invisible to tests2
... and when looking at a file in tests2
nothing from tests1
one shows or applies.