Azure-functions-host: 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.

[remirobichet]

This feature is definitely needed. As my application grow I struggle more and more organizing my folders..
I have implemented the only maintenable workaround (same as @csandman; and others in this related issue https://github.com/Azure/Azure-Functions/issues/1240)
Could we get some update on the roadmap ?

[jeffhollan]

We’ve been doing some active prototyping on a few options here - no ETA, but is definitely on the roadmap and a capability we recognize is needed. Potentially later this calendar year. It’s also worth noting it’s mainly the function.json that needs to be in a specific spot. It can reference .js modules from elsewhere using the “scriptFile” property

// @anthonychu @mhoeger

[llimos]

It’s also worth noting it’s mainly the function.json that needs to be in a specific spot. It can reference .js modules from elsewhere using the “scriptFile” property

@jeffhollan Perhaps the host.json functions property could be extended to accept the full contents of the function.json (instead of just the function name). Each function would have its own scriptFile property which could be anywhere, and the definitions are all in one place. It seems like a neat solution.

[beyerleinf]

For TypeScript projects, Decorators could be a good option. That would make it more similar to .NET

[anthonychu]

As @jeffhollan mentioned, we're investigating newer programming models. There's some foundational work on the core runtime and language workers that are needed before we can enable these scenarios. Depending on other priorities, we're hoping to make some progress in the second half of this year.