Allow discovery of functions in nested directories

[ryancole]

As far as I'm aware, the func host start command currently requires a directory structure in which the function.json files reside in directories that are siblings to the host.json - or the function project root. So, currently a directory structure something like ..

project-root/
  host.json
  function-one/
    function.json
  function-two/
    function.json

I'm familiar with the two config options for specifying script location and entry point, but those two still require that the function host can discover the function.json.

Would it be possible to add a config option to allow the function host to discover functions that are nested deeper than one directory? Perhaps something that might let me structure a directory like ...

project-root/
  host.json
  src/
    account/
      get-all/
        function.json
      get-single/
        function.json
      create/
        function.json
    client/
      get-all/
        function.json

... and so on.

With this, in combination with the already existing options to specify script location, you could pretty much structure a more complex functions app in any way you want. It'd work great with multi-function typescript projects, where the compiled output goes into a lib folder, as well.

[granmoe]

This would be amazing. Without it, multi-function apps quickly become disorganized.

[leftclickben]

Not supporting this is frankly ridiculous.

[mhoeger]

cc: @paulbatum @jeffhollan

[paulbatum]

It is probably straightforward to make the runtime capable of discovering functions in nested directories. However there would be a larger work item to make sure that tooling knows how to interact with nested functions correctly. For example, I suspect the editor in the Azure portal would not handle this correctly today. More tooling analysis is required before we consider making this runtime change.

[fabiocav]

Another approach here is to leverage the build process to generate the appropriate output but still support the file structure and code management to follow the model above.

[mhoeger]

This isn't ideal for scripting languages like JavaScript that don't necessarily require a build process, but doesn't mean we can't include one!

[ElementalCyclone]

I don't know if this behavior is specific to class library type project.
In my case, on class library type project, by attributing each method that correspond to a function with [Function("FunctionName")], even though its .cs file is nested somewhere, it will be loaded (at least that's what the cli from func.exe said)

haven't tested it on Azure or even doing request to those endpoints locally

[csandman]

I completely agree that this is a necessary feature to be implemented, for http functions this seems like an obvious choice.

The only workaround I've tried to kind of mimic this is adding a prefix to the function directories and changing the route in the function.json

A folder structure something like this:

project-root/
  host.json
  account_get-all/
    function.json
    index.js
  account_get-single/
    function.json
    index.js
  account_create/
    function.json
    index.js
  client_get-all/
    function.json
    index.js

with a function.json that looks something like this:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get"],
      "route": "account/get-all"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
  ]
}

This does not fix the problem and I still completely agree that this should be a feature, however this should at least order your functions correctly which has ended up being my biggest issue.