tasks.json

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  //https://code.visualstudio.com/docs/editor/tasks
  //https://code.visualstudio.com/docs/editor/tasks-appendix
  //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
  //https://github.com/thehaseebahmed/vscode-dotnet-docker-debug
  //https://www.youtube.com/watch?v=k0hpant9wXo
  "tasks": [
    {
      "label": "build: catalogs",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.Api/FoodDelivery.Services.Catalogs.Api.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://stackoverflow.com/questions/59830506/how-to-setup-an-auto-watch-run-for-net-core-3-1-projects-using-visual-studio-co
    //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
    //https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch
    {
      "label": "watch: catalogs",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "watch",
        "--project",
        "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.Api/FoodDelivery.Services.Catalogs.Api.csproj"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.Api"
      },
      "linux": {
        "options": {
          "env": {
            // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
            "DOTNET_USE_POLLING_FILE_WATCHER": "true"
          }
        }
      },
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
    },
    //https://github.com/microsoft/vscode-docker/issues/3831
    //https://docs.docker.com/engine/reference/commandline/build/#target
    // this task only build target stage here `final`, and we will change the entrypoint in 'ducker run' (we change entrypoint only in debug mode) with --entrypoint because we don't want our contaoner runs we will run our cotainer in debug mode with launching app from docker container remotly
    {
      "label": "docker-build-dev: catalogs",
      "command": "docker build --target final -f ${workspaceFolder}/src/Services/Catalogs/dev.Dockerfile --tag catalogs:dev ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-build-prod: catalogs",
      "command": "docker build --target final -f ${workspaceFolder}/src/Services/Catalogs/Dockerfile --tag catalogs:prod ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    //https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
    //https://laurentkempe.com/2022/11/14/dotnet-7-sdk-built-in-container-support-and-ubuntu-chiseled/
    //https://www.mytechramblings.com/posts/trying-out-the-built-in-container-support-for-the-dotnet-7-sdk/
    {
      "label": "docker-dotnet-publsih: catalogs",
      "command": "dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release",
      "type": "shell",
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.Api"
      },
      "problemMatcher": []
    },
    {
      "label": "docker-build-base: catalogs",
      "command": "docker build --target base -f ${workspaceFolder}/src/Services/Catalogs/dev.Dockerfile --tag catalogs:base ${workspaceFolder}",
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it catalogs-debug`
    {
      "label": "docker-run-debug: catalogs",
      "command": "${workspaceFolder}/scripts/docker/debug-run.sh catalogs-debug catalogs:dev 4000 4001 ${workspaceFolder}/src/Services/Catalogs/.env",
      "dependsOn": [
        "docker-build-dev: catalogs"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it catalogs-dev bash`
    {
      "label": "docker-run-dev: catalogs",
      "command": "${workspaceFolder}/scripts/docker/dev-run.sh catalogs-dev catalogs:dev 4000 4001 ${workspaceFolder}/src/Services/Catalogs/.env",
      "dependsOn": [
        "docker-build-dev: catalogs"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-prod: catalogs",
      "command": "${workspaceFolder}/scripts/docker/prod-run.sh catalogs-prod catalogs:prod 4000 4001 ${workspaceFolder}/src/Services/Catalogs/.env",
      "dependsOn": [
        "docker-build-prod: catalogs"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-base: catalogs",
      "command": "${workspaceFolder}/scripts/docker/base-run.sh catalogs-base catalogs:base 4000 4001 ${workspaceFolder}/src/Services/Catalogs/.env ${workspaceRoot}",
      "dependsOn": [
        "docker-build-base: catalogs"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-base: catalogs",
      "command": "docker container rm catalogs-base --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-debug: catalogs",
      "command": "docker container rm catalogs-debug --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "unit test: catalogs",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/tests/Services/Catalogs/FoodDelivery.Services.Catalogs.UnitTests/FoodDelivery.Services.Catalogs.UnitTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "integrtion test: catalogs",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.IntegrationTests/FoodDelivery.Services.Catalogs.IntegrationTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "end-to-end test: catalogs",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Catalogs/FoodDelivery.Services.Catalogs.EndToEndTests/FoodDelivery.Services.Catalogs.EndToEndTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "build: customers",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.Api/FoodDelivery.Services.Customers.Api.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      "group": {
        "kind": "build"
      },
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://stackoverflow.com/questions/59830506/how-to-setup-an-auto-watch-run-for-net-core-3-1-projects-using-visual-studio-co
    //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
    //https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch
    {
      "label": "watch: customers",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "watch",
        "--project",
        "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.Api/FoodDelivery.Services.Customers.Api.csproj"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.Api"
      },
      "linux": {
        "options": {
          "env": {
            // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
            "DOTNET_USE_POLLING_FILE_WATCHER": "true"
          }
        }
      },
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
    },
    //https://github.com/microsoft/vscode-docker/issues/3831
    //https://docs.docker.com/engine/reference/commandline/build/#target
    // this task only build target stage here `final`, and we will change the entrypoint in 'ducker run' (we change entrypoint only in debug mode) with --entrypoint because we don't want our contaoner runs we will run our cotainer in debug mode with launching app from docker container remotly
    {
      "label": "docker-build-dev: customers",
      "command": "docker build --target final -f ${workspaceFolder}/src/Services/Customers/dev.Dockerfile --tag customers:dev ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    //https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
    //https://laurentkempe.com/2022/11/14/dotnet-7-sdk-built-in-container-support-and-ubuntu-chiseled/
    //https://www.mytechramblings.com/posts/trying-out-the-built-in-container-support-for-the-dotnet-7-sdk/
    {
      "label": "docker-dotnet-publsih: customers",
      "command": "dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release",
      "type": "shell",
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.Api"
      },
      "problemMatcher": []
    },
    {
      "label": "docker-build-base: customers",
      "command": "docker build --target base -f ${workspaceFolder}/src/Services/Customers/dev.Dockerfile --tag customers:base ${workspaceFolder}",
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it customers-debug`
    {
      "label": "docker-run-debug: customers",
      "command": "${workspaceFolder}/scripts/docker/debug-run.sh customers-debug customers:dev 8000 8001 ${workspaceFolder}/src/Services/Customers/.env",
      "dependsOn": [
        "docker-build-dev: customers"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it customers-dev bash`
    {
      "label": "docker-run-dev: customers",
      "command": "${workspaceFolder}/scripts/docker/dev-run.sh customers-dev customers:dev 8000 8001 ${workspaceFolder}/src/Services/Customers/.env",
      "dependsOn": [
        "docker-build-dev: customers"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-base: customers",
      "command": "${workspaceFolder}/scripts/docker/base-run.sh customers-base customers:base 8000 8001 ${workspaceFolder}/src/Services/Customers/.env ${workspaceRoot}",
      "dependsOn": [
        "docker-build-base: customers"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-base: customers",
      "command": "docker container rm customers-base --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-debug: customers",
      "command": "docker container rm customers-debug --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "unit test: customers",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/tests/Services/Customers/FoodDelivery.Services.Customers.UnitTests/FoodDelivery.Services.Customers.UnitTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "integrtion test: customers",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.IntegrationTests/FoodDelivery.Services.Customers.IntegrationTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "end-to-end test: customers",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Customers/FoodDelivery.Services.Customers.EndToEndTests/FoodDelivery.Services.Customers.EndToEndTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "build: identity",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.Api/FoodDelivery.Services.Identity.Api.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      "group": {
        "kind": "build"
      },
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://stackoverflow.com/questions/59830506/how-to-setup-an-auto-watch-run-for-net-core-3-1-projects-using-visual-studio-co
    //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
    //https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch
    {
      "label": "watch: identity",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "watch",
        "--project",
        "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.Api/FoodDelivery.Services.Identity.Api.csproj"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.Api"
      },
      "linux": {
        "options": {
          "env": {
            // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
            "DOTNET_USE_POLLING_FILE_WATCHER": "true"
          }
        }
      },
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
    },
    //https://github.com/microsoft/vscode-docker/issues/3831
    //https://docs.docker.com/engine/reference/commandline/build/#target
    // this task only build target stage here `final`, and we will change the entrypoint in 'ducker run' (we change entrypoint only in debug mode) with --entrypoint because we don't want our contaoner runs we will run our cotainer in debug mode with launching app from docker container remotly
    {
      "label": "docker-build-dev: identity",
      "command": "docker build --target final -f ${workspaceFolder}/src/Services/Identity/dev.Dockerfile --tag identity:dev ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    //https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
    //https://laurentkempe.com/2022/11/14/dotnet-7-sdk-built-in-container-support-and-ubuntu-chiseled/
    //https://www.mytechramblings.com/posts/trying-out-the-built-in-container-support-for-the-dotnet-7-sdk/
    {
      "label": "docker-dotnet-publsih: identity",
      "command": "dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release",
      "type": "shell",
      "dependsOn": [
        "build: identity"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.Api"
      },
      "problemMatcher": []
    },
    {
      "label": "docker-build-base: identity",
      "command": "docker build --target base -f ${workspaceFolder}/src/Services/Identity/dev.Dockerfile --tag identity:base ${workspaceFolder}",
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it identity-debug`
    {
      "label": "docker-run-debug: identity",
      "command": "${workspaceFolder}/scripts/docker/debug-run.sh identity-debug identity:dev 7000 7001 ${workspaceFolder}/src/Services/Identity/.env",
      "dependsOn": [
        "docker-build-dev: identity"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it identity-dev bash`
    {
      "label": "docker-run-dev: identity",
      "command": "${workspaceFolder}/scripts/docker/dev-run.sh identity-dev identity:dev 7000 7001 ${workspaceFolder}/src/Services/Identity/.env",
      "dependsOn": [
        "docker-build-dev: identity"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-base: identity",
      "command": "${workspaceFolder}/scripts/docker/base-run.sh identity-base identity:base 7000 7001 ${workspaceFolder}/src/Services/Identity/.env ${workspaceRoot}",
      "dependsOn": [
        "docker-build-base: identity"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-base: identity",
      "command": "docker container rm identity-base --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-debug: identity",
      "command": "docker container rm identity-debug --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "unit test: identity",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/tests/Services/Identity/FoodDelivery.Services.Identity.UnitTests/FoodDelivery.Services.Identity.UnitTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "integrtion test: identity",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.IntegrationTests/FoodDelivery.Services.Identity.IntegrationTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "end-to-end test: identity",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Identity/FoodDelivery.Services.Identity.EndToEndTests/FoodDelivery.Services.Identity.EndToEndTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "build: orders",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.Api/FoodDelivery.Services.Orders.Api.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      "group": {
        "kind": "build"
      },
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://stackoverflow.com/questions/59830506/how-to-setup-an-auto-watch-run-for-net-core-3-1-projects-using-visual-studio-co
    //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
    //https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch
    {
      "label": "watch: orders",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "watch",
        "--project",
        "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.Api/FoodDelivery.Services.Orders.Api.csproj"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.Api"
      },
      "linux": {
        "options": {
          "env": {
            // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
            "DOTNET_USE_POLLING_FILE_WATCHER": "true"
          }
        }
      },
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
    },
    //https://github.com/microsoft/vscode-docker/issues/3831
    //https://docs.docker.com/engine/reference/commandline/build/#target
    // this task only build target stage here `final`, and we will change the entrypoint in 'ducker run' (we change entrypoint only in debug mode) with --entrypoint because we don't want our contaoner runs we will run our cotainer in debug mode with launching app from docker container remotly
    {
      "label": "docker-build-dev: orders",
      "command": "docker build --target final -f ${workspaceFolder}/src/Services/Orders/dev.Dockerfile --tag orders:dev ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    //https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
    //https://laurentkempe.com/2022/11/14/dotnet-7-sdk-built-in-container-support-and-ubuntu-chiseled/
    //https://www.mytechramblings.com/posts/trying-out-the-built-in-container-support-for-the-dotnet-7-sdk/
    {
      "label": "docker-dotnet-publsih: orders",
      "command": "dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release",
      "type": "shell",
      "options": {
        "cwd": "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.Api"
      },
      "problemMatcher": []
    },
    {
      "label": "docker-build-base: orders",
      "command": "docker build --target base -f ${workspaceFolder}/src/Services/Orders/dev.Dockerfile --tag orders:base ${workspaceFolder}",
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it orders-debug`
    {
      "label": "docker-run-debug: orders",
      "command": "${workspaceFolder}/scripts/docker/debug-run.sh orders-debug orders:dev 9000 9001 ${workspaceFolder}/src/Services/Orders/.env",
      "dependsOn": [
        "docker-build-dev: orders"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it orders-dev bash`
    {
      "label": "docker-run-dev: orders",
      "command": "${workspaceFolder}/scripts/docker/dev-run.sh orders-dev orders:dev 9000 9001 ${workspaceFolder}/src/Services/Orders/.env",
      "dependsOn": [
        "docker-build-dev: orders"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-base: orders",
      "command": "${workspaceFolder}/scripts/docker/base-run.sh orders-base orders:base 9000 9001 ${workspaceFolder}/src/Services/Orders/.env ${workspaceRoot}",
      "dependsOn": [
        "docker-build-base: orders"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-base: orders",
      "command": "docker container rm orders-base --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-debug: orders",
      "command": "docker container rm orders-debug --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "unit test: orders",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/tests/Services/Orders/FoodDelivery.Services.Orders.UnitTests/FoodDelivery.Services.Orders.UnitTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "integrtion test: orders",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.IntegrationTests/FoodDelivery.Services.Orders.IntegrationTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "end-to-end test: orders",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "test",
        "${workspaceFolder}/src/Services/Orders/FoodDelivery.Services.Orders.EndToEndTests/FoodDelivery.Services.Orders.EndToEndTests.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "build: gateway",
      "command": "dotnet",
      "type": "process",
      "args": [
        "build",
        "${workspaceFolder}/src/ApiGateway/FoodDelivery.ApiGateway/FoodDelivery.ApiGateway.csproj"
      ],
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://stackoverflow.com/questions/59830506/how-to-setup-an-auto-watch-run-for-net-core-3-1-projects-using-visual-studio-co
    //https://jasonwatmore.com/post/2021/06/24/vs-code-net-debug-a-net-web-app-in-visual-studio-code
    //https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch
    {
      "label": "watch: gateway",
      "command": "dotnet",
      "type": "process",
      //when we `run` app `dll`, inner `api project` working directory (will resolve to current working directory for app) that contains appsetings.json files or inner `bin directory` because when run app dll in this directory `app working directory` and `current working directory` will be set bin and because appsettings.json are there, so app can find this `appsettings.json` files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find `appsettings.json` files in current working directory, so we should explicitly specify working dir in `cwd`, this problem doesn't exist for `.csproj files` and their working dir always resolve `correctly` based on `api project`
      "args": [
        "watch",
        "--project",
        "${workspaceFolder}/src/ApiGateway/FoodDelivery.ApiGateway/FoodDelivery.ApiGateway.csproj"
      ],
      "options": {
        "cwd": "${workspaceFolder}/src/ApiGateway/FoodDelivery.ApiGateway"
      },
      "linux": {
        "options": {
          "env": {
            // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
            "DOTNET_USE_POLLING_FILE_WATCHER": "true"
          }
        }
      },
      "problemMatcher": "$msCompile",
      //https://code.visualstudio.com/docs/editor/tasks-appendix
      //https://code.visualstudio.com/docs/editor/tasks#_custom-tasks
      "group": {
        "kind": "build"
      },
    },
    //https://github.com/microsoft/vscode-docker/issues/3831
    //https://docs.docker.com/engine/reference/commandline/build/#target
    // this task only build target stage here `final`, and we will change the entrypoint in 'ducker run' (we change entrypoint only in debug mode) with --entrypoint because we don't want our contaoner runs we will run our cotainer in debug mode with launching app from docker container remotly
    {
      "label": "docker-build-dev: gateway",
      "command": "docker build --target final -f ${workspaceFolder}/src/ApiGateway/dev.Dockerfile --tag gateway:dev ${workspaceFolder}", //--no-cache
      "type": "shell",
      "problemMatcher": []
    },
    //https://learn.microsoft.com/en-us/dotnet/core/docker/publish-as-container
    //https://laurentkempe.com/2022/11/14/dotnet-7-sdk-built-in-container-support-and-ubuntu-chiseled/
    //https://www.mytechramblings.com/posts/trying-out-the-built-in-container-support-for-the-dotnet-7-sdk/
    {
      "label": "docker-dotnet-publsih: gateway",
      "command": "dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -c Release",
      "type": "shell",
      "options": {
        "cwd": "${workspaceFolder}/src/ApiGateway/FoodDelivery.ApiGateway"
      },
      "problemMatcher": []
    },
    {
      "label": "docker-build-base: gateway",
      "command": "docker build --target base -f ${workspaceFolder}/src/ApiGateway/dev.Dockerfile --tag gateway:base ${workspaceFolder}",
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it gateway-debug`
    {
      "label": "docker-run-debug: gateway",
      "command": "${workspaceFolder}/scripts/docker/debug-run.sh gateway-debug gateway:dev 3000 3001 ${workspaceFolder}/src/ApiGateway/.env",
      "dependsOn": [
        "docker-build-dev: gateway"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    // for see data inner container `docker exec -it gateway-dev bash`
    {
      "label": "docker-run-dev: gateway",
      "command": "${workspaceFolder}/scripts/docker/dev-run.sh gateway-dev gateway:dev 3000 3001 ${workspaceFolder}/src/ApiGateway/.env",
      "dependsOn": [
        "docker-build-dev: gateway"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-run-base: gateway",
      "command": "${workspaceFolder}/scripts/docker/base-run.sh gateway-base gateway:base 3000 3001 ${workspaceFolder}/src/ApiGateway/.env ${workspaceRoot}",
      "dependsOn": [
        "docker-build-base: gateway"
      ],
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-base: gateway",
      "command": "docker container rm gateway-base --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-remove-debug: gateway",
      "command": "docker container rm gateway-debug --force",
      "type": "shell",
      "problemMatcher": []
    },
    {
      "label": "docker-compose-build: infrastructures",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.infrastructure.yaml build",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://docs.docker.com/engine/reference/commandline/compose_up/
    //https://docs.docker.com/engine/reference/commandline/compose_start/
    {
      "label": "docker-compose-up: infrastructures",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.infrastructure.yaml up -d",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://code.visualstudio.com/docs/containers/reference#_docker-compose-task
    //https://docs.docker.com/engine/reference/commandline/compose_down/
    //https://docs.docker.com/engine/reference/commandline/compose_stop/
    {
      "label": "docker-compose-down: infrastructures",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.infrastructure.yaml down",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.html
    {
      "label": "docker-compose-build: debug services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.debug.yaml build",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.htmlk
    //https://docs.docker.com/engine/reference/commandline/compose_up/
    //https://docs.docker.com/engine/reference/commandline/compose_start/
    {
      "label": "docker-compose-up: debug services",
      "dependsOn": [
        "docker-compose: up infrastructures"
      ],
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      // to remove containers we use `docker-compose down`
      //https://docs.docker.com/compose/environment-variables/set-environment-variables/#substitute-with---env-file
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.debug.yaml --env-file ${workspaceFolder}/deployments/docker-compose/.env  --env-file ${workspaceFolder}/deployments/docker-compose/.env.dev up -d",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.html
    //https://docs.docker.com/engine/reference/commandline/compose_down/
    //https://docs.docker.com/engine/reference/commandline/compose_stop/
    {
      "label": "docker-compose-down: debug services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.debug.yaml down",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.html
    {
      "label": "docker-compose-build: dev services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.dev.yaml build",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.htmlk
    //https://docs.docker.com/engine/reference/commandline/compose_up/
    //https://docs.docker.com/engine/reference/commandline/compose_start/
    {
      "label": "docker-compose-up: dev services",
      "dependsOn": [
        "docker-compose: up infrastructures"
      ],
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      // to remove containers we use `docker-compose down`
      //https://docs.docker.com/compose/environment-variables/set-environment-variables/#substitute-with---env-file
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.dev.yaml --env-file ${workspaceFolder}/deployments/docker-compose/.env  --env-file ${workspaceFolder}/deployments/docker-compose/.env.dev up",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://www.richard-banks.org/2018/07/debugging-core-in-docker.html
    //https://docs.docker.com/engine/reference/commandline/compose_down/
    //https://docs.docker.com/engine/reference/commandline/compose_stop/
    {
      "label": "docker-compose-down: dev services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.dev.yaml down",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://docs.docker.com/engine/reference/commandline/compose_up/
    //https://docs.docker.com/engine/reference/commandline/compose_start/
    {
      "label": "docker-compose-up: prod services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      // to remove containers we use `docker-compose down`
      //https://docs.docker.com/compose/environment-variables/set-environment-variables/#substitute-with---env-file
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml --env-file ${workspaceFolder}/deployments/docker-compose/.env  --env-file ${workspaceFolder}/deployments/docker-compose/.env.prod up",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    //https://docs.docker.com/engine/reference/commandline/compose_down/
    //https://docs.docker.com/engine/reference/commandline/compose_stop/
    {
      "label": "docker-compose-down: prod services",
      "type": "shell",
      // https://docs.docker.com/compose/reference/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
      // https://docs.docker.com/compose/extends/
      "command": "docker-compose -f ${workspaceFolder}/deployments/docker-compose/docker-compose.services.yaml down",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "label": "script: install vsdbg ubuntu",
      "type": "shell",
      "command": "curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v vs2019 -l ~/vsdbg",
      "problemMatcher": [],
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    },
    {
      "type": "npm",
      "script": "prepare",
      "problemMatcher": [],
      "label": "npm: prepare",
      "detail": "husky install && dotnet tool restore"
    },
    {
      "type": "npm",
      "script": "install",
      "problemMatcher": [],
      "label": "npm: install dependencies",
      "detail": "install dependencies from package"
    }
  ]
}