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 Azure/Azure-Functions#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.

[Krucial92]

Any update on progress with this @anthonychu @jeffhollan?

[derekg52]

I could use this feature also to help organize multi-function projects, any word @anthonychu ?

[cr1tterp0wer]

Not supporting this is frankly ridiculous.

agree.

[csandman]

@cr1tterp0wer Based on what standards and good practices? Most serverless tools I've used have allowed for nested directories based on endpoint type.

[cr1tterp0wer]

@cr1tterp0wer Based on what standards and good practices? Most serverless tools I've used have allowed for nested directories based on endpoint type.
^I read grammar wrong.
exactly.

[dpr-dev]

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.

@anthonychu, do you have any updates ? It's already 2022...

[vkarampinis]

@anthonychu do you have any updates?

[anthonychu]

The teams are working on new programming models for Python and Node.js. @ejizba @vrdmr @stefanushinardi

[ejizba]

Here's the issue to track the new Node.js programming model: Azure/azure-functions-nodejs-worker#480

We've made some progress on prototypes, and we'd welcome any feedback y'all have

[Krucial92]

@ejizba @anthonychu do we have any ETA of when this feature will be available? Or how far off is this newer programming model from completion? I appreciate that this is being worked on, however this issue was opened almost 3 and a half years ago.

[ejizba]

Hi, we recently created a roadmap that you can use to track dates for Node.js features. We will try to keep it as up to date as possible. See here: https://github.com/Azure/azure-functions-nodejs-worker/wiki/Roadmap

A few other notes:

• For practical purposes, there is no difference between "this feature" and "the new programming model". They are directly tied together and unfortunately you cannot get one before the other.
• For people using other languages, I can say Python will probably be first, Node.js second, and other languages to follow. That's about the extent of my knowledge for other languages
• I agree 3.5 years is a long time. Personally I was not on this particular team that whole time so I don't know why it was not prioritized before, but it is a top priority now

[Krucial92]

Thank-you for the update @ejizba, and the roadmap is helpful to get an idea of estimated timelines 🙏

[andrewtuplin]

@ejizba I see the tracker for Node, but I'm not seeing a way to get updates around the Python effort. Are there any updates specific to Python?

[ejizba]

The Python team just created a roadmap, here it is: https://github.com/Azure/azure-functions-python-worker/wiki/Roadmap

In addition, they actually already announced public preview of their new programming model. Here are docs for trying it out: https://github.com/Azure/azure-functions-python-worker/wiki/V2-Programming-Model-for-Azure-Functions-using-Python

[ejizba]

We just announced public preview of the new Node.js programming model! 🎉 Try it out and let us know what you think:
https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-functions-version-4-of-the-node-js-programming-model-is-in/ba-p/3773541

This GitHub issue was one of the main motivators for this effort, so thank you for all the upvotes and comments (even if it took a lot longer than everyone wanted). While the new model has many benefits, you might notice "Flexible folder structure" is listed first in the blog post.

[ejizba]

The Python team GA'ed their new programming model in May and for Node.js we just GA'ed the new programming model today 🥳

• Python GA blog post here
• Node.js GA blog post here

I think that's enough to close this issue. Other languages are also working on new programming models, although I don't know when they would happen. I would suggest tracking further progress in the language-specific GitHub repo, for example this is PowerShell's repo: https://github.com/Azure/azure-functions-powershell-worker/issues

[ryancole]

The Python team GA'ed their new programming model in May and for Node.js we just GA'ed the new programming model today 🥳

• Python GA blog post here

• Node.js GA blog post here

I think that's enough to close this issue. Other languages are also working on new programming models, although I don't know when they would happen. I would suggest tracking further progress in the language-specific GitHub repo, for example this is PowerShell's repo: https://github.com/Azure/azure-functions-powershell-worker/issues

Wow where did 5 years go by so fast? Thanks!

[iamdanthedev]

I've just updated my Core Tools to the recent version and now nested functions get discovered correctly. I am using the "dotnet-isolated" model