How to run/debug Azure Functions project in a sub-folder in VS Code?

Question

I have a working node-based Azure Functions project that I am in the process of restructuring in order to have the Functions project be in it's own sub-folder (instead of having everything in the root directory). I'm trying to work my way toward a monorepo approach where I would (eventually) have the front-end of the app also in this same repo.

I have part of it working (more on that in a minute). But I need help getting the VS Code project to run/debug now that I have the Functions app in its own sub-folder.

Before I changed the folder structure I could debug the functions both locally in VS Code and once deployed to Azure via GitHub workflow action.

After placing the Functions app contents in their own sub-folder, I edited the Github workflow yaml file to specify the new sub-directory (by setting the AZURE_FUNCTIONAPP_PACKAGE_PATH). This has enabled me to push code to GitHub and have the normal trigger fire so that the code is built and deployed to Azure. So deploying to Azure works with my new sub-folder. And I can access everything in the Azure portal as I could before the folder restructure (the portal is not confused by the new folder structure).

Now my problem is getting VS Code to understand how to run my functions app locally.

I think there's some setting I need to change in one of the files in the .vscode directory since those seem to control the run cycle. But I can't figure out which property to edit. Thanks for your help!

Answer 1

I was able to able to make some progress on this by following guidance I found here.

I added a .code-workspace file and specified a path to my sub-folder. VS Code then noticed my nested Azure Functions app and offered to setup the .vscode folder within that sub-folder:

By opening that new workspace I am now able to run/debug the function app.

However, I am not yet able to just open the root directory (instead of the workspace) and run/debug. I tried adding the launch section in the .code-workspace file (as shown in the example from that article) but it would not accept entries for the launch/compounds/configurations property. Perhaps that failed since I only have one such sub-folder project right now?

I'll need to solve this last part in order to get to my goal of a monorepo approach where I have both the front-end and back-end projects in the same root folder.

Answer 2

@Jason Frank the code workspace approach is the simplest way to go which helps in keeping all configuration separate. For the root folder, you could add it as another folder to access it when opening the code workspace.

Another option that I am messing with recently is using Task Inputs that too could setup if it makes sense for you. For this, your tasks.json would have to look something like this

   {  
     "version": "2.0.0",  
     "tasks": [  
       {  
         "type": "func",  
         "command": "host start",  
         "problemMatcher": "$func-watch",  
         "isBackground": true,  
         "dependsOn": "yarn build",  
         "options": {  
           "cwd": "${workspaceFolder}/${input:functionapp}"  
         }  
       },  
       {  
         "type": "shell",  
         "label": "yarn build",  
         "command": "yarn run build",  
         "dependsOn": "yarn install",  
         "problemMatcher": "$tsc",  
         "options": {  
           "cwd": "${workspaceFolder}/${input:functionapp}"  
         }  
       }  
     ],  
     "inputs": [  
       {  
         "id": "functionapp",  
         "description": "Which Function App?",  
         "type": "pickString",  
         "options": [  
           "function-app-1",  
           "function-app-2"  
         ]  
       }  
     ]  
   }  

This would trigger a picker to show up to select which function app to debug. This works great for when working on a single function app within the monorepo but port conflicts arise if you want to work against multiple function apps.

Personally, I prefer using docker containers that mount the required folder (run as local user) and run func host start inside, allowing me to work across function apps and just use docker-compose to get all of them up and running at once.